idnits 2.17.1 draft-ram-siprec-metadata-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 7, 2010) is 4950 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-siprec-req-02 == Outdated reference: A later version (-12) exists of draft-ietf-siprec-architecture-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPREC Ram Mohan. Ravindranath 2 Internet-Draft Parthasarathi. Ravindran 3 Intended status: Standards Track Paul. Kyzivat 4 Expires: April 10, 2011 Cisco Systems, Inc. 5 October 7, 2010 7 Session Initiation Protocol (SIP) Recording Metadata 8 draft-ram-siprec-metadata-01 10 Abstract 12 Session recording is a critical requirement in many communications 13 environments such as call centers and financial trading. In some of 14 these environments, all calls must be recorded for regulatory, 15 compliance, and consumer protection reasons. Recording of a session 16 is typically performed by sending a copy of a media stream to a 17 recording device. This document describes the metadata model as 18 viewed by Session Recording Server(SRS). 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 10, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Metadata Model . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Recording Metadata elements . . . . . . . . . . . . . . . . . . 5 58 4.1. Recording Session . . . . . . . . . . . . . . . . . . . . . 5 59 4.2. Communication Session . . . . . . . . . . . . . . . . . . . 5 60 4.3. Recorded Media Streams . . . . . . . . . . . . . . . . . . 6 61 4.4. Received Media Streams . . . . . . . . . . . . . . . . . . 6 62 4.5. Participant . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.6. Application Data . . . . . . . . . . . . . . . . . . . . . 6 64 5. Association of different Recording metadata elements . . . . . 6 65 5.1. Recording Session : Communication Session . . . . . . . . . 6 66 5.2. Communication Session : Recorded Media Stream . . . . . . . 7 67 5.3. Recorded Media Stream : Received Media Stream . . . . . . . 7 68 5.4. Received Media Stream : Participant . . . . . . . . . . . . 7 69 5.5. Participant : Application Data . . . . . . . . . . . . . . 7 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 72 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 8 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 Session recording is a critical requirement in many communications 81 environments such as call centers and financial trading. In some of 82 these environments, all calls must be recorded for regulatory, 83 compliance, and consumer protection reasons. Recording of a session 84 is typically performed by sending a copy of a media stream to a 85 recording device. This document focuses on the Recording metadata 86 which describes the communication session. The document describes a 87 metadata modelas viewed by Session Recording Server, the architecture 88 for which is described in [I-D.ietf-siprec-architecture] and the 89 requirements for which are described in [I-D.ietf-siprec-req]. 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. This 96 document only uses these key words when referencing normative 97 statements in existing RFCs." 99 3. Metadata Model 101 Metadata is the data that describes the communication session. Below 102 diagram shows a model for Metadata as viewed by Session Recording 103 Server (SRS). 105 +-------------------------------+ 106 | Recording Session (RS) | 107 +-------------------------------+ 108 | Recording RequestorID(SRC or | 109 | SRS) | 1 110 | Reason for Recording |---------------+ 111 | Recording Type (Selective | | 112 | Persistant) | | 113 +-------------------------------+ | 114 | 1..* | 115 | | 116 | 0..* | 117 +-------------------------------+ 1 | 118 | Communication Session (CS) |---------------| 119 +-------------------------------+ | +--------------+ 120 | 1 | | | 121 | | 0..* |Application | 122 | 0..* |------| Data | 123 +-------------------------------+ | | | 124 | Recorded Media Stream | | +--------------+ 125 +-------------------------------+ | 126 | Recorded Media Stream | | 127 | Type (audio/video/...) | 1 | 128 | Recorded Encoding |---------------| 129 | Recorded Bits | | 130 +-------------------------------+ | 131 | 1 | 132 | | 133 | 1..* | 134 +-------------------------------+ | 135 | Received Media Stream | | 136 +-------------------------------+ | 137 | Start Time | 1 | 138 | End Time |---------------| 139 | Codec | | 140 | Media Stream Reference | | 141 +-------------------------------+ | 142 | 1..* | 143 | | 144 | 1..* | 145 +-------------------------------+ | 146 | Participant | | 147 +-------------------------------+ 1 | 148 | AoR |---------------+ 149 | Name | 150 +-------------------------------+ 151 The metadata model above MUST be used by a SRS. (NOTE: Not entirely 152 clear what sort of normative statement to make about this.) 154 The Session Recording Client (SRC) MUST initiate the Recording 155 Session. It should be noted that the Recording Session is a 156 completely independent from the Communication Session that is being 157 recorded at both the SIP dialog level and at the session level. The 158 metadata MUST be conveyed from SRC to SRS. The metadata MAY be 159 conveyed in Recording Session Dialog. 161 Note that the metadata model captures changes that occur over the 162 duration of the recording session. For example, if the call is 163 transferred from one participant to another, then the SRC MUST convey 164 a change of participant and received media stream in the 165 communication session. 167 Some of the data in the model may not be conveyed explicitly from the 168 SRC to the SRS, if it can be obtained contextually by the SRS. For 169 instance, the timing of changes may not explicitly conveyed from the 170 SRC to the SRC, because the mechanism (yet to be defined) which 171 conveys the metadata may implicitly provide the timing. (E.g. the 172 time a change occurred by be assumed to be the same as the time when 173 notification of the change is received by the SRS.) 175 4. Recording Metadata elements 177 This section describes the different elements and its attributes of 178 the metadata model shown above. 180 4.1. Recording Session 182 A Recording Session element represents one instance of a Recording 183 Session. It MAY have attributes like Recording requestor ID(which 184 could be SRS or SRC), reason for recording and recording type. The 185 reason for recording MUST be a policy(in a financial trading floor or 186 Call centre) or to monitor a agent, or for quality purposes etc. The 187 recording type attribute indicates whether the recording session is 188 selective or persistant. 190 4.2. Communication Session 192 A Communication Session element represents one instance of a 193 Communication Session. 195 NOTE: Discussions are needed to determine different attributes of CS 196 which are needed for SRS 198 4.3. Recorded Media Streams 200 A Recorded Media Stream represents the content of a media stream 201 captured and stored by the SRS. A Communication Session MUST have 202 one, and MAY have several, Recorded Media Streams. In addition to 203 the recorded media, it has attributes describing the encoding of the 204 recording. 206 4.4. Received Media Streams 208 A Received Media Stream is an element that represents a media stream 209 received by the SRS that contributed content to a recorded media 210 stream. There MUST be one Received Media Stream per Recorded Media 211 Stream if mixing is done before recording, or several if a separate 212 unmixed stream per participant is supplied. Or there could be 213 multiple per source (with disjoint time intervals) due to codec 214 changes. 216 The Received Media Stream element can have attributes like Start 217 time, End time, Codec, Media Stream reference. 219 4.5. Participant 221 A Participant represents one contributor of media. Participant has 222 attributes like AoR, Name. AoR MAY be SIP/SIPS/TEL URI. 224 4.6. Application Data 226 A recording metadata object MAY have a opaque application data. This 227 opaque data is intended to be used by vendor specific applications on 228 SRS. 230 5. Association of different Recording metadata elements 232 This section describes in brief on how the different elements of 233 metadata are associated. 235 5.1. Recording Session : Communication Session 237 A Recording Session element MAY have zero or more CS per RS. One CS 238 per RS is typical. Multiple CS per RS can arise due to private side 239 conversations, etc. Having no Communication Sessions is possible if 240 the RS is established in anticipation of future CS. 242 NOTE: We are currently modeling exactly one RS per CS, as a stake in 243 the ground. The assumption is that its difficult to distinguish a 244 single CS viewed from two different RSs. But this requires 245 discussion. 247 5.2. Communication Session : Recorded Media Stream 249 Communication Session MAY have zero or more Recorded Media Streams 250 for various reasons. Distinct media might have their own. (Or not - 251 maybe audio/video together.) Independent sources might be recorded 252 separately. 254 A Recorded Media Stream is always associated with exactly one 255 Recording Session. 257 5.3. Recorded Media Stream : Received Media Stream 259 There MUST be one or more Received Media Streams per Recorded Media 260 Stream. There may be one if mixing is done before recording, or if 261 media only flows in one direction. There may be several if a 262 separate unmixed stream per participant is supplied and mixing is 263 done at the recorder. Or there could be multiple for a single 264 participant (with disjoint time intervals) due to codec changes. 266 A Received Media Stream is always associated with exactly one 267 Recorded Media Stream. 269 5.4. Received Media Stream : Participant 271 A Received Media Stream MUST have one or more participants. 272 Typically there will be one, unless mixed before being sent to RS, in 273 which case there may be several. 275 A Participant MAY supply multiple Received Media Streams. 277 5.5. Participant : Application Data 279 NOTE: This is a place holder for as yet undefined data. 281 6. Security Considerations 283 The Recording Session is fundamentally a standard SIP dialog 284 [RFC3261] and media session and therefore make use of existing SIP 285 security mechanisms for securing the Recording Session and Media 286 Recording Metadata. 288 7. IANA Considerations 290 Not Applicable 292 8. Acknowledgement 294 We wish to thank John Elwell, Henry Lum and Leon Portman for the 295 valuable comments. 297 9. References 299 9.1. Normative References 301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", BCP 14, RFC 2119, March 1997. 304 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 305 A., Peterson, J., Sparks, R., Handley, M., and E. 306 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 307 June 2002. 309 9.2. Informative References 311 [I-D.ietf-siprec-req] 312 Rehor, K., Jain, R., Portman, L., and A. Hutton, 313 "Requirements for SIP-based Media Recording (SIPREC)", 314 draft-ietf-siprec-req-02 (work in progress), 315 September 2010. 317 [I-D.ietf-siprec-architecture] 318 Hutton, A., Portman, L., Jain, R., and K. Rehor, "An 319 Architecture for Media Recording using the Session 320 Initiation Protocol", draft-ietf-siprec-architecture-00 321 (work in progress), June 2010. 323 Authors' Addresses 325 Ram Mohan R 326 Cisco Systems, Inc. 327 Cessna Business Park, 328 Kadabeesanahalli Village, Varthur Hobli, 329 Sarjapur-Marathahalli Outer Ring Road 330 Bangalore, Karnataka 560103 331 India 333 Email: rmohanr@cisco.com 334 Parthasarathi R 335 Cisco Systems, Inc. 336 Cessna Business Park, 337 Kadabeesanahalli Village, Varthur Hobli, 338 Sarjapur-Marathahalli Outer Ring Road 339 Bangalore, Karnataka 560103 340 India 342 Email: partr@cisco.com 344 P. Kyzivat 345 Cisco Systems, Inc. 346 1414 Massachusetts Avenue 347 Boxborough, MA 01719 348 USA 350 Email: pkyzivat@cisco.com