> On April 28, 2014, 12: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. > > > > > > Mark Michelson wrote: > 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.
Okay, that makes sense now how we ended up on this solution, but I agree with your later comment - I like the new approach much better. Keeping consumers unaware of whether or not the destination happens to be the craziness that is parking is a win. - Matt ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3485/#review11766 ----------------------------------------------------------- On April 28, 2014, 2:10 p.m., Jonathan Rose wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3485/ > ----------------------------------------------------------- > > (Updated April 28, 2014, 2:10 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/parking/parking_bridge_features.c 413071 > /branches/12/main/parking.c 413071 > /branches/12/main/bridge.c 413071 > /branches/12/include/asterisk/parking.h 413071 > > 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
