[asterisk-dev] [Code Review] 3107: chan_sip: Prevent orphaned channel during a failed SIP transfer to Park

[rmudgett]

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



/branches/11/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/3107/#comment20052>

    The transferee channel would get orphaned here since it has already been masqueraded.


- rmudgett


On Jan. 13, 2014, 3:41 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3107/
> -----------------------------------------------------------
> 
> (Updated Jan. 13, 2014, 3:41 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-22834 and ASTERISK-23047
>     https://issues.asterisk.org/jira/browse/ASTERISK-22834
>     https://issues.asterisk.org/jira/browse/ASTERISK-23047
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> When performing a SIP transfer to a Park extension, if the Park fails, chan_sip will currently not hang up either the transferer or the transfer target. This results in the channels being orphaned with no thread to service frames, resulting in stuck channels.
> 
> This patch immediately hangs up the two channels if a Park fails.
> 
> Note that this is also a bug in 1.8; the code is identical between 11 and 1.8 in this respect. This is not a bug in 12+.
> 
> 
> Diffs
> -----
> 
>   /branches/11/channels/chan_sip.c 405361 
> 
> Diff: https://reviewboard.asterisk.org/r/3107/diff/
> 
> 
> Testing
> -------
> 
> Prior to the patch, the channels were stuck.
> 
> With the patch, the two channels are properly hung up.
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140113/892d63a7/attachment.html>