Subject: Re: [SIP] as if there wasn't enough traffic on this darn list...

From: Neil Deason <[email-masked]>
Date: Fri, 01 Dec 2000 10:16:13 +0000

David Oran wrote:
> 
> Hmmm, I would simplify by going the OTHER direction and allowing SDP in any leg of an INVITE transaction. The meaning would be coupled with the state the transaction is in. This allows for 3-way negotiation of SDP, and allows very simple rules: the SDP you operate on, and reply to is the one you received in the last Request (INVITE or PRACK).

Or indeed ACK. Is late SDP in ACK for 3pcc really that 
difficult to support? Some people certainly do it already and I 
plan on testing for this at the upcoming bakeoff. Mandating UAs 
to support it looks like a more attractive approach to robust
and widespread support for 3pcc than 'strongly recommending' 
restrictions on what SDP changes you can do on a reINVITE.

Cheers,
Neil.
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net

> The simple call scenarios don't get any more complicated: you use the most recent SDP sent, otherwise the most recent one you received.
> 
> That gives much more flexibility and eliminates the special case rules as well.
> 
> Is the liquid sloshing out of the pot yet?
> 
> Dave.
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Jonathan Rosenberg
> > Sent: Thursday, November 30, 2000 3:06 AM
> > To: [email-masked]'
> > Subject: [SIP] as if there wasn't enough traffic on this darn list...
> >
> >
> > So, figuring we didn't all have enough email on the sip list
> > to read (I am personally hopelessly behind), let me stir
> > things around some more with another proposal for something
> > to ditch from the spec.
> >
> > Right now, you can carry SDP in the INV/200/ACK exchange in
> > two ways. You can send nothing in the INVITE, followed by SDP
> > in the 200, and then SDP in ACK (and fortunately I don't know
> > anyone who actively does this). Or, you can send SDP in
> > INVITE, SDP in 200, and nothing in ACK. I also think there
> > are several confused implementations that likely send it in
> > all three.
> >
> > Add to this the unfortunate PRACK mess, which also has been
> > used to send SDP in order to support the manyfolks resource
> > work when used with 3pcc, but which is yet unimplemented.
> >
> > It all adds up to a messy confusion. Its not clear what it
> > means to send SDP in all these places, and how it works.
> >
> > So, my proposal is that we simplify. We only allow SDP in
> > INVITE and then provisionals/200 OK. No SDP in ACK. No SDP in
> > PRACK. (sounds like a Dr. Seuss rhyme, doesn't it?)
> >
> > The latest 3pcc draft no longer recommends using the
> > SDP-in-ACK, since it has problems. Given that there don't
> > seem to be useful applications of it any longer, and given
> > that, to my knowledge, it is not sent by anyone (at least not
> > in any commercially shipping boxes, I hope), I'd like to yank it.
> >
> > There is a consequence, and that is dealing with the
> > manyfolks requirement for sending an updated SDP to deal with
> > manyfolks+3pcc. My proposal for that is to use a re-invite,
> > rahter than PRACK, to carry the updated SDP. This does mean
> > that we need to allow, in SIP, a re-INVITE to arrive while an
> > initial INVITE is in progress. Allowing this would also
> > address some of the concerns raised in previous threads about
> > handling requirements for changes in early media.
> >
> > I don't think its hard to deal with the re-INVITE while
> > INVITE-is-active case. The simplest solution is to reject the
> > first INVITE and continue processing with the second one,
> > using the new SDP and all.
> >
> > Anyway, before getting into those details, what does the
> > group think about dropping the SDP-in-ACK and SDP-in-PRACK stuff?
> >
> > -Jonathan R.
> >
> > ---
> > Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > [email-masked]                     FAX:   (973) 952-5050
> > http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> >
> >
> > _______________________________________________
> > SIP mailing list
> > [email-masked]
> > http://lists.bell-> labs.com/mailman/listinfo/sip
> >
> >
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip

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

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 01 Dec 2000 13:25:31 +0100

I don't think it's that simple.

For many changes the two parties involved in a call need to agree that
the change should happen.

When a UA does a re-INVITE with updated SDP it effectively proposes new
media settings. If for whatever reason the UAS can't or won't honour
those settings it can reject the INVITE. If media settings are updated
in an ACK there's no way for the UAS to tell the UAC that it doesn't
have enough bandwidth or it doesn't support any of those codecs etc.

So at a minimum there should be a number of restrictions on what a UA
can do with SDP in an ACK. Maybe the same restrictions that now apply
for SDP in responses to INVITE, e.g. you can't suddenly add a media
stream in an ACK.

So generally allowing SDP in ACK could work for some operations. I don't
think it's worth the confusion, though. Better simply to say that ACK is
for stopping INVITE retransmissions only. If you want to modify media
settings do a re-INVITE.

Anders

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 1 Dec 2000 09:56:23 -0500

> have enough bandwidth or it doesn't support any of those codecs etc.

Correct.  An INVITE without SDP is a request for 
the receiver to propose the new media settings.  If the 
receiver did not put the call on hold, the receiver most 
likely would not desire to remain on hold.

> for SDP in responses to INVITE, e.g. you can't suddenly add a media

I agree.

> for stopping INVITE retransmissions only. If you want to modify media

For 3pcc a re-INVITE loop would potentially 
get established if both sides keep changing 
ports with every re-INVITE (and particularly 
when the same port is not used before and 
after hold).  This is why SDP in ACK for 
re-INVITEs is important for 3pcc.

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 01 Dec 2000 16:13:54 +0100

> re-INVITEs is important for 3pcc.

Yes, but why would the UA keep changing ports (or anything else in the
SDP)? There are many ways SIP UAs can misbehave. This is just another
way of misbehaving. For example, is this much different from the fact
that a 3pcc controller can't keep either UA from re-inviting over and
over again for no good reason?

--
Anders Kristensen

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 1 Dec 2000 11:04:38 -0500

> over again for no good reason?

That is just it, according to the rfc2543, this
is not misbehaving.  Changing port
and/or connection address is even
part of the new advance media scenarios
for the upcoming bakeoff.

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 01 Dec 2000 17:17:55 +0100

> for the upcoming bakeoff.

Well, that's my point. The point of view of rfc 2543 and the 3pcc
controller are not the same here. Both behaviours are legal according to
rfc 2543 and both are Bad according to the 3pcc controller.

--
Anders Kristensen