Subject: Session timer comments

From: Anders Kristensen <[email-masked]>
Date: Mon, 13 Mar 2000 13:20:52 +0000

A couple of comments on the session timer draft...

The first is that I think it would be better if timer refreshing used a
method other than INVITE, say TIMER-REFRESH. There are several drawbacks
to reusing INVITE:

  o UAC must send a superfluous ACK for timer refresh responses
  o timer refresh INVITEs must carry a body which has no use
    whatsoever
  o overloading INVITE makes logic in UAS more complex
  o UAS may respond with non-200 which really doesn't make
    sense for timer refresh

Secondly, on the open issues

   o Should we allow the UAC to insert a Require header in the
     request, indicating that the UAS must support the session
     timer?  (I think no)

This is allowed as per the definition of extensions and the Require
header. Why would you go out of your way to disallow it in this case?

   o With this draft (and the previous versions), there was no way
     for the proxy to reject the call if the calling UA supported
     the session timer, but the called UA didn't. Is this a
     problem? If so, what can be done about it? (I think there is
     nothing we can do, and we should not worry about it)

This seems to me to be a big problem. It means there are circumstances
under which a call-statefull proxy *cannot* protect itself against DoS
attacks. It *must* allow the session to proceed without timers.

Fortunately there may be a simple solution: when a UAC sends an INVITE
through a proxy indicating that it supports the 'timer' extension but
without either "Require: timer" and "Session-Expires:" headers the proxy
inserts a "Require: timer" before forwarding the INVITE:

  UAC -> Proxy
          INVITE
          Supported: timer

  Proxy -> UAS
          INVITE
          Supported: timer
          Require: timer

  Proxy <- UAS
          420 Bad Extension
          Unsupported: timer

  UAC <- Proxy
          420 Bad Extension
          Unsupported: timer

This means that an INVITE which indicates support for session timers but
without "Require: timer" can fail with "Unsupported: timer". This may
seem a bit odd, but as we're defining an extension here we can just
mandate that UACs must understand this response.

A proxy which is willing to let the call go ahead without session timers
may of course still choose not to insert the Require: timer header.

Anders

-- 
Anders Kristensen <[email-masked]>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Mar 2000 02:18:25 -0500

>   o UAS may respond with non-200 which really doesn't make

I'm not sure I agree with this. As a general rule, protocols which have
refreshes use the same message for refresh as the original thing. I
agree ACK is superflous, but I think its good to stick with this model.
If a non-200 response comes to a re-INVITE refresh, it makes perfect
sense. Its the same thing as when a re-INVITE that changes session
parameters is rejected.

I don't consider this overloading re-INVITEs; yes, there is additional
logic to process the timer, but thats the case for any header in a
request. Overloading is when the header makes the meaning of the method
something different. I don't think thats the case here.

> header. Why would you go out of your way to disallow it in this case?

Hmm, I suppose you're right. OK, we can allow them.

> inserts a "Require: timer" before forwarding the INVITE:

Interesting idea. It might work. A few issues:

1. If the request is signed, and the Require header is below the
Authorization header, the proxy can't muck with it. 
2. The UAC is going to be confused. It sent a request without a Require
header, and gets a 420 listing some random extension as being
Unsupported. What does it do then? 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 22 Mar 2000 12:03:08 +0000

> sense. Its the same thing as when a re-INVITE that changes session

A non-200 status makes sense in responses to "traditional" re-INVITEs
whose purpose it is to modify the media streams, but I don't see what
purpose a non-200 response could possibly have for re-INVITEs whose sole
purpose it is to refresh the session timer. Are you saying refreshing
the session timer can fail?

> something different. I don't think thats the case here.

I would say overloading occurs when the same mechanism is used for
separate and independent purposes. In this case re-INVITEs are used for
modifying media streams and for refreshing session timer.

I still think we'd be better off with a new method, but if I'm the only
one I'll shut up about it.

> Authorization header, the proxy can't muck with it.

Right, but in this case I suppose adding another Require header above
the Authorization header wont hurt.

