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

From: "Brian Stucker" <[email-masked]>
Date: Thu, 19 Oct 2000 14:26:37 -0500

Your correct, I can't stop the UAC from sending the method again, but I'd
like to plead to as many implementors as I can that it would definitely be
preferable in any setting if you wouldn't. =)

Brian

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Tuesday, October 17, 2000 9:00 AM
To: [email-masked]
Cc: hammer michael
Subject: Re: [SIP] Session-timer with INFO

Hi,

If I send you an INFO, or any other method that you don't support, you
can for example send a 501 Not Implemented response, and include an
Allow header with the methods you support. Of course, you can't stop the
UAC of sending the method again, if he chooses to...

You can not, however, tell an UAC not to send you re-INVITEs, because
then you would also forbid the UAC to send you INVITEs - and I don't
think you want to do that. Also, the specification says that a UA MUST
be able to receive INVITEs (which included re-INVITEs), so...

Regards,

Christer Holmberg
Ericsson Finland

hammer michael wrote:
> 
> Is this the Internet version of "let them eat cake?"  Signal-spam is not
> more palatable than the normal variety.
> 
> Is there a response code that can indicate the sentiment:  I don't support
> this method, don't try it again?  It might also be good to make sure that
> such undesirable sub-methods are indicated as "Unsupported."  If that
> sub-method is well-defined, then that header parameter should be
applicable.
> 
> Mike
> 
> At 12:30 AM 10/17/2000 +0300, Christer Holmberg wrote:
> 
> >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
> > >
> > > -----Original Message-----
> > > 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
> > >
> > > 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: Fri, 20 Oct 2000 13:12:19 +0300

Hi,

I think this issue is also related to another thread, 'Source
Routing/Route out of band'. If the reason for using re-INVITE is that
booted stateful proxies can re-establish the session, but they don't
support Routes in a new INVITE, I guess it will not work. Of course, an
INFO would not pass that proxy either, so it is a general problem, and
does not only affect the session-timer functionality.

Christer Holmberg
Ericsson Finland

> Brian Stucker wrote:
> 
> Your correct, I can't stop the UAC from sending the method again, but
> I'd like to plead to as many implementors as I can that it would
> definitely be preferable in any setting if you wouldn't. =)
> 
> Brian
> 
> > > > From: Culpepper, Bert
> [mailto:[email-masked]]
> > > > > From: Christer Holmberg
> [mailto:[email-masked]]