Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]

[Roman Shpount <[e-mail]>]

On Fri, Oct 28, 2011 at 3:14 PM, Ravindran Parthasarathi <
[e-mail]> wrote:

>
> Thanks for the clarification. "Fedex IVR" usecase is under browser to
> GW/server section (sec 4.3) which is a SIP based forking requirement. If you
> look at carefully, "Fedex IVR non-final response" scenario could have be
> achieved cleanly using two separate offer/answer exchange & two final
> responses (INVITE/200/ACK, RE-INVITE/200/ACK) :
>
>
This is actually wrong, unless we specify that WebRTC is always using the
same media stream address parameters (list of ICE candidates) within the
same call. If in WebRTC this cannot be guaranteed, serial forking cannot be
implemented unless multiple answers can be provided to the same offer. In
other words we either get the same offer from WebRTC client so we can
quietly not send it, or multiple answers need to be provided.

In addition to Fedex IVR scenario, we also have find-me/follow-me scenarios
where either multiple early media sources are playing at the same time (land
line ring back and cell phone ring back). We also sometimes end up with
situations where two people answer the same call, such as boss and a
secretary answering the same call.
_____________
Roman Shpount