Summary:	ASTERISK-11226: AMI bug - call track lost - when using queues
Reporter:	Joze Zivic (jozza)	Labels:
Date Opened:	2008-01-13 05:43:31.000-0600	Date Closed:	2008-02-06 14:10:20.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 106-Events_01_02_2008.zip ( 1) 11757-1.4.patch ( 2) ami_log.txt
Description:	Hello, The track of call is lost when using queues. Sample: incoming call on capi line with uniqueId 1200051030.8283 joins queue. After it joins queue, there is no way to know what happened to the call with this uniqueId until trunk hangs up. The track of this call is lost as no message specifies the bridge connection with source UniqueId which is capi and destination which is a queued call  local/105 Can anyone confirm this or maybe suggest a workaround? Attached is a text file with this call scenario in AMI events.
Comments:	By: Joze Zivic (jozza) 2008-01-13 14:51:53.000-0600 This is probably more of a core problem, not app_queue application By: Mark Michelson (mmichelson) 2008-01-14 11:59:45.000-0600 What you want is already provided via the eventwhencalled option in queues.conf. Setting this option to yes will cause app_queue to generate manager events whenever a queue member is called. One of these is the "AgentConnect" event which has the information you want. I am going to close this since changing this configuration setting is all that is necessary to fix the problem. By: Joze Zivic (jozza) 2008-02-01 14:02:26.000-0600 I am still unable to track calls properly, even when events for app_queue are enabled. There is no proper way to know which incoming line is ringing at the specified agent phone. The AgentCalled event shows parameter AgentCalled with insufficient information to track the call: Event: AgentCalled Privilege: agent,all AgentCalled: Local/105@from-internal/n //there is no unique id for the above Local/105 channel, instead it shows "/n" AgentName: Local/105@from-internal/n ChannelCalling: CAPI/ISDN5#02/4205908-1c9 CallerID: 0017291094 CallerIDName: BIG BANG: 0017291094 Context: ext-queues Extension: 201 Priority: 18 I will attach a log of ami events. Please tell me if you can track the call on incoming misdn line with unique id 1201852948.2513 and is answered by sip/106 It is impossible to know when sip/106 rings, which external line was offered to it. And you will see my mixup with a also active line at that moment which is CAPI/ISDN3#02/4205906-1c6 with unique Id 1201852856.2489 You should see the log in 106-Events_01_02_2008.zip Thanks, J. By: Joze Zivic (jozza) 2008-02-03 09:03:02.000-0600 Ok, this is really hard. I've managed to keep track of call 1201852948.2513, but i am unsure if this behaviour will stand: 1. I always create new call (my track) on Join event when 1201852948.2513 joins queue 2. I always assign last agent called tag to 1201852948.2513 when AgentCalled Event comes, to a value of AgentCalled parameter with stripped "/n" (i.e. AgentCalled Local/105@from-internal/n -> Local/105@from-internal) 3. When i see a message Dial with src channel Local, assigned to one of the saved local calls (in this case 1201852948.2513 has assigned Local/105 from point 2.) and dst channel also Local, i change the agentcalled tag for 1201852948.2513 from Local/105 to the new local call (i.e Local/104) with stripped unique channel id (i.e. Local/1064from-internal-XXXX to Local/104@from-internal). I can only save Local/104@from-internal because AgentCalled event does not have the unique channel id in its AgentCalled parameter. 4. This changing from points 2. to 3. could go on and on until the call is actualy answered at some destination channel (in this case SIP/106) (i decide that call is answered when i see the Link message with one of my saved tags (i.e. Local/106) for 1201852948.2513). 5. But my call 1201852948.2513 still has Local/106... tag saved as last agent call. 6. So i delete this tag (my last attempt that seems to work) from 1201852948.2513 call when i see the Link message of  Local/106..., because some other previous call that is still active, for example  could have the same last tag (Local/106) still saved (1201852856.2489 ), and thats where the mixup could occur as i iterate through my list of calls to find the call(1201852948.2513) with last saved tag of Local/106 (for which i can only presume is the correct call from the information ami offers me) I didnt test the events to all possibilities, but i need to be sure that new AgentCalled message for i.e. Local/106 will never be assigned to any different line until the previous one has hungup or linked the call to the destination channel and also that Local/106 will never be called (Dial message) before AgentCalled message is received which would update the original line i.e. 1201852948.2513 to a new Local/XXX channel. Can you confirm that it is the only way to know that 1201852948.2513 is ringing at eventualy connected at SIP/106? I'm sorry if i seem a real drag. J. By: Mark Michelson (mmichelson) 2008-02-04 11:09:15.000-0600 With regards to the concerns about the AgentCalled event not having a UniqueId present, I agree that it should be there. What you are experiencing here is the "fun" that Local channels bring as well as the additional "super fun" that Local channels with the /n on the end bring. I was able to successfully trace the call you described, but it required a lot of tracing through the logs and knowledge about how Local channels work. Your plan for tracing the flow of all the local channels seems like it should be all right, but there is actually a simpler way to figure it out. Look at the AgentConnect event and see the name of the local channel that it connected to. It should end with ",1". Search for the Link event where the local channel with the same name, except with a ",2" at the end, is in the "Channel1" field. If Channel2 is another Local channel, it will once again have a name with ",1" at the end. Search again for the Link event with the new Local channel's name, except with a ",2" at the end as the "Channel1" field. Eventually you'll be able to repeat this process until "Channel2" is an actual SIP channel. Another potential plan for your situation would be to leave the "/n" off the end of your queue member definitions if possible. By doing that, the Local channel will actually be aliased with the identity of the final channel so that the AgentConnect event will actually specify the SIP channel involved instead of the first Local channel in the chain of Local channel calls. By: Joze Zivic (jozza) 2008-02-04 11:56:07.000-0600 Thanks for your reply. I need to know what the incoming line is when the phone rings, because a user program needs this info a that point, so agentconnect event is too late. I wouldnt have gone so deeply and track the calls otherwise. Fortunately, i'm an expert on csta protocol and it was not that hard to unravel the call flow. It might even be possible to write csta module that would extend ami. I see in the logs that before AgentCalled event, there are always two messages with a Local channel created. Then Agentcalled message has that channel specified without unique id in its agentcalled parameter. If that is fixed, then there should be no problem tracking calls in queue anymore. Will you provide a patch? J. By: Mark Michelson (mmichelson) 2008-02-06 13:07:02.000-0600 I will provide a patch that improves the AgentCalled event to include the "AgentChannel" and the "UniqueID" paramaters. The "AgentChannel" will actually be the channel name (including the unique suffix) as opposed to the interface called. The "UniqueID" will be the UniqueID of the calling channel as it appears in other manager events. I will have it uploaded shortly. By: Joze Zivic (jozza) 2008-02-06 13:27:22.000-0600 Ok great, thanks. By: Mark Michelson (mmichelson) 2008-02-06 14:04:52.000-0600 I have uploaded 11757-1.4.patch. This adds the Agent's channel (I called it DestinationChannel since the trunk version of app_queue has the channel in this event and calls it that) and the Uniqueid of the calling channel to the AgentCalled event. Now, unfortunately, I will not be able to actually merge this patch into the 1.4 branch due to the fact that it is adding new functionality and is not directly fixing a bug. I will, however merge the patch into trunk. Thanks for the bug report and thanks for following up on it! By: Mark Michelson (mmichelson) 2008-02-06 14:10:19.000-0600 Trunk now has the Uniqueid for the AgentCalled event as of revision 102777.