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

["Ravindran Parthasarathi" <[e-mail]>]

John,

I like remote recording requirement. IMO, few changes may be required.

In SIPREC architecture, decomposed SRC with signaling handling in one
physical device (webserver in RTCWeb) and media handling in another
physical device(browser in RTCWeb) is possible but the communication
protocol between signaling server (webserver) and media server (browser)
is outside the scope of SIPREC. I agree that IETF Megaco (H.248) or IETF
Mediactrl of or equivalent proprietary mechanism between webserver &
browser will serve the purpose. IMO, it is better to spelt out
explicitly protocol mechanism between webserver & browser if this
architecture is chosen.

Actually, I thought of using browser as SIP UA & SRC which is not
consume more bandwidth compare to browser acts as media server because
number of signaling message compare to media messages are very low. I'm
discussing SIP UA based architecture because SIP as a protocol choice is
an open item in RTCWeb
(http://www.ietf.org/mail-archive/web/rtcweb/current/msg00730.html)

Thanks
Partha


>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
Behalf
>Of Elwell, John
>Sent: Thursday, August 25, 2011 6:21 PM
>To: Harald Alvestrand; [e-mail]
>Subject: Re: [rtcweb] Remote recording - RTC-Web client acting as
SIPREC
>session recording client
>
>
>
>
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Harald Alvestrand
>> Sent: 25 August 2011 13:02
>> To: [e-mail]
>> Subject: Re: [rtcweb] Remote recording - RTC-Web client
>> acting as SIPREC session recording client
>>
>> On 08/24/11 21:06, Paul Kyzivat wrote:
>> > 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.
>> If we can get the signalling part done through some channel
>> that doesn't
>> touch the RTCWEB API, it may be enough to say something like:
>>
>> The API MUST allow the application to specify that a copy of a media
>> stream (incoming or outgoing) is sent out to some other
correspondent.
>[JRE] This is the essential part of what I was trying to get across
when
>I originally proposed text for the use cases document. I reproduce it
>below, with a slight change to refer to a third party rather than a
>recording device:
>===================
>4.2.yy Remote Session Recording
>In this use case, the web application user wishes to record a real-time
>communication at a remote third party (e.g., a recording device), such
>that transmitted and received audio, video or other real-time media are
>transmitted in real-time to the third party. The third party can
perform
>recording, archiving, retrieval, playback, etc., but can also perform
>real-time analytics on the media. A typical deployment might be in a
>contact centre. For a given medium, the two directions of transmission
>can be transmitted together (mixed) or separately. The web application
>also sends metadata that gives context to the stored media.
>
>New requirements:
>Fyy1: The browser MUST be able to send in real-time to a third party
>media that are being transmitted to and received from remote
>participants.
>
>Ayy1: The web application MUST be able to ask the browser to transmit
in
>real-time to a third party media that are being transmitted to and
>received from remote participants and, in the case of audio at least,
>ask for the two directions of transmission to be transmitted to the
>remote recording device mixed or separately.
>====================
>
>I think it desirable that the application have control over whether to
>send mixed or unmixed, but we can certainly discuss that. It also has
>implications for the RTP model, because mixing implies an RTP mixer or
>endpoint model, rather than just relaying RTP packets. Other aspects
>such as whether a different security context is needed will also have
>impact.
>
>>
>> In PeerConnection API terms, that means that some construct like this
>> should work:
>>
>>     mainConn = new PeerConnection(...)
>> <connect mainConn to remote participant, producing remoteStream and
>> localStream>
>>     recorderConn = new PeerConnection(...)
>> <connect recorderConn to remote recorder>
>>     recorderConn.addStream(remoteStream)
>>     recorderConn.addStream(localStream)
>>
>> The important part of this, implementation-wise, is that one stream
>> needs to be able to have several destinations. What that
>> means for codec
>> negotiations, transcoding-or-not and so on may perhaps best be kept
>> under the covers.
>[JRE] By "under covers", I assume you mean not exposed at the API. That
>might be sufficient, but the implications need thinking about.
>
>John
>
>> >
>> >     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
>> >>
>> >
>> > _______________________________________________
>> > 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