[asterisk-dev] [Code Review] Cancel retries for all dialogs when the remote host isn't answering

Mark Michelson mmichelson at digium.com
Wed Dec 9 13:18:43 CST 2009


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


I really really really do not like this method. Like Vossel suggested, it is really confusing to see that the last transmitted method was a CANCEL when we haven't even sent a cancel yet.

If I understand the problem correctly, it's that we send an INVITE out and never get a final response for it (in the description it says the packet is never ACKed, but in SIP INVITEs aren't ACKed, their final response is). The result is that retrans_pkt should eventually reach the maximum number of retries and remove the packet from the sip_pvt. Now, in __sip_autodestruct, the problem is that even though the sip_pvt is free of packets, the SIP_NEEDDESTROY flag is not set. So couldn't this problem be solved by setting the SIP_NEEDDESTROY flag in retrans_pkt?

- Mark


On 2009-12-09 09:52:44, Tilghman Lesher wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/446/
> -----------------------------------------------------------
> 
> (Updated 2009-12-09 09:52:44)
> 
> 
> Review request for Asterisk Developers and Russell Bryant.
> 
> 
> Summary
> -------
> 
> Currently, certain dialogs, including INVITE, may never deallocate resources, if the remote host does not ACK the packets.  This is due to a retry loop in the autodestruct function that has no terminating condition.
> 
> 
> This addresses bug 15627.
>     https://issues.asterisk.org/view.php?id=15627
> 
> 
> Diffs
> -----
> 
>   /branches/1.4/channels/chan_sip.c 233049 
> 
> Diff: https://reviewboard.asterisk.org/r/446/diff
> 
> 
> Testing
> -------
> 
> Works to solve reporter's problem.
> 
> 
> Thanks,
> 
> Tilghman
> 
>




More information about the asterisk-dev mailing list