Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - dionv

Pages: [1] 2
1
Improving QueueMetrics / Ajaxify realtime page?
« on: July 23, 2009, 14:41:23 »
Currently the realtime monitoring page must refresh itself in order to "maintain session information", and to get updated queue data.

This generates constant network traffic, and affects the CPU usage of the machine it is running on.

It would be nice if the realtime monitor was modernized a bit to take advantage of newer web technologies.

DionV

2
Super cool man! ;-) this will be linked straight from the FAQs.

We'll add a check for the weird /img behaviour.... it will be more likely ../img, meaning "the folder img in the partent directory".





Ah, yes, my typo in creating the message. It was late. I double-checked the source page of the rendered page in my browser:

Code: [Select]
<tr class='ST_TR0'>
  <td class='stData' style='width: 250;'> John Smith </td>
  <td class='stData' style='width: 90;'>1</td>

  <td class='stData' style='width: 50;' align='right'> 5.6% </td>
 <td class='stData' style='width: 200;'><img src='../img/shade-histo.gif' height='10' width='200.0'></td>
</tr>

It is, indeed, "../img/"

DionV

3
Hello,

  I need to automatically generate custom report and also general report (via crontab ?), convert them in pdf and send them by email.
I had a look on the forum and also in the documentation but found nothing ...
Any idea ?

Best regards,

Didier Chabanol
http://www.ives.fr

Took some digging around, but looks like one way that could work is with the htmldoc package, which is generally available through most linux distributions.

With it, you could do something like:

Code: [Select]
wget -O - -p "http://yourserver.com:8080/queuemetrics/qm_rep.do?user=robot&pass=robotpass&queues=q1&period=t1" | htmldoc --webpage --size 11x8.5in -f report.pdf -

Note the dash (-) after the -O (that's O like Oscar, not 0 like zero), and the ending dash by itself, these are required to work properly. The first one tells wget to send its output to stdout, the final one tells htmldoc to read from stdin.

Since the report pages are kind of wide, I used htmldoc's "size" option to set the output to US letter landscape mode.

You could write the command as two separate steps if you wanted:

Code: [Select]
wget -nH -k -K -E -O myreport.html -p "http://yourserver.com:8080/queuemetrics/qm_rep.do?user=robot&pass=robotpass&queues=q1&period=t1"
htmldoc --webpage --size 11x8.5in -f report.pdf report.html

This one should show most of the images (so if you have a company logo in QM, it will still be there in the report), except the bar graph images. For some reason the robot user's reports do not show the bar graphs for me. (The source code of the rendered page has the bar graph image trying to be called from "/img" instead of "/queuemetrics/img" for some reason.)

To send the report as an attachment from the command line (or from within a script), you may want to install mutt or nail (yes, with an 'n'). In my testing, nail seems to work a little better, but I haven't spent much time on it at this point.

Something like this seems to work well, putting it all together:

Code: [Select]
wget -nH -k -K -E -O myreport.html -p "http://myserver.com:8080/queuemetrics/qm_rep.do?user=robot&pass=robotpass&queues=q1&period=t1"
htmldoc --webpage --size 11x8.5in -f myreport.pdf myreport.html
echo "Your daily report is attached as a PDF" | env MAILRC=/dev/null from=qm-server@example.com smtp=mail.example.com nail -n -s "Daily Report" -a myreport.pdf user@privatelabelcc.com

I hope this helps!

DionV

4
Thought I'd share this, as it may help someone else out.

If you need to broadcast a custom callerid when dialling out, the stock extensions_queuemetrics.conf will not work (in my testing, at least).

Let's say your main number is 615-555-1212, and you have rollover lines of 615-555-1213 and 519-615-1214. Dialling out will pick one of those rollover lines and broadcast that number as the callerid. Someone calling back on that number gets a busy signal or dumped into the wrong area of your phone tree. It all depends on how your system is setup. Plus it confuses them when they see 615-555-1214 on their call display, as they do not know your company by that number. Or, you are running a multi-project contact centre and need to show a specific callback number for each client.

If you use the "outbound callerid" setting in the trunk to set your callerid to 615-555-1212, then all outbound calls will appear in QM as being from Agent/6155551212, which will make it difficult to track who actually made the call.

I was not able to find the right variable in Asterisk 1.2 (we use Trixbox CE 2.2) that would help with this, so I ended up creating a hack to handle a couple of things. First the [queuedial] section:

Quote
[queuedial]
; this piece of dialplan is just a calling hook into the [qm-queuedial] context that actually does the
; outbound dialing - replace as needed - just fill in the same variables.
exten => _XXX.,1,NoOp( "Entering queuedial context..." )
exten => _XXX.,n,Set(QDIALER_QUEUE=${EXTEN:0:3})
exten => _XXX.,n,Set(QDIALER_NUMBER=${EXTEN:3})
; Let's get the agent's extension now, before we lose it
exten => _XXX.,n,Set(QDIALER_AGENT=${CALLERID(num)})
; Note, the QueueName is prefixed with "outq", you can choose your own, of course
exten => _XXX.,n,Set(QueueName=outq${QDIALER_QUEUE})
; This is one long line for debugging, you can comment it out if you want
exten => _XXX.,n,NoOp( "Outbound call -> Agent:${QDIALER_AGENT} NumberToCall:${QDIALER_NUMBER} QueueNumber:${QDIALER_QUEUE} QueueName:${QueueName} Ch:${QDIALER_CHANNEL}" )
; Note, we're creating a filename like: outq123-20090322-145523-123456789.1234.WAV
exten => _XXX.,n,MixMonitor(${QueueName}-${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)}-${UNIQUEID}.WAV|b|)
; The following calls a Gosub based on the QueueName to set callerid and outbound channel
exten => _XXX.,n,NoOp( "Gosub setcid-${QueueName} next..." )
exten => _XXX.,n,Gosub(setcid-${QueueName})
exten => _XXX.,n,NoOp( "Returning from setting callerid..." )
; Now we call qm-queuedial
exten => _XXX.,n(call-qm-queuedial),NoOp( "Going to call qm-queuedial..." )
exten => _XXX.,n,Goto(qm-queuedial,s,1)
exten => _XXX.,n,Congestion


