[asterisk-bugs] [Asterisk 0011757]: AMI bug - call track lost - when using queues

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11757 
====================================================================== 
Reported By:                jozza
Assigned To:                putnopvut
====================================================================== 
Project:                    Asterisk
Issue ID:                   11757
Category:                   Applications/app_queue
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.13 
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             01-13-2008 05:43 CST
Last Modified:              02-04-2008 11:09 CST
====================================================================== 
Summary:                    AMI bug - call track lost - when using queues
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.
====================================================================== 

---------------------------------------------------------------------- 
 putnopvut - 02-04-08 11:09  
---------------------------------------------------------------------- 
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. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
02-04-08 11:09  putnopvut      Note Added: 0081667                          
======================================================================