Re: [Technical Errata Reported] RFC3261 (2769)

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.