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

["Ravindran Parthasarathi" <[e-mail]>]

Roman,

 

The point is that WebRTC browser is not required to get multiple answer
for single offer in case RTCWeb-SIP interop scenario with SIP forking
and it applies for "Fedex IVR" usecase.  Could you please point out the
exact usecase for "find-me/follow-me" in
draft-ietf-rtcweb-use-cases-and-requirements-06.

 

Thanks

Partha

 

From: Roman Shpount [mailto:[e-mail]] 
Sent: Saturday, October 29, 2011 12:59 AM
To: Ravindran Parthasarathi
Cc: Harald Alvestrand; [e-mail]
Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE:
draft-kaplan-rtcweb-sip-interworking-requirements-00]

 

 

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