SIPREC A. Hutton, Ed. Internet-Draft Siemens Enterprise Intended status: Informational Communications Expires: April 5, 2012 L. Portman, Ed. Nice Systems R. Jain IPC Systems K. Rehor Cisco Systems, Inc. October 3, 2011 An Architecture for Media Recording using the Session Initiation Protocol draft-ietf-siprec-architecture-03 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 April 5, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Hutton, et al. Expires April 5, 2012 [Page 1] Internet-Draft Architecture for Media Recording October 2011 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Session Recording Architecture . . . . . . . . . . . . . . . . 5 3.1. Location of the Session Recording Client . . . . . . . . . 5 3.1.1. B2BUA acts as a Session Recording Client . . . . . . . 5 3.1.2. Endpoint acts as Session Recording Client . . . . . . 7 3.1.3. A SIP Proxy cannot be a Session Recording Client . . . 7 3.1.4. Interaction with MEDIACTRL . . . . . . . . . . . . . . 8 3.1.5. Interaction with Conference Focus . . . . . . . . . . 9 3.2. Establishing the Recording Session . . . . . . . . . . . . 10 3.2.1. Session Recording Client Initiated Recording . . . . . 11 3.2.2. Session Recording Server Initiated Recording . . . . . 11 3.2.3. Pause/Resume Recording Session . . . . . . . . . . . . 12 3.2.4. Media Stream Mixing . . . . . . . . . . . . . . . . . 12 3.2.5. Media Transcoding . . . . . . . . . . . . . . . . . . 12 3.3. Media Recording Metadata . . . . . . . . . . . . . . . . . 12 3.3.1. Contents of recording metadata . . . . . . . . . . . . 13 3.3.2. Mechanisms for delivery of metadata to Session Recording Server . . . . . . . . . . . . . . . . . . . 13 3.4. Notifications to the Recorded User Agents . . . . . . . . 13 3.5. Preventing the recording of a SIP session . . . . . . . . 13 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 5. Security considerations . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 7. Informative References . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Hutton, et al. Expires April 5, 2012 [Page 2] Internet-Draft Architecture for Media Recording October 2011 1. 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 [RFC6341]. 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 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. Hutton, et al. Expires April 5, 2012 [Page 3] Internet-Draft Architecture for Media Recording October 2011 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 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 as the SRS may be the initiator of recording requests. 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 is aware of SIP extensions associated with the Communication Session. Such extensions may be used to notify the SIP UA that a session is being recorded or to all the SIP UA to express preferences as to whether a recording should be started, paused, resumed or stopped. 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 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 Hutton, et al. Expires April 5, 2012 [Page 4] Internet-Draft Architecture for Media Recording October 2011 just a subset (E.g. Audio). 3. Session Recording Architecture 3.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. 3.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. Hutton, et al. Expires April 5, 2012 [Page 5] Internet-Draft Architecture for Media Recording October 2011 +-----------+ (Recording Session) | Session | +------SIP------>| Recording | | | Server | | +--RTP/RTCP-->| (SRS) | | | +-----------+ V | ^ +-------------+ | | | | | |-- MetaData -+ | | | B2BUA | | | | Session | +--------+ | Recording | +---------+ | |<- SIP ->| Client |<- SIP ->| | | UA-A | | (SRC) | | UA-B | | |<- RTP ->| |<- RTP ->| | +--------+ | | +---------+ +-------------+ |____________________________________________________| (Communication Session) Figure 1: B2BUA Acts as the Session Recording Client. Hutton, et al. Expires April 5, 2012 [Page 6] Internet-Draft Architecture for Media Recording October 2011 3.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. (Recording Session) +-----------+ +----------SIP------>| | | +----RTP/RTCP---->| Session | | | | Recording | | | | Server | | | +-- Metadata -->| (SRS) | | | | | | | | | +-----------+ | | | | | | | | | | | | V | | (Communication Session) +--+------+ +---------+ | |<-------SIP--------->| | | UA-A | | UA-B | | (SRC) |<-----RTP/RTCP------>| | +---------+ +---------+ Figure 2: SIP Endpoint acts as the Session Recording Client 3.1.3. A SIP Proxy cannot be a Session Recording Client A SIP Proxy is unable to act as an SRC because it does not have access to the media and therefore has no way of enabling the delivery of the replicated media to the SRS Hutton, et al. Expires April 5, 2012 [Page 7] Internet-Draft Architecture for Media Recording October 2011 3.1.4. 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 the [RFC5567] architecure the AS typically uses SIP Third Party Call Control (3PCC) to instruct the SIP UA's to direct their 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. In addition, any appropriate control protocols such as RTC-Web can be used for such decomposition. Session Recording Server (SRS) +----------------------------------------+ | | (Recording Session) | +-----------+ +------------+ | +------------SIP----|->| | | | | | | | MediaCtrl |MEDIACTRL | Media | | | | |Application|<-------->| Server | | | +-----Metadata--->| Server | | (Recorder)| | | | | | | | | | | | | +-----------+ +------------+ | | | | ^ | | | +------------------------------|---------+ | | +--------------- RTP/RTCP -----------------+ | | | V | V +---+------+ +---------+ | |<-------SIP-------------->| | | UA-A | (Communication Session) | UA-B | | (SRC) |<-------RTP/RTCP--------->| | +----------+ +---------+ Figure 3: Example of Session Recording Server using MEDIACTRL Hutton, et al. Expires April 5, 2012 [Page 8] Internet-Draft Architecture for Media Recording October 2011 +----------+ (Recording Session) | Session | +-----------SIP------------------------->|Recording | | | Server | | | (SRS) | | UA-A Session Recording Client (SRC) +----------+ +----------------------------------------+ | | | | | +-----------+ +------------+ | | | | | Control | |<----RTP---+ +---------+ | | UA | Protocol | Media | | | | | |Application|<-------->| Server | |<----SIP----->| UA-B | | | Server | | |<-----RTP------>| | | | | | | | +---------+ | +-----------+ +------------+ | | | +----------------------------------------+ Figure 4: Example of Session Recording Client decomposition 3.1.5. Interaction with Conference Focus In the case of a centralised conference a combination of the conference focus and mixer [RFC4353] may act as a SRC and therefore provide the SRS with the replicated media and associated media recording metadata. In this arrangement the SRC is able to provide media and metadata relating to each of the participants, including, for example, any side conversations where the media passes through the mixer The conference focus may also act as a Recording Aware UA in the case when one of the participants acts as a SRC. In an alternative arrangement a SIP endpoint which is a conference participant can act as an SRC. The SRC will in this case have access to the media and metadata relating to that particular participant and may be able to obtain additional metadata from the conference focus. The SRC may for example use the conference event package as described in [RFC4575] to obtain information about other participants which it provides to the SRS within the media recording metadata. The SRC may be involved in the conference from the very beginning or may join at some later point of time. Hutton, et al. Expires April 5, 2012 [Page 9] Internet-Draft Architecture for Media Recording October 2011 User 1 +-----------+ | | | | |Participant| | 1 | | | +-----------+ |SIP |Dialog |1 User 2 | Recording +-----------+ +-----------+ Session ************* | | | |--------------* * | | | |----RTP 1 --->* * |Participant|-----------| Focus/SRC |----RTP 2 --->* SRS * | 2 | SIP | |----RTP 3 --->* * | | Dialog | | * * +-----------+ 2 +-----------+ ************* | |SIP |Dialog |3 | +-----------+ | | | | |Participant| | 3 | | | +-----------+ User 3 Figure 5: Conference Focus acting as an SRC. 3.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 independent from the Communication Session that is being recorded at both the SIP dialog level and at the session level. Concerning media negotiation, regular SIP/SDP capabilities should be used, and existing transcoding capabilities should not be precluded Hutton, et al. Expires April 5, 2012 [Page 10] Internet-Draft Architecture for Media Recording October 2011 3.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 The SRC is provisioned with a URI for the SRS, which is resolved through normal [RFC3263] procedures. 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 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. 3.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 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 April 5, 2012 [Page 11] Internet-Draft Architecture for Media Recording October 2011 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. 3.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 "recvonly" or "sendonly". 3.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 SRC before being transmitted to the SRS or it may be a requirement of the recording server that the media streams are not mixed and are sent to the SRS as two separate streams. The case when media is mixed at the SRC is simple as only a single media stream is required to be sent to the SRS. However in the case when the media streams are not mixed then the SDP offer sent to the SRS must describe two separate media streams. 3.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 between the two sessions. If the SRC is not capable of performing media transcoding it may 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]. 3.3. Media Recording Metadata Hutton, et al. Expires April 5, 2012 [Page 12] Internet-Draft Architecture for Media Recording October 2011 3.3.1. Contents of recording metadata The metadata model is defined in [I-D.ietf-siprec-metadata]. 3.3.2. Mechanisms for delivery of metadata to Session Recording Server The SRS obtains session recording metadata from the SRC. The metadata is transported via SIP based mechanisms as specified in [I-D.ietf-siprec-protocol] It is also possible that metadata is transported via non SIP based mechanisms but these are considered out of scope. 3.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 SIP requests and responses associated with that communication session. It is the Session Recording Client that provides the notification to all SIP UA's for which it is replicating received media for the purpose of recording including the local user if the Session Recording Client is a SIP endpoint. 3.5. Preventing the recording of a SIP session A Recording Aware UA may during the initial session establishment or during an established session provide an indication of their preference with regard to recording the media in the communication session. The mechanism for this are specified in [I-D.ietf-siprec-protocol] 4. IANA considerations None. 5. 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. Hutton, et al. Expires April 5, 2012 [Page 13] Internet-Draft Architecture for Media Recording October 2011 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. 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. 6. Acknowledgements Thanks to John Elwell, Alan Johnson, Cullen Jennings, Hadriel Kaplan, Henry Lum, Paul Kyzivat, Parthasarathi R, Ram Mohan R, and Charles Eckel for their significant contributions and assistance with this document and Working Group, and to all the members of the SIPREC WG mailing list for providing valuable input to this work. 7. Informative 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. [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004. [RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use Cases and Requirements for SIP-Based Media Recording (SIPREC)", RFC 6341, August 2011. [I-D.ietf-siprec-metadata] R, R., Ravindran, P., and P. Kyzivat, "Session Initiation Protocol (SIP) Recording Metadata", draft-ietf-siprec-metadata-04 (work in progress), September 2011. Hutton, et al. Expires April 5, 2012 [Page 14] Internet-Draft Architecture for Media Recording October 2011 [I-D.ietf-siprec-protocol] Portman, L., Lum, H., Johnston, A., and A. Hutton, "Session Recording Protocol", draft-ietf-siprec-protocol-00 (work in progress), August 2011. [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. [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 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 (editor) Siemens Enterprise Communications Hofmannstrasse 51 Munich D-81379 Germany Email: andrew.hutton@siemens-enterprise.com Hutton, et al. Expires April 5, 2012 [Page 15] Internet-Draft Architecture for Media Recording October 2011 Leon Portman (editor) 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 April 5, 2012 [Page 16]