> Unsupported. What does it do then?

The draft would mandate that the UAC treat this case as if it had itself
required the 'timer' extension in the first case, i.e. the INVITE fails
as it should do.  This is not to say that requests in general can fail
with 420 for extensions they didn't Require. The draft would allow it
specifically for the case where a UAC sends an INVITE indicating
"Supported: timer" without "Require: timer". Like I said in the original
posting I believe this is acceptable because its basically a matter of
definition. If a UA supports the 'timer' extension it is required to
understand this special case.

Anders

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 22 Mar 2000 09:47:45 -0500

Anders Kristensen wrote:

> the session timer can fail?

While not likely, this is possible. Imagine that the UAS crashes and
then comes back to life, minus recollection of call-id in the timer
refresh. In that case, a failure is quite likely. (The resurrected UAS
would treat it as a new call, which would be appropriate, but the user
might refuse the new call or something else might go wrong.)

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 22 Mar 2000 15:11:32 +0000

> might refuse the new call or something else might go wrong.)

Excellent point, but isn't this just another argument for using a
non-INVITE method? In this case, by using INVITE the timer refresh
operation might be interpreted as a regular, brand new INVITE, whereas
with a non-INVITE method the refresh would correctly be recognized as
belonging to an "old" call and would be rejected with a 481 just like,
say, a BYE received for an old call after a UAS comes back up after a
crash.

Anders

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Mar 2000 01:04:05 -0500

> say, a BYE received for an old call after a UAS comes back up after a

The argument is that you WANT it to look like a regular, new invite.
This means, for example, the UAC can crash, and when it comes back up,
the call in progress can be re-established afresh.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Mar 2000 01:12:25 -0500

> the Authorization header wont hurt.

Hmm, I think this is OK.

> understand this special case.

OK, sounds like this might work. Its a bit ugly, since it makes the
Require/420 mechanism different for this extension. I'll raise this
issue during the meeting and see if we can come up with any other
interactions this might introduce.

-Jonathan R.

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 24 Mar 2000 18:53:27 +0000

> the call in progress can be re-established afresh.

I would question the wisdom of attempting to do this, partly because I
don't think it can be made to work well, and partly because I'm not
convinced it's something we'd really want to do anyway.

There are several reasons I can think of why it won't work:

 o The To tag of re-INVITEs will (usually) be non-null. When a UAS
receives an INVITE with a non-null To tag and it has no knowledge of the
leg it is rejected. 

 o The crashed UA may have had a route associated with the leg. Allowing
a re-INVITE to set up a leg in the crashed UAS as if it was an original
INVITE ignores the fact that subsequent requests should follow a route
established prior to the crash.

 o Many types of media streams may not be tolerant towards this sort of
re-establishment long after the initial session initiation. Consider,
for example, a chat media stream using TCP. The caller might accept a
TCP connection in the time between having sent the initial INVITE and
receiving the 200. Such a media stream may not be capable of being
reestablished if a crashed UAS comes back up and attempts to patch up
the session, even if at the SIP level the session could be picked up
properly again.

For these reasons I think that after a crash it is necessary for user
agents to reject requests belonging to old calls. Of course this is only
possible if it can reliably recognize when the request is indeed for an
old call and not an INVITE for a new call.

Anders

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 25 Mar 2000 02:44:11 -0500

My general inclination is to allow implementations latitude to
accomodate their own specific requirements, as long this doesn't
interfere with other compliant implementations. In this case, whether to
accept a tagged (re)INVITE can be completely up to the UAS. In general,
it may be difficult to do this (e.g., because of connection-oriented
media streams), but since the UAS clearly indicates its reaction, I
don't see the need to disallow either accepting or rejecting
connections. Outlining the trade-offs is obviously helpful.

Such flexibility is particularly important since we don't want to
restrict SIP to just setting up 'traditional' phone calls. As a somewhat
contrived example, imagine some kind of RTP-based monitoring application
in a system with a watchdog timer (that reboots the system if hung). In
that case, having a periodic refresh of the session is appropriate and
contributes to overall system reliability.