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

Harald Alvestrand <> Thu, 25 August 2011 12:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1BE4121F86B6 for <>; Thu, 25 Aug 2011 05:00:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.922
X-Spam-Status: No, score=-106.922 tagged_above=-999 required=5 tests=[AWL=3.677, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qyp5rsO9b0YS for <>; Thu, 25 Aug 2011 05:00:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BF11A21F86AC for <>; Thu, 25 Aug 2011 05:00:23 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9173839E113 for <>; Thu, 25 Aug 2011 14:00:21 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yfpgbcN9O3DC for <>; Thu, 25 Aug 2011 14:00:19 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTPS id C843839E082 for <>; Thu, 25 Aug 2011 14:00:19 +0200 (CEST)
Message-ID: <>
Date: Thu, 25 Aug 2011 14:01:34 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Remote recording - RTC-Web client acting as SIPREC session recording client
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Aug 2011 12:00:25 -0000

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.

In PeerConnection API terms, that means that some construct like this 
should work:

    mainConn = new PeerConnection(...)
<connect mainConn to remote participant, producing remoteStream and 
    recorderConn = new PeerConnection(...)
<connect recorderConn to remote recorder>

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.
>     Thanks,
>     Paul
>> Regards
>> Andy
>>> -----Original Message-----
>>> From: [] On
>>> Behalf Of Elwell, John
>>> Sent: 24 August 2011 09:24
>>> To: Randell Jesup;
>>> Subject: Re: [rtcweb] Remote recording - RTC-Web client acting as
>>> SIPREC session recording client
>>> Randell,
>>>> -----Original Message-----
>>>> From:
>>>> [] On Behalf Of Randell Jesup
>>>> Sent: 24 August 2011 08:43
>>>> To:
>>>> 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: +44 1908 817801 (office and mobile)
>>> Email:
>>> 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
>>>> _______________________________________________
>>>> rtcweb mailing list
>>> _______________________________________________
>>> rtcweb mailing list
>> _______________________________________________
>> rtcweb mailing list
> _______________________________________________
> rtcweb mailing list