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
> :).
While these are *early* dialogs you pretty much just have to pick one to
render early media from, but you don't know which one will answer.
Generally, once one answers, whichever proxy did the forking will cancel
the others, and you will never hear from them again. The one you got a
2xx from is the one you will then use.
It is *possible* that you might get 2xx responses from multiple dialogs.
This will generally only happen if they answer at almost the same time,
so that the answer is sent before a cancel is received. When that
happens, you must decide what to do. The usual answer is to send a BYE
to any 2xx you get after the first. But you can handle multiples if you
wish.
> 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)---|
If the IVR is acting as a B2BUA, as above, then the call flow you show
is incorrect. There are two things the IVR can do that are correct:
- after receiving the 200 from the GW, the IVR can send a 200 to the UAC
with sdp2. After receiving the ACK, it can then send a reinvite with
sdp3. (But beware - the call flows necessary to get the UAC and the GW
agreeing on the SDP are subtle. See RFC 3725.)
- make F2 be a reliable provisional, which then ends an offer/answer
cycle. Then, at F5, send an UPDATE with sdp3. (Again you will need
to do some stuff to ensure alignment with the GW.) The 200 for the
invite will then preferably contain no sdp.
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
