Subject: AW: [Sip] PRACK holding the offer

From: Mayer Georg <[email-masked]>
Date: Wed, 13 Feb 2002 20:19:34 +0100

Hello,

does this mean the PRACK will generally not be allowed to carry SDP information or were the comments below only based on the initially described scenario (no SDP in INVITE and 183)?

From 3GPP point of view it would be of great value of INVITE/183 and its PRACK/200 could carry SDP, follwed by COMET/200 after ressource reservation.

Thanks for the help
Georg

> -----Ursprüngliche Nachricht-----
> Von: Jonathan Rosenberg [mailto:[email-masked]]
> Gesendet: Mittwoch, 13. Februar 2002 06:53
> An: Gonzalo Camarillo
> Cc: Hisham Khartabil; [email-masked]
> Betreff: Re: [Sip] PRACK holding the offer
> 
> 
> I agree with Gonzalo on all points. To further his reasoning, 
> with this
> proposal, a UAS would not know whether it needs to make the offer, or
> whether the UAC will offer it later. This will require additional
> signaling from UAC to UAS to say "even though I am not 
> sending the offer
> in invite, i will send it later". More needless signaling and
> complexity.
> 
> -Jonathan R.
> 
> Gonzalo Camarillo wrote:
> > 
> > Hi,
> > 
> > A reson for not allowing this exchange is that it would 
> complicate the
> > glare prevention mechanisms (if the UAS sends an offer in a 
> 1xx and the
> > UAC is sending at the same time an offer in an UPDATE we will have a
> > collision).
> > 
> > But I believe you are thinking of only using the PRACK to a 
> 1xx to send
> > the offer from the UAC. In my opinion this increases the 
> complexity of
> > the protocol for no real gain.
> > 
> > If the UAC can send an offer in the first place, it will 
> send it it the
> > INVITE. If it could not send the offer in the INVITE (maybe 
> because it
> > is a 3pcc controller), why would it be able to send it now 
> in the PRACK?
> > 
> > On the UAS side, if there is an scenario (I do not know of 
> any) where
> > the UAS can send an answer, but not an offer, it would not work with
> > plain SIP (INVITE-200 OK-ACK). Therefore, you would be defining a
> > mechanism that would only work with certain extensions.
> > 
> > Best regards,
> > 
> > Gonzalo
> > 
> > Hisham Khartabil wrote:
> > >
> > > Well, I don't have a specific scenario, just the general 
> one where I
> > invite
> > > you and say "lets do something, what do you have", you send a 1xx
> > saying
> > > "ok, but you let me first what you have".
> > >
> > > I just questioned it because the restrictions in section 13.2.1
> > prohibit
> > > such scenario and I was wondering why should it be prohibited.
> > >
> > > Regards,
> > > Hisham
> > >
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Gonzalo
> > > > Camarillo
> > > > Sent: Tuesday, 12 February 2002 6:29 PM
> > > > To: Hisham Khartabil
> > > > Cc: [email-masked]; [email-masked]
> > > > Subject: Re: [Sip] PRACK holding the offer
> > > >
> > > >
> > > > Hi,
> > > >
> > > > So far we have assumed that if you do not send an offer in the
> > INVITE it
> > > > is because you wait for an offer from the UAS.
> > > >
> > > > Do you have an scenario where the UAC does not 
> introduce an offer in
> > the
> > > > INVITE but intends to do it later (only if the first 
> 1xx does not
> > > > contain one)??
> > > >
> > > > Gonzalo
> > > >
> > > > Hisham Khartabil wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Perhaps this has been discussed earlier, but here is 
> goes anyway:
> > > > >
> > > > > What is the harm in a PRACK carrying the SDP offer 
> and the answer
> > being
> > > > > carried in the 200OK for PRACK or even in the 200OK for the
> > > > initial INVITE?
> > > > >
> > > > >    INVITE (no SDP)
> > > > > ------------------->
> > > > >
> > > > >    1xx (no SDP) 100rel
> > > > > <------------------
> > > > >
> > > > >    PRACK (SDP)
> > > > > ------------------->
> > > > >
> > > > >    200 (SDP) for PRACK
> > > > > <------------------
> > > > >
> > > > > OR
> > > > >    200 (SDP) for INVITE
> > > > > <------------------
> > > > >
> > > > > Regards,
> > > > > Hisham
> > > > >
> > > > > _______________________________________________
> > > > > Sip mailing list  https://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
> > > >
> > > > --
> > > > Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> > > > Columbia University                  Mobile:  +358 40 702 35 35
> > > > 472 Computer Science Building        Fax   :  +358  9 299 30 52
> > > > 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> > > > New York, NY 10027
> > > > USA                              [email-masked]
> > > >
> > > > _______________________________________________
> > > > Sip mailing list  https://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
> > 
> > --
> > Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> > Columbia University                  Mobile:  +358 40 702 35 35
> > 472 Computer Science Building        Fax   :  +358  9 299 30 52
> > 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> > New York, NY 10027
> > USA                              [email-masked]
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> [email-masked]                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sip mailing list  https://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
> 

_______________________________________________
Sip mailing list  https://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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Feb 2002 15:14:54 -0500

Mayer Georg wrote:
> 
> Hello,
> 
> does this mean the PRACK will generally not be allowed to carry SDP
> information or were the comments below only based on the initially
> described scenario (no SDP in INVITE and 183)?

No, we are only talking about the initial offer.

It is allowed for the following to occur:

inital offer in the initial INVITE
initial answer in the 18x
second offer in PRACK
second answer in 2xx

Take a look at the rules about this in bis-07.

> 
> >From 3GPP point of view it would be of great value of INVITE/183 and its
> PRACK/200 could carry SDP, follwed by COMET/200 after ressource
> reservation.

UPDATE/COMET would also be allowed to contain offers after the initial
exchanges have completed, yes.

-Jonathan R.