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

From: Bryan Byerly <[email-masked]>
Date: Fri, 01 Dec 2000 09:02:28 -0500

Jonathan Rosenberg wrote:

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

I am specifically aware of a commerical implementation that 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.

I am specifically aware of two separate commerical implementations of assured
QoS using the manyfolks draft (and thus SDPs in PRACK).  I see no reason to
place an unwarrented restriction on which messages SDP can and cannot be sent
in.

Please elaborate on what specific problems you've identified w/r/t SDP in ACK.

> 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, let's clarify what the SDP does mean.

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

This sounds like the original two-stage DCS proposal.  Why don't the same
original criticisms apply now?

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

I think it's an unwarrented limitation.

I really don't understand what problem you're trying to solve.  If the spec is
unclear, then additional clarification is in order.

thanks,
Bryan

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

---

From: Vladislav Zubarev <[email-masked]>
Date: Thu, 30 Nov 2000 14:50:08 -0800

There have been already applications implemented using this scheme:
INVITE (no SDP), 200 OK (SDP), ACK (SDP), including SIP/H323
gateways and SIP UAs (supporting this features).

This is very important for SIP/H323 gateways, which use this
feature, especially for the calls orignated on H.323 side. In this case
INVITE withoud SDP and ACK with SDP is the best way to do it.
Since there are lot of H.323 endpoints on the market, which do not
support FastConnect, INVITE without SDP is a good sulution for
it.

So it's reasonable to keep this feature. It could be something like
multipart SDP in SIP msg - it's not prohibited, but at the
same time it's not the thing which is encouraged to do as well.
So SIP UAs would still support existing implementations of SIP/H.323
gateways, while new ones would be encouraged to use re-INVITEs,
instead of no SDP in INVITE.

Thank you.

Jonathan Rosenberg wrote:

> ACK (and fortunately I don't know anyone who actively does this). Or, you

--
Vladislav Zubarev        mailto:[email-masked]
Software Engineer        http://www.cisco.com
Cisco Systems, Inc.      http://www.vovida.org

---

From: Michael Thomas <[email-masked]>
Date: Fri, 1 Dec 2000 07:10:31 -0800 (PST)

> So, let's clarify what the SDP does mean.

   If I understand this correctly -- and I may not -- it
   seems to me that the problem has more to do with mid
   transaction collisions between participants in a call
   and as such, it's not just SDP, but any other headers
   which could cause an unstable state, SDP being the
   most obvious. This can be because either the two UA's
   collide, or whether one of them just changes its
   mind mid-transaction.

   If I'm correct, it seems that the what Jonathan's
   recommending is, in effect, a way mitigating the
   collision problem by a strict state machine on 
   where the SDP announcement can be seen so that
   they cannot collide. However, I'm suspicious that
   taking that tact may create a solution which is
   incomplete, draconian or both. 

		Mike