Subject: RE: [SIP] Session-timer with INFO

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 18 Oct 2000 03:17:47 -0400

First off, I'd like to agree with others here that this is a rehash of whats
already been discussed, and decided, in the past. If we revisit every
decision every few months as new people join the lists, we'll never make
progress.

The use of INVITE along with the SDP has numerous benefits above just the
INFO approach. It allows for crash recoveries, it allows for refreshes of
session state in intermediate devices, such as proxies, and it follows the
soft-state model present in other similar protocols. Thus, it is more
general purpose of a solution. Thats been our goal with SIP - to have fairly
general purpose components that could be used to build a variety of
different services. I'll agree INFO would eliminate a message, but compared
to media, signaling is still negligable. We've been through that one umpteen
times, and the horse is very dead.

As for the question about how to make sure session timers don't keep getting
resent if the UAS doesn't support them, thats easy. It would include a
Require header in the request, listing "timer". If the UAS doesn't support
session timer, the request is rejected (no session is setup either). Now,
the UAC knows that the terminating UA doesn't support the timer. So, it can
either start the session without session timer at all by sending a new
INVITE with no Supported header and no Session-Expires header, give up, or
do session timer anyway if the proxies want it (Supported header, no
Session-Expires header).

Brett also asks if the UAC can ask to not have the session revived if the
UAS isn't active. The question really is, who gets to make that decision? Is
it realy the UAC who should ultimately decide whether a session restart is
appropriate? Since its really the UAS that needs to do it, it seems like it
should be its responsibility to decide.

-Jonathan R.

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

> -----Original Message-----
> From: Brett Tate [mailto:[email-masked]]
> Sent: Tuesday, October 17, 2000 6:57 PM
> To: [email-masked]
> Subject: Re: [SIP] Session-timer with INFO
> 
> 
> > While it is true that there are other ways that this could have been
> solved,
> > it is pretty late in the game to make this kind of a 
> change.  Especially
> if
> > the only reason for doing so is to avoid the ACK message.
> 
> Other reasons include the desire not to revive a
> dead session and to avoid the possibility of a new
> SDP in the 200 response.
> 
> >
> > As a side note, we are in the process of creating a new 
> version of the
> draft
> > that we hope will be used for working group last call.
> 
> Steve,
> 
> Can a header or parameter be defined within
> the sip-session-timer to indicate that the sender
> is just trying to extend the Session-Timer and
> check session state, but the sender does NOT
> want the session revived if it is down?  The
> reverse of the boolean value could indicate a
> request to revive the session if it is down.
> 
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

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

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 18 Oct 2000 15:42:10 -0400

> should be its responsibility to decide.

Thanks for the response.

I agree that the UAS could ultimately decide, but a
parameter/header to indicate the desire to revive or
not revive the session would be extremely useful when
making the decision.  This parameter/header would
be useful for all re-INVITEs.

Without the parameter/header, the possibility exists
that the entity originally called might unintentionally
revive a session to the original caller.  Thus assuming
calling party pays, the wrong party may be billed for it.

A 3pcc/B2BUA may be the entity sending
re-INVITEs to the call-legs on both sides.  Without the
parameter/header, the 3pcc/B2BUA might
unintentionally re-establish a released call
between 2 subscribers.