[rtcweb] New usecase & requirement for media forking in browser

[Ravindran Parthasarathi <[e-mail]>]

Usecase:  Media forking in browser

Description: User forks local stream/stream components to multiple peers simultaneously and able to receive multiple streams from multiple peers. 

Functional requirement: F11, F12, (any new requirement has to be added ?)

API requirement:   The Web API MUST provide means for the web application to initiate sending/receiving of stream/stream components to a multiple peer simultaneously and relate each of these streams individually by web application.

Having said that, I'm not very sure whether this usecase falls under the category of remote-recording by John.

Hadriel,

Thanks for the clarification on the current status and practical usecases.

Thanks
Partha


>-----Original Message-----
>From: Hadriel Kaplan [mailto:[e-mail]]
>Sent: Saturday, October 29, 2011 1:58 AM
>To: Ravindran Parthasarathi
>Cc: Harald Alvestrand; Iñaki Baz Castillo; <[e-mail]>
>Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE:draft-kaplan-
>rtcweb-sip-interworking-requirements-00]
>
>
>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.
>>