Summary:ASTERISK-21146: Semi attended (blonde) transfer causes queue member not to respect wrapuptime
Reporter:Eelco Brolman (eelcob)Labels:
Date Opened:2013-02-21 12:13:57.000-0600Date Closed:2013-03-15 15:05:34
Versions: Frequency of
Environment:Attachments:( 0) semi_attended_transfer_queue_member_status.patch
Description:h2. Situation

Considering the following situation:

* 1 queue Q (900) with a wrapuptime of 30 seconds
* 1 member M (Local/800@from-internal)
* a local phone 700
* queue members can do a *2 DTMF for atxfer

h2. Call sequence

* Call A to queue 900
* M is called and answers
* Call B to queue 900 (so we have a waiting call)
* M presses *2, dials 700# (M wants to transfer the call to 700)
* 700 is ringing, but DOES NOT answer
* M hangs up, making the atxfer a semi blindxfer (if that is a word)

h3. Expected

At this points, I expect M to get another call after 30 seconds (wrap up time).

h3. Problem

BUT: M gets the new call B immediately.

h2. Analyse

This is due to the fact that when M hangs up while 700 is still in ringing state, no channel masquerade is done, since there is nothing to masquerade yet. app_queue does not get notified at this point yet, but DOES get notified that a channel (in this case Local/800) has changed the state to AST_DEVICE_NOTINUSE. So it makes the agent available, and he get a new call immediate.

h2. Fix

I have attached a patch, which hooks to the device-state notification code, and sets the member->lastcall timestamp to "now" in the case the device was previously in the AST_DEVICE_INUSE state.

This fixes the wrapuptime issues, but does not take care of the queue_log entry and the QueuememberState event which occur late (i.e. when 700 really answers the call and a masquerade can be done).

Comments:By: Richard Mudgett (rmudgett) 2013-02-21 14:07:08.607-0600

You might want to investigate this compile option in main/features.c:

* Party A - transferee
* Party B - transferer
* Party C - target of transfer
* DTMF attended transfer works within the channel bridge.
* Unfortunately, when either party A or B in the channel bridge
* hangs up, that channel is not completely hung up until the
* transfer completes.  This is a real problem depending upon
* the channel technology involved.
* For chan_dahdi, the channel is crippled until the hangup is
* complete.  Either the channel is not useable (analog) or the
* protocol disconnect messages are held up (PRI/BRI/SS7) and
* the media is not released.
* For chan_sip, a call limit of one is going to block that
* endpoint from any further calls until the hangup is complete.
* For party A this is a minor problem.  The party A channel
* will only be in this condition while party B is dialing and
* when party B and C are conferring.  The conversation between
* party B and C is expected to be a short one.  Party B is
* either asking a question of party C or announcing party A.
* Also party A does not have much incentive to hangup at this
* point.
* For party B this can be a major problem during a blonde
* transfer.  (A blonde transfer is our term for an attended
* transfer that is converted into a blind transfer. :))  Party
* B could be the operator.  When party B hangs up, he assumes
* that he is out of the original call entirely.  The party B
* channel will be in this condition while party C is ringing,
* while attempting to recall party B, and while waiting between
* call attempts.
* The ATXFER_NULL_TECH conditional is a hack to fix the
* problem.  It will replace the party B channel technology with
* a NULL channel driver.  The consequences of this code is that
* the 'h' extension will not be able to access any channel
* technology specific information like SIP statistics for the
* call.
* Uncomment the ATXFER_NULL_TECH define below to replace the
* party B channel technology in the channel bridge to complete
* hanging up the channel technology.
//#define ATXFER_NULL_TECH 1

By: Eelco Brolman (eelcob) 2013-02-21 14:30:31.227-0600

I'll try the switch tomorrow and let you know if this *could* fix the problem. We use SIP only most of the time, but I'll have to investigate how much other dialplan code will be broken, since we have a lot of dialplan which depend on the 'h' extension...

By: Rusty Newton (rnewton) 2013-02-27 09:18:54.921-0600

Let us know whether the compile time option works for this issue.

By: Matt Jordan (mjordan) 2013-03-15 15:05:28.870-0500

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.  Further information can be found at http://www.asterisk.org/developers/bug-guidelines