SIPREC Ram Mohan. Ravindranath Internet-Draft Parthasarathi. Ravindran Intended status: Standards Track Paul. Kyzivat Expires: April 10, 2011 Cisco Systems, Inc. October 7, 2010 Session Initiation Protocol (SIP) Recording Metadata draft-ram-siprec-metadata-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 the metadata model as viewed by Session Recording Server(SRS). 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). 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 10, 2011. 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 Ravindranath, et al. Expires April 10, 2011 [Page 1] Internet-Draft SIP Recording Metadata October 2010 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Metadata Model . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Recording Metadata elements . . . . . . . . . . . . . . . . . . 5 4.1. Recording Session . . . . . . . . . . . . . . . . . . . . . 5 4.2. Communication Session . . . . . . . . . . . . . . . . . . . 5 4.3. Recorded Media Streams . . . . . . . . . . . . . . . . . . 6 4.4. Received Media Streams . . . . . . . . . . . . . . . . . . 6 4.5. Participant . . . . . . . . . . . . . . . . . . . . . . . . 6 4.6. Application Data . . . . . . . . . . . . . . . . . . . . . 6 5. Association of different Recording metadata elements . . . . . 6 5.1. Recording Session : Communication Session . . . . . . . . . 6 5.2. Communication Session : Recorded Media Stream . . . . . . . 7 5.3. Recorded Media Stream : Received Media Stream . . . . . . . 7 5.4. Received Media Stream : Participant . . . . . . . . . . . . 7 5.5. Participant : Application Data . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Ravindranath, et al. Expires April 10, 2011 [Page 2] Internet-Draft SIP Recording Metadata October 2010 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 focuses on the Recording metadata which describes the communication session. The document describes a metadata modelas viewed by Session Recording Server, the architecture for which is described in [I-D.ietf-siprec-architecture] and the requirements for which are described in [I-D.ietf-siprec-req]. 2. 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]. This document only uses these key words when referencing normative statements in existing RFCs." 3. Metadata Model Metadata is the data that describes the communication session. Below diagram shows a model for Metadata as viewed by Session Recording Server (SRS). Ravindranath, et al. Expires April 10, 2011 [Page 3] Internet-Draft SIP Recording Metadata October 2010 +-------------------------------+ | Recording Session (RS) | +-------------------------------+ | Recording RequestorID(SRC or | | SRS) | 1 | Reason for Recording |---------------+ | Recording Type (Selective | | | Persistant) | | +-------------------------------+ | | 1..* | | | | 0..* | +-------------------------------+ 1 | | Communication Session (CS) |---------------| +-------------------------------+ | +--------------+ | 1 | | | | | 0..* |Application | | 0..* |------| Data | +-------------------------------+ | | | | Recorded Media Stream | | +--------------+ +-------------------------------+ | | Recorded Media Stream | | | Type (audio/video/...) | 1 | | Recorded Encoding |---------------| | Recorded Bits | | +-------------------------------+ | | 1 | | | | 1..* | +-------------------------------+ | | Received Media Stream | | +-------------------------------+ | | Start Time | 1 | | End Time |---------------| | Codec | | | Media Stream Reference | | +-------------------------------+ | | 1..* | | | | 1..* | +-------------------------------+ | | Participant | | +-------------------------------+ 1 | | AoR |---------------+ | Name | +-------------------------------+ Ravindranath, et al. Expires April 10, 2011 [Page 4] Internet-Draft SIP Recording Metadata October 2010 The metadata model above MUST be used by a SRS. (NOTE: Not entirely clear what sort of normative statement to make about this.) The Session Recording Client (SRC) MUST 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. The metadata MUST be conveyed from SRC to SRS. The metadata MAY be conveyed in Recording Session Dialog. Note that the metadata model captures changes that occur over the duration of the recording session. For example, if the call is transferred from one participant to another, then the SRC MUST convey a change of participant and received media stream in the communication session. Some of the data in the model may not be conveyed explicitly from the SRC to the SRS, if it can be obtained contextually by the SRS. For instance, the timing of changes may not explicitly conveyed from the SRC to the SRC, because the mechanism (yet to be defined) which conveys the metadata may implicitly provide the timing. (E.g. the time a change occurred by be assumed to be the same as the time when notification of the change is received by the SRS.) 4. Recording Metadata elements This section describes the different elements and its attributes of the metadata model shown above. 4.1. Recording Session A Recording Session element represents one instance of a Recording Session. It MAY have attributes like Recording requestor ID(which could be SRS or SRC), reason for recording and recording type. The reason for recording MUST be a policy(in a financial trading floor or Call centre) or to monitor a agent, or for quality purposes etc. The recording type attribute indicates whether the recording session is selective or persistant. 4.2. Communication Session A Communication Session element represents one instance of a Communication Session. NOTE: Discussions are needed to determine different attributes of CS which are needed for SRS Ravindranath, et al. Expires April 10, 2011 [Page 5] Internet-Draft SIP Recording Metadata October 2010 4.3. Recorded Media Streams A Recorded Media Stream represents the content of a media stream captured and stored by the SRS. A Communication Session MUST have one, and MAY have several, Recorded Media Streams. In addition to the recorded media, it has attributes describing the encoding of the recording. 4.4. Received Media Streams A Received Media Stream is an element that represents a media stream received by the SRS that contributed content to a recorded media stream. There MUST be one Received Media Stream per Recorded Media Stream if mixing is done before recording, or several if a separate unmixed stream per participant is supplied. Or there could be multiple per source (with disjoint time intervals) due to codec changes. The Received Media Stream element can have attributes like Start time, End time, Codec, Media Stream reference. 4.5. Participant A Participant represents one contributor of media. Participant has attributes like AoR, Name. AoR MAY be SIP/SIPS/TEL URI. 4.6. Application Data A recording metadata object MAY have a opaque application data. This opaque data is intended to be used by vendor specific applications on SRS. 5. Association of different Recording metadata elements This section describes in brief on how the different elements of metadata are associated. 5.1. Recording Session : Communication Session A Recording Session element MAY have zero or more CS per RS. One CS per RS is typical. Multiple CS per RS can arise due to private side conversations, etc. Having no Communication Sessions is possible if the RS is established in anticipation of future CS. NOTE: We are currently modeling exactly one RS per CS, as a stake in the ground. The assumption is that its difficult to distinguish a single CS viewed from two different RSs. But this requires Ravindranath, et al. Expires April 10, 2011 [Page 6] Internet-Draft SIP Recording Metadata October 2010 discussion. 5.2. Communication Session : Recorded Media Stream Communication Session MAY have zero or more Recorded Media Streams for various reasons. Distinct media might have their own. (Or not - maybe audio/video together.) Independent sources might be recorded separately. A Recorded Media Stream is always associated with exactly one Recording Session. 5.3. Recorded Media Stream : Received Media Stream There MUST be one or more Received Media Streams per Recorded Media Stream. There may be one if mixing is done before recording, or if media only flows in one direction. There may be several if a separate unmixed stream per participant is supplied and mixing is done at the recorder. Or there could be multiple for a single participant (with disjoint time intervals) due to codec changes. A Received Media Stream is always associated with exactly one Recorded Media Stream. 5.4. Received Media Stream : Participant A Received Media Stream MUST have one or more participants. Typically there will be one, unless mixed before being sent to RS, in which case there may be several. A Participant MAY supply multiple Received Media Streams. 5.5. Participant : Application Data NOTE: This is a place holder for as yet undefined data. 6. Security Considerations The Recording Session is fundamentally a standard SIP dialog [RFC3261] and media session and therefore make use of existing SIP security mechanisms for securing the Recording Session and Media Recording Metadata. 7. IANA Considerations Not Applicable Ravindranath, et al. Expires April 10, 2011 [Page 7] Internet-Draft SIP Recording Metadata October 2010 8. Acknowledgement We wish to thank John Elwell, Henry Lum and Leon Portman for the valuable comments. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. 9.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-02 (work in progress), September 2010. [I-D.ietf-siprec-architecture] Hutton, A., Portman, L., Jain, R., and K. Rehor, "An Architecture for Media Recording using the Session Initiation Protocol", draft-ietf-siprec-architecture-00 (work in progress), June 2010. Authors' Addresses Ram Mohan R Cisco Systems, Inc. Cessna Business Park, Kadabeesanahalli Village, Varthur Hobli, Sarjapur-Marathahalli Outer Ring Road Bangalore, Karnataka 560103 India Email: rmohanr@cisco.com Ravindranath, et al. Expires April 10, 2011 [Page 8] Internet-Draft SIP Recording Metadata October 2010 Parthasarathi R Cisco Systems, Inc. Cessna Business Park, Kadabeesanahalli Village, Varthur Hobli, Sarjapur-Marathahalli Outer Ring Road Bangalore, Karnataka 560103 India Email: partr@cisco.com P. Kyzivat Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA Email: pkyzivat@cisco.com Ravindranath, et al. Expires April 10, 2011 [Page 9]