Paul Kyzivat wrote:
> 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 from 3725.) The 200 for the
> invite will then preferably contain no sdp.
Some further thoughts:
Its also possible for the B2BUA to use the fake forking approach. And it
will be simpler than either of the two above.
Better yet, the IVR need not be a B2BUA. It can act as a UAS for the
early media IVR response, and then act as a proxy for sending the call
to the GW. Not only does this simplify the call flow, it also means that
the IVR need not be involved in the call once it goes to the GW.
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
