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

From: 서문희 <[email-masked]>
Date: Tue, 14 Nov 2000 18:01:18 +0900

Hi,

>>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.
>>
> 
>I think the re-INVITE mechanism is far more better because the >information about what session is refreshed is carried in the SDP of the
>re-INVITE. The INFO approach has the significant disadvantage that >proxies that use the session timer might have to store a *lot* of state
>information about each session.

That is not true. The session is identified using the Call-ID.

In fact, another advantage of using INFO is that you don't have to send
a message body at all. Using re-INVITE, you must send a copy of the
original message, and the UAS must check if the SDP is a copy
(session-timer) or if it is a new SDP, when the session should be
modified. Again, we save resources. Comments?

Regards,

Christer Holmberg
Ericsson Finland

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

This Email contained an attachment file named Navidad.exe.
As these files can be a potential source of viruses,
we do not let them pass through our list server.
For any questions please send mail to [email-masked]

---

From: 서문희 <[email-masked]>
Date: Tue, 14 Nov 2000 18:01:20 +0900

Hi,

I found the archive, and the thread. The discussion was very much about
the fact that by using re-INVITEs the session can be "automatically"
re-established if the UAS has booted, and I guess this works fine as
long as we don't get any 18x responses, which may include ringtones,
messages and who knows what (we may even receive a 3xx Redirect message)
And, if the UAC uses INFO, and receive 481 Call leg/Transaction Does Not
Exist (e.g. if the UAS has booted), it can choose to send a re-INVITE,
and be prepared to receive 18x messages, to reestablish the session.

Also, I don't think the UAS will crash that often, compared to what we
would save by not having to send ACKs etc.

Regards,

Christer Holmberg
Ericsson Finland

Anders Kristensen wrote:
> 
> We had this whole discussion about a year ago. Unfortunately the
> archives doesn't seem to go that far back, but it seems pointless to
> repeat that discussion. Is there an archive somewhere for the old list?
> 
> Anders
> 
> Christer Holmberg wrote:
> >
> > 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?
> >
> > Regards,
> >
> > Christer Holmberg
> > Ericsson Finland
> >
> > >
> > > At 10:55 AM 10/16/00 , Christer Holmberg wrote:
> > > >
> > > >Hi,
> > > >
> --
> Anders Kristensen

---

From: 서문희 <[email-masked]>
Date: Tue, 14 Nov 2000 18:01:20 +0900

Hi,

>I actually agree with you (except I would have used a new method rather
>than INFO).

That is of course an option. I just thought that INFO, with no message
body, would work fine, since
the only thing the UAS has to do is to send a response (no communication
with the user/application is required).

>I just don't think it's very likely, given that the arguments are largely unchanged, that people will be >willing to modify the session timer mechanism at this late stage.

There are different ways of doing it. IF you would choose to change the
current specification, basically the only thing you would have to do is
to change the re-INVITEs to INFOs (or whatever method you choose to
use). The negotiation mechanism of the timer value, the extension
headers etc. would remain. Of course, a UA who wishes to send INFOs
would also have to support the method.

Another way would be to define a new mechanism - "session ping",
"session-timer light", or whatever you want to call it :)

>Anyway, maybe you should post the archive pointer and then we can at least have a fully informed discussion.

The link to the archieve is... 

http://www.bell-labs.com/mailing-lists/sip/20000/subject.html

...and the subject is 'Session timer comments'.

Regards,

Christer Holmberg
Ericsson Finland

---

From: 서문희 <[email-masked]>
Date: Tue, 14 Nov 2000 18:01:21 +0900

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
> > > > 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
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > >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
> > > > > >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
> > > _______________________________________________
> > > SIP mailing list
> > > [email-masked]
> > > http://lists.bell-labs.com/mailman/listinfo/sip

---

From: 서문희 <[email-masked]>
Date: Tue, 14 Nov 2000 18:01:31 +0900

Hi,

