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

"Elwell, John" <john.elwell@siemens-enterprise.com> Tue, 23 August 2011 07:57 UTC

Return-Path: <john.elwell@siemens-enterprise.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 927E421F8997 for <rtcweb@ietfa.amsl.com>; Tue, 23 Aug 2011 00:57:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.221
X-Spam-Status: No, score=-103.221 tagged_above=-999 required=5 tests=[AWL=-0.622, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nrFyrxZLrmEt for <rtcweb@ietfa.amsl.com>; Tue, 23 Aug 2011 00:57:24 -0700 (PDT)
Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com []) by ietfa.amsl.com (Postfix) with ESMTP id 7592F21F856A for <rtcweb@ietf.org>; Tue, 23 Aug 2011 00:57:24 -0700 (PDT)
Received: from MCHP064A.global-ad.net (unknown []) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 2FEDB1EB8468; Tue, 23 Aug 2011 09:58:31 +0200 (CEST)
Received: from MCHP058A.global-ad.net ([]) by MCHP064A.global-ad.net ([]) with mapi; Tue, 23 Aug 2011 09:58:31 +0200
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Date: Tue, 23 Aug 2011 09:58:30 +0200
Thread-Topic: Remote recording - RTC-Web client acting as SIPREC session recording client
Thread-Index: AcxhanJfOVyAVK9AQb6/ifBQPZV7FQ==
Message-ID: <A444A0F8084434499206E78C106220CA0B00FDB08B@MCHP058A.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [rtcweb] Remote recording - RTC-Web client acting as SIPREC session recording client
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Aug 2011 07:57:25 -0000

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 standardized.

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 include:
- 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 Elwell
Tel: +44 1908 817801 (office and mobile)
Email: john.elwell@siemens-enterprise.com

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.