See below.
> -----Original Message----- > From: [email protected] [mailto:sip- > [email protected]] On Behalf Of Subbu > Rajendran > Sent: Sunday, February 01, 2009 7:29 AM > To: Nebojsa Miljanovic > Cc: [email protected] > Subject: Re: [Sip-implementors] Query related to SDP in 200 OK after > UPDATE > > Hi, > Thanks all for the response to my query. And sorry for delaying this > email. > The draft that Neb had mentioned in the email had the answers to my > query > (The example in section 3.1.1). > > I suppose the following two are acceptable UAS behavior in this case: > 1. If the offer answer is completed for an INVITE transaction, i.e. > when > answer to the offer is send in reliable response (180 Ringing with > 100rel > option), then the 200 OK for INVITE should not echo the answer SDP. [Neel] In this case, the 200 OK MUST contain the same answer SDP as that of 180 Ringing. > > 2. However if the 200 OK for INVITE has SDP it MUST be the last > answer > SDP (no offer can be initiated). This way there shall be no impact to > the > media session if the UAC honors the SDP in the 200 OK for INVITE or > even if > it ignores it. > [Neel] There is no last answer. For each offer, there is only one answer for the same endpoint. > Thanks & Regards, > Subbu > > On Wed, Jan 21, 2009 at 2:29 AM, Nebojsa Miljanovic > <[email protected]>wrote: > > > Subbu, > > take a look at the following draft that talks about it. > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip- > offeranswer-10.txt > > > > Section 3.1.1 states that if you are UAS, you should not send any SDP > in > > 2xx but > > if you are UAC, be ready to ignore it. In other words, don't kill a > call if > > it > > is there. > > > > Unfortunate reality is that many endpoints are hardcoded to expect > SDP in > > 2xx > > even if offer/answer is fully done. And, they end up killing the call > if no > > SDP > > is present in 2xx. > > > > Neb > > > > On 1/20/2009 1:30 AM, Subbu Rajendran wrote: > > > Hi All, > > > Following is example call flow from RFC 3311 (SIP UPDATE Method). > Is SDP > > a > > > must in the 200 OK for INVITE in this case? If it is required, then > 200 > > OK > > > should contain 'answer 3'. Is this a legal behavior as answer in > 200 OK > > for > > > INVITE ('answer 3') is not based on the offer in the INVITE ('offer > 1'). > > > > > > Could anyone please explain or point me to the RFC that explains > this > > case? > > > > > > Caller Callee > > > > > > (1) INVITE with offer 1 > > > |---------------------------->| > > > > > > (2) 180 with answer 1 > > > |<----------------------------| > > > > > > (3) PRACK > > > |---------------------------->| > > > > > > (4) 200 PRACK > > > |<----------------------------| > > > > > > (5) UPDATE with offer 2 > > > |---------------------------->| > > > > > > (6) 200 UPDATE with answer 2 > > > |<----------------------------| > > > > > > (7) UPDATE with offer 3 > > > |<----------------------------| > > > > > > (8) 200 UPDATE with answer 3 > > > |---------------------------->| > > > > > > (9) 200 INVITE (SDP ?) > > > |<----------------------------| > > > > > > (10) ACK > > > |---------------------------->| > > > > > > > > > Thanks & Regards, > > > Subbu > > > _______________________________________________ > > > Sip-implementors mailing list > > > [email protected] > > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > > > > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
