idnits 2.17.1 draft-ram-siprec-metadata-00.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (August 23, 2010) is 4993 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) == Unused Reference: 'RFC3261' is defined on line 319, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-siprec-req-00 == Outdated reference: A later version (-12) exists of draft-ietf-siprec-architecture-00 Summary: 0 errors (**), 0 flaws (~~), 5 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: February 24, 2011 Cisco Systems, Inc. 5 August 23, 2010 7 Session Initiation Protocol (SIP) Recording Metadata 8 draft-ram-siprec-metadata-00 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 February 24, 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 Group . . . . . . . . . . . . . . . . . . 5 59 4.2. Recording Session . . . . . . . . . . . . . . . . . . . . . 5 60 4.3. Communication Session . . . . . . . . . . . . . . . . . . . 5 61 4.4. Recorded Media Streams . . . . . . . . . . . . . . . . . . 5 62 4.5. Received Media Streams . . . . . . . . . . . . . . . . . . 6 63 4.6. Participant . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.7. Application Data . . . . . . . . . . . . . . . . . . . . . 6 65 5. Association of different Recording metadata elements . . . . . 6 66 5.1. Recording Session Group : Recording Session . . . . . . . . 6 67 5.2. Recording Session : Communication Session . . . . . . . . . 6 68 5.3. Communication Session : Recorded Media Stream . . . . . . . 7 69 5.4. Recorded Media Stream : Received Media Stream . . . . . . . 7 70 5.5. Received Media Stream : Participant . . . . . . . . . . . . 7 71 5.6. Participant : Application Data . . . . . . . . . . . . . . 7 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 Session recording is a critical requirement in many communications 82 environments such as call centers and financial trading. In some of 83 these environments, all calls must be recorded for regulatory, 84 compliance, and consumer protection reasons. Recording of a session 85 is typically performed by sending a copy of a media stream to a 86 recording device. This document focuses on the Recording metadata 87 which describes the communication session. The document describes a 88 metadata modelas viewed by Session Recording Server, the architecture 89 for which is described in [I-D.ietf-siprec-architecture] and the 90 requirements for which are described in [I-D.ietf-siprec-req]. 92 2. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. This 97 document only uses these key words when referencing normative 98 statements in existing RFCs. 100 3. Metadata Model 102 Metadata is the data that describes the communication session. Below 103 diagram shows a model for Metadata as viewed by Session Recording 104 Server (SRS). 106 +-------------------------------+ 107 | Recording Session Group | 108 +-------------------------------+ 109 | 0..* 110 | 111 | 1..* 112 +-------------------------------+ 113 | Recording Session (RS) | 114 +-------------------------------+ 115 | Recording RequestorID(SRC or | 116 | SRS) | 117 | Reason for Recording | 118 | Recording Type (Selective | 119 | Persistant) | 120 +-------------------------------+ 121 | 1..* 122 | 123 | 0..* 125 +-------------------------------+ 126 | Communication Session (CS) | 127 +-------------------------------+ 128 | 1 129 | 130 | 0..* 131 +-------------------------------+ 132 | Recorded Media Stream | 133 +-------------------------------+ 134 | Type (audio/video/...) | 135 | Recorded Encoding | 136 | Recorded Bits | 137 +-------------------------------+ 138 | 1 139 | 140 | 1..* 141 +-------------------------------+ 142 | Received Media Stream | 143 +-------------------------------+ 144 | Start Time | 145 | End Time | 146 | Codec | 147 | Media Stream Reference | 148 +-------------------------------+ 149 | 1..* 150 | 151 | 1..* 152 +-------------------------------+ 153 | Participant | 154 +-------------------------------+ 155 | AoR | 156 | Name | 157 +-------------------------------+ 158 | 0 159 | 160 | 1..* 161 +-------------------------------+ 162 | Application Data | 163 +-------------------------------+ 165 The metadata model above MUST be used by a SRS. (NOTE: Not entirely 166 clear what sort of normative statement to make about this.) 168 The Session Recording Client (SRC) MUST initiate the Recording 169 Session. It should be noted that the Recording Session is a 170 completely independent from the Communication Session that is being 171 recorded at both the SIP dialog level and at the session level. The 172 metadata MUST be conveyed from SRC to SRS. The metadata MAY be 173 conveyed in Recording Session Dialog. 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 Group 182 A recording Session Group represents a collection of related 183 Recording Sessions maintained by SRS. Recording Session Groups are 184 optional - they need not be present in the common case where 185 Recording Sessions are independent of one another. 187 (A group with multiple sessions might arise when recordings of the 188 same or different communication sessions independently initiate 189 recording sessions.) 191 4.2. Recording Session 193 A Recording Session element represents one instance of a Recording 194 Session. It MAY have attributes like Recording requestor ID(which 195 could be SRS or SRC), reason for recording and recording type. The 196 reason for recording MUST be a policy(in a financial trading floor or 197 Call centre) or to monitor a agent, or for quality purposes etc. The 198 recording type attribute indicates whether the recording session is 199 selective or persistant. 201 4.3. Communication Session 203 A Communication Session element represents one instance of a 204 Communication Session. 206 NOTE: Discussions are needed to determine different attributes of CS 207 which are needed for SRS 209 4.4. Recorded Media Streams 211 A Recorded Media Stream represents the content of a media stream 212 captured and stored by the SRS. A Communication Session MUST have 213 one, and MAY have several, Recorded Media Streams. In addition to 214 the recorded media, it has attributes describing the encoding of the 215 recording. 217 4.5. Received Media Streams 219 A Received Media Stream is an element that represents a media stream 220 received by the SRS that contributed content to a recorded media 221 stream. There MUST be one Received Media Stream per Recorded Media 222 Stream if mixing is done before recording, or several if a separate 223 unmixed stream per participant is supplied. Or there could be 224 multiple per source (with disjoint time intervals) due to codec 225 changes. 227 The Received Media Stream element can have attributes like Start 228 time, End time, Codec, Media Stream reference. 230 4.6. Participant 232 A Participant represents one contributor of media. Participant has 233 attributes like AoR, Name. AoR MAY be SIP/SIPS/TEL URI. 235 4.7. Application Data 237 A recording metadata object MAY have a opaque application data. This 238 opaque data is intended to be used by vendor specific applications on 239 SRS. 241 5. Association of different Recording metadata elements 243 This section describes in brief on how the different elements of 244 metadata are associated. 246 5.1. Recording Session Group : Recording Session 248 A Recording Session Group element MUST have one or more Recording 249 Session elements. 251 NOTE: Model is currently permitting a single Recording Session to 252 participate in more than one Recording Session Group. Its unclear if 253 this makes sense. Might be better to restrict to one or none. 255 5.2. Recording Session : Communication Session 257 A Recording Session element MAY have zero or more CS per RS. One CS 258 per RS is typical. Multiple CS per RS can arise due to private side 259 conversations, etc. Having no Communication Sessions is possible if 260 the RS is established in anticipation of future CS. 262 NOTE: We are currently modeling exactly one RS per CS, as a stake in 263 the ground. The assumption is that its difficult to distinguish a 264 single CS viewed from two different RSs. But this requires 265 discussion. 267 5.3. Communication Session : Recorded Media Stream 269 Communication Session MAY have zero or more Recorded Media Streams 270 for various reasons. Distinct media might have their own. (Or not - 271 maybe audio/video together.) Independent sources might be recorded 272 separately. 274 A Recorded Media Stream is always associated with exactly one 275 Recording Session. 277 5.4. Recorded Media Stream : Received Media Stream 279 There MUST be one or more Received Media Streams per Recorded Media 280 Stream. There may be one if mixing is done before recording, or if 281 media only flows in one direction. There may be several if a 282 separate unmixed stream per participant is supplied and mixing is 283 done at the recorder. Or there could be multiple for a single 284 participant (with disjoint time intervals) due to codec changes. 286 A Received Media Stream is always associated with exactly one 287 Recorded Media Stream. 289 5.5. Received Media Stream : Participant 291 A Received Media Stream MUST have one or more participants. 292 Typically there will be one, unless mixed before being sent to RS, in 293 which case there may be several. 295 A Participant MAY supply multiple Received Media Streams. 297 5.6. Participant : Application Data 299 NOTE: This is a place holder for as yet undefined data. 301 6. Security Considerations 303 The Recording Session is fundamentally a standard SIP dialog and 304 media session and therefore make use of existing SIP security 305 mechanisms for securing the Recording Session and Media Recording 306 Metadata. 308 7. IANA Considerations 310 Not Applicable 312 8. References 314 8.1. Normative References 316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC 2119, March 1997. 319 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 320 A., Peterson, J., Sparks, R., Handley, M., and E. 321 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 322 June 2002. 324 8.2. Informative References 326 [I-D.ietf-siprec-req] 327 Rehor, K., Jain, R., Portman, L., and A. Hutton, 328 "Requirements for SIP-based Media Recording (SIPREC)", 329 draft-ietf-siprec-req-00 (work in progress), May 2010. 331 [I-D.ietf-siprec-architecture] 332 Hutton, A., Portman, L., Jain, R., and K. Rehor, "An 333 Architecture for Media Recording using the Session 334 Initiation Protocol", draft-ietf-siprec-architecture-00 335 (work in progress), June 2010. 337 Authors' Addresses 339 Ram Mohan R 340 Cisco Systems, Inc. 341 Cessna Business Park, 342 Kadabeesanahalli Village, Varthur Hobli, 343 Sarjapur-Marathahalli Outer Ring Road 344 Bangalore, Karnataka 560103 345 India 347 Email: rmohanr@cisco.com 348 Parthasarathi R 349 Cisco Systems, Inc. 350 Cessna Business Park, 351 Kadabeesanahalli Village, Varthur Hobli, 352 Sarjapur-Marathahalli Outer Ring Road 353 Bangalore, Karnataka 560103 354 India 356 Email: partr@cisco.com 358 P. Kyzivat 359 Cisco Systems, Inc. 360 1414 Massachusetts Avenue 361 Boxborough, MA 01719 362 USA 364 Email: pkyzivat@cisco.com