Subject: Re: [Sip] Repost: Timer C, Timer B and Spiraling

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Jun 2002 16:38:44 -0400

inline.

Vijay K. Gurbani wrote:
> Jonathan Rosenberg wrote:
> [...]
> 
>>>Looking at Figure 5, it seems that UAC will also benefit from a
>>>dynamic transaction timeout window.  Furthermore, why set Timer B in
>>>the "Calling" state?  If UDP is being used, we will know on the second
>>>retx that a UAS does not exist (if the socket is bind()'ed to the UAS
>>
> --
> 
>>>funny, this is missing from -09bis).  If TCP (or TLS, or I believe
>>
> even
> 
>>>SCTP) is being used, the connection will fail right away.  So, a
>>>transport error is bound to occur in the "Calling" state if a UAS does
>>>not exist.  Is it possible to set timer B in the "Proceeding" state
>>
> and
> 
>>>initalize it to the value of the Expires header (if present, T1*64 if
>>>not) and then dynamically updated on provisionals, just like proxies?
>>
>> 
>>I'm lost. Timer B handles time outs because of no response whatsoever.
> 
> 
> OK; let me explain...in Figure 5, Calling state is exited when either of
> the following events occur:
> 
>     (1) Receipt of a 2xx
>     (2) Receipt of a 1xx
>     (3) Timer B fires
>     (4) Transport error
> 
> In case of UDP, a transport error will occur when the request is retx'd
> on a bound socket where a server is not listening.  In case of TCP
> (TLS/TCP) and SCTP, a transport error will occur as soon as an attempt
> is made to establish a connection to an address where a server is not
> listening.  Control thus always goes to Terminated state in case of a
> transport error (event (4)).  Control also goes to Terminated state when
> a 2xx is received while in Calling state (event (1)).
> 
> So that leaves events (2) and (3) for exiting Calling state.  If we
> receive a 1xx (event (2)), we transit to Proceeding state as normal and
> *then* start Timer B.
> 
> If we do not start Timer B in the Calling state, we are guaranteed to
> have exited Calling state either through events (4) (2) or (1).  If we
> exit Calling state due to event (2), we can *then* start Timer B.  This
> has the nice side-effect of maintaining a dynamic Timer B (mirroring
> Timer C for proxies).

But that is not the point of timer B. There is also a "timer C" for UA, 
but its sufficiently flexible that it can be a matter of local 
implementation. You can give up at any time.

> 
> BTW, in -09bis I notice that binding UDP sockets to destination
> addresses (so that a ECONNREFUSED is generated on a retx) has been
> taken out.  Was this intentional or a an error.  What I describe
> above depends on a bound UDP socket.

Intentional; we are not writing an implementors guide. We tried to 
remove as much as possible (and still look at the size...)

> 
> Also note that even if a UAC core does put an "Expires: 60" in a
> request, the client transaction will still time out in 32 s (T1*64) as
> per -09bis. 

Not with the current definition of timer B. It should get an immediate 
1xx and thus move into proceeding.

  Suggested change to the sentence on line 3274 (-09bis,
> PDF):
>     "For any transport, the client transaction MUST start timer B
>      with a value of the Expires header, if present, or 64*T1 if not."

I disagree. Timer B is not an application layer timer.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 18 Jun 2002 17:03:20 -0500

> 1xx and thus move into proceeding.

But -09bis does not instruct turning Timer B off when "Proceeding" is
entered, so presumably Timer B is still ticking away.  32 s after the
transaction started, it will be torn down.  The UAS, on the other hand,
thinks that it has 60 s to generate a final response (since it saw an
Expires: 60 in the request), so it is still searching the callee.

In fact, Timer B should not be turned off on entering the Proceeding
state since without it, a UAC will remain in the Proceeding state if
the UAS dies after sending a 1xx.

>>  Suggested change to the sentence on line 3274 (-09bis, PDF):

No, but transaction timeouts should honor the Expires header, right? 
Otherwise, we should simply say that the Expires header value must be
<= (T1*64).

Setting Timer B in the Proceeding state and making its value be that of
Expires header if present, or 64*T1 if not, makes the state machine
more resilient, I think.  As my previous email detailed, the "Calling"
state is guaranteed to have been egressed due to other events occuring.
We can safely start Timer B in the Proceeding state.  This enables the
state machine to recover even if the UAS crashes after sending a 1xx.

While I agree whole heartedly with you about not turning -09bis into
a programming manual, to the extent that we can make the state machine
unambiguous, we should.

Best regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Jun 2002 01:31:01 -0400

Vijay K. Gurbani wrote:
>>>request, the client transaction will still time out in 32 s (T1*64)
>>
> as
> 
>>>per -09bis. 
>>
> entered, so presumably Timer B is still ticking away.

No, it is not.

The spec doesn't tell you to "turn it off", but no state transitions are 
defined if it fires outside of the calling state. So, your 
implementation can turn it off if it likes. Note that it doesn't 
instruct you to ever turn off any of the other timers either.

> the UAS dies after sending a 1xx.

The UAC decides how long the phone should ring. Irregardless of what the 
UAS does, it will give up (or the proxies will, based on timer C) 
resulting in termination of the transaction.

> Otherwise, we should simply say that the Expires header value must be

No. This is based on your misinterpretation of timer B above.

-Jonathan R.