; Set the outbound CALLERID, based on the project code used
; 102 = Project Alpha
exten => _XXX.,n(setcid-outq102),Set(CALLERID(all)=Project Alpha <8665551212>)
; Note, this trunk uses a "6" prefix for dialling out, we set it here...
exten => _XXX.,n,Set(QDIALER_CHANNEL=IAX2/alphatrunk/6${QDIALER_NUMBER})
exten => _XXX.,n,NoOp( "Callerid set to: ${CALLERID(all) using channel: $QDIALER_CHANNEL" )
exten => _XXX.,n,Return
; 104 = Project Beta
exten => _XXX.,n(setcid-outq104),Set(CALLERID(all)=Beta Support <8665551234>)
exten => _XXX.,n,Set(QDIALER_CHANNEL=SIP/mysiptrunk/${QDIALER_NUMBER})
exten => _XXX.,n,NoOp( "Callerid set to: ${CALLERID(all) using channel: $QDIALER_CHANNEL" )
exten => _XXX.,n,Return
; 999 = Main line
exten => _XXX.,n(setcid-outq999),Set(CALLERID(all)=My Company <6155551212>)
exten => _XXX.,n,Set(QDIALER_CHANNEL=SIP/mysiptrunk/${QDIALER_NUMBER})
exten => _XXX.,n,NoOp( "Callerid set to: ${CALLERID(all) using channel: $QDIALER_CHANNEL" )
exten => _XXX.,n,Return

And then in the [qm-queuedial] we adjust for Asterisk 1.2 by calling the queueDial.agi script:

Quote
[qm-queuedial]
; We use a global variable to pass values back from the answer-detect macro.
; STATUS = U unanswered
;        = A answered    (plus CAUSECOMPLETE=C when callee hung up)
; The 'g' dial parameter must be used in order to track callee disconnecting.
; Note that we'll be using the 'h' hook in any case to do the logging when channels go down.
; We set the CDR(accountcode) for live monitoring by QM.
;
exten => s,1,NoOp( "Entering qm-queuedial. Outbound call info -> A:${QDIALER_AGENT} N:${QDIALER_NUMBER} Q:${QDIALER_QUEUE} Ch:${QDIALER_CHANNEL}" )
exten => s,n,Set(CDR(accountcode)=QDIALAGI)
exten => s,n,Set(ST=${EPOCH})
exten => s,n,Set(GM=QDV-${QDIALER_AGENT})
exten => s,n,Set(GLOBAL(${GM})=U)
exten => s,n,Set(GLOBAL(${GM}ans)=0)
; Note that we pass QueueName to queueDial.agi, instead of QDIALER_QUEUE
exten => s,n,DeadAGI(queueDial.agi|${QDIALER_NUMBER}|${QDIALER_CHANNEL}|${QueueName}|Local/${QDIALER_AGENT})
exten => s,n,Set(CAUSECOMPLETE=${IF($["${DIALSTATUS}" = "ANSWER"]?C)})

; Note sure if this section is still needed/used since we are using queueDial.agi, but it doesn't seem to hurt anything
; Trapping call termination here
exten => h,1,NoOp( "qm-queuedial Call exiting: status ${GLOBAL(${GM})} answered at: ${GLOBAL(${GM}ans)} DIAL_STATUS: ${DIALSTATUS}"  )
exten => h,n,Goto(case-${GLOBAL(${GM})})
exten => h,n,Hangup()

