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

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 30 Nov 2000 03:06:05 -0500

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

---

From: Vijay Gurbani <[email-masked]>
Date: Thu, 30 Nov 2000 08:18:11 -0600

> another proposal for something to ditch from the spec.
[...]
> Seuss rhyme, doesn't it?)

Did you just get done watching "The Grinch" :-)

[...]
> dropping the SDP-in-ACK and SDP-in-PRACK stuff?

Personally, I do not have any problems dropping SDP-in-ACK and SDP-in-PRACK 
(modulo Arjun's note that dropping SDP-in-ACK may break SIP-H.323 
implementations).

However, getting a re-INVITE while processing an INVITE (for the same call)
may get messy.  My first impulse it to say that, from a developer's view-
point, there is enough complexity while processing a normal INVITE: 
detecting and handling spiralled loops, request merging, forking, 
correlating response to multiple requests, etc.  Is the added complexity 
of handling re-INVITEs worth it?  Furthermore, will this break older 
implementations which at best may send a 4xx response with a Retry-After 
header, or at worst will not know what to do with the re-INVITE.  I don't 
think RFC 2543 dealt with re-INVITEs.

Just my $0.02.

Best regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 30 Nov 2000 14:07:21 -0500

BroadSoft uses the re-INVITE without SDP and ACK
with SDP to avoid the possibility of both sides getting
into a SDP-change-loop discussed in thread
"[SIP] 3PCC and the re-invite response".

This is why BroadSoft would like to keep the use of
ACK with SDP at least with regard to re-INVITEs.

---

From: "David Oran" <[email-masked]>
Date: Thu, 30 Nov 2000 16:09:53 -0500

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

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
> To: [email-masked]'
> 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 
> 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.
> 
> ---
> http://lists.bell-> labs.com/mailman/listinfo/sip
> 
>