> On April 28, 2014, 5:14 p.m., Matt Jordan wrote: > > /branches/12/res/res_pjsip_refer.c, lines 898-906 > > <https://reviewboard.asterisk.org/r/3485/diff/1/?file=57945#file57945line898> > > > > This feels like the wrong way to solve this problem. Having a 'parked' > > variable bleed up into this handling feels like we've got a design flaw in > > how we're handling parking. > > > > refer_progress_bridge *should* be detecting that the channel entered > > into a holding bridge. That should be sending the 200 notification. If that > > isn't happening, then there is some other bug here that this solution is > > masking. > > > >
The problem here is that the stasis subscription that sets up refer_progress_bridge never gets the opportunity to get set up. refer_blind_callback() is called on the local channel that ends up running dialplan during a blind transfer. When transferring to parking, such a local channel is typically not created since the transferee channel is moved directly from its current bridge into the parking bridge. Thus all the progress-tracking code is bypassed. It was my suggestion to use a separate return value to indicate a successful transfer had occurred due to being parked (or more generically, the transfer was successful and was entirely complete). There's no bug that the solution is masking, it's just that parking bypasses the typical blind transfer process, and so it has to be taken into account. The problem is that transfers to parking require special handling, and that unfortunately bleeds out to others. - Mark ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3485/#review11766 ----------------------------------------------------------- On April 25, 2014, 10:48 p.m., Jonathan Rose wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3485/ > ----------------------------------------------------------- > > (Updated April 25, 2014, 10:48 p.m.) > > > Review request for Asterisk Developers, Matt Jordan and Mark Michelson. > > > Repository: Asterisk > > > Description > ------- > > If a PJSIP endpoint attempts to blind transfer to a parking extension, there > is an override to the normal transfer logic that can make things act a little > weird. We noticed that this would leave various phones hanging on transfer > screens without progressing. When the transfer was considered successful, > PJSIP deferred the actual action of sending the 200 notify and the actual > trigger for that happening never occurs when the transfer is to a parking > extension. > > In order to handle this, the bridge function that handles blind transfers now > returns a different value if a call was parked and if the channel driver > needs to react differently in this case, it can. In the case of PJSIP, we > respond to transfers to park by immediately sending the notify with 200 OK > sip frag instead of deferring the action. > > > Diffs > ----- > > /branches/12/res/res_pjsip_refer.c 412824 > /branches/12/main/manager.c 412824 > /branches/12/main/bridge_basic.c 412824 > /branches/12/main/bridge.c 412824 > /branches/12/include/asterisk/bridge.h 412824 > /branches/12/channels/chan_unistim.c 412824 > /branches/12/channels/chan_skinny.c 412824 > /branches/12/channels/chan_sip.c 412824 > /branches/12/channels/chan_oss.c 412824 > /branches/12/channels/chan_iax2.c 412824 > > Diff: https://reviewboard.asterisk.org/r/3485/diff/ > > > Testing > ------- > > Before patch: > * Blind transfer on Polycom SPIP: Phone is on the blind transfer screen until > it either manually hangs up or 60 seconds pass and Asterisk terminates the > session. > > After the patch: > * Blind transfer on Polycom SPIP: Phone immediately leaves the blind transfer > screen and goes back to idle mode. > > > Thanks, > > Jonathan Rose > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
