Subject: RE: Session timer comments

From: "Donovan, Steven R." <[email-masked]>
Date: Tue, 28 Mar 2000 01:55:50 +0000

Anders Kristensen wrote:

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

This is addressed by an addition to 2543bis:

  "Note that proxy servers have to add Record-Route headers to each
   request as long as they want to be "visited" by the next request
   for the call leg."

The only way for a proxy to insure that it will be a part of all requests is
to insert the Record-Route header into all requests, even those that have a
Route header.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 Mar 2000 20:35:02 -0500

> to insert the Record-Route header into all requests, even those that have a

I think this may cause interop problems. Much as I'd like to add this,
it means any old proxy that doesn't insert REcord-Route is going to get
booted off the signaling path. That seems like a problem. 

Beyond that, the other problem with re-establishing the session at the
crashed and rebooted UA is the CSeq space. It will loose track of the
CSeq number it had been using in the other direction. Thus, any messages
it sends may be rejected by the UA on the other side as being out of
order. This, too, can be fixed if you are careful about choosing CSeq
numbers. The spec recommends, I believe, choosing them based on a local
clock. This would actually mean that a UA that crashes and reboots would
still be able to send requests with the right CSeq.

However, a more interesting problem is the following. Lets say A and B
are talking, and B crashes and reboots. Now, A sends a re-invite to B. B
rejects the re-INVITE, which it believes is an initial INVITE, and thus
it thinks there is no call. A thinks the rejection is for a re-INVITE,
and thus still believes the call is up. Session timer is meant to deal
with exactly these kinds of things, and it would detect this condition.
But, any other ideas on possible solutions outside of session timer? 

Stepping back a moment, this problem is rooted in the simple fact that
we use INVITE for both initiation and modification. That will work, I
believe, if the rules for handling and responding to INVITE are
absolutely, positively no different if you are in, or not in a call. As
soon as the behavior is different because its a re-INVITE, thats where
oddball problems like this come up. For example, if the response to a
re-INVITE is always 200 OK so long as the session is still up, and a
response of 400 means the session is not active (as it is for a normal
INVITE), this crash and reboot problem above will not happen.

-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