Subject: [SIP] Comments on Session Timer draft

From: Lars Berggren <[email-masked]>
Date: Tue, 16 May 2000 14:53:14 +0200 (CEST)

After reading the draft-ietf-sip-session-timer-01.txt I have some
comments.

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.
Consider the example 8.5 in the draft:

>   Calling UA -> SPS
>          INVITE
>          k: timer
>
>   SPS -> Called UA
>          INVITE                    SPS adds S-E header
>          k: timer
>          Session-Expires: 180
>
>   SPS <- Called UA
>          200 OK            Called UA doesn't understand session timer
>
>   Calling UA <- SPS
>          200 OK
>
>   Calling UA -> SPS
>          ACK
>
>   SPS -> Called UA
>          ACK

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.

Another similar situation occurs when the UAC does not support 'timer' but
the UAS does. Then, according to the draft, the SPS MUST NOT add a
Session-Expires header. If the SPS were allowed to add such a header also
in this case, the UAS could do the refreshes and the 'timer' would be
applied. The UAS would simply look at the Supported header, if present. If
the request states support for timer, the UAS knows the UAC does the
re-inviting, otherwise the UAS will do it.

A useful semantic that the proxy can signal with this proposal is "I'm
giving you a service here, but only for a limited period of time if you do
not request to refresh the service". As opposed to the current draft that
limits the SPS expressivness to "I require that you support session timer
to get my service" or "Please, use the session timer".

Apologies if I have missed something fundamental.

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

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

---

From: "Schroeder, Tim" <[email-masked]>
Date: Tue, 23 May 2000 17:34:40 -0500

I was reading some of the old messages commenting on the session timer
draft, and there was a long discussion about whether re-INVITE or some other
method was the "correct" method to use to refresh the timer.  A re-INVITE
might set up a session that had fallen down, which was perceived to be good.
There were issues with Cseq space (addressed by basing them on a local
clock), routes (addressed by proxies adding Record-Route to every request
they see, media intolerant of sessions being set up again without being
cleanly torn down first, and tags.  (I didn't see anything addressing the
last two.)

I'm wondering, though, why the feature must require any specific method at
all.  If the user agent wants the behavior of re-INVITE, it could send
re-INVITEs to refresh the timer.  If it doesn't it could send an INFO.  In
fact, if it were sending "real" re-INVITES anyway (to adjust the media),
there'd be no need to send another one just to refresh the timer.  Or if it
were sending INFO messages anyway (perhaps to keep track of some billing
stuff), there'd be no need to send any sort of re-INVITE or INFO just to
refresh the timer.  And if the user agent were *receiving* messages of any
type from the far end, it would also be able to skip the timer refresh
messages.

Maybe the draft could say that *any* message (sent or received) would
refresh the timer?  And if the timer were about to expire, that only then
must a message be sent?  And it could suggest any of a re-INVITE, or an
INFO, or ...  -- the exact message type wouldn't matter, only that one was
sent or received.

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