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

David Vossel dvossel at digium.com
Mon Jun 28 11:59:10 CDT 2010

This is an automatically generated e-mail. To reply, visit:

Review request for Asterisk Developers.


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.


  /trunk/channels/chan_sip.c 272652 
  /trunk/channels/sip/include/sip.h 272649 

Diff: https://reviewboard.asterisk.org/r/749/diff


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.



More information about the asterisk-dev mailing list