|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-0600||Date Closed:||2013-03-15 15:05:34|
|Environment:||Attachments:||( 0) semi_attended_transfer_queue_member_status.patch|
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)
At this points, I expect M to get another call after 30 seconds (wrap up time).
BUT: M gets the new call B immediately.
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.
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
* 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
* 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