Re: [rtcweb] Remote recording - RTC-Web client acting as SIPREC session recording client

[Paul Kyzivat <[e-mail]>]

On 8/24/11 5:32 AM, Hutton, Andrew wrote:
> Randell,
>
> I would like to make it clear that I am not saying that SIPREC is a reason for putting SIP in the browser but if SIP is not in the browser then we need to be able to build applications like a SIPREC SRC using a combination of the browser and the web application.
>
> Therefore I do think that the remote recording case is a useful use case to explore and should not be out of scope as it helps us understand the type of media handling requirements that the browser needs to support innovative applications.
>
> Of course as John stated if a decision is made to put SIP in the browser then there would be additional browser and API requirements to support SIPREC.

I agree with John and Andrew.

Certainly it is possible to punt and say that if you want recording then 
you need to insert a B2BUA that is in the media path and that serves as 
the SRC. But before deciding that is "the story" for recording with 
RTCWEB, it would be good to understand the implications of that approach.

Since this is RTCWEB, I guess we can assume that there is a web server 
interacting with a browser. The browser will provide one end to some 
media streams. There will be another end to those media streams, which 
might be in another browser talking to the same web server, or the web 
server might have those media streams attached to a sip session. In some 
of the cases of interest, the web server won't itself ever touch the 
actual media.

If the web server wants to record the media, it needs to get an SRC into 
the signaling and media paths. If the session is already going to a sip 
server, then its probably not to hard to integrate SRC functionality 
there or juggle the signaling paths to involve a free standing SRC into 
the call path.

But if the web server is orchestrating media streams between browsers 
talking to it, without any sip, then adding recording will be more 
complex. It may need to pull in a sip server that can be an SRC, reroute 
the media through it, etc. Its not evident to me if this would be 
straightforward or not. I suspect not. It would be good to understand 
what would need to be done.

As John and/or Andrew mentioned, it could be advantageous if there were 
primitives by which the JavaScript in the browser had simple ways to 
fork the media and direct it different ways. That could eliminate the 
need to perturb the normal media path in order to do recording.

	Thanks,
	Paul

> Regards
> Andy
>
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Elwell, John
>> Sent: 24 August 2011 09:24
>> To: Randell Jesup; [e-mail]
>> Subject: Re: [rtcweb] Remote recording - RTC-Web client acting as
>> SIPREC session recording client
>>
>> Randell,
>>
>>> -----Original Message-----
>>> From: [e-mail]
>>> [mailto:[e-mail]] On Behalf Of Randell Jesup
>>> Sent: 24 August 2011 08:43
>>> To: [e-mail]
>>> Subject: Re: [rtcweb] Remote recording - RTC-Web client
>>> acting as SIPREC session recording client
>>>
>>> On 8/23/2011 1:50 PM, Hutton, Andrew wrote:
>>>
>>>> Hi,
>>>>
>>>> Also agree that implementing a full SIP Session Recording
>>> Client (SRC) as defined ]
>>>> by the SIPREC WG in to the browser would be a tall order
>>> and would open the flood
>>>> gates for a lot of other requests for SIP functionality in
>>> the browser.
>>>
>>> Agreed
>>>
>>>> If however SIP is not in the browser then I think it is a
>>> useful and interesting test case
>>>> to look at whether we could build a decomposed SRC with the
>>> browser handling the
>>>> media and the web server handling the signalling. What I
>>> heard a number of times at
>>>> IETF81 is that what people want is to build innovative new
>>> applications with a real time
>>>> media enabled browser and to it seems clear to me we need a
>>> browser API which is
>>>> flexible and enables applications to do clever things with
>>> media streams. So exploring
>>>> some use cases which require the browser to duplicate and
>>> copy media streams is a good idea.
>>>>
>>>> Therefore I think we should keep explore the remote
>>> recording use case further.
>>>
>>> My personal (not Mozilla's) opinion is that SIPREC-style recording is
>>> out-of-scope,
>>> and would be handled in this context by a webrtc-B2BUA (i.e.
>>> something
>>> that sits on the
>>> signalling and media paths), or something that interacts
>>> directly with
>>> the app.
>>>
>>> What I do want to consider for in-scope are local recording options.
>>> This can cover the "local
>>> answering machine" case, but also "I want to record my call
>>> with Dad",
>>> "I want to record
>>> my team's chatter in the game", "I want to interview someone for
>>> genealogy research", etc, etc.
>>> Yes, these can be done (poorly) by using some external app to capture
>>> the screen and
>>> speaker/mic audio - I don't consider that a replacement for
>>> local recording.
>>>
>>> Local recording is far less problematical protocol-wise than
>>> SIPREC, and
>>> doesn't require
>>> mandating SIP.
>> [JRE] I am not advocating supporting SIP in the browser just for the
>> purpose of supporting SIPREC SRC functionality. What I am saying is
>> that if the browser is concerned only with media aspects, then only the
>> media aspects of SRC functionality need to be considered in the browser
>> (e.g., copying the media streams). On the other hand, if, for other
>> reasons, SIP is implemented in the browser, it would require additional
>> enhancements to support SIP aspects of SIPREC SRC functionality.
>>
>> John
>>
>> John Elwell
>> Tel: [phone] (office and mobile)
>> Email: [e-mail]
>> http://www.siemens-enterprise.com/uk/
>>
>> Siemens Enterprise Communications Limited.
>> Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15
>> 0DJ.
>> Registered No: 5903714, England.
>>
>> Siemens Enterprise Communications Limited is a Trademark Licensee of
>> Siemens AG.
>>
>>
>>>
>>> --
>>> Randell Jesup
>>> [e-mail]
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>