The offer/answer model is definitely an on-going issue for SIP interoperation. I have read the draft-ietf-sipping-sip-offeranswer-00.txt briefly. I think it still does not cover the forking problem. Here's the example:
UAC Proxy UAS1 UAS2 F1 |--Invite (SDP)-->|----Invite--------------->| | |-----------------Invite------------------------------->| | |<--180 100rel(tag1)+sdp1--| | F5 |<--180sdp1(tag1)-| | | | |<----------------200 (tag2)+ dp2 --------------------| F7 |<--200sdp2(tag2)-| Now, should the UAC accept the SDP in F7, or not? According to this draft, the SDP in F1 is an offer, the sdp1 in 180 reliable response is an answer. Then the sdp2 should be ignored. But obviously it will cause an audio problem. Jerry > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Attila > Sipos > Sent: Thursday, February 15, 2007 4:20 AM > To: Meir Leshem; Sanjay Sinha (sanjsinh); Nebojsa Miljanovic; > [email protected] > Subject: Re: [Sip-implementors] SDP in 2xx response after reliable 18x > > > > >>My understanding is that if the SDP in the 200(Invite) has a different > >>version in the "o" line than the previous SDP then the new SDP is a new > >>Offer. The UA receiving this SDP should respond with SDP answer in the > >>ACK message. > > No, you can't do this. > > If the INVITE has an offer and the answer is in the 180x, then > and SDP in the 200 is not another offer and you musn't > send another SDP in the ACK. > > This document summarises the various offer/answers that are allowed: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeran > swer-00.txt > > (this document also references RFC 3262 for PRACK and RFC 3311 for UPDATE) > > Regards, > Attila > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Meir > Leshem > Sent: 15 February 2007 08:28 > To: Sanjay Sinha (sanjsinh); Nebojsa Miljanovic; > [email protected] > Subject: Re: [Sip-implementors] SDP in 2xx response after reliable 18x > > > Hi all, > My understanding is that if the SDP in the 200(Invite) has a different > version in the "o" line than the previous SDP then the new SDP is a new > Offer. The UA receiving this SDP should respond with SDP answer in the > ACK message. > > Regards > --------------------------------------- > Meir Leshem > Veraz Networks > Tel: +972-3-9709107 > Fax: +972-3-9709442 > Mobile: +972-54-9709107 > --------------------------------------- > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Sanjay > Sinha (sanjsinh) > Sent: Wednesday, February 14, 2007 8:37 PM > To: Nebojsa Miljanovic; [email protected] > Subject: Re: [Sip-implementors] SDP in 2xx response after reliable 18x > > > Option 2 does not seem correct. Option 1 is correct and you may also > want to ignore the sdp in 200 OK, just treat it as if there was no sdp > in 200 OK. > > Sanjay > > >-----Original Message----- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] On Behalf Of > >Nebojsa Miljanovic > >Sent: Wednesday, February 14, 2007 12:30 PM > >To: [email protected] > >Subject: [Sip-implementors] SDP in 2xx response after reliable 18x > > > >Trying to get a feel on how various developers interpret RFCs > >3261, 3262 and 3264. > > > >If you are acting as an UAC and you have received SDP in > >reliable 18x response (i.e. PRACK was used), and then again > >that same SDP comes in 2xx, what will you do? > > > >1. Verify that 18x and 2xx SDPs are the same and accept it. > > > >2. Tear down the call since you consider SDP in 2xx as an > >invalid Offer. > > > > > >Also, do you know of any UAs that require 2xx to contain SDP > >even after Offer/Answer was done with 183/PRACK. > > > >Thanks. > > > > > > > > > >_______________________________________________ > >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 > > _______________________________________________ > 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
