I understand the issue. But my question is why the RFC3261 has such kind of limitations. SIP was supposed to be simple. With current offer/answer model and many restrictions, the media handling is very closely coupled with the SIP stack. This makes the implementation very difficult. Since there's opportunity here we have a new draft, I hope it would make the offer/answer model more practical.
Jerry > -----Original Message----- > From: Nebojsa Miljanovic [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 21, 2007 2:57 PM > To: Jerry Yin > Cc: Paul Kyzivat; [email protected] > Subject: Re: [Sip-implementors] SDP in 2xx response after reliable 18x > > > Jerry, > was PRACK used for first 183 with sdp2? If not, this would be > violating RFC3261 > which states that SDP has to match in 18x and 2xx (if sdp was > sent in unreliable > 18x). > If PRACK was used, I assume sdp3 should just be ignored by the > UAC (based on the > draft section 2.1.1). I know that does not make the call work. But, in my > opinion there is nothing that would allow it to work (maybe old > RFC 2543) except > forking (which is very unclear to almost everybody I speak). > > Also, if PRACK was supported, IVR should use UPDATE to make this > work. That > would be by far the cleanest way. > > The scenario below appears to be a short cut taken by IVR instead of using > UPDATE. The same can be said for forking maybe. > > > Neb > > > On 2/21/2007 1:33 PM, Jerry Yin wrote: > > Hi Paul, > > > > Thanks for your comments. I agree with you that if the UAC handles the > > early-dialog properly, it may make it right. The question still > remaining is > > that if there are multiple early dialogs with multiple answers > (each dialog > > with one answer), how would the UAC decide which answer to > accept? To accept > > the last one, or accept the first one, or by checking the SDP owener and > > session id parameters? I think the question is not how long should a > > developer to follow the RFCs, but how many RFCs a developer has > to follow to > > make it right? I noticed you are one of the authors of the > draft. I hope you > > can clarify some of the muddy issues as much as possible, not > by implying > > :). > > > > Here's another example. I don't how to implement using the offer/answer > > model. In this example, the UAC calls (F1) a IVR system > (B2BUA), it receives > > the anouncement (F2)and exchanges the pin number by DTMF in the early > > dialog. Then the IVR invites (F3) the destination (A media > gateway, or PSTN > > gateway) which plays a ringback (F4, F5). Now, should the UAC accept the > > second answer(sdp3) or not? Please note that there's only one > dialog between > > UAC and the IVR. > > > > UAC IVR (B2BUA) Media GW > > F1 |--INV(sdp1)-> | > > F2 |<-183(sdp2)---| > > |-DTMF pin---->| > > F3 | |---INV (sdp1)-->| > > F4 | |<--183(sdp3)----| > > F5 |<-183(sdp3)---| | > > F6 | |<--200(sdp3)----| > > F7 |<-200(sdp3)---| > > > > Thanks, > > > > Jerry > > > > > > > > > >>-----Original Message----- > >>From: [EMAIL PROTECTED] > >>[mailto:[EMAIL PROTECTED] Behalf Of Paul > >>Kyzivat > >>Sent: Tuesday, February 20, 2007 5:00 PM > >>To: Jerry Yin > >>Cc: [email protected] > >>Subject: Re: [Sip-implementors] SDP in 2xx response after reliable 18x > >> > >> > >>Jerry privately send me a copy with the call flow in readable form. I'm > >>commenting back to the list for completeness. > >> > >> Paul > >> > >>Jerry Yin wrote: > >> > >>>Hi Paul, > >>> > >>>Here's the call flow. What I want to say is the current > >> > >>offer/answer model > >> > >>>has some problems. Each of following SIP messages is with one > >> > >>SDP. The 18x > >> > >>>are relievable responses. I didn't draw the Prack transaction for > >>>simplicity. > >> > >>I think you forgot to fork to UAS2. > >> > >> > >>>UAC Proxy UAS1 UAS2 > >>>|-Inv+sdp-->| > >>>| |-Inv+sdp->| > >>>| |<-180sdp1-| > >>>|<-180(sdp1)| > >> > >> | |-Inv+sdp------------->| > >> > >>>| |<-----------200 sdp2--| > >>>|<-200(sdp2)| > >> > >>As has been mentioned by others and by me, none of the RFCs relating to > >>o/a really discuss forking. But they all assume you are talking about a > >>single early dialog. In the case of multiple early dialogs, you need to > >>apply the o/a rules independently for each. This is one of those things > >>that is implied by the specs if you have studied them long enough, but > >>it doesn't leap out at you. > >> > >>So in the above, the responses from UAS1 and UAS2 will have different > >>to-tags, and so different dialog-ids, and so the UAC should understand > >>that sdp1 is the answer in one dialog, while sdp2 is the answer in the > >>other dialog. Each dialog has had only one answer, and so is in > >>compliance with the o/a rules. > >> > >> Paul > >> > >> > >>>I really concern that newly introduced drafts or RFCs are not > compatible > >>>with the previous ones. For Offer/answer model, there are > >> > >>following RFCs and > >> > >>>drafts are involved currently as I know: > >>> > >>>RFC3261, RFC3264, RFC3311, RFC3959, and the draft mentioned in > >> > >>this thread. > >> > >>>Jerry > >>> > >>> > >>>>-----Original Message----- > >>>>From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > >>>>Sent: Tuesday, February 20, 2007 2:32 PM > >>>>To: Jerry Yin > >>>>Subject: Re: [Sip-implementors] SDP in 2xx response after reliable 18x > >>>> > >>>> > >>>>Jerry, > >>>> > >>>>Your picture was destroyed by mail reformatting somewhere, to > the point > >>>>that I can't figure out what it was intended to show. Can you > >>> > >>try again? > >> > >>>> Paul > >>>> > >>>>Jerry Yin wrote: > >>>> > >>>>>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 > >>>>> > >>>> > >>_______________________________________________ > >>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
