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

From: "Culpepper, Bert" <[email-masked]>
Date: Mon, 16 Oct 2000 15:38:11 -0500

Some things to think about.

I believe INFO is _not_ to be used to modify the state of a session.  I
suppose a debate is possible about session-timer affecting session
state - present vs. future and if INFO is only restricted to one.  But it's
probably best to leave it alone.  Also, the INV-200-ACK exchange
allows multiple parties to agree on the duration of the session.  If the
recipient of the INFO request wants a smaller value (because its
heartbeat interval is shorter) for the session timer it would have to
send its own INFO request (unless you plan to keep the proposed
Session-expires header and its use in a 200 OK).  Now four
messages are needed.  In addition, there may be proxy issues when
using INFO.  There's other behavior described in the draft too.

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Monday, October 16, 2000 3:42 PM
> To: [email-masked]
> Cc: Rohan Mahy
> Subject: Re: [SIP] Session-timer with INFO
> 
> 
> 
> Hi,
> 
> Thanks for the comments!
> 
> >If the UA crashed and rebooted and forgot about the old session, it
> would
> >respond with either a 481 call leg doesn't exist (you would know the
> call
> >is down), or a 501 (you know the UA is up, but is the call?)
> > 
> >thanks,
> >-rohan
> 
> I think that would be good, because then we could inform the user that
> the call doesn't exist anymore.
> 
> Let's assume the UAS crashes, reboots and the UAC sends the
> session-timer re-INVITE. If the UAS has forgotten about the old
> session
> it would consider the re-INVITE as a new INVITE, for a new session. It
> would try to establish a new session - and we could suddenly start
> receiving provisional 18x responses (with or without SDP bodies),
> and/or
> a 200 response with a SDP body, to the session-timer re-INVITE. What
> do
> we do then? 

Well, you could ignore the provisional responses (you know the other end
is confused) and let the session get re-established or decide to terminate
the session with CANCEL/BYE.

Regards,
Bert

> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> 
> 
> 
> 
> > 
> > At 10:55 AM 10/16/00 , Christer Holmberg wrote:
> > >
> > >Hi,
> > >
> > >First, this mail is NOT a proposal for a change. I would just like
> to
> > >hear some opinions - or maybe it has already been discussed on the
> list?
> > >
> > >The INFO Method RFC says that for INFO requests without a message
> body,
> > >a server supporting INFO MUST respond with response code 200. So,
> my
> > >question is: why couldn't INFO be used for the session-timer
> > >functionality? Is the ACK the (re-)INVITE provides really necessary
> for
> > >the purpose?
> > >
> > >And, like the session-timer is defined now, the other party would
> not
> > >even have to support the INFO method, because a 501 Not Implemented
> > >would be sent, and the sender of the INFO would know the session is
> > >"alive".
> > >
> > >Just some thoughts... Please let me know if there is something I
> haven't
> > >taken into consideration.
> > >
> > >Regards,
> > >
> > >Christer Holmberg
> > >Ericsson Finland
> > >
> 

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 Oct 2000 23:57:09 +0300

Hi,

>I believe INFO is _not_ to be used to modify the state of a session.

Well, I guess it depends on how you define modifying the session. The
session-timer re-INVITE doesn't change the state of the session either.
Of course, if there is no response to the request, or if a request is
not received before the timer expires, we will change the state of the
session by releasing it, but that could happend in other cases too.

>I suppose a debate is possible about session-timer affecting session
>state - present vs. future and if INFO is only restricted to one.  But >it's probably best to leave it alone.  Also, the INV-200-ACK exchange
>Session-expires header and its use in a 200 OK).

That was my idea. I did not plan to remove the headers related to the
session-timer, just to change the request method used for the heartbeat.

Regards,

Christer Holmberg
Ericsson Finland

>Now four messages are needed.  In addition, there may be proxy issues >when using INFO.  There's other behavior described in the draft too.
>

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 16 Oct 2000 16:58:36 -0500

Hi,

Yeah, I knew that this method is already in there, and that there is a
re-INVITE method that's worse from the viewpoint of number of messages. I'm
just throwing things out there for people to consider when thinking about
these types of mechanisms in their designs (and a draft suggests one way of
doing things, not necessarily always the best way of doing things). I
strongly suspect that this mechanism was considered as part of a relatively
high-bandwidth, low jitter network environment with a relatively small
number of users.

It seems to me that there are those who would like to solve every problem
that they come across by throwing more bandwidth at it, which is fine if
you've got tons of bandwidth to spare (I definitely don't consider bandwidth
free) and are running on a network with low jitter. Not everyone has that
luxury, and by pinning them down by requiring them to support a solution
that does not work well in other environments means just that more people
are going to do one of two things:

1. Not be completely compliant to all RFCs and drafts.
2. Not implement SIP for their solution.

