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

[Ravindran Parthasarathi <[e-mail]>]

Harald,

Please read inline.

Thanks
Partha

>-----Original Message-----
>From: Harald Alvestrand [mailto:[e-mail]]
>Sent: Thursday, November 03, 2011 4:07 PM
>To: Ravindran Parthasarathi
>Cc: <[e-mail]>
>Subject: Re: New usecase & requirement for media forking in browser
>
>On 11/03/2011 12:55 AM, Ravindran Parthasarathi wrote:
>> 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.
>This does not need forking. The caller (the agent) is the one setting up
>2 connections.
>He will also have to relay media from the customer to the supervisor.
>> 2) Remote Recording: The call is forked towards remote peer as well as
>recording server. This usecase is already covered in usecase document
>Again, this does not need forking. The client creating 2 connections is
>the one deciding to do so.

<partha> I'll take this usecase because it is very common usecase. Client (browser) is not required to create two connection in this scenario if recording request is going as metadata and WebRTC Server forks the request to remote peer and recorder. Please note that client is not required to know the recorder destination till get the answer. </partha>

>> 3) Interworking SIP parallel forking with RTCWeb client:
>"Because SIP does it" is not an use case.
<partha> Agree with you as RTCWeb client is not the only way to solve this interworking usecase. Interworking itself could be the usecase for RTCWeb but it is not as we interested in Freedom world. The point to be noted is that SIP parallel forking (media) infrastructure helps for the above two usecases as well. </partha>

>> Please let me know your opinion on addition of this usecase now.
>I still do not see an use case from this description.
>> 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.
>>