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

[Mark Michelson]

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

Ship it!


Ship It!

- Mark Michelson


On Feb. 13, 2014, 3:01 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3214/
> -----------------------------------------------------------
> 
> (Updated Feb. 13, 2014, 3:01 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/18933301/attachment.html>