That's why I was saying that it's a bad idea to rely on a 501 response to an
INFO for keep-alive purposes. The other guy is telling you in a SIP
compliant manner that he doesn't want you to send him INFO messages for
whatever reason (just doesn't support it, or doesn't want them clogging up
their network). Even though this mechanism is compliant to the protocol, I
wouldn't characterize it as being compliant to the spirit of the protocol
(although it is ingenious).

Brian Stucker
Nortel Networks

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, October 16, 2000 4:30 PM
To: [email-masked]
Cc: Stucker, Brian [RICH2:WI12:EXCH]
Subject: Re: [SIP] Session-timer with INFO

Hi,

>Good points. Here's one more problem you may want to consider.
>Whenever you invoke a ping-style method of deciding if a session is
>alive, you open up problems due to network jitter and bandwidth. For
>instance, you could easily have a packet delayed at an endpoint due to
>a large file transfer starting up, or some other bandwidth consuming
>event. In this case, your ping could be delayed long enough to cause
>the session to drop for no good reason.

Well, this could be the case no matter which method (INVITE, INFO, or
whatever...) you use in the heartbeat request...
 
>You're also creating the potential for artificial problems in wireless
>networks by using a ping-method to keep a session alive. During a
>handover there may be a period where packets are in effect "muted" for
>a short period of time. The mute period may not, by itself be long
>enough to trigger a ping-timer to pop and kill the session, but if the
>ping was near the edge of the time envelope to be accepted as
>"on-time" anyhow, once again, your session could very easily drop when
>the media was operating just fine.
>Also, keep in mind, the longer you set the ping timer for, the more
>network resources you will likely waste over time because of the
>additional latentcy in discovering a "dead" session.

Just to clarify, this "ping-method" IS already defined for SIP
(draft-ietf-sip-session-timer-02.txt), and re-INVITEs are used to ping.
My idea was about replacing the re-INVITE with INFO, which mean we would
actually save resources since we don't have to send ACK every time.
 
>This method has one other nasty side-effect. You'd be wasting network
>resources on an event that will likely not occur very often. After
>all, every INFO exchange except the very last one that invalidates the
>session could have very well not been sent without any negative impact
>on the session (otherwise they would have been the last one). So
>you've got proxies and UAs, and other transport resources being tied
>up processing packets that by and large are providing no value, and
>they're chewing up bandwidth budget that other services could be using
>instead.

That is an interesting point, and it is valid also for a number of other
SIP extensions where extra messages are sent (e.g. PRACK), but it is
another discussion.
 
>Please keep in mind that not everyone is looking at implementing SIP
>on a 10Mbit+ hardwired LAN (or has to scale up to tremendous numbers
>of users), pinging and triangle-routing can be the death-knell of
>these sorts of networks.

Who said "bandwidth is free"? :)
 
>Because of all of this, I think it would be a very bad idea for a UA
>to send an INFO to a client who repeatedly tells him "I don't
>understand INFO" to see if he's alive.

The number of messages on the network will be the same no matter if we
send an INVITE which he understands, or an INFO he may not understand.
Also, when we receive the response for the INVITE we also have to send
back an ACK, which is not the case when INFO is used.

>He may not understand INFO because that particular network doesn't deem
>the bandwidth required for this mechanism as being best used for that
>purpose. If someone tells you "don't send me this method" then don't send
>it to them.

Again, this has nothing to do with the bandwith issue. Even if I send
re-INVITEs, which the other party understands, he can not tell me not to
send any more re-INVITEs.

>Otherwise your implementation may be viewed as favorably as the record
>clubs that used to require you to send them a card every month telling
>them not to send you anything by some groups.

Well, it's not up to me to decide when and if an operator will use the
session-timer, as defined in the draft, or not - I am just trying to
make it as good (and less resource consuming) if he choses to.

Regards,

Christer Holmberg
Ericsson Finland

> Brian Stucker
> Nortel Networks
> From: Culpepper, Bert [mailto:[email-masked]]
> Sent: Monday, October 16, 2000 3:38 PM
> To: Christer Holmberg; [email-masked]
> Cc: Rohan Mahy
> Subject: RE: [SIP] Session-timer with INFO
> 
> I

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 Oct 2000 11:14:54 +0300

Hi,

>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 don't want to change the current draft, because it does provide a very
mechanism to keep sessions alive, and I agree that it would not take us
anywhere if we change things every time someone has a different opinion.

My point it is very "heavy", both on the network and the endpoint logic,
if the only thing I want is a session heartbeat on the signaling level.
Of course, I can personally chose to send INFOs wherever I want, but I
don't
think that is a good thing to do. And, that way no negotiation of the
timeout value, and of which party should send the messages, is possible,
why it would be much better to have a standard way on how to do it.

Regards,

Christer Holmberg
Ericsson Finland

>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
> 
> 
> > From: Brett Tate [mailto:[email-masked]]
> > Sent: Tuesday, October 17, 2000 6:57 PM
> > > 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.
> >
> >
> >