I don't think this is warranted. This behavior of Timer E is well
documented in RFC 3261. It does not bear reiteration every time it is
mentioned.
In particular, the quoted paragraph is quite clear on the topic, if one
is to finish reading it:
The default value of T2 is 4s,
and it represents the amount of time a non-INVITE server transaction
will take to respond to a request, if it does not respond
immediately. For the default values of T1 and T2, this results in
intervals of 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc.
This is also explained in 17.1.2.1:
For unreliable transports, requests
are retransmitted at an interval which starts at T1 and doubles until
it hits T2.
/a
On 04/08/2011 02:52 AM, RFC Errata System wrote:
The following errata report has been submitted for RFC3261,
"SIP: Session Initiation Protocol".
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3261&eid=2769
--------------------------------------
Type: Technical
Reported by: Iñaki Baz Castillo<[email protected]>
Section: 17.1.2.2
Original Text
-------------
MUST be passed to the transport layer for transmission. If an
unreliable transport is in use, the client transaction MUST set timer
E to fire in T1 seconds. If timer E fires while still in this state,
the timer is reset, but this time with a value of MIN(2*T1, T2).
When the timer fires again, it is reset to a MIN(4*T1, T2). This
process continues so that retransmissions occur with an exponentially
increasing interval that caps at T2.
Corrected Text
--------------
MUST be passed to the transport layer for transmission. If an
unreliable transport is in use, the client transaction MUST set timer
E to fire in T1 seconds. If timer E fires while still in this state,
the timer is reset, but this time with a value of MIN(2*T1, T2).
When the timer fires again, it is reset to a MIN(4*T1, T2). Multiplier
on T1 doubles with each reset so that retransmissions occur with an
exponentially increasing interval that caps at T2.
Notes
-----
The original text doesn't clarify that the multiplier of T1 is doubled with
each timer reset, so it could be understood that the maximum value the timer
takes is MIN(4*T1, T2) which is 2s (so the timer would never reach 4s and the
resulting intervals would be 500ms, 1s, 2s, 2s, 2s, 2s, etc).
Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.
--------------------------------------
RFC3261 (draft-ietf-sip-rfc2543bis-09)
--------------------------------------
Title : SIP: Session Initiation Protocol
Publication Date : June 2002
Author(s) : J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston,
J. Peterson, R. Sparks, M. Handley, E. Schooler
Category : PROPOSED STANDARD
Source : Session Initiation Protocol
Area : Real-time Applications and Infrastructure
Stream : IETF
Verifying Party : IESG
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use [email protected] for questions on how to develop a SIP
implementation.
Use [email protected] for new developments on the application of sip.
Use [email protected] for issues related to maintenance of the core SIP
specifications.
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use [email protected] for questions on how to develop a SIP
implementation.
Use [email protected] for new developments on the application of sip.
Use [email protected] for issues related to maintenance of the core SIP
specifications.
