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

David Vossel dvossel at digium.com
Tue Jun 29 09:30:45 CDT 2010


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

(Updated 2010-06-29 09:30:45.485819)


Review request for Asterisk Developers.


Changes
-------

This update reflects comments made by both myself and Nick_Lewis.


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 (updated)
-----

  /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




More information about the asterisk-dev mailing list