Subject: Negotiation of session-expires refresh timer

From: "Donovan, Steven R. (MCI)" <[email-masked]>
Date: Wed, 17 Feb 1999 09:08:39 -0700

One of the things that had been bothering me about the draft as it exists is
the interaction of multiple proxy servers interested in session timers.  If
the first proxy server has a desired refresh period longer then the second
then the following could occur (I have added the concept of including the
acceptable session expires in the 4xx response, which at a minimum needs to
be added to the existing draft):

UAC  -> SPS1 INVITE Session-Expires=180
SPS1 <- UAC  4xx Session-Expires=120
UAC  -> SPS1 INVITE Session-Expires=120
SPS1 -> SPS2 INVITE Session-Expires=120
SPS2 <- SPS1 4xx Session-Expires=100
SPS1 <- UAC  4xx Session-Expires=100
UAC  -> SPS1 INVITE Session-Expires=100
SPS1 -> SPS2 INVITE Session-Expires=100
SPS2 -> UAS  INVITE Session-Expires=100
UAS  <- SPS2 4XX Session-Expires=90

etc., etc, etc.

This is clearly not a desirable situation and is made worse by the inclusion
of more proxy servers.

I would assert that the following behavior, suggested in an offline note by
Adam Roach, is better.  The concept here is that the Proxy Servers and the
UAS would have the ability to adjust the value of the Session-Expires header
to their liking (although it could only be adjusted down).

UAC  -> SPS1  INVITE Session-Expires=180
SPS1 -> SPS2  INVITE Session-Expires=120
SPS2 -> UAS   INVITE Session-Expires=100
UAS  <- SPS2  200 OK Session-Expires=90
SPS2 <- SPS1  200 OK Session-Expires=90
SPS1 <- UAC   200 OK Session-Expires=90
UAC  -> SPS1  ACK Session-Expires=90
SPS1 -> SPS2  ACK Session-Expires=90
SPS2 -> UAS   ACK Session-Expires=90

This way no new messages have been added to achieve the negotiation of
acceptable session refresh timers.

At any time during this process, the proxy servers or UAC could CANCEL the
session setup if the negotiated timers are not acceptable.

Another variant of this would be if the initial invite from the UAC did not
contain a session-expires header.  In this case, the SPS1 would have the
ability to add a session-expires header to the INVITE that is sent on to the
SPS2, instead of explicitly rejecting the INVITE and requiring the UAC to
initiate a new INVITE.

UAC  -> SPS1  INVITE (no session-expires header)
SPS1 -> SPS2  INVITE Session-Expires=120
SPS2 -> UAS   INVITE Session-Expires=100
UAS  <- SPS2  200 OK Session-Expires=90
SPS2 <- SPS1  200 OK Session-Expires=90
SPS1 <- UAC   200 OK Session-Expires=90
UAC  -> SPS1  ACK Session-Expires=90
SPS1 -> SPS2  ACK Session-Expires=90
SPS2 -> UAS   ACK Session-Expires=90

Thanks to Adam for the suggestion.

Thoughts...

Steve

---

From: Lars Berggren <[email-masked]>
Date: Thu, 18 Feb 1999 10:27:42 +0100

Donovan, Steven R. (MCI) wrote:
> 
> One of the things that had been bothering me about the draft as it
> exists is the interaction of multiple proxy servers interested in
> session timers.  If the first proxy server has a desired refresh
> period longer then the second then the following could occur (I have
> added the concept of including the acceptable session expires in the
> 4xx response, which at a minimum needs to be added to the existing
> draft):
> 
> This is clearly not a desirable situation and is made worse by the
> inclusion of more proxy servers.
> 
> I would assert that the following behavior, suggested in an offline
> note by Adam Roach, is better.  The concept here is that the Proxy
> Servers and the UAS would have the ability to adjust the value of the
> Session-Expires header to their liking (although it could only be
> adjusted down).
> 
> At any time during this process, the proxy servers or UAC could CANCEL
> the session setup if the negotiated timers are not acceptable.
> 
> Another variant of this would be if the initial invite from the UAC
> did not contain a session-expires header.  In this case, the SPS1
> would have the ability to add a session-expires header to the INVITE
> that is sent on to the SPS2, instead of explicitly rejecting the
> INVITE and requiring the UAC to initiate a new INVITE.
> 

Yes, this is a better approach.

I don't know if you are planning to replace or extend the behaviour of
SPS:s in the session-timer draft, however, if replacing is what you are
thinking of, I guess that the proposed 4xx responses will not be used
any more and I have some thoughts on this...

In the case where the initial INVITE from the UAC did not contain a
Session-Expires header, the '4xx Session-Expires Header Required'
response message could still be useful.

If the UAC did not provide a Session-Expires header in the INVITE and
some SPS added one, there is a chance that the UAC does not understand
the Session-Expires header in the response.

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.

Lars

-- 
Lars Berggren       <[email-masked]>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 18 Feb 1999 16:06:40 -0500

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

-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