[asterisk-dev] [Code Review] 3214: chan_sip: Set SIP_DEFER_BYE_ON_TRANSFER prior to calling ast_bridge_transfer_blind

[Matt Jordan]

> On Feb. 13, 2014, 8:17 a.m., Mark Michelson wrote:
> > It's fine to set the flag early, but I think you need to clear the defer flag if the transfer does not succeed. Sending a NOTIFY stating that the transfer failed could result in the transferrer resuming the call. If that happens, we don't want to defer the BYE anymore.

Works for me. In that case, we should probably do the same in local_attended_transfer


- Matt


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


On Feb. 12, 2014, 10:29 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3214/
> -----------------------------------------------------------
> 
> (Updated Feb. 12, 2014, 10:29 p.m.)
> 
> 
> Review request for Asterisk Developers and Mark Michelson.
> 
> 
> Bugs: ASTERISK-23290
>     https://issues.asterisk.org/jira/browse/ASTERISK-23290
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This patch moves setting SIP_DEFER_BY_ON_TRANSFER prior to calling ast_bridge_transfer_blind.
> 
> The blind-transfer-accountcode test will sporadically fail due to a BYE request being sent for the transferor prior to the NOTIFY request being sent. This is due to the PVT being unlocked while ast_bridge_transfer_blind, allowing the thread ejecting the channel from the bridge to hangup the channel.
> 
> Note that it should be safe to move this prior to the ast_bridge_transfer_blind call, as the attended transfer handling does this exact same thing. It should also be okay (and probably correct) to set this flag on the channel before sending any of the NOTIFY requests, regardless of it notifying the transferor of the success or failure of the transfer.
> 
> 
> Diffs
> -----
> 
>   /branches/12/channels/chan_sip.c 407986 
> 
> Diff: https://reviewboard.asterisk.org/r/3214/diff/
> 
> 
> Testing
> -------
> 
> The test passes; however, it always did on my machine anyway... but this should fix the bug, given what the testsuite shows.
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140213/8219fbb3/attachment.html>