[asterisk-dev] [Code Review] RFC 3261 compliant SIP unreliable retransmit timing + 'registerattempts' option tweak
David Vossel
dvossel at digium.com
Thu Jun 3 11:43:49 CDT 2010
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/687/
-----------------------------------------------------------
Review request for Asterisk Developers.
Summary
-------
Changes.
1. RFC 3261 states in section 17.1.2.2 and 17.1.1.2 that retransmission timers should initially be set to timer T1. T1 by default is 500ms. Asterisk was starting the retransmission timers at T1*2 which shouldn't cause any problems, but is not RFC compliant.
2. RFC 3261 states in section 17.1.2.2 that for a non-INVITE client transaction, if the retransmit timer fires while in the proceeding state that the request must be retransmitted. Asterisk currently ack's requests for both INVITE and non-INVITE transactions when a 1XX response is received, this patch changes this for non-INVITE requests.
3. The 'registerattempts' option in sip.conf is supposed to set how many registry attempts will be made before giving up. When this option is set to 1, I would expect only one registry attempt to be made before stopping because of a failure, but instead two are made. In my opinion this is not expected behavior. This option does not indicate that these are re-attempts. The logic behind this option has been changed to only attempt registers the exact number of times this option is set to. If this option is 0, it still continues to re-attempt the registration forever.
Diffs
-----
/trunk/channels/chan_sip.c 267442
Diff: https://reviewboard.asterisk.org/r/687/diff
Testing
-------
For change 1. I verified that for both INVITE and non-INVITE transactions the retransmission timer start at T1 and increment by doubling as expected. This was verified using wireshark.
For change 2. I verified that for a SIP Register receiving a response of 100 trying, the retransmission of that register occured as expected.
For change 3. I verified that the exact number of registry attempts set by the 'registerattempts' were made before giving up, and that when 'registerattempts is 0 Asterisk retries forever.
Thanks,
David
More information about the asterisk-dev
mailing list