Subject: [SIP] Session-timer with INFO

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 Oct 2000 20:55:07 +0300

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

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 16 Oct 2000 12:21:06 -0700

Hi,

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

>taken into consideration.

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 Oct 2000 22:41:50 +0300

Hi,

Thanks for the comments!

>is down), or a 501 (you know the UA is up, but is the call?)

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

---

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

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.

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

---

From: Lars Berggren <[email-masked]>
Date: Tue, 17 Oct 2000 10:06:06 +0200 (CEST)

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

Regards /Lars

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 17 Oct 2000 13:43:22 +0200

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

--
Anders Kristensen

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 Oct 2000 16:11:26 +0300

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

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 17 Oct 2000 15:17:13 +0200

I actually agree with you (except I would have used a new method rather
than INFO). 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. Anyway, maybe you should
post the archive pointer and then we can at least have a fully informed
discussion.

Anders

---

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

Hi,

>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: Lars Berggren <[email-masked]>
Date: Tue, 17 Oct 2000 16:29:58 +0200 (CEST)

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

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.

Regards,

/Lars

---

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

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.

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