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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 5 Dec 2001 13:53:58 -0500

(cc'ing mmusic since there is a comedia issue in here, and trimming simple)

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, November 29, 2001 3:01 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]'; Ben Campbell; [email-masked]
> Subject: Re: [Simple] New I-D on IM transport
> 
> 
> > > - 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?
> 
> 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.

The assumption in the reconstitute draft is that a re-invite is generally
only going to be useful to fix the problem where a UA failed, and thus we
need to reconstruct state at a backup. If its a network problem, its not
clear to me that changing ports or servers will fix those problems. Indeed,
one might argue that if there is a network problem, the SIP messaging is not
likely to get through either...

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

Right; you likely need to use a=reuse. One thing that is missing from
comedia, though, is what to do if no existing connection exists. This would
be an issue for the reconstitute draft, since it would send a re-invite with
a=reuse, which might arrive at a new server that doesn't have a connection.
Indeed, one might argue that reuse is orthogonal to a=active/passive/both.
a=reuse would say what to do if the connection exists, the rest would say
what to do when it doesn't.

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

induce another problem? No - the reinvite would get routed to another box
that is up.

-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

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Dec 2001 15:50:45 -0500

While I think this is a more general problem, I can't at the moment
offer any proof of this. So, I am willing to go along with a solution
within comedia since it is the only place I can point to that has the
problem.

David says that a=reuse isn't suitable for solving this problem.
I will go a bit further and say that I don't think a=reuse is
quite right in general. The problem with it is that it isn't
idempotent - I can't send the same sdp in a reinvite and get
unchanged behavior.

Instead, I think it works better if a reinvite with identical
sdp for a particular comedia media description automatically means
to preserve an existing connection, with some sort of change in
the sdp for that media description required to force establishment
of a new connection. This could be an extension to sdp to permit
o= to be used within a media description, or it could be a new
a= line containing something like a media description version.

More below.

	Paul

David Yon wrote:
> 
> While I'm not in tune with the full history of this thread, but what you
> are saying above is in violation of what is specified in comedia.  An
> endpoint may only specify "reuse" when it is signaling its intention to
> add a media stream over an existing connection.  If there is no existing
> connection, why would an endpoint specify "reuse"?

> likely to get through either...

There are more cases than this. The UA may itself have components on
multiple nodes. (You have addressed the 3pcc/b2bua case but there may
well be others, such as sip gateways to h.323.) Or on a single node some
communications may work and others not - such as when a device has
multiple network adapters.

The cases where the sip signalling still works at the original node are
the messy ones, because then the receiving device can't tell the
difference between a reinvite because of errors, and a reinvite for
other reasons. 

> what to do when it doesn't.

This is partly solved by having version information in the session
description.
If the version is different then a new connection must be established,
whether
or not there is an old one. In the case of a new server picking up the
call,
any version would be a new one.

> induce another problem? No - the reinvite would get routed to another box

I meant to include that. I meant that the problem that first showed up
as a media problem will also manifest itself in sip signalling. For
instance, routing the new invitation to an alternate server box because
the one used previously no longer responds.

	Paul