Subject: RE: [Simple] New I-D on IM transport

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 21 Nov 2001 01:37:57 -0500

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, November 20, 2001 7:32 PM
> To: Jonathan Rosenberg
> Cc: Ben Campbell; [email-masked]
> Subject: Re: [Simple] New I-D on IM transport
> 
> 
> I think the question is one of how to recover from problems with media
> transport. Having an FQDN gives an opportunity to try some recovery
> strategy that doesn't involve sip signalling. I think it is 
> possible to
> argue both sides convincingly as to whether this is a good thing.
> 
> The alternative is that when something goes wrong with the media
> transport then perhaps you should use more sip signalling to recover -
> by doing a reinvite. 

Indeed. I have in fact written a draft on doing just that:

http://www.jdrosen.net/papers/draft-rosenberg-sip-reconstitute-00.txt

> This gives the opportunity to exchange new
> addresses in order to continue the session. But it also has 
> the problem
> of getting the two endpoints to mutually understand what is 
> going on and
> what recovery action to take.

Its somewhat complicated when intermediaries are in the picture. A proxy in
the middle which has rewritted the SDP to point to an intermediary that has
now failed, needs to recognize that a re-INVITE is an opportunity to update
the SDP to point to a new intermediary. Whether the proxy that has done this
rewrite can realize that the intermediary has failed - well, thats hard.
This would be an argument for a media solution (i.e., using domain names in
SDP and using an alternate when media fails), as it wouldn't require the
proxy to know that the intermediary has failed.

On the other hand, a signaling solution will work better when the failure
requires some kind of state transfer or reconstitution (of the sorts
discussed in the draft above).

> But I think there is a better chance of
> doing this with signalling than without. This may need 
> something like a
> reason code (e.g. Reason: header) explaining why a reinvite is being
> done, and probably some SDP content that indicates what media session
> needs attention.

Its not clear to me that a reason is needed. THe above draft does not
require one. Its effectively the responsibility of elements "next to" the
ones that failed to detect this condition and handle the re-INVITE
appropriately.

> I posted about this some time ago, as an offshoot of the comedia
> discussions, but that faded away without any resolution. Perhaps it is
> time to resurrect it.

Yes, this is an important issue, and not really a simple one at all (and
thus the addition of sip to the cc list).

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Nov 2001 13:44:53 -0500

> http://www.jdrosen.net/papers/draft-rosenberg-sip-reconstitute-00.txt

Intesting paper. I think that a procedure of this sort is definitely
needed.

Here are some specific comments/questions about the details of what you
propose:

- what if the problem wasn't with the endpoint at all, but rather was an
intermittent problem with the network? In that case, both ends may try
to initiate recovery. (The analogy in the PSTN is the familiar "we were
disconnected, but when I tried to call back your line was busy"
problem.)

- what if there is no problem with signalling but there is a problem
with the media stream? Then the reinvite will reach the original
endpoint rather than a backup. It will not be able to distinguish this
reinvite from one for some other purpose, like session timer refresh. It
will note that the sdp has not changed, and may choose to simply return
the last sdp it sent. (This could happen if the sip and media travel on
different network connections to the same host, or if the media is on a
separate device with its own network connection.) 

- your 3pcc example requires that the controller forward on all
reinvites, even if nothing in the sdp has changed. However there are
other cases where this is a bad thing. There may well be reinvites going
on simply to update session timers. Since the session timer schedule may
differ on the two legs, it isn't desirable to forward noop invites.

- in a separate mail thread on the comedia draft, we identified some
added problems with reinvites and connection oriented media. In that
case, what is negotiated in the sdp is used to establish a media
connection, so it isn't idempotent to subsequent invitations. There is
need to indicate in the sdp whether to renegotiate the connection or
not. I don't think we ever fully resolved that. But I believe it is
important that something in the sdp be changed to indicate a desire to
renegotiate the connection. The same kind of scenario applies here.

All of these issues suggest to me that some explicit information needs
to be conveyed indicating what is being attempted. Part of this might be
a Reason header indicating that the reinvite is being sent to recover
from a perceived problem. In addition, I think there needs to be
something in the SDP to indicate what needs to be done. One possibility
I have suggested elsewhere is to extend sdp to permit an o= line for
each media description. This could then be revised to indicate a desire
to renegotiate the media stream without changing the caller's end. (This
could also be indicated with a new kind of a= line.)

	Paul