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

[Hadriel Kaplan <[e-mail]>]

We've debated serial and parallel forking a number of times but I don't know if there's been consensus.

But your email is really two different questions/topics:
1) Is there a use-case for forking within WebRTC?
2) Does supporting SIP forking mean the Browser has to handle the SDP/media behavior of it, vs. the Web-server/Interworking-function handling it?

For the first question, I can certainly envision a Web-app wanting to let Alice press a single button on her Browser and end up communicating with Bob no matter where he may be, or letting her single button-press end up communicating with Bob first and then Charlie, or letting her single button-press end up communicating with Bob and Charlie at the same time.  But I think such things can be accomplished through clever Web-app code without needing the Browser to be aware it's a forked ROAP/SDP scenario. 
[Note: though this may depend on what W3C decides the user-consent UI model is relative to PeerConnections, MediaStreams and ROAP]

With regards to the second question, there was a long email thread on this which started here I think:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg01354.html

-hadriel


On Oct 28, 2011, at 3:14 PM, Ravindran Parthasarathi wrote:

> Harald,
> 
> 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) :
> 
> 1) customer - fedex IVR offer/answer exchange
> 2) fedex agent - Customer offer/answer exchange
> 
> but it may be avoided in legacy for billing reasons which should not be major concern for RTCWeb. In case of SIP forking, it is assumed that 2nd answer override the 1st answer in the media plane.
> 
> As I mentioned earlier, SIP (serial) forking requirement shall be met by gateway signaling and no extra requirement for browser. Also, switching media stream from one responder to other responder in Fedex IVR usecase is not so easy because of legacy media handling (ICE, RTCP) differences as mentioned in draft-kaplan-rtcweb-sip-interworking-requirements-00.
> 
> ISTM, we don't have RTCWeb specific forking usecase till now.
> 
> Thanks
> Partha 
> 
>> -----Original Message-----
>> From: Harald Alvestrand [mailto:[e-mail]]
>> Sent: Friday, October 28, 2011 11:58 PM
>> To: Ravindran Parthasarathi
>> Cc: Iñaki Baz Castillo; [e-mail]; Hadriel Kaplan
>> Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-
>> rtcweb-sip-interworking-requirements-00]
>> 
>> On 10/28/2011 10:56 AM, Ravindran Parthasarathi wrote:
>>> By looking at draft-ietf-rtcweb-use-cases-and-requirements-06, I could
>> not see any specific requirement for RTCWeb forking. In case SIP forking
>> is the only requirement for RTCWeb and also, RTCWeb does not have any
>> specific forking requirement, then the gateway between RTCWeb&  SIP
>> shall take care of the functionality. I'm asking this question to get
>> the clarity on whether SIP forking feature has to impact RTCWeb client
>> requirement or not.
>> I believe the "Fedex IVR" case was specifically intended to surface the
>> requirement for "non-final responses" (switching a media stream from the
>> initial responder to a next responder).
>> That's one form of forking ("serial fork"?)
>> 
>> I haven't understood forking to be a requirement in any other use case.
>