Internet DRAFT - draft-hutton-dispatch-session-recording-arch
draft-hutton-dispatch-session-recording-arch
DISPATCH Working Group A. Hutton
Internet-Draft Siemens Enterprise Communications
Intended status: BCP L. Portman
Expires: August 30, 2010 Nice Systems
R. Jain
IPC Systems
K. Rehor
Cisco Systems, Inc.
February 26, 2010
An Architecture for Media Recording using the Session Initiation
Protocol
draft-hutton-dispatch-session-recording-arch-00
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). This is an initial
draft which explores possible architectural solutions and has many
open issues.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Hutton, et al. Expires August 30, 2010 [Page 1]
Internet-Draft Architecture for Media Recording February 2010
This Internet-Draft will expire on August 30, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Hutton, et al. Expires August 30, 2010 [Page 2]
Internet-Draft Architecture for Media Recording February 2010
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Session Recording Architectures . . . . . . . . . . . . . . . 5
4.1. Location of the Recording Client . . . . . . . . . . . . . 5
4.1.1. B2BUA acts as a Recording Client . . . . . . . . . . . 5
4.1.2. Endpoint acts as Recording Client . . . . . . . . . . 6
4.2. Establishing the Recording Session . . . . . . . . . . . . 7
4.2.1. Recording Client Initiated Recording . . . . . . . . . 8
4.2.2. Recording Server Initiated Recording . . . . . . . . . 8
4.2.3. Pause/Resume Recording Session . . . . . . . . . . . . 9
4.2.4. Media Stream Mixing . . . . . . . . . . . . . . . . . 9
4.3. Media Recording Metadata . . . . . . . . . . . . . . . . . 9
4.3.1. Contents of recording metadata . . . . . . . . . . . . 9
4.3.2. Mechanisms for delivery of metadata to Recording
Server . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Notifications to the Recorded User Agents . . . . . . . . 10
4.5. Preventing the recording of a SIP session . . . . . . . . 10
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security considerations . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Hutton, et al. Expires August 30, 2010 [Page 3]
Internet-Draft Architecture for Media Recording February 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
Recording Server (RS): A Recording Server (RS) is a SIP User Agent
(UA) that is a specialized media server or collector that acts as the
sink of the recorded media. An Recording Server is typically
implemented as a multi-port device that is capable of receiving media
from several sources simultaneously. An Recording Server is
typically also the sink of the Media Recording Metadata.
Recording Client (RC): A Recording Client (RC) is a SIP User Agent
(UA) that acts as the source of the recorded media, sending it to the
Recording Server. An Recording Client is a logical function. Its
capabilities may be implemented across one or more physical devices.
In practice, an Recording Client could be a personal device (such as
a SIP phone), a SIP Media Gateway (MG), a Session Border Controller
(SBC) or an Application Server. The Recording Client is also the
source of the recorded session metadata
Communication Session: A SIP session created between two or more
UA's for the purpose of communication which may be recorded (I.e.
Not the Recording Session).
Recording Session: The session created between an Recording Client
and 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: The metadata describing the communication
session that is required by the Recording Server. This will include
for example the identity of users that participate in the
Communication Session and dialog state. Typically this metadata is
archived with the replicated media at the recording server. The
media recording metadata is delivered in real-time to the Recording
Server.
Hutton, et al. Expires August 30, 2010 [Page 4]
Internet-Draft Architecture for Media Recording February 2010
Replicated Media: A copy of the media associated with the
Communication Session created by the Recording Client and sent to the
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.rehor-dispatch-session-recording-req].
This is an initial draft which explores possible architectural
solutions and has many open issues.
This document focuses on how sessions are established between a
Recording Client (RC) and the Recording Server for the purpose of
conveying the Replicated Media and Media Recording Metadata (e.g.
Identity of parties involves) relating to the Communication Session.
Once the Replicated Media and Media Recording Metadata have been
received by the 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 Recording
Client purposefully streams media to a 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 are outside the
scope of this document which takes account of the IETF policy on
wiretapping [RFC2804].
The Recording Session that is established between the Recording
Client and the 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 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 Recording Server and is not
Hutton, et al. Expires August 30, 2010 [Page 5]
Internet-Draft Architecture for Media Recording February 2010
buffered by the Recording Client to allow for real-time analysis of
the media by the Recording Server.
This is an initial draft which explores some possible architectural
solutions for media recording using SIP and it is intended as a basis
for discussion. A future version of this document will focus on a
specific architectural solution and protocol extensions.
4. Session Recording Architectures
4.1. Location of the Recording Client
This section contains some example session recording architectures
showing how the Recording Client is a logical function that can be
located in or split between various physical components.
4.1.1. B2BUA acts as a Recording Client
A SIP B2BUA which has access to the media that is to be recorded may
act as a 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/RC makes the decision to initiate the Recording Session
then it will initiate the establishment of a SIP Session by sending
an INVITE to the Recording Server.
If the 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/Recording Client.
OPEN ISSUE: What would the Recording Server use as the Request-URI
and how does it indicate that it wishes to record the session (i.e.
recvonly the media). The Recording server will probably need to use
an offerless INVITE to allow the RC to provide the offer. We also
want to make sure the Recording Session actually terminates at a
Recording Server and is not accidently retargeted so probably need to
include a require header indicating that recording is required.
The B2BUA/RC is responsible for notifying the UA's involved in the
communication session that the session is being recorded.
The B2BUA/RC is responsible for honouring any indication from
recording aware UA's that the communication session must not be
recorded.
Hutton, et al. Expires August 30, 2010 [Page 6]
Internet-Draft Architecture for Media Recording February 2010
The Recording Server if it requires Media Recording Metadata relating
to the communications session will request this information from the
Recording Client.
OPEN ISSUE: Does the Recording Server have to request metadata from
the Recording Client our does the Recording Client provide it anyway?
(Recording Session) +-----------+
+----------------- RTP -------------->| |
| +--------- SIP --->| Recording |
| | | Server |
| | +- MetaData ->| (RS) |
| | | +-----------+
| | |
| | |
| V |
| +-------------+
| +--- SIP --->| |
| | | B2BUA |
| | | |
| V | Recording |
+--------+ | Client | +---------+
| |<- SIP ->| |<- SIP ->| |
| UA-A | +-------------+ | UA-B |
| | | |
| |<------------- RTP ------------->| |
+--------+ (Recorded Session) +---------+
Figure 1: B2BUA Acts as the Recording Client.
4.1.2. Endpoint acts as Recording Client
A SIP Endpoint / User Agent may act as a Recording Client in which
case the endpoint sends the Replicated Media to the 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 Recording Server.
If the Recording Server makes the decision to initiate the Recording
Session then it will initiate the establishment of a SIP Session by
Hutton, et al. Expires August 30, 2010 [Page 7]
Internet-Draft Architecture for Media Recording February 2010
sending an INVITE to the endpoint.
OPEN ISSUE: What would the Recording Server use as the Request-URI
and how does it indicate that it wishes to record the session (i.e.
recvonly the media).
(Recording Session) +-----------+
+----------SIP------>| |
| +-------RTP------>| Recording |
| | | Server |
| | + (RS) |
| | +-- Metadata -->| |
| | | | |
| | | +-----------+
| | |
| | |
| | |
| | |
V | | (Communication Session)
+--+------+ +---------+
| |<-------SIP--------->| |
| UA-A | | UA-B |
| |<-------RTP--------->| |
+---------+ +---------+
Figure 2: SIP Endpoint acts as the Recording Client
4.2. Establishing the Recording Session
The Recording Client or the 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
both the SIP dialog level and at the session level. For example if
media encryption is used for the Communication Session the 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 Recording
Server.
Hutton, et al. Expires August 30, 2010 [Page 8]
Internet-Draft Architecture for Media Recording February 2010
4.2.1. Recording Client Initiated Recording
When the Recording Client initiates the Recording Session for the
purpose of conveying media to the Recording Server it performs the
following actions.
o Initiates the dialog by sending an INVITE request to the 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. Still
to be decided what this is
o If the Replicated Media is to be started immediately then the
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 Recording Server.
4.2.2. Recording Server Initiated Recording
When the Recording Server initiates the media recording session with
the Recording Client it performs the following actions.
o Send an INVITE request to the 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
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]
Hutton, et al. Expires August 30, 2010 [Page 9]
Internet-Draft Architecture for Media Recording February 2010
o If the Recording Session is to be started immediately then the
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
OPEN ISSUE: How does the Recording Server discover what media
streams are available to be recorded does it use an offerless INVITE
and leave this decision to the Recording Client.
OPEN ISSUE: If the 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 Recording Server or the 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 Recording Client before being transmitted to the
Recording Server or it may be a requirement of the recoding server
that the media streams are not mixed and are sent to the Recording
Server as two separate streams. The case when media is mixed at the
Recording Client is simple as only a single media stream is required
to be sent to the Recording Server. However in the case when the
media streams are not mixed then the SDP offer sent to the Recording
Server must describe two separate media streams. OPEN ISSUE: HOW TO
DO THIS COULD BE TWO SEPERATE INVITE DIALOGS OR SOME SDP ENHANCEMENTS
?
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 Recording Client to
the Recording Server in the recording metadata. OPEN ISSUE: Need
some discussion on this.
Hutton, et al. Expires August 30, 2010 [Page 10]
Internet-Draft Architecture for Media Recording February 2010
o Dialog identifiers for the Communication Session
o Identities of users 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 Recording Server
OPEN ISSUE: How should the metadata be transported possible
mechanisms include an INFO package [I-D.ietf-sipcore-info-events]or
an event package (possibly the dialog event package).
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 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 Recording Client is a SIP
endpoint.
If the Recording Client is aware that the remote UA is a recording
aware UA then it MUST notify the UA using a SIP based mechanism.
OPEN ISSUE: TO BE DEFINED. If the 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
Hutton, et al. Expires August 30, 2010 [Page 11]
Internet-Draft Architecture for Media Recording February 2010
terminated.
5. IANA considerations
None.
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 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 Recording Client act that the Recording Client decrypts and re-
encrypts media, means the Recording Client must take precautions to
prevent disclosure of media in the clear. Also the Recording Client
has to be trusted not to manipulate or suppress media.
It is the responsibility of the 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.
Hutton, et al. Expires August 30, 2010 [Page 12]
Internet-Draft Architecture for Media Recording February 2010
[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.
7.2. Informative References
[I-D.rehor-dispatch-session-recording-req]
Rehor, K., Jain, R., Portman, L., Gurbani, V., and H.
Kaplan, "Requirements for Session Recording Protocol
(SRP)", draft-rehor-dispatch-session-recording-req-00
(work in progress), October 2009.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804,
May 2000.
[I-D.ietf-sipcore-info-events]
Holmberg, C., Burger, E., and H. Kaplan, "Session
Initiation Protocol (SIP) INFO Method and Package
Framework", draft-ietf-sipcore-info-events-07 (work in
progress), February 2010.
Authors' Addresses
Andrew Hutton
Siemens Enterprise Communications
KG Hofmannstrasse 51
Munich D-81379
Germany
Phone: +44 1908 855395
Email: andrew.hutton@siemens-enterprise.com
URI: http://www.siemens-enterprise.com
Hutton, et al. Expires August 30, 2010 [Page 13]
Internet-Draft Architecture for Media Recording February 2010
Leon Portman
Nice Systems
8 Hapnina
Ra'anana 43017
Israel
Email: leon.portman@nice.com
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 August 30, 2010 [Page 14]
