[asterisk-dev] [Code Review] Guard against retransmitting a BYE forever

[David Vossel]

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

Ship it!


This looks correct to me!

- David


On 2011-01-18 16:52:16, Terry Wilson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1077/
> -----------------------------------------------------------
> 
> (Updated 2011-01-18 16:52:16)
> 
> 
> Review request for Asterisk Developers and David Vossel.
> 
> 
> Summary
> -------
> 
> In the case of an attended transfer (A calls B, A atxfers to C) where A becomes unreachable before replying to Asterisk's BYE, Asterisk can sometimes retransmit the BYE indefinitely. This is because __sip_autodestruct tests p->refer && !ast_test_flag(&p->flags[0], SIP_ALREADYGONE and will then transmit a BYE. When this BYE times out, it will not ever be marked as ALREADYGONE, so when __sip_autodestruct is called again, we end up starting the cycle over.
> 
> This patch adds a call to sip_alreadygone(pkt->owner) in retrans_pkt in the case of a BYE that has timed out. This should prevent Asterisk from trying to transmit new BYE messages in the future.
> 
> 
> Diffs
> -----
> 
>   /branches/1.4/channels/chan_sip.c 302087 
> 
> Diff: https://reviewboard.asterisk.org/r/1077/diff
> 
> 
> Testing
> -------
> 
> Modified Asterisk to sleep for 2 seconds before sending the transfer NOTIFY to give me time to unplug the network cable from the transfering phone. Registered 3 phones A, B, and C. A calls B, A atxfer to C. I often (but not always) got infinite BYEs. After the patch I did not.
> 
> 
> Thanks,
> 
> Terry
> 
>

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