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

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

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.

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.

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.

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.

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

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: Tue, 17 Oct 2000 00:30:16 +0300

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

---

From: hammer michael <[email-masked]>
Date: Tue, 17 Oct 2000 09:54:45 -0700

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:

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 Oct 2000 17:00:13 +0300

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

---

From: hammer michael <[email-masked]>
Date: Tue, 17 Oct 2000 10:34:10 -0700

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?

Mike

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 Oct 2000 22:43:21 +0300

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.

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Steve Donovan" <[email-masked]>
Date: Tue, 17 Oct 2000 17:58:59 -0400

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Christer Holmberg
> Sent: Tuesday, October 17, 2000 3:43 PM
> Cc: hammer michael
> >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 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.

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.

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

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 17 Oct 2000 18:56:54 -0400

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

> 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: Christer Holmberg <[email-masked]>
Date: Wed, 18 Oct 2000 08:53:35 +0300

Hi,

>>>to do what a subordinate capability should be explicitly defined to do?
>>
>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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 Oct 2000 08:57:20 +0300

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.

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