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

From: Itamar Gilad <[email-masked]>
Date: Fri, 1 Dec 2000 13:02:52 +0200

I agree with Vijay that INVITE within INVITE is going to make things much
more complicated.  I believe the method INVITE is overloaded enough as it is
with re-INVITE.  Adding another use for it is going to make things worse.
The fundamental problem with the manyfolks draft in my opinion is that it
breaks these key principles that otherwise could keep SIP much simpler:
1) a call-leg is established in a three-way handshake.  
2) call-leg state is affected by one and only one transaction at a time (in
other words: there are no transactions within transactions).

I'm not saying we need to reject the manyfolks draft just because it doesn't
fit SIP's basic scheme. I'm saying that under the assumption that QoS
capabilities negotiation needs to be completed within the scope of
INVITE-to-ACK (BTW, is everybody in agreement that this is necessary ?),
PRACK-COMET within INVITE is a better solution than INVITE within INVITE.

  Itamar

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thu, November 30, 2000 10: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

---

From: "Keith Robinson" <[email-masked]>
Date: Fri, 1 Dec 2000 14:27:36 +0000

Bryan writes:

"So, lets clarfy what the SDP does mean"

This is the crucial point. Jonathans's proposal changes the method in which the
SDP is received,
it does not change the context. If there is confusion surrounding the various
contexts in which
an SDP can be received, then a discussion is required to clarify this. Only then
can a decision
be made on what is the best method(s) to deliver SDPs. Until then, if its not
broken, don't fix it.

Bryan Byerly <[email-masked]> on 01/12/2000 14:02:28

                                                              

 To:      Jonathan Rosenberg <[email-masked]>        
                                                              
 cc:      "[email-masked]'"                         
          <[email-masked]>, [email-masked](bcc:    
          Keith Robinson/MAIN/MC1)                            

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

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

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

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

> Anyway, before getting into those details, what does the group think about

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