Subject: RE: [SIP] Comments on Session Timer draft

From: "Schroeder, Tim" <[email-masked]>
Date: Fri, 19 May 2000 16:31:42 -0500

The session timer draft (draft-ietf-sip-session-timer-01.txt) as written is
asymmetric, in that it seems to assume that the UAC is more likely to
impolitely abandon the session, and that the proxies and UAS need some way
to recover from that.

I'd like to see the reverse case addressed as well: where the UAC (or a
proxy) is distrustful of the UAS, and needs some way to clean up if the UAS
impolitely abandons the session.

I suppose the keep-alive re-INVITES can still be sent by the UAC, and it
will be the lack of a response (rather than the lack of an incoming message)
which informs the UAC and the proxies that the UAS has dropped off.

But in regard to the Open Issues list, I think the answer to the second
issue (should we allow the UAS to insert a Require: timer header?) should be
YES.  Just like the UAS can reject a call that won't be set up with a
session timer, the UAC should be able to avoid having a call set up without
a session timer.  It would do this by using the "Require: timer" header
rather than the weaker "Supported: timer" header.  If the UAS cannot handle
the feature, the call would be rejected, rather than set up without the
(demanded) timer feature.

And for the third Open Issue on the list, a proxy should also be able to add
the "Require: timer" header if the UAC merely "supports" but does not
"require" the feature.  Just like the proxy can tighten up the timing
requirements by lowering the expiration time, it should be able to tighten
up the requirements by making the feature "required" rather than merely
"supported".  Then, if the UAS did not implement that feature, the request
would be denied.  [This might take some more thought; it would seem odd to
the UAC for its request to end up denied for lack of a feature it did not
require.]

Alternatively, maybe there's no support needed in the UAS at all: the
re-INVITES are all sent from the UAC, and the UAS needn't know anything
about the feature to process them.  This is similar to what Lars Berggren  <
<mailto:[email-masked]> mailto:[email-masked]>
proposes:

For the Session Timer to be applied for a call leg, the specifications in
the draft requires that both the UAC and UAS understand the extension
(See example 8.5). However, since the keep-alive mechanism is achieved by
sending 'standard' re-INVITEs, it is sufficient (and useful) that at least
one of the parties is aware of the Session Timer to accomplish a
keep-alive mechanism. The usefulness of such an approach is for example
when a UAC supports 'timer', a stateful proxy server, SPS, wants to apply
a Session Timer to the call and the UAS doesn't understand the extension.

Here, the call will be setup without Session Timer even though the SPS
wanted one and the UAC could do the necessary re-inviting. The UAS doesn't
need to know about Session Timers in order to process re-INVITEs properly.
The only thing that forces that the UAS have to be aware of the Session
Timer is the statement in the draft that the UAS SHOULD send BYE if no
re-INVITE has arrived when the session expires. Well, the UAC could do the
sending of the BYE if it does not intend to update the timer.

So, to solve this problem, I would like to propose that the SPS could add
a Session-Expires header in the response if the SPS knows the UAC supports
'timer' and the response does not contain a Session-Expires header.
<<
 
At any rate, I'd like the draft to address the cases where any of the
UAC/UAS/proxy *require* the session timer feature.  I'd consider it OK for
the session to not get set up if the session timer feature weren't supported
by all (or enough) of the UAs, but not OK for the session to get set up
without a timer if one were required anywhere along the path.
 
Also, the third to the last paragraph in section 4 (beginning "A UAC may use
the refreshing re-INVITE as a normal SIP re-INVITE ...") makes no sense to
me.  It talks about sending an *updated* session description and using the
origin field to indicate the description is *unchanged*.

Tim Schroeder
[email-masked]
SBC Technology Resources, 9505 Arboretum Blvd., Austin, TX  78759

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Lars Berggren <[email-masked]>
Date: Mon, 22 May 2000 12:55:36 +0200 (CEST)

> without a timer if one were required anywhere along the path.

I agree. I think any sip device involved in the signalling could be
interested in a way to:
1) Suggest/request/propose that a timer is used.
2) Require a timer.
3) Kind of inform that resources will be released at a certain
time, regardless of whether a session timer is used or not. If no session
timer is used you just cant get 100% service. Like "Services applied in 
this call will time out, send re-INVITE to update the timeout".

