Subject: RE: Negotiation of session-expires refresh timer

From: "Donovan, Steven R. (MCI)" <[email-masked]>
Date: Thu, 18 Feb 1999 22:21:47 -0000

> -----Original Message-----
> From:	Jonathan Rosenberg [SMTP:[email-masked]]
> Sent:	Thursday, February 18, 1999 3:07 PM
> To:	Lars Berggren
> Cc:	Donovan, Steven R. (MCI); Conference Control List
> Subject:	Re: Negotiation of session-expires refresh timer
> 
> Lars Berggren wrote:
> > 
> > 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.
> 
> 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.
> 
	I agree, however, there needs to be a method for the proxy server to
understand whether or not the UAC will be doing refreshes.  This can be
achieved by the UAC including the final "negotiated" session-expires header
in the ACK to the 200 OK.  A UAC that cannot, or chooses not to, send
refresh INVITEs would not include a session-expires header in the ACK
message.  It would be up to the proxy server to decide what to do if the UAC
does not include the session-expires header.

> -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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 18 Feb 1999 23:42:51 -0500

> Donovan, Steven R. (MCI) wrote:
> 
>      I agree, however, there needs to be a method for the proxy server
>      to understand whether or not the UAC will be doing refreshes.
>      This can be achieved by the UAC including the final "negotiated"
>      session-expires header in the ACK to the 200 OK.  A UAC that
>      cannot, or chooses not to, send refresh INVITEs would not include
>      a session-expires header in the ACK message.  It would be up to
>      the proxy server to decide what to do if the UAC does not include
>      the session-expires header.

My mechanism for determining whether the UAC will do refreshes was
whether it included the Session-Expires header in the request in the
first place. This indicates that the UAC *is* willing to do them. If it
is not, or cannot, it doesn't put the header in the request message.

Your approach has the benefit that there is another decision round
possible. The UAC can decide to add the Session-Expires to the request,
and then the response comes back with a refresh value that is
unacceptable to the UAC (too low, perhaps). The UAC can then refuse it
by not putting the Session-Expires in the ACK.

A potential problem with the approach is with forking proxies:

A---->B---->C--->F
      |     ^
      |     |
      \/    |
       D--->E

A is the UAC, F the UAS. B,C,D,E proxies. B forks. Now, F sends a 200 OK
in response to both the A-B-D-E-C-F and A-B-C-F request. The latter
arrives first at A. All proxies are adding record routes and want
refreshes. Now, the ACK is sent along A-B-C-F, so D and E never see an
ACK. They should actually time out call state (they will time out SIP
transaction state). But, they are waiting for the timeout from the ACK,
not the response, which they never get. So, how do D and E determine how
long to wait before deciding that an ACK will never come? I guess they
could extract the timer from the response, and then if an ACK comes, use
the timer there instead. Seems a bit complex for little gained.

By having the final timer value be the one in the response, behavior is
consistent and straightforward.

-Jonathan R.