Subject: Re: Session timer comments

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 02 Apr 2000 11:29:06 -0400

Jonathan Rosenberg wrote:

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

Is this a practical problem? How many proxy servers that implement
Route/Record-Route couldn't be trained to do that? Also, I believe this
has been discussed since the first bake-off or thereabouts, so most
implementors should have seen this. 

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

One solution is to define a status code in 4xx (or maybe 3xx) that says
"modification failed, call remains".

I suppose other 4xx conditions could suddenly arise (for example, I
somehow turn on authentication in mid-call), but these seem somewhat
unlikely. 

I'm curious how RSVP deals with this, since it also has the problem that
state may be modified during a reservation.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 03 Apr 2000 03:43:15 -0400

> implementors should have seen this.

We can take a poll at the bakeoff, but I'm sure there are
implementations that won't be there...

> "modification failed, call remains".

Actually, to be consistent with a regular INVITE, it would need to be a
2xx that says "modification failed, call remains", since a 200 OK to
initial INVITE means the call is up.

I'm not sure we want to do this, though. I think we are pretty far down
the road of re-INVITE being different from INVITE.

-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

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