[Technical Errata Reported] RFC3261 (2769)

[RFC Errata System]

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 <***@aliax.net>

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

[Adam Roach]

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

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.
For unreliable transports, requests
are retransmitted at an interval which starts at T1 and doubles until
it hits T2.

/a

The following errata report has been submitted for RFC3261,
"SIP: Session Initiation Protocol".
--------------------------------------
http://www.rfc-editor.org/errata_search.php?rfc=3261&eid=2769
--------------------------------------
Type: Technical
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).
-------------
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.

[Dean Willis]

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.

Other than the fact that it appears to disagree with itself, 3261 is quite clear.

While it is true that the behavior of the timer is correctly-described in one part of the spec, it seems to be incorrectly (or at least misleadingly) described in an early passage. So while reiteration may not be needed, correct initial iteration is probably warranted. Or the misleading initial passage could be excised.

If you say something only once, say it right. If you must say it again, don't say something different. Just say it more clearly.

--
Dean

_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Iñaki Baz Castillo]

Post by Dean Willis

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.

Other than the fact that it appears to disagree with itself, 3261 is quite clear.
While it is true that the behavior of the timer is correctly-described in one part of the spec, it seems to be incorrectly (or at least misleadingly) described in an early passage. So while reiteration may not be needed, correct initial iteration is probably warranted. Or the misleading initial passage could be excised.
If you say something only once, say it right. If you must say it again, don't say something different. Just say it more clearly.

+1