Jerry, I don't think this draft was meant to introduce new rules or relax the old ones. I think it was meant only to summarize what was scattered across many RFCs. But, I should not speak for Paul here. He can answer better.
Neb On 2/21/2007 2:27 PM, Jerry Yin wrote: > 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
