Peter Hanratty
Senior Software Developer

Pinnacle Telecom Group PLC
Brooke House
4 The Lakes
Bedford Road
Northampton
NN4 7YD

Tel:  0845-006-0800
Fax:  0871-872-0866

2011/4/8 Dean Willis <dean.willis@softarmor.com>:

I think you're right that the spec is written incorrectly. I believe it should describe that the multiplier on T1 doubles with each reset. This is not clear in the existing text. So for example, if 8*T1 < T2, then the third reset is 8*T1, and if 16*T1 < T2, then the 4th reset is 16*T2

Otherwise said, MIN(2^N*T1,T2) where N is the repetition iterator.

That would clarify it, right.

PS: Sorry for the cross-posting, I don't know which maillist is better
to report it.

sipcore@ietf.org would probably be the right place.

Finally I've reported an errata for RFC 3261 (hope it's also a good place):

  http://www.rfc-editor.org/errata_search.php?rfc=3261

Thanks a lot.

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 9.0.894 / Virus Database: 271.1.1/3545 - Release Date: 04/01/11 19:36:00

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.
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 <ibc@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

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