Subject: Re: Negotiation of session-expires refresh timer

From: John Hearty <[email-masked]>
Date: Thu, 18 Feb 1999 16:48 -0600 (CST)

>> 
>> To tell the UAC to add a session timer for this session the first SPS
>> that requires session timeouts can still have the option of returning
>> such a 4xx response. Now, if the UAC adds a Session-Expires header to
>> the next INVITE request, it is assumed that the UAC understands the
>> concept of session timers and everyone is satisfied.
>
>But, if the UAC doesn't understand the session timer, the UAC gets the
>400 response, tries again (without the timer header, of course), which
>generates another 400 response, and so on.

The SIP spec states for 4xx responses that "The client SHOULD NOT retry
the same request without modification..."  It seems to me UACs should
have a minimum requirement to understand _all_ 4xx responses for the
supported SIP version, whether or not they can support the appropriate
modified re-try request, or if they don't understand the 4xx response,
don't retry the Invite.

>I think the best solution is that the UAC which is capable of using the
>session-expires should always insert it in the message, with any initial
>value it likes, or inifinity if it doesn't personally want to refresh. A
>proxy or UAS can modify the value if its there. If its not there, this
>means the UAC is unable or unwilling to refresh, so returning an error
>does not good anyway.

This should work OK, but if a proxy requires the session-expires timer,
it should still have the ability to reject the Invite, so a 4xx is
still needed.  The UAC just won't be able to retry the Invite through
that proxy when they don't support session-expires timers.

John H.
MCI Worldcom

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 18 Feb 1999 23:48:50 -0500

> modified re-try request, or if they don't understand the 4xx response,

I don't think clients should be required to understand all 4xx responses
- thats the point of having a hierarchical error namespace.

You are correct, though (thanks for the info) that they won't retry the
request. But, this means no call gets made. This means that these
forceful proxies will not complete any calls for
non-expiration-supporting clients - seems bad for business...

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: [email-masked] (Adam B. Roach)
Date: Fri, 19 Feb 1999 11:24:10 -0600 (CST)

>Jonathan Rosenberg:

Perhaps; however, I beleive you'll find that a stateful proxy which 
absolutely requires this sort of notification will tear down the call
whenever it realises that either party is unable or unwilling to provide 
session refreshes; the result is the same: uncooperative or ignorant 
clients will not be able to interoperate with such a system.

I agree with Lars Berggren on this point: A specific 4xx response 
merely makes such a failure more efficient.

Under the scenario I described to Steven (which is what has been
discussed here), such a failure would not be discovered until
after the UAS has sent its final response and is waiting for
an ACK. For most clients, this will already represent alerting
the callee and receiving a response. It would be very annoying to
receive a call, only to have it error out when I attempt to
answer it.

UAC -> SPS          INVITE
       SPS -> UAS   INVITE Session-Expires=240
       SPS <- UAS   200 OK Session-Expires=240
UAC <- SPS          200 OK Session-Expires=240
UAC -> SPS          ACK 

                    This is where the SPS detects the problem, 
                    and behaviour gets a bit funky.

       SPS -> UAS   BYE
       SPS <- UAS   200 OK
UAC <- SPS          BYE 
UAC -> SPS          200 OK 

 From a user's perspective, then, what have we seen? The caller
places a call, which is sucessfully set up. It is then immediately
torn down, for no discernable reason.

The callee receives notification of an incoming call, and decides
to answer it. In the midst of call set up, an unexplained failure
occurs.

Human nature is to try this sequence several times, tweaking
small things each time, to see if it will work ("You've almost got it,
Bill! It's ringing over here!") . Of course, we all know that it won't 
help under these circumstances.

On the other hand, with a "4xx Session-Expires Required" (probably
with some more user-friendly descriptive text), the caller receives
an error right away, without any illusion that the call is
going through. The callee never gets involved. Less annoying.
More elegant. Fewer messages.

To address your concern directly: if the SPS is willing at all to 
carry the call without a Session-Expires header, but would *prefer* 
one (eg will provide a fuller set of services if one is present), it 
would not respond with the 4xx code; it would merely insert the header
itself and check the ACK to determine whether to expect refreshes.

--
Adam Roach                 |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
Ericsson Inc.              | Fax: +1 972 669 0154 | Richardson, TX 75081
[email-masked]    |                  <*> | USA