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 - supertle

Pages: [1]
1
See my other thread about dynamic members and local context channels which is working good but I am noticing the following for a SINGLE call:

gnsc*CLI> show g729
0/2 encoders/decoders of 100 licensed channels are currently in use

gnsc*CLI> show channels
Channel              Location             State   Application(Data)
SIP/1104-0117c530    (None)               Up      Bridged Call(Local/2301@Xerox2
Local/2301@Xerox2-0a 2301@Xerox2:3        Up      Dial(SIP/1104|10|t)
Local/2301@Xerox2-0a s@Xerox2:1           Up      Bridged Call(SIP/ARS_GW1-0118c
SIP/ARS_GW1-0118c620 6831@Xerox2-default: Up      Queue(Xerox-q6831|t|||6000000)
4 active channels
2 of 192 max active calls ( 1.04% of capacity)

Its using TWO of my g729 licenses instead of normally one if I had added SIP/1104 directly into the queue.  I am adding instead agent_id@customer_context.  In the context as previously noted in my other thread, it does a lookup to see which agents to ring.  I have a total of 100 g729 licenses.  This is going to reduce it half.  This probably is a question for the asterisk community then QM but this was the solution for dynamic agents not always sitting at the same phone extension for QM.

2
My resolution was to use Locations as a customer type.  I associate all my agents from various queues to a location.  I then select to filter out by Location in the realtime monitoring.  I also use visibility keys to give out to Supervisors user for each customer so they can see all agents associated to their "Location" (Customer)

Hope that makes sense but its working well in preventing one customer from seeing another customer's agents.  We have many customers using the system simutaneously and its a privacy issue to block them seeing each otther.

3
"Please note that – as agents are not linked to a specific queue save for the moment they are actually talking to a caller on the queue – the agent information is computed for all agents on the Asterisk server and not for specific queues, unless the “Show members only” button is pressed."
..
"If the “Show members only” button was not pressed, all agents logged in on Asterisk will be shown, no matter to which queue they belong. If you press the “Show members only” button, only agents defined for the selected queue will be displayed. "
--from the manual

I have associated my agents to my queues but I still get ALL agents being displayed after pressing this Show Members ONLY.  Its actually very temperamental.  If I click maybe around 100 times (clicking all the buttons randomly) in the RealTime Monitoring screen, it FINALLY shows ONLY THE MEMBERS belonging to that queue.  Its very imporant I display only agents selected for the queue I want on the monitoring reasoning being is we have multiple customers and multiple queues and privacy is an issue for customers to see other customers agents.

4
1218571546|1218571545.544|Xerox-q6831|NONE|ENTERQUEUE||ARS_GW1
1218571605|1218571586.153|NONE|Local/2301@Xerox2|AGENTLOGIN|-
1218571608|1218571586.153|NONE|Local/2301@Xerox2|AGENTLOGIN|-
1218571613|1218571545.544|Xerox-q6831|Local/2301@Xerox2-7b57,1|CONNECT|67
1218571695|1218571545.544|Xerox-q6831|Local/2301@Xerox2-7b57,1|COMPLETECALLER|67|82

Actually since adding that /n to my dynamic members, everything is going great how asterisk reports the calls now to the queue_log

I think this issue is fixed* but I will have tons more of questions :)

5
Nevermind, I found a fix for this

http://www.voip-info.org/wiki/view/Asterisk+local+channels

Add a /n to the local_channel@customer1/n when adding this member into a queue.  Works like a charm.

6
on a side note, using agent context dialing with the local_channel@customer1 causes some minor nuisances with the TRANSFERS. 

When you initiate a transfer, it looks in this same customer1 context for a match rather then the phone's context specified in the sip.conf file.  B/c my agentID and my extensions are the same, I am using a  temporary work around to have the agents enter a "9" if they want to transfer to an extension.  If they transfer by entering in an agent's ID, then just the 4 digit is fine however I'm having difficulties trying to figure out how to handle things such as a VM in this customer1 context. 

My customer1 context is pretty simple the way it is:

[customer1]

exten => _xxxx,1,RealTimeLookup(.....)  Find out the extension of the agent
exten => _xxxx,2,Dial(sip/xxxx)

I can't start adding things like priority 3 and sending it to VM b/c that will cause regular calls from the queue into voicemail.  Any suggestions welcomed.

7
1218557396|1218557354.172|NONE|Local/2301@Customer1|AGENTLOGIN|-
1218557399|1218557354.172|NONE|Local/2301@Customer1|AGENTLOGIN|-
1218557442|1218557442.173|Customer1-q6831|NONE|ENTERQUEUE||ARS_GW1
1218557486|1218557442.173|Customer1-q6831|SIP/1104-0087e4b0|CONNECT|44
1218557831|1218557442.173|Customer1-q6831|SIP/1104-0087e4b0|COMPLETECALLER|44|345


Here's a snippet of an agent logging into a queue.  Follow by a call into that queue.  How can I tweak what's written above of having SIP/1104 to agent/2301 as the one answering and completing the call. 

8
I tried what u suggested in:
default.useEndingChannelName=true
default.useEndingChannelName=false

and it does not make a difference with either.  In the report, it shows the agentID as the SIP/XXXX.  I need to be able to group the reports by the actual AgentID and not where the agent happenned to be sitting at the time he logged in at.  We can have many agents sitting at the same SIP/XXXX location so looking at a report grouped by phone locations does not help.

I am adding the agents in using addmemberqueue as you suggested Local/AgentID@CustomerContext. 
I have default.rewriteLocalChannels=true which is displaying the Agent ID great in the realtime monitoring but when the call is answered, it still shows the SIP/XXXX answering the call.

We have over thousands of agents that is configured like this in our database:

ABC_1001
...
ABC_1999

QST_1001
...
QST_1999

XYZ_1001
...
XYZ_1999

Each customer is assigned with a different 3 digit code.  We have many customers and these 3 digit code is how we are distinguishing agents between each customers.  Do I need to do something in the context CustomerContext to send to the queue_log to tell queuemetrics that it is this AgentXXXX@CustomerContext  answering the call and not SIP/XXXX??

9
Also, the realtime monitoring is looking good but when I run reports on the queue.  It is showing the phone extension rather then the Local/agent@context.  The reports does not show anything about these Local/Agents@context answering calls.  It shows the SIP/XXXX devices answering the call.

10
i did what you suggested and its working great.  Now I see local/AgentID@context in QM.  I think I can work with this.  It was much easier then I thought.  Now I just have to test to make sure context interface within a queue works the same way as having a "real" interface in the queue. 

One question I have is though ... I am noticing if I add the following interfaces to my queues

Local/1001@Customer1 to Queue1
Local/1001@Customer2 to Queue2

QM is recognizing this as the same Agent when in fact its two different agents.

11
This looks to be a solution.  So you are suggesting when we add a dynamic member to a queue, to use agent@context as the interface to be added in.  Will try it out and let you know.  Do you see any other alternative that would involve only tweaking with QM?  Reason is b/c we have many customers and hundreds of queues that we would have to go back and re-modify/test out to make it compatible with QM. 

12
Running QueueMetrics / Re: Queue(s) field and Srv field empty ..
« on: July 17, 2008, 23:29:02 »
My Srv gets populated as I'm using a cluster (i.e. default.queue_log_file=cluster:trix) but my Queue is empty and I'm not sure what you mean by using the AddMember logins.  I am using AddQueueMember in asterisk and I added the codes for Asterisk 1.2 to add to queue_log  when an agent logon/logoff.  Verified queue_log the entries are there.

queue_log:
1216311974|1216311964.4436|NONE|SIP/1104|AGENTLOGIN|-
1216313216|1216313181.1410|NONE|SIP/1005|AGENTLOGOFF|-|8154

Can you explain more about what AddMember logins you are referring to?  Thanks.

13
General Asterisk configuration / Dynamic Agents and Asterisk ARA
« on: July 17, 2008, 16:33:41 »
In our callcenter, we allow an agent to dynamically sit wherever they want.  So we have no idea where they are until they actually log in.  We give out a separate loginID# to each agent to use for logging in.  When they log in,  the agent enters the extension# of the phone they are sitting at and I track this in mysql database.  I then add in the extension interface they entered using ADDQUEUEMEMBER to the queue(s) they belong to as they log in.  When they logoff, I lookup interface in the database and remove that interface out of the queue.

I have a table in my Asterisk ARA database call Agents which basically has two columns

AgentID    |     Location
ABC_1001       SIP/1104
ABC_1002       SIP/1109
ABC_1003       LOGOUT
ABC_1004       LOGOUT
ABC_1005       LOGOUT

I use the RealTimeUpdate and RealTime command in my Asterisk dialplan to update these entries.  How can I associate and show the AgentIDs rather then the INTERFACE in the queues.  I have a custom web GUI that displays the AgentID and the location they are sitting at but that would not work too well if say agent ID1001 was sitting at 1104 and leaves for the day and then agentID1005 comes in at night and sits at extension SIP/1104.   

Sorry if this may have been covered in the documents somewhere but I have looked through many and not found anything.  I only found about tracking dynamic agents as they log in and logoff.  I can echo the agentID (i.e. ABC_1001) during the logon/logoff process but then later when SIP/1104 gets calls, I don't see how to connect the relationship as Asterisk does not know anything about my ABC_1001 when it writes to queue_log.  I'm running on Asterisk 1.2 (ABE-B).  Will be upgrading to 1.4 very soon.

Pages: [1]