Subject: [sipcore] SIP timer B in RFC 3261

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 17 Oct 2017 09:07:34 +0200

Hi!

Section 17.1.1.2 of 3261 says:
"For any transport, the client transaction MUST start timer B with a value
   of 64*T1 seconds (Timer B controls transaction timeouts).”

This MUST surprised me when someone pointed at it recently. For a very long time, almost all SIP implementations has a user-configurable
setting for Timer B, so there must be a reason why this MUST is ignored. Many web pages found with my friends at G talk about a default
setting being 64*T1, but the RFC is quite clear that it’s not something one should not modify.

In my experience there are plenty of situations where you want to modify T1 to set the number of retransmissions and
speed of them independently of the end of transaction. The user experience comes first and you want SRV failover to
be quite quick. Lowering the T1 will generate more of a packet storm which in many cases doesn’t help.

Anyone from that time long ago when this was written that remembers why there is a MUST here?  Was the MUST
just indicating “start timer B” or was it really a MUST on 64*T1? Could be an edit that made this turn out wrong...

Do we have any other documents (or part of 3261) that makes Timer B configurable?

Thank you for your feedback!

/Olle

---

From: Keith Drage <[email-masked]>
Date: Tue, 17 Oct 2017 22:59:23 +0100

I don't go back far enough to have the history of this - it is well over 
17 years ago, but:

My perspective has always been that these timers are the protocol 
protection timers, i.e. those that prevent the protocol getting locked 
up and the protocol disappearing into a state that it cannot get out of, 
particularly when it is running over UDP where it also needs to provide 
a mechanism for giving some reliability to messages.

There is nothing to stop the user implementing timers at an application 
level that are shorter than this, and running in parallel to the 
protocol level timers, and then using the cancellation mechanisms as 
appropriate within the protocol to clear the protocol. Those timers 
could depend on the needs of the application, and the needs of human 
user interaction, therefore applications supporting a voice call might 
take a different approach to one running MSRP.

Therefore timer B is not shorter in this viewpoint, merely never expires 
because something else at the application layer gets there first.

I would add that anyone designing an application with such shorter 
timers needs to ensure that they are not creating a mechanism for a 
denial of service attack using this application.

regards

Keith

On 17-Oct-17 8:07 AM, Olle E. Johansson wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Jesske, Roland" <[email-masked]>
Date: Thu, 19 Oct 2017 02:37:49 +0000

Hi Keith,
You can "configure"  Timer B. But you can do it only via T1, since T1 may be choose it shorter (not recommended) or longer as defined in section 
17.1.1.2 Formal Description
The default value for T1 is 500 ms.  T1 is an estimate of the RTT
   between the client and server transactions.  Elements MAY (though it
   is NOT RECOMMENDED) use smaller values of T1 within closed, private
   networks that do not permit general Internet connection.  T1 MAY be
   chosen larger, and this is RECOMMENDED if it is known in advance
   (such as on high latency access links) that the RTT is larger.
   Whatever the value of T1, the exponential backoffs on retransmissions
   described in this section MUST be used.

But keep in mind  if you change T1 then you change all T1 dependent timers.

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: sipcore [mailto:[email-masked]] Im Auftrag von Keith Drage
> Gesendet: Dienstag, 17. Oktober 2017 23:59
> An: [email-masked]
> Betreff: Re: [sipcore] SIP timer B in RFC 3261
> 
> protection timers, i.e. those that prevent the protocol getting locked up and
> the protocol disappearing into a state that it cannot get out of, particularly
> when it is running over UDP where it also needs to provide a mechanism for
> giving some reliability to messages.
> 
> There is nothing to stop the user implementing timers at an application level
> that are shorter than this, and running in parallel to the protocol level timers,
> and then using the cancellation mechanisms as appropriate within the
> protocol to clear the protocol. Those timers could depend on the needs of
> the application, and the needs of human user interaction, therefore
> applications supporting a voice call might take a different approach to one
> running MSRP.
> 
> I would add that anyone designing an application with such shorter timers
> needs to ensure that they are not creating a mechanism for a denial of
> service attack using this application.
> 
> regards
> 
> Keith
> 
> 
> 
> > This MUST surprised me when someone pointed at it recently. For a very
> > long time, almost all SIP implementations has a user-configurable
> > setting for Timer B, so there must be a reason why this MUST is ignored.
> Many web pages found with my friends at G talk about a default setting
> being 64*T1, but the RFC is quite clear that it’s not something one should not
> modify.
> >
> > In my experience there are plenty of situations where you want to
> > modify T1 to set the number of retransmissions and speed of them
> > independently of the end of transaction. The user experience comes first
> and you want SRV failover to be quite quick. Lowering the T1 will generate
> more of a packet storm which in many cases doesn’t help.
> >
> > Anyone from that time long ago when this was written that remembers
> > why there is a MUST here?  Was the MUST just indicating “start timer B” or
> was it really a MUST on 64*T1? Could be an edit that made this turn out
> wrong...
> >

---

From: Keith Drage <[email-masked]>
Date: Sun, 22 Oct 2017 12:25:16 +0100

I am not sure this answers the point of the original poster, and in many 
ways, just reinforces my argument that these are protocol protection 
timers.

What the application does over the top is entirely up to the 
application, and should not directly interfere with these timers, 
because underlying these timers are the physical characteristics of the 
link itself.

However, in the same way as if a human user decides that setting up a 
call is taking too long and manually clears it down, there is nothing to 
stop the application using SIP from running a timer to do the same thing.

Keith

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 26 Oct 2017 15:21:27 +0200

> On 22 Oct 2017, at 13:25, Keith Drage <[email-masked]> wrote:
> 
> I am not sure this answers the point of the original poster, and in many ways, just reinforces my argument that these are protocol protection timers.
> 
> What the application does over the top is entirely up to the application, and should not directly interfere with these timers, because underlying these timers are the physical characteristics of the link itself.
> 
> However, in the same way as if a human user decides that setting up a call is taking too long and manually clears it down, there is nothing to stop the application using SIP from running a timer to do the same thing.
Well, there that matter of a MUST for timer B being 64*T1.

T1 determines the number of retransmissions until timer B fires. In some cases, like when using a satellite link, this doesn’t work. I have a long latency
and don’t need a lot of retransmissions. I need timer T1 to be 700 ms, but don’t want to wait 64*T1 for failover. It does not make sense.

It seems like Keith agrees with me that 64*T1 should be a “default” value and timer B should be configurable in the software.

The way I parse RFC 3261 this breaks SIP compliance and we will need to update in order to get this setting - which again exists in almost
every SIP implementation - SIP compliant.

/O