SIPREC A. Hutton
Internet-Draft Siemens Enterprise Communications
Intended status: Informational L. Portman
Expires: December 20, 2010 Nice Systems
R. Jain
IPC Systems
K. Rehor
Cisco Systems, Inc.
June 18, 2010
An Architecture for Media Recording using the Session Initiation
Protocol
draft-hutton-siprec-session-recording-arch-01
Abstract
Session recording is a critical requirement in many communications
environments such as call centers and financial trading. In some of
these environments, all calls must be recorded for regulatory,
compliance, and consumer protection reasons. Recording of a session
is typically performed by sending a copy of a media stream to a
recording device. This document describes architectures for
deploying session recording solutions in an environment which is
based on the Session Initiation Protocol (SIP).
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 20, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Hutton, et al. Expires December 20, 2010 [Page 1]
Internet-Draft Architecture for Media Recording June 2010
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Session Recording Architecture . . . . . . . . . . . . . . . . 5
4.1. Location of the Session Recording Client . . . . . . . . . 5
4.1.1. B2BUA acts as a Session Recording Client . . . . . . . 5
4.1.2. Endpoint acts as Session Recording Client . . . . . . 6
4.1.3. Interaction with MEDIACTRL . . . . . . . . . . . . . . 7
4.1.4. Interaction with Conference Focus . . . . . . . . . . 8
4.2. Establishing the Recording Session . . . . . . . . . . . . 8
4.2.1. Session Recording Client Initiated Recording . . . . . 9
4.2.2. Session Recording Server Initiated Recording . . . . . 9
4.2.3. Pause/Resume Recording Session . . . . . . . . . . . . 10
4.2.4. Media Stream Mixing . . . . . . . . . . . . . . . . . 10
4.2.5. Media Transcoding . . . . . . . . . . . . . . . . . . 10
4.3. Media Recording Metadata . . . . . . . . . . . . . . . . . 11
4.3.1. Contents of recording metadata . . . . . . . . . . . . 11
4.3.2. Mechanisms for delivery of metadata to Session
Recording Server . . . . . . . . . . . . . . . . . . . 11
4.4. Notifications to the Recorded User Agents . . . . . . . . 12
4.5. Preventing the recording of a SIP session . . . . . . . . 12
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Hutton, et al. Expires December 20, 2010 [Page 2]
Internet-Draft Architecture for Media Recording June 2010
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119] and
indicate requirement levels for compliant mechanisms.
2. Definitions
Session Recording Server (SRS): A Session Recording Server (SRS) is
a SIP User Agent (UA) that acts as the sink of the recorded media.
An SRS is a logical function that typically archives media for
extended durations of time and provides interfaces for search and
retrieval of the archived media. An SRS is typically implemented as
a multi-port device that is capable of receiving media from several
sources simultaneously. An SRS is typically also the sink of the
recorded session metadata. Note that the term "Server" does not
imply the SRS is the server side of a signaling protocol - the SRS
may be the initiator of recording requests, for example.
Session Recording Client (SRC): A Session Recording Client (SRC) is
a SIP User Agent (UA) that acts as the source of the recorded media,
sending it to the Session Recording Server. A Session Recording
Client is a logical function. Its capabilities may be implemented
across one or more physical devices. In practice, a Session
Recording Client could be a personal device (such as a SIP phone), a
SIP Media Gateway (MG), a Session Border Controller (SBC), Media
Server, or an Application Server. The Session Recording Client is
also the source of the recorded session metadata.
Communication Session (CS): A SIP session created between two or
more UA's for the purpose of communication which may be recorded.
Recording Session (RS): The session created between an Session
Recording Client and Session Recording Server for the purpose of
recording a Communication Session.
Recording aware UA: A SIP User Agent that can at a minimum
understand notifications indicating that a Communication Session in
which it is involved is being recorded. It may also be able to
express preferences relating to whether a Communication session can
or should be recorded.
Media Recording Metadata (MRM): The metadata describing the
communication session that is required by the Session Recording
Server. This will include for example the identity of users that
participate in the Communication Session and dialog state. Typically
Hutton, et al. Expires December 20, 2010 [Page 3]
Internet-Draft Architecture for Media Recording June 2010
this metadata is archived with the replicated media at the Session
Recording Server. The media recording metadata is delivered in real-
time to the Session Recording Server.
Replicated Media: A copy of the media associated with the
Communication Session created by the Session Recording Client and
sent to the Session Recording Server. It may contain all the media
associated with the communication session (E.g. Audio and Video) or
just a subset (E.g. Audio).
3. Introduction
Session recording is a critical requirement in many communications
environments such as call centers and financial trading. In some of
these environments, all calls must be recorded for regulatory,
compliance, and consumer protection reasons. Recording of a session
is typically performed by sending a copy of a media stream to a
recording device. This document describes architectures for
deploying session recording solutions in an environment which is
based on the Session Initiation Protocol (SIP) the requirements for
which are described in [I-D.ietf-siprec-req].
This document focuses on how sessions are established between a
Session Recording Client (SRC) and the Session Recording Server (SRS)
for the purpose of conveying the Replicated Media and Media Recording
Metadata (e.g. Identity of parties involved) relating to the
Communication Session.
Once the Replicated Media and Media Recording Metadata have been
received by the Session Recording Server they will typically be
archived for retrieval at a later time. The procedures relating to
the archiving and retrieval of this information in outside the scope
of this document.
This document only considers active recording, where the Session
Recording Client purposefully streams media to a Session Recording
Server. Passive recording, where a recording device detects media
directly from the network (E.g. using port mirroring techniques), is
outside the scope of this document. In addition, lawful intercept is
outside the scope of this document which takes account of the IETF
policy on wiretapping [RFC2804].
The Recording Session that is established between the Session
Recording Client and the Session Recording Server uses the normal
procedures for establishing INVITE initiated dialogs as specified in
[RFC3261] and uses SDP for describing the media to be used during the
session as specified in [RFC4566]. However it is intended that some
Hutton, et al. Expires December 20, 2010 [Page 4]
Internet-Draft Architecture for Media Recording June 2010
extensions to SIP (E.g. Headers, Option Tags, Etc.) will be defined
to support the requirements for media recording. The Replicated
Media is required to be sent in real-time to the Session Recording
Server and is not buffered by the Session Recording Client to allow
for real-time analysis of the media by the Session Recording Server.
4. Session Recording Architecture
4.1. Location of the Session Recording Client
This section contains some example session recording architectures
showing how the Session Recording Client is a logical function that
can be located in or split between various physical components.
4.1.1. B2BUA acts as a Session Recording Client
A SIP B2BUA which has access to the media that is to be recorded may
act as a Session Recording Client. The B2BUA may already be aware
that a session needs to be recorded before the initial establishment
of the communication session or the decision to record the session
may occur after the session has been established.
If the B2BUA/SRC makes the decision to initiate the Recording Session
(RS) then it will initiate the establishment of a SIP Session by
sending an INVITE to the Session Recording Server.
If the Session Recording Server makes the decision to initiate the
recording session then it will initiate the establishment of a SIP
Session by sending an INVITE to the B2BUA/Session Recording Client.
The RS INVITE will need to contain information which identifies the
session as being established for the purposes of recording and
prevents the session from being accidently rerouted to a UA which is
not a SRS.
The B2BUA/SRC is responsible for notifying the UA's involved in the
communication session that the session is being recorded.
The B2BUA/SRC is responsible for honoring any indication from
recording aware UA's or through some configured policies that the
communication session must not be recorded.
The Session Recording Server if it requires Media Recording Metadata
relating to the communications session will request this information
from the Session Recording Client.
OPEN ISSUE: Does the Session Recording Server have to request
Hutton, et al. Expires December 20, 2010 [Page 5]
Internet-Draft Architecture for Media Recording June 2010
metadata from the SRC or does the SRC provide it anyway?
+-----------+
(Recording Session) | Session |
+----SIP-------->| Recording |
| | Server |
| +----RTP---->| (SRS) |
| | +-----------+
V | ^
+-------------+ |
| | |
| |--- MetaData -+
| |
| B2BUA |
| |
| Session |
+--------+ | Recording | +---------+
| |<- SIP ->| Client |<- SIP ->| |
| UA-A | | (SRC) | | UA-B |
| |<- RTP ->| |<- RTP ->| |
+--------+ | | +---------+
+-------------+
(Communication Session) (Communication Session)
Figure 1: B2BUA Acts as the Session Recording Client.
4.1.2. Endpoint acts as Session Recording Client
A SIP Endpoint / User Agent may act as a Session Recording Client in
which case the endpoint sends the Replicated Media to the Session
Recording Server
If the endpoint makes the decision to initiate the Recording Session
then it will initiate the establishment of a SIP Session by sending
an INVITE to the Session Recording Server.
If the Session Recording Server makes the decision to initiate the
Recording Session then it will initiate the establishment of a SIP
Session by sending an INVITE to the endpoint.
OPEN ISSUE - Need to state how the SRC and SRS address each other -
Use of GRUU etc.
Hutton, et al. Expires December 20, 2010 [Page 6]
Internet-Draft Architecture for Media Recording June 2010
(Recording Session) +-----------+
+----------SIP------>| |
| +-------RTP------>| Session |
| | | Recording |
| | + Server |
| | +-- Metadata -->| (SRS) |
| | | | |
| | | +-----------+
| | |
| | |
| | |
| | |
V | | (Communication Session)
+--+------+ +---------+
| |<-------SIP--------->| |
| UA-A | | UA-B |
| (SRC) |<-------RTP--------->| |
+---------+ +---------+
Figure 2: SIP Endpoint acts as the Session Recording Client
4.1.3. Interaction with MEDIACTRL
The mediactrl architecture [RFC5567] describes an architecure in
which an application server (AS) controls a Media Server (MS) which
may be used for purposes such as conferencing and recording media
streams. In this architecure the AS typically uses SIP Third Party
Call Control (3PCC) to instruct the SIP UA's to direct the media to
the Media Server.
The Session Recording Client and Session Recording Server described
in this document may act as an application server as described in
[RFC5567] and therefore may when further decomposed be made up of an
application server which uses a mediactrl interface to control a
media server for the purpose of recording the media streams however
this interface is considered outside the scope of this document.
Hutton, et al. Expires December 20, 2010 [Page 7]
Internet-Draft Architecture for Media Recording June 2010
(Recording Session) +-----------+
+----------SIP------>| Session | +------------+
| | Recording | MEDIACTRL | |
| | Server |<----------->| Media |
| + / | | Server |
| +---- Metadata -->| MediaCtrl | | (Recorder)|
| | |Application| | |
| | | Server | +------------+
| | +-----------+ ^
| | |
| | +--------------- RTP ----------------------------
| | |
V | V
+--+------+ +---------+
| |<-------SIP--------->| |
| UA-A | | UA-B |
| (SRC) |<-------RTP--------->| |
+---------+ +---------+
(Communication Session)
Figure 3: Example of Session Recording Server using MEDIACTRL
4.1.4. Interaction with Conference Focus
In the case of a centralised conference the conference focus
[RFC4353] may also act as a SRC and therefore provide the SRS with a
copy of the conferenced media or as a Recording Aware Client in the
case when recording is initiated by one of the conference
participants.
The SRC when co-located with a conference focus may provide the SRS
with information of all the conference participants within the
recording metadata and be able to correlate the media streams, in the
case of providing the SRS with separate streams for each participant,
by providing information in the metadata which identifies the media
stream for a given participant (E.g. SSRC).
4.2. Establishing the Recording Session
The Session Recording Client or the Session Recording Server may
initiate the Recording Session.
It should be noted that the Recording Session is a completely
independent from the Communication Session that is being recorded at
Hutton, et al. Expires December 20, 2010 [Page 8]
Internet-Draft Architecture for Media Recording June 2010
both the SIP dialog level and at the session level. For example if
media encryption is used for the Communication Session the Session
Recording Client must decrypt any media received on the Communication
Session and, if required, re-encrypt the media using a separate SRTP
key for the Recording Session before sending the media to the Session
Recording Server.
4.2.1. Session Recording Client Initiated Recording
When the Session Recording Client initiates the Recording Session for
the purpose of conveying media to the Session Recording Server it
performs the following actions.
o Initiates the dialog by sending an INVITE request to the Session
Recording Server. The dialog is established according to the
normal procedures for establishing an INVITE initiated dialog as
specified in [RFC3261].
o Include in the INVITE an indication that the session is
established for the purpose of recording the associated media.
Possible mechanisms for this include using the Require header
and/or a new media feature tag similar to the use of "isfocus" as
defined in [RFC3840]
o Indicate support for the recording metadata event package.
o If the Replicated Media is to be started immediately then the
Session Recording Client will include an SDP attribute of
"a=sendonly" for each media line or "a=inactive" if it is not
ready to transmit the media.
o The Recording Session may replicate all media associated with the
Communication Session or only a subset.
o Replicate the media streams that are to be recorded and transmit
the media to the Session Recording Server.
4.2.2. Session Recording Server Initiated Recording
When the Session Recording Server initiates the media recording
session with the Session Recording Client it performs the following
actions.
o Send an INVITE request to the Session Recording Client
o Include in the INVITE an indication that the session is
established for the purpose of recording the associated media.
Possible mechanisms for this include using the Require header or a
Hutton, et al. Expires December 20, 2010 [Page 9]
Internet-Draft Architecture for Media Recording June 2010
media feature tag similar to the use of "isfocus" as defined in
[RFC3840]
o Identify the session that is to be recorded - Possibly using the
Join header [RFC3911]
o If the Recording Session is to be started immediately then the
Session Recording Client will include an SDP attribute of
"a=recvonly" for each media line or "a=inactive" if it is not
ready to receive the media
If the Session Recording Server does not have prior knowledge of what
media streams are available to be recorded it can make use of an
offerless INVITE which allows the Session Recording Client to make
the initial SDP offer.
OPEN ISSUE: If the Session Recording Server wants to invoke
persistent recording (I.e. all calls) and establish the recording
session before the recorded session is established what are the
procedures for this ?
4.2.3. Pause/Resume Recording Session
The Session Recording Server or the Session Recording Client may
pause the recording by changing the SDP direction attribute to
"inactive" and resume the recording by changing the direction back to
"sendonly" or "recvonly"
4.2.4. Media Stream Mixing
In a basic session involving only audio there are typically two
audio/RTP streams between the two UA's involved transporting media in
each direction. When recording this media the two streams may be
mixed at the Session Recording Client before being transmitted to the
Session Recording Server or it may be a requirement of the recoding
server that the media streams are not mixed and are sent to the
Session Recording Server as two separate streams. The case when
media is mixed at the Session Recording Client is simple as only a
single media stream is required to be sent to the Session Recording
Server. However in the case when the media streams are not mixed
then the SDP offer sent to the Session Recording Server must describe
two separate media streams.
4.2.5. Media Transcoding
The communication session (CS) and the recording session (RS) are
negotiated separately using a standard SDP offer/answer exchange
which may result in the SRC having to perform media transcoding
Hutton, et al. Expires December 20, 2010 [Page 10]
Internet-Draft Architecture for Media Recording June 2010
between the two sessions. If the SRC is not capable of performing
media transcoding it may be limit the media formats in the offer to
the SRS depending on what media is negotiated on the CS or may limit
what it includes in the offer on the CS if it has prior knowledge of
the media formats supported by the SRS. However typically the SRS
will be the more capable device which can provide a wide range of
media format options to the SRC and may also be able to make use of a
media transcoder as detailed in [RFC5369].
4.3. Media Recording Metadata
4.3.1. Contents of recording metadata
The content of the recording metadata will be defined in a separate
specification and therefore the following list is just a guide to the
type of information that may be conveyed by the Session Recording
Client to the Session Recording Server in the recording metadata.
o Dialog identifiers for the Communication Session
o Identities of SIP UA's taking part in the Communication Session
o Dialog state of the Communication Session
o Session state relating to the Communication Session(i.e. sendonly,
inactive, sendrecv).
o Etc.
4.3.2. Mechanisms for delivery of metadata to Session Recording Server
The recording metadata definition will be described through an XML
schema. There are several potential mechanisms for transporting
metadata from SRC to SRS. They have their pros and cons. These
mechanisms include the following:
o Event Package: The metadata event XML documents may be conveyed
from SRC to SRS by defining an event-package and using it with the
SIP events notification mechanism [RFC3265]. This allows the
metadata to be communicated within its own SUBSCRIBE initiated
dialog as opposed to be in-band to the SIP INVITE RS dialog. This
allows for sending metadata where the CS and RS lifecycles are
different.
o INFO Package: The metadata event XML documents may be conveyed
from SRC to SRS by defining an INFO package
[draft-ietf-sipcore-info-events] and using it inside the SIP
method [RFC 2976]. Since INFO is a mid-dialog request, this
Hutton, et al. Expires December 20, 2010 [Page 11]
Internet-Draft Architecture for Media Recording June 2010
mechanism requires the metadata to be communicated within the SIP
INVITE RS dialog.
o Using Non-SIP Mechanism: The recording metadata may be conveyed
using some other non-SIP means (e.g. HTTP, WS-*), while still
adhering to the recording metadata XML.
4.4. Notifications to the Recorded User Agents
Typically a user that is involved in a session that is to be recorded
is notified by an announcement at the beginning of the session or may
receive some warning tones within the media. However the
standardization of media recording protocols when using SIP enable an
indication that the call is being recorded to be included in the
signaling associated with that communication session
It is the Session Recording Client that must provide a notification
to all users for which it is replicated received media for the
purpose of recording including the local user if the Session
Recording Client is a SIP endpoint.
If the Session Recording Client is aware that the remote UA is a
recording aware UA then it MUST notify the UA using a SIP based
mechanism. If the Session Recording Client is not aware that the
peer UA is a recording aware UA then it MUST use an in-band tone or
announcement to notify the remote UA.
4.5. Preventing the recording of a SIP session
A Recording Aware UA may include one of the following indications in
an INVITE request.
o No Recording Allowed
o Recording Required
OPEN ISSUES: How are these conveyed one possibility is to use the
require header so that if they are not understood the dialog will be
terminated.
5. IANA considerations
None.
Hutton, et al. Expires December 20, 2010 [Page 12]
Internet-Draft Architecture for Media Recording June 2010
6. Security considerations
The Recording Session is fundamentally a standard SIP dialog and
media session and therefore make use of existing SIP security
mechanisms for securing the Recording Session and Media Recording
Metadata. SRTP is used for securing the Replicated Media.
The intended use of this architecture is only for the case where the
users are aware of that they are being recorded and the architecture
provides the means for the Session Recording Client to notify users
that they are being recorded.
This architectural solution is not intended to support lawful
intercept which in contrast requires that users are not informed.
The Session Recording Client fact that the Recording Client decrypts
and re-encrypts media, means the Session Recording Client must take
precautions to prevent disclosure of media in the clear. Also the
Session Recording Client has to be trusted not to manipulate or
suppress media.
It is the responsibility of the Session Recording Server to protect
the Replicated Media and Media Recording Metadata once it has been
received and archived.
7. References
7.1. Normative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol
(SIP) "Join" Header", RFC 3911, October 2004.
Hutton, et al. Expires December 20, 2010 [Page 13]
Internet-Draft Architecture for Media Recording June 2010
7.2. Informative References
[I-D.ietf-siprec-req]
Rehor, K., Jain, R., Portman, L., and A. Hutton,
"Requirements for SIP-based Media Recording (SIPREC)",
draft-ietf-siprec-req-00 (work in progress), May 2010.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353,
February 2006.
[RFC5567] Melanchuk, T., "An Architectural Framework for Media
Server Control", RFC 5567, June 2009.
[RFC5369] Camarillo, G., "Framework for Transcoding with the Session
Initiation Protocol (SIP)", RFC 5369, October 2008.
[RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804,
May 2000.
Authors' Addresses
Andrew Hutton
Siemens Enterprise Communications
KG Hofmannstrasse 51
Munich D-81379
Germany
Email: andrew.hutton@siemens-enterprise.com
Leon Portman
Nice Systems
8 Hapnina
Ra'anana 43017
Israel
Email: leon.portman@nice.com
Hutton, et al. Expires December 20, 2010 [Page 14]
Internet-Draft Architecture for Media Recording June 2010
Rajnish Jain
IPC Systems
777 Commerce Drive
Fairfield, CT 06825
USA
Email: rajnish.jain@ipc.com
Ken Rehor
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Email: krehor@cisco.com
Hutton, et al. Expires December 20, 2010 [Page 15]