Subject: RE: Negotiation of session-expires refresh timer

From: "Donovan, Steven R. (MCI)" <[email-masked]>
Date: Fri, 19 Feb 1999 14:57:51 -0000

> -----Original Message-----
> From:	Jonathan Rosenberg [SMTP:[email-masked]]
> Sent:	Thursday, February 18, 1999 10:43 PM
> To:	Donovan, Steven R. (MCI)
> Cc:	Lars Berggren; Conference Control List
> Subject:	Re: Negotiation of session-expires refresh timer
> 
> > Donovan, Steven R. (MCI) wrote:
> > 
> >      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.
> 
> 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.
> 
	SRD> Jonathan, I'm a little confused.  The session-expires timer
does not apply to session control signaling.  It only applies after the
session has been successfully setup.  The above scenario appears to be a
general problem for forking proxy scenarios.  What happens depends on the
behavior of B, the forking proxy.  If it sends a CANCEL to the second 200 OK
then there will be no problem.  If it doesn't, then the originating user
agent will need to handle the multiple 200 OKs.  The SIP spec implies that
an ACK is sent for the subsequent 200 OKs.  The Record-Route behavior should
force the ACK to get delivered to D and E.

	SRD> Or am I missing something?

> -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: Sat, 20 Feb 1999 01:26:21 -0500

>      does not apply to session control signaling.  It only applies
>      after the session has been successfully setup.  The above
>      scenario appears to be a general problem for forking proxy
>      scenarios.  What happens depends on the behavior of B, the
>      forking proxy.  If it sends a CANCEL to the second 200 OK then
>      there will be no problem.  If it doesn't, then the originating
>      user agent will need to handle the multiple 200 OKs.  The SIP
>      spec implies that an ACK is sent for the subsequent 200 OKs.  The
>      Record-Route behavior should force the ACK to get delivered to D
>      and E.
> 

No, I had forgotten about the CANCEL's. I guess putting the timer in the
ACK or reading it from the response is a wash.

-Jonathan R.