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

[Olle E Johansson]

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



/trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/749/#comment5211>

    See below - we need to have both checks, MAX_RETRANS and the maximum timer.



/trunk/channels/sip/include/sip.h
<https://reviewboard.asterisk.org/r/749/#comment5210>

    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.


- Olle E


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