SIPREC A. Hutton Internet-Draft Siemens Enterprise Communications Intended status: BCP L. Portman Expires: October 31, 2010 Nice Systems R. Jain IPC Systems K. Rehor Cisco Systems, Inc. April 29, 2010 An Architecture for Media Recording using the Session Initiation Protocol draft-hutton-siprec-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 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 October 31, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the Hutton, et al. Expires October 31, 2010 [Page 1] Internet-Draft Architecture for Media Recording April 2010 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. 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 . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . 10 6. Security considerations . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Hutton, et al. Expires October 31, 2010 [Page 2] Internet-Draft Architecture for Media Recording April 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 October 31, 2010 [Page 3] Internet-Draft Architecture for Media Recording April 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-siprec-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 October 31, 2010 [Page 4] Internet-Draft Architecture for Media Recording April 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 October 31, 2010 [Page 5] Internet-Draft Architecture for Media Recording April 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) | | +----SIP-------->| Recording | | | Server | | +----RTP---->| (RS) | | | +-----------+ V | ^ +-------------+ | | | | | |--- MetaData -+ | | | B2BUA | | | | Recording | +--------+ | Client | +---------+ | |<- SIP ->| |<- SIP ->| | | UA-A | | | | UA-B | | |<- RTP ->| |<- RTP ->| | +--------+ | | +---------+ +-------------+ (Communication Session) (Communication 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 sending an INVITE to the endpoint. Hutton, et al. Expires October 31, 2010 [Page 6] Internet-Draft Architecture for Media Recording April 2010 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. 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 Hutton, et al. Expires October 31, 2010 [Page 7] Internet-Draft Architecture for Media Recording April 2010 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] 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 Hutton, et al. Expires October 31, 2010 [Page 8] Internet-Draft Architecture for Media Recording April 2010 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. o Dialog identifiers for the Communication Session o Identities of users taking part in the Communication Session o Dialog state of the Communication Session Hutton, et al. Expires October 31, 2010 [Page 9] Internet-Draft Architecture for Media Recording April 2010 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 terminated. 5. IANA considerations None. Hutton, et al. Expires October 31, 2010 [Page 10] Internet-Draft Architecture for Media Recording April 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 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. [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 October 31, 2010 [Page 11] Internet-Draft Architecture for Media Recording April 2010 7.2. Informative References [I-D.rehor-siprec-req] Rehor, K., Jain, R., Portman, L., and A. Hutton, "Requirements for SIP-based Media Recording (SIPREC)", draft-rehor-siprec-req-00 (work in progress), April 2010. [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 Leon Portman Nice Systems 8 Hapnina Ra'anana 43017 Israel Email: leon.portman@nice.com Hutton, et al. Expires October 31, 2010 [Page 12] Internet-Draft Architecture for Media Recording April 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 October 31, 2010 [Page 13]