Summary:ASTERISK-14951: AMI redirect of caller channel while being answered by queue agent causes caller disconnect
Reporter:Jay Reeder (escape2mtns)Labels:
Date Opened:2009-10-06 21:08:44Date Closed:2011-07-26 14:26:08
Versions:Frequency of
Environment:Attachments:( 0) 2266.txt
( 1) 3129.txt
Description:We're using the AMI to allow queue agents to sometimes cherry-pick important calls from queue.  If a redirect command is issued on a channel just as it is being answered by an Agent, the caller is disconnected.


This is a timing issue so there's not much I can provide along the lines of test scenarios.  I'm hoping it's something obvious that can be checked for during the AMI redirect request.  

Comments:By: Jay Reeder (escape2mtns) 2009-10-07 14:36:14

I've attached a couple Asterisk traces for this issue.

Call #1 - 2266:
   1) Called DID and call went into queue 600
   2) SIP/110 tried to pick up around line 53.
   3) While the announcement was playing to SIP/110, operator attempted to pluck the call to SIP/2014 and app_queue complains that the call is gone when it tries to bridge.
   4) The call goes through some of the FreePBX stuff that tries to call 2014 but dies before SIP/114 rings.  (Packet sniffing confirms no attempt to INVITE the phone.)

To rule out the FreePBX macros and AGIs we removed the extensions_additional entry and added a simple Dial(SIP/114) command.

Call #2 - 3129:
   1) Called the same DID and queue.
   2) SIP/107 tried to pick up around line 54.
   3) Same behavior on the call pluck where app_queue loses the call while the agent announcement was playing.
   4) The call actually gets to line 58 where the dial command executes and a packet capture confirms an INVITE goes to the phone.
   5) At this point the call immediately disconnects.  It's only clear that Asterisk is sending SIP/114 a CANCEL, not why...

The 'call plucking' is done with an AMI redirect command and works for both calls in queue that aren't being answered and also for calls already connected.  The only time this happens is when we try to redirect the call while the agent is answering that call (during the announcement I guess).

If the AMI could even ignore the redirect command if it would cause the caller to be disconnected, that would be preferable to the current situation.

By: Jay Reeder (escape2mtns) 2009-12-11 15:42:13.000-0600

A similar issue is that if a call is in queue and we try to redirect that call to someone who is not a member of that queue then the call is disconnected.  Redirection occurs with an AMI command as described above.

By: Jay Reeder (escape2mtns) 2010-01-29 08:54:48.000-0600

This ticket (https://issues.asterisk.org/view.php?id=16566) seems similar and reports that the issue has been fixed in trunk.  Would that mean that our issue might be fixed as well?  Could it be a similar issue in another section of code?

By: Leif Madsen (lmadsen) 2011-07-26 14:26:02.876-0500

Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions

If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks!