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

"Ravindran Parthasarathi" <> Tue, 23 August 2011 09:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDF6221F8880 for <>; Tue, 23 Aug 2011 02:34:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.28
X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bJW8jBRO-vEX for <>; Tue, 23 Aug 2011 02:34:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2BC4121F87F9 for <>; Tue, 23 Aug 2011 02:34:05 -0700 (PDT)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p7N9Zb8O019812; Tue, 23 Aug 2011 05:35:37 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Aug 2011 05:35:09 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 23 Aug 2011 15:05:05 +0530
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [rtcweb] Remote recording - RTC-Web client acting as SIPREC session recording client
Thread-Index: AcxhcPhJALRhDbneQI2akXZYIpXUkwAAPZrw
References: <> <>
From: "Ravindran Parthasarathi" <>
To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= <>, <>
X-OriginalArrivalTime: 23 Aug 2011 09:35:09.0007 (UTC) FILETIME=[F2D6D5F0:01CC6177]
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: Tue, 23 Aug 2011 09:34:06 -0000


As you expect, I have disagreement for not including this usecase in RTCweb 1.0. My reasoning are as follows:

1) As John pointed out and other folks responded, remote recording has importance in few segments like call centre deployment.

2) RTCweb1.0 solution without considering this usecase may end-up in a non-scalable RTCWeb remote recording solution for ever or break RTCWeb1.0 to meet this architectural need of remote recording. 

3) Based on SIPREC discussion, it is very apparent that short-sighted SIP Endpoint implementation which assumes single session for the end-point are forced to interop with SRS using middle box only . I wish that the same situation does not occur for rtcweb clients.


>-----Original Message-----
>From: [] On Behalf
>Of Stefan Håkansson LK
>Sent: Tuesday, August 23, 2011 2:15 PM
>Subject: Re: [rtcweb] Remote recording - RTC-Web client acting as SIPREC
>session recording client
>I must admit that my instinctive reaction when reading this is:
>1. Say that SRC and SRS functionality is out of scope for rtcweb/webrtc
>version 1.
>2. If someone wants to support this, force media through a middlebox
>(which has all media and can do stuff like inserting beeps, mixing,
>recording, ...).
>I'm sure there are other opinions....
>On 2011-08-23 09:58, Elwell, John wrote:
>> There has been some discussion recently on remote recording, mixed to
>some extent with discussions on local recording and with mailbox, but I
>would like to focus on remote recording and try to summarize.
>> First, some background on the IETF SIPREC WG. This is specifying
>support for SIP-based session recording, whereby a Session Recording
>Client (SRC) on the path of a call (communication session) can forward
>media and metadata to a session recording server (SRS) or recording
>device. In conventional SIP terms, the SRC can exist at an endpoint of
>the communication session being recorded (i.e., at a SIP UA), or at a
>B2BUA that has access to the media as well as the signalling. Very often
>in a contact centre, there are mandatory requirements for recording some
>or all communication sessions, and often calls are routed through a
>B2BUA that also provides the SRC. So in this case there is no
>responsibility on SIP UAs to support SRC functionality, and no issues of
>additional bandwidth on the device's access. However, it is anticipated
>in SIPREC that in some deployments UA-located SRCs will be used. How a
>UA is organized internally to provide SRC functionality is not
>> So the question for RTC-Web is whether a SIP UA implemented as an RTC-
>Web client can provide SRC functionality, i.e., support remote
>recording. An RTC-Web SIP UA is implemented by a combination of
>functionality running on the web server, functionality running in client
>side script (JS) and functionality embedded in the browser. The amount
>of functionality needed in the browser and needing to be exposed at the
>browser API in support of SRC will depend to some extent on how much
>core functionality goes into the browser, in particular whether the
>browser implements SIP or not. Some of the functions noted to date
>> - ability to take a copy of streams sent to / received from the remote
>party and send them, in real-time, to a remote recording device (SRS);
>> - possible need to mix the copied streams before sending (e.g., mix
>the sent and received audio streams)
>> - possible need to use a different codec or other parameters when
>sending to the SRS;
>> - possible need to use a different encryption/integrity context when
>sending to the SRS;
>> - possible need to insert tones / announcements into the original
>media path being recorded;
>> - possible need to support SDP enhancements for indicating media that
>are being recorded or preferences for which media are being recorded;
>> - possible need to support SIP enhancements for indicating SRC/SRS
>capability and recording awareness (if SIP is implemented in browser);
>> - possible need to support the sending of metadata to the SRS (if SIP
>is implemented in browser).
>> Clearly there would be a fairly big hurdle for browsers to support SRC
>functionality. But without this, RTC-Web clients would not be suitable
>for use in environments where remote recording is required and calls are
>not forced through some middlebox that provides 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
>> Registered No: 5903714, England.
>> Siemens Enterprise Communications Limited is a Trademark Licensee of
>Siemens AG.
>> _______________________________________________
>> rtcweb mailing list
>rtcweb mailing list