; Call unanswered
exten => h,n(case-U),Set(WT=$[${EPOCH} - ${ST}])
exten => h,n,NoOp( "qm-queuedial UNanswered case flow" )
exten => h,n,Macro(queuelog,${EPOCH},${UNIQUEID},${QDIALER_QUEUE},${QDIALER_AGENT},ABANDON,1,1,${WT})
exten => h,n,Hangup()

; call answered: agent/callee hung
exten => h,n(case-A)i,Set(COMPLETE=${IF($["${CAUSECOMPLETE}" = "C"]?COMPLETECALLER:COMPLETEAGENT)})
exten => h,n,NoOp( "qm-queuedial answered case flow" )
exten => h,n,Set(WT=$[${GLOBAL(${GM}ans)} - ${ST}])
exten => h,n,Set(CT=$[${EPOCH} - ${GLOBAL(${GM}ans)}])
exten => h,n,Macro(queuelog,${EPOCH},${UNIQUEID},${QDIALER_QUEUE},${QDIALER_AGENT},${COMPLETE},${WT},${CT})
exten => h,n,Hangup()

I'm sure there is a more elegant way to do this, but it does not seem easily possible with Asterisk 1.2.

Now, outbound calls will appear in QM with the proper information to let you know which person made the call.

Hopefully this will help someone.

Comments/feedback welcomed.

DionV

5
While testing QM 1.4.3 again on a new server, we've noticed that if something happens to a call, the closing entry is not written to the queue_log, resulting in calls that are still listed as ongoing even days later. If we run a report and look at the details of the call, we can get the uniqueid of the call. Using that we can grep the call from queue_log. We can see the call enter the queue, we can see the agent take the call, but then no entry to show that the call ended.

By doing a CDR report, we can extrapolate the call details, but are not quite sure how we could fix the queue_log to show that the call has finished.

It *looks* like we could simply create an echo command on the command line to write the closing entry to queue_log, but attempting to do so with one call now makes it look like a multi-stint call, with on stint still ongoing, and the other stint completed.

For example, the queue_log showed (with the phone number blanked for privacy):

Code: [Select]
1200493315|1200493245.610463|10301|NONE|ENTERQUEUE||519xxxxxxx
1200493330|1200493245.610463|10301|Local/3012@from-internal-8a42,1|CONNECT|15

In the CDR, this call lasted about 284 seconds, so calculating the EPOCH it looks like we should be able to write:

Code: [Select]
echo "1200493614|1200493245.610463|10301|Local/3012@from-internal-8a42,1|COMPLETECALLER|15|284|1" >> queue_log

But this does not fix the reported time of the call. It still shows as being a 5 hour call.

Any suggestions on how we could properly fix these entries?

TIA

DionV

6
Trixbox 2.2 with Asterisk 1.2.20

7
Improving QueueMetrics / Re: More flexible reporting
« on: October 10, 2007, 05:36:46 »
1. How would you imagine the report by call number? would an additional filter be okay as well?

Yes, an additional filter would work. Having the ability to filter by queue and/or agent and/or callerid_number would be helpful. The search options in the CDR program used by trixbox 2.2 show some of this additional flexibility.

For example, search for all calls in q1 that went to agent/user 1001
Or, search for all calls that came from 7245551212 today


Quote
2. This is planned.

OK


Quote
3. You already get that as an average on the Agent screen. Do you find that unpractical/unusable?

Ah, might have missed that as we do not have our users configured as Agents due to an issue with the CDR system at this point. The Agents screen contains no data for us.


DionV

8
Hi
I have replaced the name with the number, but this change had no effect.  The AGI script still does not terminate properly when the remote side hangs up.  The PSTN number that I dial is correct, I just deleted the first part for anonymity.


Although this is an older thread, I am experiencing a similar issue. I followed the tutorial for setting up the outbound "queue", and it seems to track the beginning of the call just fine, but not the end. Doesn't really seem to matter who hangs up first in my case.

I am using an IAX2 trunk for mine. My dialplan for this is as follows:
Code: [Select]
[queuedial]
exten => _XXX.,1,SetVar(MY_QUE=${EXTEN:0:3})
exten => _XXX.,2,SetVar(MY_NUM=${EXTEN:3})
exten => _XXX.,3,SetVar(MY_AGENT=${CALLERIDNUM})
exten => _XXX.,4,NoOp,Ag: ${MY_AGENT} N: ${MY_NUM} Q: ${MY_QUE}
exten => _XXX.,5,MixMonitor(Q-${MY_QUE}-${UNIQUEID}.wav|b|)
exten => _XXX.,6,DeadAGI(queueDial.agi|${MY_NUM}|IAX2/iax2trunk/${MY_NUM}|q-${MY_QUE}|Local/${MY_AGENT}@from-internal)
exten => _XXX.,7,Congestion

