> On May 19, 2014, 9:11 a.m., Matt Jordan wrote:
> > /branches/12/include/asterisk/bridge.h, lines 951-953
> > <https://reviewboard.asterisk.org/r/3485/diff/5/?file=58486#file58486line951>
> >
> >     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.
> 
> Jonathan Rose wrote:
>     There is no way to prevent the playback based on the channel's current 
> hangup state. The hangup state generally hasn't changed by the time we enter 
> the announcement function. The blind transfer itself isn't what initiates the 
> hangup. It's the response we get from the phone to the SIP notify after 
> returning from everything in the bridge blind transfer code. At best we'd end 
> up with a race condition between the announcement subscription and hanging up 
> on the BYE we get from the phones.
>     
>     This stuff worked with chan_sip in Asterisk 11 because Asterisk 11's 
> chan_sip had logic specifically in place to handle deferring the final notify 
> (the one that triggers the BYE from phones) when parking completed.
>     
>     
>     Perhaps it would be more palpable if instead of adding this to flag to 
> the API call, I instead added it to the transfer channel data wrapper. As for 
> a name change, how about just 'disable_media'?
>     
>     Alternatively, I can start investigating what it would take to be able to 
> defer the final notify of chan_sip blind transfers. I know you said we don't 
> want to go down that road right now, but it's basically the only real way of 
> getting this to behave like it behaved in Asterisk 11.
> 
> Jonathan Rose wrote:
>     On second thought, I can't really move the variable to the wrapper either 
> since the transfer channel callback data isn't wrapped until it is already in 
> the bridging function. Meh.

Ah, but on the other hand... I could set the variable in the 
transfer_channel_cb since that gets executed before the parked channel is put 
into the bridge anyway. That solves that problem.


- Jonathan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3485/#review11915
-----------------------------------------------------------


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

Reply via email to