----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3485/#review11915 -----------------------------------------------------------
/branches/12/include/asterisk/bridge.h <https://reviewboard.asterisk.org/r/3485/#comment21793> Terminal does not feel like a good name for this parameter. What's more, in most blind transfers, media is never played to the transferer. The context of this is definitely not clear from the description of the function. The fact that we have a single parameter - which ripples throughout the _entire_ codebase - merely to work around chan_sip feels like a mistake. Ideally, the blind transfer routine would be smart enough to bump the reference count of the channel to prevent it getting nuked before attempting the playback and - if the channel is marked to be hung up - not attempt the playback in the first place. - Matt Jordan On May 16, 2014, 5:02 p.m., Jonathan Rose wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3485/ > ----------------------------------------------------------- > > (Updated May 16, 2014, 5:02 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 413303 > /branches/12/res/parking/parking_bridge_features.c 413303 > /branches/12/res/parking/parking_applications.c 413303 > /branches/12/main/parking.c 413303 > /branches/12/main/manager.c 413303 > /branches/12/main/bridge_basic.c 413303 > /branches/12/main/bridge.c 413303 > /branches/12/include/asterisk/parking.h 413303 > /branches/12/include/asterisk/bridge.h 413303 > /branches/12/channels/sig_analog.c 413303 > /branches/12/channels/chan_skinny.c 413303 > /branches/12/channels/chan_sip.c 413303 > /branches/12/channels/chan_oss.c 413303 > /branches/12/channels/chan_mgcp.c 413303 > /branches/12/channels/chan_iax2.c 413303 > /branches/12/channels/chan_dahdi.c 413303 > > 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
