Subject: [Sip] Possible bug in "Non-INVITE Client Transaction" - 17.1.2.2

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 6 Apr 2011 18:36:03 +0200

Hi, RFC 3261 section 17.1.2.2 states that:

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

I've calculated those intervals and can't get same values:

Timer E:
- Initially => T1 = 0.5s
- Fires    => MIN(2*T1, T2) = 1s
- Fires    => MIN(4*T1, T2) = 2s
- Fires    => MIN(4*T1, T2) = 2s
- Fires    => MIN(4*T1, T2) = 2s
...

So the resulting intervals are 500ms, 1s, 2s, 2s, 2s, 2s, etc.
In short, it's obvious that MIN(4*T1, T2) will always be 2 seconds! it
can never reach 4s.

IMHO the text should say:

   If timer E fires while still in this state,
   the timer is reset, but this time with a value of MIN(2*TIMER_E, T2).

And remove the line about "When the timer fires again, it is reset to
a MIN(4*T1, T2)

So we get:

Timer E:
- Initially => T1 = 0.5s
- Fires    => MIN(2*TIMER_E, T2) = 1s
- Fires    => MIN(2*TIMER_E, T2) = 2s
- Fires    => MIN(2*TIMER_E, T2) = 4s
- Fires    => MIN(2*TIMER_E, T2) = 4s

 Am I wrong? Thanks a lot.

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

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 6 Apr 2011 19:12:25 +0200

2011/4/6 Pandurangan R S <[email-masked]>:
>>> This process continues so that retransmissions occur with an exponentially
>>>  increasing interval that caps at T2.
>
> I think this actually means
>
>> - Initially => T1 = 0.5s
>> - Fires    => MIN(8*T1, T2) = 4s
>> - Fires    => MIN(16*T1, T2) = 4s
>
> 2,4, 8, 16... which is exponential.

Yes, assuming that after 4*T1 it becomes 8*T1 it works. However that
is not what I've understood by reading the section (but I must be
wrong as all the SIP stacks I've tested behave as you describe) :)

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Dean Willis <[email-masked]>
Date: Thu, 7 Apr 2011 23:13:21 -0500

On Apr 6, 2011, at 11:36 AM, Iñaki Baz Castillo wrote:

...

> Am I wrong? Thanks a lot.

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.

> PS: Sorry for the cross-posting, I don't know which maillist is better

[email-masked] would probably be the right place.

--
Dean

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 8 Apr 2011 09:56:44 +0200

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

That would clarify it, right.

> [email-masked] 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.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Peter Hanratty <[email-masked]>
Date: Fri, 08 Apr 2011 13:04:18 +0100

While youre at it, the INVITE server transaction could use some 
rethinking.  Terminating on a 2xx but on no other final response is a 
bit daft and makes people like me want to cut corners rather than use 
other objects such as the dialog or session to handle the ACK, which 
doesn't really make for a nice logical model :)  The ACK is attached to 
a single transaction and should handled by that transaction (as it is 
for a non-2xx final response).

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

On 08/04/2011 08:56, Iñaki Baz Castillo wrote:
> 2011/4/8 Dean Willis<[email-masked]>:
>    
>> 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
>>
> 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
>
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 8 Apr 2011 14:14:47 +0200

2011/4/8 Peter Hanratty <[email-masked]>:
> While youre at it, the INVITE server transaction could use some rethinking.
> Terminating on a 2xx but on no other final response is a bit daft and makes
> people like me want to cut corners rather than use other objects such as the
> dialog or session to handle the ACK, which doesn't really make for a nice
> logical model :)  The ACK is attached to a single transaction and should
> handled by that transaction (as it is for a non-2xx final response).

Hi Peter, you should take a look to RFC 6026 "Correct Transaction
Handling for 2xx Responses to SIP INVITE Requests".
;)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Robert Sparks <[email-masked]>
Date: Fri, 8 Apr 2011 09:07:58 -0500

Since, as Iñaki noted, implementations are almost always getting this right,
I plan to put this errata into the "Hold for Document Update" state
(see <http://www.ietf.org/iesg/statement/errata-processing.html>).

RjS

On Apr 8, 2011, at 2:56 AM, Iñaki Baz Castillo wrote:

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 8 Apr 2011 16:27:29 +0200

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>