Okay, then it can probably be clarified in the offer-answer draft, if it is not already.
Sanjay >-----Original Message----- >From: Robert Sparks [mailto:[EMAIL PROTECTED] >Sent: Tuesday, November 20, 2007 9:54 AM >To: Sanjay Sinha (sanjsinh) >Cc: sip List >Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel > >Yeah - that's not it - it doesn't match your assertion even. >That text says that _if_ SDP shows up in the 200, you have to >ignore it. >It doesn't say anything about it matching the 18x, and it >doesn't say anything about whether the UAS is allowed to put >it in the 200 in the first place. > >Btw - that passage _IS BEING USED_ to argue that it's ok, and >even _right_, to put SDP in the 200 OK since things MUST ignore it. > >RjS > >On Nov 19, 2007, at 6:35 PM, Sanjay Sinha (sanjsinh) wrote: > >> Pl. see inline... >> >>> -----Original Message----- >>> From: Robert Sparks [mailto:[EMAIL PROTECTED] >>> Sent: Monday, November 19, 2007 5:23 PM >>> To: Sanjay Sinha (sanjsinh) >>> Cc: sip List >>> Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel >>> >>> Yes, I did mean 200 INVITE. >>> >>> On Nov 19, 2007, at 3:22 PM, Sanjay Sinha (sanjsinh) wrote: >>> >>>> It is not clear from the call flow if the 200 OK is for PRACK or >>>> INVITE? >>>> >>>> I guess you meant 200 OK for Invite. If that is the case, I >>> think the >>>> RFC is clear that the answer sdp is optional in it and if it >>> does have >>>> an answer sdp, it MUST be idential to answer in 18x. >>>> >>> >>> Really? Point me to where you find this please. >> >> I was referring to sec. 13.2.1 of RFC 3261. >> >> o If the initial offer is in an INVITE, the answer MUST be in a >> reliable non-failure message from UAS back to UAC which is >correlated >> to that INVITE. For this specification, that is only the final 2xx >> response to that INVITE. That same exact answer MAY also be >placed in >> any provisional responses sent prior to the answer. The UAC MUST >> treat the first session description it receives as the answer, and >> MUST ignore any session descriptions in subsequent responses to the >> initial INVITE. >> >> The strengths of assertion may not be what you are looking for here. >> >> Thanks >> Sanjay >> >> >> >>> >>>> But I think the >>>> offer-answer draft has clarified it further that it should >not have >>>> any answer sdp. This is probably harsh in case of one offer-answer >>>> exchange, but makes sense if there are multiple early dialog >>>> offer-answer exchanges in say Prack/200 OK or using UPDATE. >>>> >>>> Sanjay >>>> >>>>> -----Original Message----- >>>>> From: Robert Sparks [mailto:[EMAIL PROTECTED] >>>>> Sent: Monday, November 19, 2007 4:14 PM >>>>> To: sip List >>>>> Subject: [Sip] SIPit21: SDP in a 200OK when using 100rel >>>>> >>>>> There was a lot of discussion and disagreement at SIPit21 about >>>>> whether the following 200 OK is allowed (or should) have >SDP in it: >>>>> >>>>> INVITE (offer) >>>>> --------> >>>>> 18x (with 100rel) (answer) >>>>> <-------- >>>>> PRACK >>>>> ---------> >>>>> 200 OK (can this carry SDP?) >>>>> <--------- >>>>> ACK >>>>> ---------> >>>>> >>>>> I couldn't find anything definitive in RFC form. Paul's >offeranswer >>>>> draft talks about this I think. >>>>> >>>>> If I understand things, the right answer here is that it's not >>>>> supposed to carry any SDP and that you should ignore it >if it shows >>>>> up. >>>>> >>>>> The question is, other than waste, what can go wrong if it is >>>>> there? >>>>> When we end up with clear text around the requirement, >will it say >>>>> SDP SHOULD NOT, or MUST NOT appear? >>>>> >>>>> Or do I have this wrong? >>>>> >>>>> RjS >>>>> >>>>> >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol Use >>>>> [EMAIL PROTECTED] for questions on current sip Use >>>>> [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
