[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-03-2008 09:03 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.
====================================================================== 

---------------------------------------------------------------------- 
 jozza - 02-03-08 09:03  
---------------------------------------------------------------------- 
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 at from-internal/n ->
Local/105 at 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 at from-internal). I can only save Local/104 at 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 SIP/106?

I'm sorry if i seem a real drag.

J. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
02-03-08 09:03  jozza          Note Added: 0081619                          
======================================================================