[asterisk-dev] [Code Review] chan_sip: RFC compliant retransmission timeout

[David Vossel]

> On 2010-07-13 16:25:40, Terry Wilson wrote:
> > /trunk/channels/chan_sip.c, line 3212
> > <https://reviewboard.asterisk.org/r/749/diff/2/?file=11186#file11186line3212>
> >
> >     Since pkt->retrans_stop is only used from inside this function, do we need to have it stored in sip_pkt? If we do need it, I notice that we have (char)is_resp, (char)is_fatal, and now (int)retrans_stop in sip_pkt. We might think about making those bitfields.

The packet has to hold on to retrans_stop because that variable can be set in a way that is only read by the next retransmit.

This occurs if the next retransmit period exceeds the maximum allowed time we can retransmit a packet.  In that case the next retransmit time is set to whenever the packet should be destroyed and retrans_stop is set so we know to just kill the packet instead of sending it out again once that event fires.


> On 2010-07-13 16:25:40, Terry Wilson wrote:
> > /trunk/channels/chan_sip.c, line 3408
> > <https://reviewboard.asterisk.org/r/749/diff/2/?file=11186#file11186line3408>
> >
> >     I suppose this could overflow for absurdly large values of timer_t1 since they are both ints. So above, instead of retransmitting for 4.3 years (with timer_t1 ~ 2^31), we would instead not retransmit at all. ;-)


- David


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


On 2010-06-29 09:30:45, David Vossel wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/749/
> -----------------------------------------------------------
> 
> (Updated 2010-06-29 09:30:45)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Retransmission of packets should not be based on how many packets were sent, but instead on a timeout period.  Depending on whether or not the packet is for a INVITE or NON-INVITE transaction, the number of packets sent during the retransmission timeout period will be different, so timing out based on the number of packets sent is not accurate.
> 
> This patch fixes this by removing the retransmit limit and only stopping retransmission after a timeout period is reached.  By default this timeout period is 64*(Timer T1) for both INVITE and non-INVITE transactions.  For more information on sip timer values refer to RFC3261 Appendix A.
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_sip.c 272920 
>   /trunk/channels/sip/include/sip.h 272920 
> 
> Diff: https://reviewboard.asterisk.org/r/749/diff
> 
> 
> Testing
> -------
> 
> I tested this with a sipp scenario that sends an INVITE but does not respond to Asterisk's 200 OK response.  I verified Asterisk continues to send retransmits until the packet times out at the correct timeout time.  I also did a sanity check to verify packets continue to be acknowledged correctly by placing some test calls.
> 
> 
> Thanks,
> 
> David
> 
>