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

[David Vossel]

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



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

    I never encountered this during my testing, but after learning how the scheduler works, this felt like a good check to make.


- David


On 2010-06-28 11:59:09, David Vossel wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/749/
> -----------------------------------------------------------
> 
> (Updated 2010-06-28 11:59:09)
> 
> 
> 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 272652 
>   /trunk/channels/sip/include/sip.h 272649 
> 
> 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
> 
>