[asterisk-dev] [Code Review] 2766: Bridging: Fix a transfer bug that left stale references to the original bridge on performing blond transfer

[rmudgett]

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

Ship it!


Ship It!

- rmudgett


On Aug. 16, 2013, 7:35 p.m., jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2766/
> -----------------------------------------------------------
> 
> (Updated Aug. 16, 2013, 7:35 p.m.)
> 
> 
> Review request for Asterisk Developers, Joshua Colp, Matt Jordan, Mark Michelson, and rmudgett.
> 
> 
> Bugs: ASTERISK-22092
>     https://issues.asterisk.org/jira/browse/ASTERISK-22092
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Fixes the bug described in ASTERISK-22092. If a SIP channel attempted to attended transfer (via its own attended transfer functions rather than through the bridge feature style attended transfers) to another device and that device hadn't been bridged yet, the a subscription expecting an event indicating the success/failure of the attended transfer would stick around and keep the channels and the bridge involved to stay alive. This patch fixes that by having this form of attended transfer not return before issuing the expected success event. It's a pretty trivial patch really.
> 
> 
> Diffs
> -----
> 
>   /trunk/main/bridge.c 396802 
> 
> Diff: https://reviewboard.asterisk.org/r/2766/diff/
> 
> 
> Testing
> -------
> 
> Tested that the successful transfer event would be received and all the expected teardown events would take place after the patch was applied.
> 
> 
> Thanks,
> 
> jrose
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130816/c90eeec9/attachment-0001.htm>