| 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 |
| Priority: | Major | Regression? | |
| Status: | Closed/Complete | Components: | Applications/app_queue |
| Versions: | 1.8.20.1 | Frequency of Occurrence | Constant |
| Related Issues: | |||
| 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: {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} 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 | ||