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

[Ravindran Parthasarathi <[e-mail]>]

Harald,

Thanks for your clarification. Some of the usecase which comes immediately to my mind for media forking are as follows:

1) Whisper call scenario:  Telemarketing Agent makes the call to the customer and the same call is forked to Supervisor for support/monitoring. Here, Customer will not realize that Supervisor & Agent has side conversation.

2) Remote Recording: The call is forked towards remote peer as well as recording server. This usecase is already covered in usecase document

3) Interworking SIP parallel forking with RTCWeb client: 

Please let me know your opinion on addition of this usecase now.

Thanks
Partha
>-----Original Message-----
>From: Harald Alvestrand [mailto:[e-mail]]
>Sent: Monday, October 31, 2011 9:30 PM
>To: Ravindran Parthasarathi
>Cc: <[e-mail]>
>Subject: Re: New usecase & requirement for media forking in browser
>
>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.
>>