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
