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

[Harald Alvestrand <[e-mail]>]

On 10/31/2011 06:23 AM, Ravindran Parthasarathi wrote:
> 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.
Ravindran,

I see this as an implementation description, and not an use case.

Could you rephrase this in terms that make it clear what the user will 
be trying to do, and that this technology (forking) is the appropriate 
solution for that problem?

That will also help uncover more requirements that the use case will 
imply. For instance, if the idea is that the user talks to multiple 
persons simultaneously, and they are able to hear each other without a 
direct connection to each other, there is an added requirement that the 
user be able to mix audio from local and remote sources.

Thank you!

      Harald Alvestrand

> 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.
>