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

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 08 May 2002 10:52:53 -0500

Since most people were busy with the interim SIP WG meeting, I did not
hear from anyone on the list, I will send this out again...

Some comments on -09bis on Timers C, B, and spiraling:

1) In SIP, proxies can fork either in serial or in parallel.  Consider
    serial forking for this discussion.  Normally, in the presence of
    multiple Contact headers to an address-of-record, a proxy will sort
    the Contacts based on their q value and fork serially to each
    Contact.  If Contact 1 did not elicit a final response within a
    certain time, Contact 2 will be tried, and so on.  Problem is,
    what exactly is the time for a proxy to give up on the current
    Contact and try the next one?

    Reading -09bis, it appears that timer C can serve this function.
    But the initial value of timer C is too high (3 minutes, and it is
    a MUST to set it to at least 3 mins), so that will not work.  Another
    possible candidate is the transaction timeout; if a proxy allows a
    client transaction to continue (T1*64 seconds = 32 seconds) until it
    times out, the time between trying the next Contact (32 seconds) is
    too large for the caller to keep holding.  So, this does not work
    either.

    Should -09bis provide some guidance on timers to use in proxy cores
    if serial forking is being used and > 1 Contact header is present,
    or should this be left upto the implementer?

2) Timer B controls transaction timeouts in INVITE client trans-
    actions.  The state diagram in Figure 5 is silent on what to
    do if Timer B fires while control is in "Proceeding" state; i.e.
    received a 180, but no final response.  The correct behavior
    should be to sent a CANCEL and enter "Terminated" state.

3) Regarding finding the spiraled R-R on responses in order to
    modify it (section 16.7, step 8), won't it be the case that
    the first R-R in a response corresponds to the inner-most
    spiral?  Since the inner-most spiral will generate the first
    response, can't we just get the first R-R header on a response
    in order to modify it?

If I mis-represented something and the solution is in -09bis, please
let me know.

Thanks,

- 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

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 May 2002 15:24:07 -0400

inline.

>     Reading -09bis, it appears that timer C can serve this function.

Timer C is meant more for cleanup, not as a way to perform services.

The timer value to use when moving amongst contacts depends heavily on
the application. I suspect that normally there would be some logic
guiding the sequential operation, rather than just based on the q
values. As such, I think this is best left as implementation specific.

>     or should this be left upto the implementer?

Left to implementor.

>     should be to sent a CANCEL and enter "Terminated" state.

No. Timer C used to be in here, specifying the amount of time the caller
"lets the phone ring". However, this really only needs to be specified
for proxies (which is whats in bis). For the UAC, how long to let the
phone ring is entirely application specific. 

>     response, can't we just get the first R-R header on a response

Thats true for the first loop through, but not the second (or
subsequent) loops through. Remember, record-routes are not popped as you
traverse through it. 

-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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 16 May 2002 17:00:13 -0500

Jonathan:

vkg>2) Timer B controls transaction timeouts in INVITE client trans-
vkg>    actions.  The state diagram in Figure 5 is silent on what to
vkg>    do if Timer B fires while control is in "Proceeding" state; i.e.
vkg>    received a 180, but no final response.  The correct behavior
vkg>    should be to sent a CANCEL and enter "Terminated" state.

jdr> No. Timer C used to be in here, specifying the amount of time the
jdr> caller "lets the phone ring". However, this really only needs to be
jdr> specified for proxies (which is whats in bis). For the UAC, how
jdr> long to let the phone ring is entirely application specific.

Hmmm, so what happens in the following case:

UAC: INVITE sip:[email-masked]
      Expires: 30

UAS: 182 Queued 5 minutes waiting time
[after 1/2 minute]
UAS: 182 Queued 4.5 minutes waiting time

After 30 seconds, the UAC will tear the transaction down since it never
got a final response; it got provisional responses which made proxies
increase their Timer C so they were fine.  But what about the UAC?
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?

For that matter, consider the above call flow for a UAS.  The spec now
dictates (in Section 13.3.1) that if the INVITE contained an Expires
header, then the UAS should generate a 487 after the time in Expires
expires.  So based on this interpretation, should the UAS at aa.business
even accept the session since it knows that there is no way a final
response will be generated in 30 seconds and there is no way it can get
the UAC to extend the expiration time?

vkg> Should -09bis provide some guidance on timers to use in proxy cores
vkg> if serial forking is being used and > 1 Contact header is present,
vkg> or should this be left upto the implementer?

jdr> The timer value to use when moving amongst contacts depends heavily 
jdr> on the application. I suspect that normally there would be some
jdr> logic guiding the sequential operation, rather than just based on
jdr> the q values. As such, I think this is best left as implementation
jdr> specific.

I still believe that the spec will not go wrong if it provided some
guidance.  For instance, most people are tuned to picking up their
phone before 4 rings since after that it kicks over to answering
machines or voice mail servers.  4 rings is about 20 seconds.  Maybe
20 seconds is a good default for a UAC branch to be tried in case
serial forking.

vkg>3) Regarding finding the spiraled R-R on responses in order to
vkg>    modify it (section 16.7, step 8), won't it be the case that
vkg>    the first R-R in a response corresponds to the inner-most
vkg>    spiral?  Since the inner-most spiral will generate the first
vkg>    response, can't we just get the first R-R header on a response
vkg>    in order to modify it?

jdr> Thats true for the first loop through, but not the second (or
jdr> subsequent) loops through. Remember, record-routes are not popped
jdr> as you traverse through it.

Yes, of course; you are absolutely right. I conveniently forgot that
part.

Regards,

- vijay

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 17 May 2002 11:37:34 -0400

> increase their Timer C so they were fine.  But what about the UAC?

It will probably cancel after 30 seconds. I think this is the right
thing. A phone shouldn't be putting Expires in the INVITE unless it
really means it. Ultimately, its a policy issue here. The UAC has
expressed a policy, and the UAS has asked for more time. Who wins? I
say, the UAC wins, since its the one that is making the call. The
current mechanism reflects that, and you should insert Expires headers
only if thats what you want.

> not) and then dynamically updated on provisionals, just like proxies?

I'm lost. Timer B handles time outs because of no response whatsoever.

> the UAC to extend the expiration time?

It can do whatever it wants. I would be inclined to play a prompt that
says "your call won't be answered within the expiration time you've
specified. Please specify a longer time". Phones shouldn't be
arbitrarily be putting Expires in the INVITEs like that.

> 20 seconds is a good default for a UAC branch to be tried in case

It depends on the app; going to voicemail is one thing, doing a hunt
across a group of customer service reps is another thing. Both are
sequential fork, but both use different timers. I don't see the need to
overspecify this.

-Jonathan R.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 17 May 2002 11:47:29 -0500

Jonathan Rosenberg wrote:
[...]
> 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).

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.

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

Thanks,

- vijay