I think 1 is fulfilled by the current draft. 2 will be so if any of 
the parties were allowed to add the require header. 3 would be fulfilled
if Session-Expires were allowed to be added by a proxy in both requests
and responses even if the proxy has no way of knowing whether a timer is
supported or not. I cant see the point in disallowing it.

Also, again, I think it is sufficient that one of UAS/UAC is session timer
aware to keep the session alive.

Any comments from the authors?

> origin field to indicate the description is *unchanged*.

Yes, that subsection confuses me too. Is it a typo?

/Lars

> SBC Technology Resources, 9505 Arboretum Blvd., Austin, TX  78759

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 23 May 2000 00:03:36 -0400

> which informs the UAC and the proxies that the UAS has dropped off.

Exactly. Failure of either UAC or UAS is detected with equal ease this
way.

> issue (should we allow the UAS to insert a Require: timer header?)

I think you mean UAC.

> should be

I recall that there was consensus to do this. Its easy enough anyway;
you could do it even if the draft didn't explicitly specify it.

> the UAC for its request to end up denied for lack of a feature it did not

This was discussed during the meeting and on the mailing list prior to
the meeting. The consensus was that we would allow this. A UAC
implementing session timer (i.e., supported) would need to be prepared
to receive a rejection response with code 420 even though it hadn't
inserted a Require header.

> <mailto:[email-masked]> mailto:[email-masked]>

I recall thinking about this possibility, but decided it was tricky. The
other thing the UAS must do that is not mentioend in Lars' mail is
reflect the Session-Expires header. If a UAS doesn't support session
timer, the response has no Session-Expires header, with the result is
that the proxies won't know the actual expiration time. 

> origin field to indicate the description is *unchanged*.

Thats an error. Thanks for pointing it out.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 23 May 2000 00:10:50 -0400

> supported or not. I cant see the point in disallowing it.

But the proxy does have a way of knowing - the Supported header in the
request, coupled with reflection of Session-Expires in the response. I
see no point in inserting the header if the proxy knows its not
understood.

-Jonathan R.

---

From: Lars Berggren <[email-masked]>
Date: Tue, 23 May 2000 10:11:01 +0200 (CEST)

> see no point in inserting the header if the proxy knows its not

OK, as the current draft is written, yes. But if it was changed according
to my proposal which started this thread, no.

Assume the draft was changed to state that either the UAC or the UAS
handles the sending of re-INVITE and that only one of the parties need to
be session timer aware. That is, a timer can be used even if the UAC
does not support timer. The party which sends the re-INVITEs is determined
by the content of the Supported header, if present. If the UAC claims
support for 'timer' it shall do the re-inviting. Otherwise the UAS does
it, if it supports it.

Now, with this assumptions, when a request without support for
'timer' arrives at a proxy it could add a Session-Expires header and hope
for the UAS to support it, but it has no way of knowing for sure.

Also, when a response arriving at a proxy without Session-Expires, but the
proxy knows the request claimed support for 'timer', it would be very
useful if the proxy was allowed to insert a Session-Expires header in the
response.

Instead of just allowing the proxy to add the header in these special 
cases, it could be allowed to be added in any situation since it does not
break anything.

/Lars

---

From: Lars Berggren <[email-masked]>
Date: Tue, 23 May 2000 10:28:20 +0200 (CEST)

> that the proxies won't know the actual expiration time. 

Proxies that insist on knowing the actual expiration time can include a
'Require: timer' in the request. 

For other proxies I suppose the Session-Expires could be added and 
eventually decremented in the response-path as well. The proxies will know
that the expiration time is not greater than the one they saw/added. And
if it is needed, the UAC could reflect the actual expiration time in the
ACK. It is not tricky.

/Lars