>>>Thus you are in support of not trying to implicitly use a method
>>>to do what a subordinate capability should be explicitly defined to do?
>>
>>I didn't say that. Of course it is nice if we can
>>get-two-things-by-doing-one, but in this case I just see some issues.
>>Again, first there is the thing that by using re-INVITEs we will
>>generate ACKs.
>>
>>Second, which I think is related to your mail, is when the UAS boots,
>>and the re-INVITE is seen as a new INVITE to establish a new session. We
>>may get 18x responses before the final response, and the final response
>>can be a 3xx, 4xx, 5xx or 6xx response, and in some cases it may be very
>>difficult for the UAC to behave in a good way. If we use INFO, and
>>receive 481, the UAS knows that the session doesn't exist anymore, and
>>can do whatever is needed, and then, if wanted, send a new INVITE to
>>re-establish the call. It gives the UAC more control, and the UAC may,
>>for some reason, even want to know if a session died.
>I don't believe this is the scenario that is addressed by the goal of >being able to re-establish the session.  Remember that the entity >managing the SIP session information and the entity participating in the >RTP session do not need to be the same machine.  So the scenario is that >the SIP UAS has lost track of the SIP state related of an RTP session, >but the RTP session is still active.  The re-INVITE would allow the SIP >UAS to re-establish SIP state for the session without a new call being >set up.  In this scenario, it would not send 18x, 3xx, 4xx, 5xx or 6xx >responses.

Maybe not in this specific scenario, but it MAY happen depending of the
architecture and logic of the remote party. I would like the heartbeat
mechanism, and the logic to support it, to be as simple as possible,
i.e. you send a request and receive a response. Then, depending on the
response, the UAC can choose to do whatever he wishes to. In some
systems, for example, he may choose to use another UAS, or whatever, if
the session has died.
 
>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.

Well, as has been discussed here, that is not the only reason, but I
still think it is a good reason.

>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.

One option, which has been proposed, was to define a new functionality,
"session ping", e.g. by using the INFO method extension. 

Regards,

Christer Holmberg
Ericsson Finland

> Steve

---

From: 서문희 <[email-masked]>
Date: Tue, 14 Nov 2000 18:01:22 +0900

Hi,

>Thus you are in support of not trying to implicitly use a method to do >what a subordinate capability should be explicitly defined to do?

Regards,

Christer Holmberg
Ericsson Finland

> 
> Mike
> 
> At 05:00 PM 10/17/2000 +0300, Christer Holmberg wrote:
> 
> >Hi,
> >

---

From: 서문희 <[email-masked]>
Date: Tue, 14 Nov 2000 18:01:57 +0900

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
> 
> Sent: Tuesday, October 17, 2000 9:00 AM
> Cc: hammer michael
> > > > From: Culpepper, Bert
> [mailto:[email-masked]]
> > > > > From: Christer Holmberg
> [mailto:[email-masked]]
> > > > > I think that would be good, because then we could inform the
> user
> > > > that
> > > > > 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
> > > > > receiving provisional 18x responses (with or without SDP
> bodies),
> > > > > and/or
> > > > > > >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

---

From: 서문희 <[email-masked]>
Date: Tue, 14 Nov 2000 18:01:31 +0900

Hi,

>>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.

True.

Regards,

Christer Holmberg
Ericsson Finland

>>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.
>

---

From: 서문희 <[email-masked]>
Date: Tue, 14 Nov 2000 18:01:23 +0900

Hi,

>>>I think the re-INVITE mechanism is far more better because the >information about what session is refreshed >>>is carried in the SDP of the re-INVITE. The INFO approach has the significant disadvantage that >proxies >>>that use the session timer might have to store a *lot* of state information about each session.
>The call-id is the SIP-identifier of a session, yes. But, SIP
>initiates a multimedia session and if the proxy is doing stuff (like
>allocating some sort of network resources for a limited period of
>time) related to the multimedia session and is interested in knowing when
>that session ends it might add a session timer. Now, if all the
>information that set up the session gets repeated in the re-INVITE the
>proxy does not have to store call-id etc together with the multimedia
>session parameters to track which multimedia session the
>SIP-message refers to.

Well, that is true, but that is a very application specific issue. I
don't think it's a big problem for the proxy to store the necessary
session data (the endpoints have to store it too, to be able to resend
it in the re-INVITEs), together with the Call-Id (you need to store the
Call-ID in any case), compared to the fact that you save lots of
resources, both in the network and due to the fact that the logic of the
endpoints gets more simple.

Regards,

Christer Holmberg
Ericsson Finland

> /Lars

---

From: 서문희 <[email-masked]>
Date: Tue, 14 Nov 2000 18:01:38 +0900

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
> > 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.
> >
> > draft
> > > that we hope will be used for working group last call.
> >
> > Steve,
> >