You may also note that I am tracking "Local/${MY_AGENT}@from-internal". This is because "agents" seem to disappear from our CDR, and we currently bill out based on CDR info.

As described by AngeloA, the end of the call does not seem to get logged. I'd rather not hack my main hangup script, especially on a production server. Could something similar be placed in the above dialplan? Or is there something in the queueDial.agi script I should look for?

Thanks!

DionV

9
Improving QueueMetrics / More flexible reporting
« on: September 26, 2007, 04:08:52 »
It would be nice to have more flexible reporting, for example:

1) Reports based on the telephone number that called us. Sometimes a caller will complain they have been on hold for a certain period of time. With the CDR, we can just do a search for their phone number and find out if that is the case. With QM, it does not appear we have that option.

2) When we do billing, we ignore any calls less than 30 seconds, as these are generally hang-ups/drops/disconnects/etc. QM does not seem to give us the ability to create a report that ignores those calls.

3) Add the option or ability to have the call times in each section. For example, in the "Agents on queue" section, in addition to name, number of calls, and the percentage, it would be nice to see the total talk time for that agent for those calls. It's great to see that over the last 24 hours Agent1 took 75 calls, and Agent2 took 64 calls, but if I see that Agent1's talk time is only 100 minutes, versus Agent2's 225 minutes, and I know the calls should last at least 2 minutes, I'm going to look more closely at the disparity between Agent1's call numbers and talk time.

Thanks for the great work so far!

DionV

10
Yes, thank you. Appears to work like a charm. One just has to remember to add those visibility keys to regular users who will need to access those queues (like the Administrator ;) )

DionV

11
Ah ha! I see now. I was almost there. I had to protect *all* the queues with a visibility key first.

Thank you!

DionV

12
The approach I've chosen is to have agents log on and off using the AgentCallbackLogin application.  Then in each queue I want a particular agent to receive calls from, I define them as a static agent using their agent number - e.g "Agent/101"  This allows one login code to log an agent in to multiple queues.  I use the following dialplan fragment in the [from-internal-custom] context in extensions_custom.conf to allow users to log in and out...

Code: [Select]
exten => _25XXX,1,Answer()
exten => _25XXX,n,AgentCallbackLogin(${EXTEN:2}||${CALLERID(num)}@from-internal)
exten => _25XXX,n,Hangup()

exten => _35XXX,1,Answer()
exten => _35XXX,n,AgentCallbackLogin(${EXTEN:2}||#)
exten => _35XXX,n,Hangup()

(to clarify - agents dial 25 or 35 before their agent number to log in our out respectively)

I should make mention though that Digium have deprecated the AgentCallbackLogin application and plan to remove it in some future version of Asterisk (despite the fact that there is no easy alternative!)

Hmm. I'll try that variation. All our agents are using softphones, so their Agent id and extension are always the same. I'm trying to work out the code for an extension they can dial that will read their CALLERID and use that to log them in and log them out when they dial appropriate extension.

I did read about the deprecation of AgentCallbackLogin. :(

DionV

13
I would like to provide each of our clients with their own login to the QueueMetrics system so they can: 1) Get reports on their project(s) (critical), and 2) See their queues status (bonus feature)

Our billing is based around minutes and SLA levels, so they want to be able to login through the month to see how their project is doing, and run historical reports.

It looks like the VISITOR key only allows for realtime queue monitoring, but not reporting. Am I missing something?

Is there some way I can create an individual login for each client that limits them to their queue(s) only, allows them to see their stats, but does not allow them to see anything else, or modify anything?

Thanks.

DionV

14
Would setting the queue's "Announcement (sec.)" field to "10 " remove these calls? Or am I misunderstanding the purpose of that field? Not sure how it would affect the SLA report (I'm new to this myself, and still trying to figure things out).

DionV

15
So, create extensions as per normal through FreePBX, plus add each agent's extension to the agents.conf file?

Our live system currently has each agent's extension statically listed in each queue they monitor. This causes delays as the system tries to ring each extension, even though some of those people are not logged in.

We were hoping to switch to having the agents login to the queues when they start their shift, and logout when they are done. It looks like the suggested method is still to have them dial the queue, for example 10101* based on my previous example, and login.

But, the extensions modifications mentioned by QM suggest using a slightly different method, which appears to require the agent enter their id , then their extension (which in our setup are one and the same, based on the FreePBX settings in TB2).

I don't quite understand the difference between the different methods listed in the QM manual and the QM + TB 2 tutorial. Are they simply alternatives with the same end result? Are they mutually exclusive? (Use one or the other, but not both?)

Right now with very few queues, it is not an issue if they have to manually dial each queue they are assigned to, but in the future, it could get quite cumbersome. Any suggestions on other methods for having agents log into and out of queues?

Thanks,

DionV

Pages: [1] 2