[asterisk-bugs] [JIRA] (ASTERISK-21146) Semi attended transfer causes queue member not to respect wrapuptime

[Richard Mudgett (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-21146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=203314#comment-203314 ] 

Richard Mudgett commented on ASTERISK-21146:
--------------------------------------------

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

{noformat}
/*
 * 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.
 *
 * WARNING:
 * 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
{noformat}

                
> Semi attended transfer causes queue member not to respect wrapuptime
> --------------------------------------------------------------------
>
>                 Key: ASTERISK-21146
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21146
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_queue
>    Affects Versions: 1.8.20.1
>            Reporter: Eelco Brolman
>         Attachments: semi_attended_transfer_queue_member_status.patch
>
>
> h2. Situation
> Considering the following situation:
> * 1 queue Q (900) with a wrapuptime of 30 seconds
> * 1 member M (Local/800 at 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).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira