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

[David Vossel]

> On 2010-07-09 04:35:04, Olle E Johansson wrote:
> > /trunk/channels/sip/include/sip.h, line 86
> > <https://reviewboard.asterisk.org/r/749/diff/2/?file=11187#file11187line86>
> >
> >     RFC 3261: "The value of
> >     64*T1 is equal to the amount of time required to send seven requests in the case of an unreliable transport."
> >     
> >     I agree with the other changes, but we need to keep this check.

>From what I understand, seven retransmits only applies for Invite transactions.  non-Invite transactions cap the retransmission interval at 4s which means they will end up sending more.

RFC 3261 17.1.2.2
"For the default values of T1 and T2, this results in
   intervals of 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc."

If we limit this to only seven retransmits, then non-Invite transactions stop at 15.5 seconds, which is not the expected 32 seconds that 64*T1 is by default.

Given this, why would this check be necessary now?  I have not read anything in the RFC that says we should keep up with the number of times a packet is retransmitted.


- David


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


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
> 
>