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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Nov 2001 00:37:18 -0500

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, November 26, 2001 1:45 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]'; Ben Campbell; [email-masked]
> Subject: Re: [Simple] New I-D on IM transport
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > Indeed. I have in fact written a draft on doing just that:
> > 
> > 
> http://www.jdrosen.net/papers/draft-rosenberg-sip-reconstitute-00.txt
> 
> Intesting paper. I think that a procedure of this sort is definitely
> needed.

There is very little in here that needs to be standardized; since it is
something that effects baseline operation (it defines a failure scenario
that is not defined), it is my hope to incorporate the baseline stuff into
bis. Thats currently an open issue we're tracking.

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

No problem. If both sides send at the same time, the glare procedures will
handle that. If its sequential, its sequential. I think the draft talks
about giving up if the reinvite doesn't help after a few tries.

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

I guess this seems to me to be the right behavior. What would you want to
happen in this case?

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

I don't think a controller will ever be in a position to adequately
determine what really constitutes a no-op re-invite, and should therefore
pass along everything, even if it means faster session timers on both ends
of a call (the session timer is infrequent anyway).

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

This is a good point. I think its a pure co-media issue, though, and that
needs to be addressed in that draft.

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

I'm still not convinced, so long as the comedia issue is handled.

-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: Thu, 29 Nov 2001 15:00:49 -0500

> I guess this seems to me to be the right behavior. What would you want to

Doing nothing in response to the problem seems wrong to me.
But clearly it is difficult to figure out the right thing to do.
Possible actions:
- switch to a different port. See if that helps.
- switch to a different media server, if it is independent of the 
  sip UA itself
- record the fact that a caller reinvited because of presumed media
  problems at this end. Eventually an accumulation of these might lead
  to taking this box out of service.

Some or all of these responses could be tried *if* the called
system knew the reinvite was sent because of problems with the call.

> needs to be addressed in that draft.

Fair enough, as long as the rules you are trying to craft dovetail with
that. It may not be sufficient to simply reinvite with same old SDP;
it may be required to do something slightly different on a per-media
basis.

> I'm still not convinced, so long as the comedia issue is handled.

You may be right, but I have the feeling the problem is bigger than
just comedia. Reinvites can be sent for many reasons, and errors can
show their symptoms in many ways. The assumption you are making is that
the reinvite will always induce another problem, and that the
resolution of that problem will fix the original one. 

	Paul