idnits 2.17.1 draft-ietf-siprec-metadata-22.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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 4, 2016) is 2943 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: 'RFC2141' is defined on line 1274, but no explicit reference was found in the text == Unused Reference: 'RFC3688' is defined on line 1283, but no explicit reference was found in the text == Unused Reference: 'RFC2648' is defined on line 1343, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-27) exists of draft-ietf-insipid-session-id-18 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPREC R. Ravindranath 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track Parthasarathi. Ravindran 5 Expires: October 6, 2016 Nokia Networks 6 Paul. Kyzivat 7 Huawei 8 April 4, 2016 10 Session Initiation Protocol (SIP) Recording Metadata 11 draft-ietf-siprec-metadata-22 13 Abstract 15 Session recording is a critical requirement in many communications 16 environments such as call centers and financial trading. In some of 17 these environments, all calls must be recorded for regulatory, 18 compliance, and consumer protection reasons. Recording of a session 19 is typically performed by sending a copy of a media stream to a 20 recording device. This document describes the metadata model as 21 viewed by Session Recording Server(SRS) and the Recording metadata 22 format. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 6, 2016. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Metadata Model . . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Recording metadata format from SRC to SRS . . . . . . . . . . 6 63 5.1. XML data format . . . . . . . . . . . . . . . . . . . . . 6 64 5.1.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 7 65 5.1.2. recording . . . . . . . . . . . . . . . . . . . . . . 7 66 6. Recording metadata classes . . . . . . . . . . . . . . . . . 7 67 6.1. Recording Session . . . . . . . . . . . . . . . . . . . . 7 68 6.1.1. Attributes . . . . . . . . . . . . . . . . . . . . . 8 69 6.1.2. Linkages . . . . . . . . . . . . . . . . . . . . . . 8 70 6.2. Communication Session Group . . . . . . . . . . . . . . . 9 71 6.2.1. Attributes . . . . . . . . . . . . . . . . . . . . . 9 72 6.2.2. Linkages . . . . . . . . . . . . . . . . . . . . . . 10 73 6.3. Communication Session . . . . . . . . . . . . . . . . . . 10 74 6.3.1. Attributes . . . . . . . . . . . . . . . . . . . . . 11 75 6.3.2. Linkages . . . . . . . . . . . . . . . . . . . . . . 12 76 6.4. CSRSAssociation . . . . . . . . . . . . . . . . . . . . . 13 77 6.4.1. Attributes . . . . . . . . . . . . . . . . . . . . . 13 78 6.4.2. Linkages . . . . . . . . . . . . . . . . . . . . . . 13 79 6.5. Participant . . . . . . . . . . . . . . . . . . . . . . . 14 80 6.5.1. Attributes . . . . . . . . . . . . . . . . . . . . . 14 81 6.5.2. Linkages . . . . . . . . . . . . . . . . . . . . . . 15 82 6.6. ParticipantCSAssociation . . . . . . . . . . . . . . . . 15 83 6.6.1. Attributes . . . . . . . . . . . . . . . . . . . . . 16 84 6.6.2. Linkages . . . . . . . . . . . . . . . . . . . . . . 17 85 6.7. Media Stream . . . . . . . . . . . . . . . . . . . . . . 17 86 6.7.1. Attributes . . . . . . . . . . . . . . . . . . . . . 18 87 6.7.2. Linkages . . . . . . . . . . . . . . . . . . . . . . 18 88 6.8. ParticipantStreamAssociation . . . . . . . . . . . . . . 18 89 6.8.1. Attributes . . . . . . . . . . . . . . . . . . . . . 19 90 6.8.2. Linkages . . . . . . . . . . . . . . . . . . . . . . 20 91 6.9. Syntax of date/time XML elements . . . . . . . . . . . . 20 92 6.10. Unique ID format . . . . . . . . . . . . . . . . . . . . 20 93 6.11. Metadata version Indicator . . . . . . . . . . . . . . . 21 94 7. Recording metadata snapshot request format . . . . . . . . . 21 95 8. SIP Recording Metadata Example . . . . . . . . . . . . . . . 22 96 8.1. Complete SIP Recording Metadata Example . . . . . . . . . 22 97 8.2. Partial Update of Recording metadata XML body . . . . . . 24 98 9. XML Schema definition for Recording metadata . . . . . . . . 24 99 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 100 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 101 11.1. SIP recording metadata Schema Registration . . . . . . . 29 102 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 29 103 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 104 13.1. Normative References . . . . . . . . . . . . . . . . . . 29 105 13.2. Informative References . . . . . . . . . . . . . . . . . 30 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 108 1. Introduction 110 Session recording is a critical requirement in many communications 111 environments such as call centers and financial trading. In some of 112 these environments, all calls must be recorded for regulatory, 113 compliance, and consumer protection reasons. Recording of a session 114 is typically performed by sending a copy of a media stream to a 115 recording device. This document focuses on the Recording metadata 116 which describes the communication session. The document describes a 117 metadata model as viewed by Session Recording Server(SRS) and the 118 Recording metadata format, the requirements for which are described 119 in [RFC6341] and the architecture for which is described in 120 [RFC7245]. 122 2. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. This 127 document only uses these key words when referencing normative 128 statements in existing RFCs." 130 3. Definitions 132 Metadata model: An abstract representation of metadata using a 133 Unified Modelling Language (UML) [UML-REF] class diagram. 135 Metadata classes: Each block in the model represents a class. A 136 class is a construct that is used as a blueprint to create 137 instances(called objects) of itself. The description of each class 138 also has representation of its attributes in a second compartment 139 below the class name. 141 Attributes: Attributes represent the elements listed in each of the 142 classes. The attributes of a class are listed in the second 143 compartment below the class name. Each instance of class conveys 144 values for these attributes which adds to the recording's metadata. 146 Linkages: Linkages represent the relationship between the classes in 147 the model. Each represents a logical connection between classes(or 148 objects) in class diagrams(or object diagrams). The linkages used in 149 the metadata model of this document are associations. 151 This document also refers to the terminlogy defined in [RFC6341]. 153 4. Metadata Model 155 Metadata is the information that describes recorded media and the 156 Communication Session(CS) to which they relate. The diagram below 157 shows a model for metadata as viewed by a SRS. 159 +-------------------------------+ 1..* 160 | Recording Session (RS) |----+ 161 +-------------------------------+ | 162 |1..* | 1..* | 163 | | | 164 | | 0..* | 165 | +-----------------+ | 166 +------------+ | | Communication | | 167 | CSRS | | | Session | | 168 | Association|--+ | Group | | 169 | | | +-----------------+ | 170 +------------+ | | 0..1 | 171 | | | 172 |0..* | 1..* | 173 +-------------------------------+ | 174 | Communication Session (CS) | | 175 | | | 176 +-------------------------------+ | 177 | 1..* |0..1 | 178 +-----+ | | 179 | | 0..* |0..* |0..* 180 | +-------------+ receives +----------------+ | 181 | | Participant |----------| Media Stream |--+ 182 | | |0..* 0..*| | 183 | | | | | 184 | | | | | 185 | | | sends | | 186 | | |----------| | 187 | | |1.* 0..*| | 188 | +-------------+ +----------------+ 189 | | | 190 | | | 191 | +------------------------+------------+ 192 | | 193 | | 194 | +------------------+ +----------------------+ 195 | |ParticipantCS | | ParticipantStream | 196 +-----------| Association | | Association | 197 | | | | 198 +------------------+ +----------------------+ 200 The metadata model is a class diagram in UML. The model describes 201 the structure of metadata in general by showing the classes, their 202 attributes, and the relationships among the classes. Each block in 203 the model above represents a class. The linkages between the classes 204 represent the relationships which can be associations or composition. 205 The metadata is conveyed from SRC to SRS. 207 The model allows metadata describing communications sessions to be 208 communicated to the SRS as a series of snapshots, each representing 209 the state as seen by a single SRC at a particular instant in time. 210 Metadata changes from one snapshot to another reflect changes in what 211 is being recorded. For example, if a participant joins a conference, 212 then the SRC sends the SRS a snapshot of metadata having that 213 participant information (with attributes like name/AoR pair and 214 associate-time.) 216 Some of the metadata is not required to be conveyed explicitly from 217 the SRC to the SRS, if it can be obtained contextually by the 218 SRS(e.g., from SIP or SDP signalling). For example, the label 219 attribute within the 'stream' XML element references an SDP 'a=label' 220 attribute that identifies an m-line within the Recording Session(RS) 221 SDP. The SRS would learn the media properties from media line. 223 5. Recording metadata format from SRC to SRS 225 This section gives an overview of the Recording metadata format. 226 Some data from the metadata model is assumed to be made available to 227 the SRS through Session Description Protocol (SDP)[RFC4566], and 228 therefore this data is not represented in the XML document format 229 specified in this document. SDP attributes describe different media 230 formats like audio, video. The other metadata attributes, such as 231 participant details, are represented in a new recording specific XML 232 document of type 'application/rs-metadata+xml'. The SDP label 233 attribute [RFC4574] provides an identifier by which a metadata XML 234 document can refer to a specific media description in the SDP sent 235 from the SRC to the SRS. 237 The XML document format can be used to represent either the complete 238 metadata or a partial update to the metadata. The latter includes 239 only elements that have changed compared to the previously reported 240 metadata. 242 5.1. XML data format 244 Every recording metadata XML document sent from SRC to SRS contain 245 a'recording' element. The 'recording' element acts as a container 246 for all other elements in this XML document. A 'recording' object is 247 an XML document. It has the XML declaration and contain an encoding 248 declaration in the XML declaration, e.g., "". If the charset parameter of the MIME content 250 type declaration is present and it is different from the encoding 251 declaration, the charset parameter takes precedence. 253 Every application conforming to this specification MUST accept the 254 UTF-8 character encoding to ensure the minimal interoperability. 256 Syntax and semantic errors in an XML document should be reported to 257 the originator using application specific mechanisms. 259 5.1.1. Namespace 261 This document defines a new namespace URI for elements defined by 262 this specification is the following URN: 264 urn:ietf:params:xml:ns:recording:1 266 5.1.2. recording 268 The 'recording' element MUST contain an xmlns namespace attribute 269 with value as urn:ietf:params:xml:ns:recording:1. Exactly one 270 recording element MUST be present in every recording metadata XML 271 document. 273 A recording element MAY contain a element indicating 274 whether the XML document is a complete document or a partial update. 275 If no element is present then the default value is 276 "complete". 278 6. Recording metadata classes 280 This section describes each class of the metadata model, and the 281 attributes of each class. This section also describes how different 282 classes are linked and the XML element for each of them. 284 6.1. Recording Session 285 +-------------------------------+ 286 | Recording Session (RS) | 287 +-------------------------------+ 288 | |1..* 0..* 289 | start-time |-------------- Media Stream 290 | end-time | 291 | | 292 | | 293 +-------------------------------+ 294 |1..* | 1..* 295 | | 296 |0..* | 0..* 297 Communication Communication 298 Session Session Group(CS Group) 300 Each instance of a Recording Session(RS) class namely the RS Object 301 represents a SIP session created between an SRC and SRS for the 302 purpose of recording a Communication Session(CS). 304 RS object is represented in XML schema using 'recording' element. 305 That in turn relies on the SIP/SDP session with which the XML 306 document is associated to provide the attributes of the RS element. 308 6.1.1. Attributes 310 An RS class has the following attributes: 312 o start-time - Represents the start time of an RS object. 314 o end-time - Represents the end time of an RS object. 316 'start-time' and 'end-time' attribute values are derivable from Date 317 header(if present in SIP message) in RS. In cases where Date header 318 is not present, 'start-time' is derivable from the time at which SRS 319 receives the notification of SIP message to setup RS and and 'end- 320 time' is derivable from the time at which SRS receives disconnect on 321 the RS SIP dialog. 323 6.1.2. Linkages 325 Each instance of RS has: 327 o Zero or more instances of Communication Session Group (CS-Group). 329 o Zero or more instances of CS objects. 331 o Zero or more instances of MediaStream objects. 333 Zero instances of CS and CS-Group in a recording element is allowed 334 to accommodate persistent recording scenarios. A persistent RS is a 335 SIP dialog that is setup between SRC to SRS even before any CS is 336 setup. The metadata sent from SRC to SRS when the persistent RS SIP 337 dialog is setup may not have any CS(and the related CS-Group) 338 elements in the XML as there may be no session that is associated to 339 the RS yet. For e.g; a phone acting as SRC can setup a RS with SRS 340 possibly even before phone is part of a CS. Once the phone joins a 341 CS, the same RS would be used to convey the CS metadata. 343 6.2. Communication Session Group 345 Recording Session (RS) 346 | 1..* 347 | 348 | 0..* 349 +-------------------------------+ 350 | Communication Session | 351 | Group | 352 +-------------------------------+ 353 | group_id | 354 | associate-time | 355 | disassociate-time | 356 | | 357 +-------------------------------+ 358 | 0..1 359 | 360 | 1..* 361 Communication Session (CS) 363 One instance of a Communication Session Group(CS-Group) class namely 364 the CS-Group object provides association or grouping of all related 365 CSs. For e.g, in a contact center flow a call can get transferred to 366 multiple agents. Each of these can trigger setup of new CS. In 367 cases where the SRC knows the related CSs it can group them using the 368 CS-Group element. CS-Group object is represented in XML schema using 369 'group' element. 371 6.2.1. Attributes 373 A CS-Group has the following attributes: 375 o group_id - This is to group different CSs that are related. SRC 376 (or SRS) is responsible for ensuring the uniqueness of 'group_id' 377 in case multiple SRC interacts with the same SRS. The mechanism 378 by which SRC groups the CS is outside the scope of this document. 380 o associate-time - This is the time when a grouping is formed. The 381 rules that determine how a grouping of different CS objects is 382 done by SRC is outside the scope of this document. 384 o disassociate-time - 'disassociate-time' for CS-Group is calculated 385 by SRC as the time when the grouping ends. 387 6.2.2. Linkages 389 The linkages between CS-Group class and other classes are 390 associations. A CS-Group is associated with RS and CS in the 391 following manner: 393 o There are one or more RS objects per CS-Group. 395 o Each CS-Group object has to be associated with one or more RS. 396 Here each RS can be setup by the potentially different SRCs. 398 o There are one or more CSs per CS-Group (for example, in case where 399 the call is transferred). A CS cannot be associated with more 400 than one CS-Group. 402 6.3. Communication Session 404 Recording Communication 405 Session Session Group(CS Group) 406 |1..* | 0..1 407 | | 408 |0..* | 1..* 409 +-------------------------------+ 410 | Communication Session (CS) | 411 +-------------------------------+ 412 | session_id | 413 | sipSessionID | 414 | reason | 415 | group-ref | 416 | start-time | 417 | stop-time | 418 +-------------------------------+ 419 | | 420 | 0..* |0..1 421 | | 422 | 0..* |0..* 423 Participant Media Stream 424 A Communication Session(CS) class and its object in the metadata 425 model represents the CS and its properties as seen by SRC. CS object 426 is represented in XML schema using 'session' element. 428 6.3.1. Attributes 430 A CS class has the following attributes: 432 o session_id - This attribute is used to uniquely identify an 433 instance of CS object namely the session XML element with in the 434 metadata XML document. 'session_id' is generated using the rules 435 mentioned in Section 6.10. 437 o reason - This represents the reason why a CS was terminated. The 438 value for this attribute is derived from SIP Reason header 439 [RFC3326] of CS. There MAY be multiple instances of the 'reason' 440 XML element inside a 'session' element. The 'reason' XML element 441 has 'protocol' as an attribute, which indicates the protocol from 442 which the reason string is derived. The default value for 443 protocol attribute is "SIP". The 'reason' element can be derived 444 from a SIP Reason header in the CS. 446 o sipSessionID - This attribute carries sip Session-ID defined in 447 [I-D.ietf-insipid-session-id]. Each CS object can have zero or 448 more sipSessionID elements. More than one 'sipSessionID' 449 attribute may be present in a CS. For example, if three 450 participants A, B and C are in a conference that has a focus 451 acting as SRC, the metadata sent from the SRC to the SRS will 452 likely have three 'sipSessionID' elements that correspond to the 453 SIP dialogs the focus has with each of the three participants. 455 o group-ref - A 'group-ref' attribute MAY be present to indicate the 456 group(identified by 'group_id') to which the enclosing session 457 belongs. 459 o start-time - This optional attribute represents start time of CS 460 as seen by SRC. 462 o stop-time - This optional attribute represents stop time of CS as 463 seen by SRC. 465 This document does not specify attributes relating to what should 466 happen to a recording of a CS after it has been delivered to the SRS 467 (E.g., how long to retain the recording, what access controls to 468 apply.) The SRS is assumed to behave in accordance with its local 469 policy. The ability for the SRC to influence this policy is outside 470 the scope of this document. However if there are implementations 471 where SRC desires to specify its own policy preferences, this could 472 be sent as extension data attached to the CS. 474 6.3.2. Linkages 476 A CS is linked to CS-Group, Participant, Media Stream and RS classes 477 using the association relationship. Association between CS and 478 participant allows: 480 o CS to have zero or more participants 482 o Participant is associated with zero or more CSs. This includes 483 participants who are not directly part of any CS. An example of 484 such a case is participants in a premixed media stream. The SRC 485 may have knowledge of such participants, yet not have any 486 signaling relationship with them. This might arise if one 487 participant in CS is a conference focus. To summarize, even if 488 the SRC does not have direct signalling relationships with all 489 participants in a CS, it should nevertheless create a participant 490 object for each participant that it knows about. 492 o The model also allows participants in CS that are not participants 493 in the media. An example is the identity of a Third Party Call 494 Control(3pcc) that has initiated a CS to two or more participants 495 of the CS. Another example is the identity of a conference focus. 496 Of course a focus is probably in the media, but since it may only 497 be there as a mixer, it may not report itself as a participant in 498 any of the media streams. 500 Association between CS and Media Stream allows: 502 o A CS to have zero or more streams 504 o A stream can be associated with at most one CS. A stream in a 505 persistent RS is not required to be associated with any CS before 506 the CS is created and hence the zero association is allowed. 508 Association between CS and RS allows: 510 o Each instance of RS has zero or more instances of CS objects. 512 o Each CS has to be associated with one more RS. Each RS can be 513 potentially setup by different SRCs. 515 6.4. CSRSAssociation 517 1..* 0..* 518 Recording Communication 519 Session ----------+---------- Session 520 | 521 | 522 | 523 +-----------------------+ 524 | CSRSAssociation | 525 | | 526 +-----------------------+ 527 | associate-time | 528 | disassociate-time | 529 | session_id | 530 +-----------------------+ 532 The CSRSAssociation class describes the association of a CS to an RS 533 for a period of time. A single CS may be associated with different 534 RSs (perhaps by different SRCs) and may be associated and dissociated 535 several times. 537 The CSRSAssociation is represented in XML using 538 'sessionrecordingassoc' XML element. 540 6.4.1. Attributes 542 CSRSAssociation class has the following attributes: 544 o associate-time - associate-time is calculated by SRC as the time 545 it sees a CS associated to a RS 547 o disassociate-time- disassociate-time is calculated by SRC as the 548 time it see a CS disassociate from a RS. 550 o session_id - Each instance of this class MUST have 'session_id' 551 attribute that identifies the the CS to which this association 552 belongs to. 554 6.4.2. Linkages 556 CSRSAssociation class is linked to CS and RS classes. 558 6.5. Participant 560 Communication Session (CS) 561 | 0..* 562 | 563 | 0..* 564 +-------------------------------+ 565 | Participant | 566 +-------------------------------+ 567 | nameID | 568 | participant_id | 569 | | 570 +-------------------------------+ 571 | 0..* 1..*| 572 receives| |sends 573 | 0..* 0..*| 574 Media Stream 576 A participant class and its objects has information about a device 577 that is part of a CS and/or contributes/consumes media stream(s) 578 belonging to a CS. 580 Participant object is represented in XML schema using 'participant' 581 element. 583 6.5.1. Attributes 585 A participant class has two attributes: 587 o nameID - This attribute is a list of Name, Address-of-Record (AoR) 588 defined in Section 6 of [RFC3261] tuples. An AoR can be one of 589 SIP/SIPS/TEL URI, FQDN or IP address. For example, the AoR may be 590 drawn from the From header field or P-Asserted-Identity header 591 [RFC3325] field. SRC's local policy is used to decide on where to 592 draw the AoR from. Name represents participant name(SIP display 593 name) or dialed number (DN) (when known). Multiple tuples are 594 allowed for cases where a participant has more than one AoR. For 595 example, a P-Asserted-identity header can have both SIP and TEL 596 URIs. 598 o participant_id - This attribute is used to identify the 599 'participant' XML element with in the XML document. It is 600 generated using the rules mentioned in Section 6.10. This 601 attribute MUST be used for all references to a participant within 602 a CS-Group, and MAY be used to reference the same participant more 603 globally. 605 This document does not specify other attributes relating to 606 participant e.g. participant role, participant type. An SRC which 607 has information of these attributes can indicate the same as part of 608 extension data to participant from SRC to SRS. 610 6.5.2. Linkages 612 The participant class is linked to MediaStream (MS) and CS class 613 using association relationship. The association between participant 614 and MS allows: 616 o participant to receive zero or more media streams. 618 o participant to send zero or more media streams. (Same participant 619 provides multiple streams e.g. audio and video) 621 o media stream to be received by zero or more participants. Its 622 possible, though perhaps unlikely, that a stream is generated but 623 sent only to the SRC and SRS, not to any participant. E.g. In 624 conferencing where all participants are on hold and the SRC is 625 collocated with the focus. Also a media stream may be received by 626 multiple participants (e.g. Whisper calls, side conversations). 628 o media stream to be sent by one or more participants (pre-mixed 629 streams). 631 Example of a case where a participant receives zero or more streams - 632 a supervisor may have side conversation with agent, while agent 633 converses with customer. 635 6.6. ParticipantCSAssociation 636 1..* 0..* 637 Communication 638 Session ----------+---------- Participant 639 | 640 | 641 | 642 +-------------------------+ 643 | ParticipantCSAssociation| 644 | | 645 | | 646 +-------------------------+ 647 | associate-time | 648 | disassociate-time | 649 | param | 650 | participant_id | 651 | session_id | 652 +-------------------------+ 654 The ParticipantCSAssociation class describes the association of a 655 participant to an CS for a period of time. A participant may be 656 associated and dissociated from a CS several times. (For example, 657 connecting to a conference, then disconnecting, then connecting 658 again.) 660 ParticipantCSAssociation object is represented in XML schema using 661 'participantsessionassoc' element. 663 6.6.1. Attributes 665 ParticipantCS association class has the following attributes: 667 o associate-time - associate-time is calculated by SRC as the time 668 it sees a participant associated to a CS. 670 o disassociate-time- disassociate-time is calculated by the SRC as 671 the time it sees a participant disassociate from a CS. It is 672 possible that a given participant can have multiple associate/ 673 disassociate times within given communication session. 675 o param - An optional attribute describing the capabilities of a 676 participant in a CS, as defined in [RFC3840]. For example, in a 677 CS(which can be a conference), you can have participants who are 678 playing the role of "focus". These participants does not 679 contribute to media in the CS, however they switch the media 680 received from one participant to every other participant in the 681 CS. Indicating the capability of participant (here "focus") would 682 be useful for recorder to learn about these kind of participants. 684 The capablities are represented using 'param' XML element in the 685 metadata. The 'param' XML element encoding defined in [RFC4235] 686 is used to represent the capabilties attributes in metadata. Each 687 participant may have zero or more capabilities. A participant may 688 use different capabilities depending on the role it plays at a 689 particular instance. For example, if a participant moves across 690 different CSs (e.g., due to transfer) or is simultaneously present 691 in different CSs with different roles. 693 o participant_id - This attribute identifies the participant to 694 which this association belongs to. 696 o session_id - This attribute identifies the session to which this 697 association belongs to. 699 6.6.2. Linkages 701 The participantCSAssociation class is linked to participant and CS 702 classes. 704 6.7. Media Stream 706 Participant 707 | 0..* 1..*| 708 receives| |sends 709 | 0..* 0..*| 710 +-------------------------+ 711 | Media Stream | 712 Communication 0..1 0..* +-------------------------+ 713 Session ------------| | 714 | label | 715 | content-type | 716 | stream_id | 717 | session_id | 718 +-------------------------+ 719 0..*| 720 | 721 | 722 1..*| 723 Recording Session 725 A MS class (and its objects) has the properties of media as seen by 726 SRC and sent to SRS. Different snapshots of a MS objects may be sent 727 whenever there is a change in media (e.g. direction change like 728 pause/resume and/or codec change and/or participant change.). 730 MS object is represented in XML schema using 'stream' element. 732 6.7.1. Attributes 734 A MS class has the the following attributes: 736 o label - The label attribute within the 'stream' XML element 737 references an SDP 'a=label' attribute that identifies an m-line 738 within the RS SDP. That m-line carries the media stream from the 739 SRC to the SRS. 741 o content-type - The content of an MS element will be described in 742 terms of value from the [RFC4796] registry. If the SRC wishes to 743 convey the Content-type to the SRS, it does so by including an 744 'a=content' attribute with the m-line in the RS SDP. 746 o stream_id - Each stream element has unique 'stream_id' attribute 747 which helps to uniquely identify stream. This identifier is 748 generated using the rules mentioned in Section 6.10. 750 o session_id - This attribute associates the stream with a specific 751 session element. 753 The metadata model can include media streams that are not being 754 delivered to the SRS. For example, an SRC offers audio, video 755 towards SRS which in response accepts only audio. The metadata 756 snapshots sent from SRC to SRS can continue to indicate the changes 757 to video stream as well. 759 6.7.2. Linkages 761 A MS class is linked to participant and CS classes using the 762 association relationship. The details of association with the 763 participant are described in the participant class section. The 764 details of association with CS is mentioned in the CS section. 766 6.8. ParticipantStreamAssociation 767 +-------------------------+ 768 | ParticipantStream | 769 | Association | 770 +-------------------------+ +----------Participant 771 | association-time | | 0..*| 1..*| 772 | disassociaton-time |---+ recv| |sends 773 | send | | 0..*| 0..*| 774 | recv | | | | 775 | participant_id | | | | 776 +-------------------------+ | | | 777 +----------Media Stream 779 A ParticipantStreamAssociation class describes the association of a 780 Participant to a MS for a period of time, as a sender or as a 781 receiver, or both. 783 This class is represented in XML using 'participantstreamassoc' 784 element. 786 6.8.1. Attributes 788 A ParticipantStreamAssociation class has the following attributes: 790 o associate-time: This attribute indicates the time a participant 791 started contributing to a MS. 793 o disassociate-time: This attribute indicates the time a participant 794 stopped contributing to a MS. 796 o send: This attribute indicates whether a participant is 797 contributing to a stream or not. This attribute has a value which 798 points to stream represented by its unique_id. The presence of 799 this attribute indicates that a participant is contributing to a 800 stream. If due to changes in CS if a participant stops 801 contributing to a stream, a snapshot MUST be sent from SRC to SRS 802 with no send element for that stream. 804 o recv: This attribute indicates whether a participant is receiving 805 a media stream or not. This attribute has a value which points to 806 a stream represented by its unique_id. The presence of this 807 attribute indicates that a participant is receiving a stream. If 808 due to changes in CS(like hold) the participants stops receiving a 809 stream, a snapshot MUST be sent from SRC to SRS with no recv 810 element for that stream. 812 o participant_id - This attributes points to the participant to 813 which a stream element is associated with. 815 'participantstreamassoc' XML element is used to represent a 816 participant association with a stream. The 'send' and 'recv' XML 817 elements MUST be used to indicate whether a participant is 818 contributing to a stream or receiving a stream. There MAY be 819 multiple instances of the 'send' and 'recv' XML elements inside a 820 'particpantstreamassoc' element. If a metadata snapshot is sent with 821 a 'participantstreamassoc' element that does not have any 'send' and 822 'recv' elements, it means that participant is neither contributing to 823 any streams nor receiving any streams. 825 6.8.2. Linkages 827 The ParticipantStreamAssociation class is linked to participant and 828 MS classes. 830 6.9. Syntax of date/time XML elements 832 XML elements 'associate-time', 'disassociate-time', 'start-time' and 833 'stop-time' contain strings representing the date and time. The 834 value of these elements MUST follow the IMPP datetime format 835 [RFC3339]. Timestamps that contain 'T' or 'Z' MUST use the 836 capitalized forms. 838 As a security measure, the timestamp element MUST be included in all 839 tuples unless the exact time of the status change cannot be 840 determined. 842 6.10. Unique ID format 844 A Unique id is generated in two steps: 846 o The UUID is created using procedures mentioned in Sections 4.3, 847 4.4 or 4.5 of [RFC4122]. The algorithm MUST ensure that it does 848 not use anything potentially personally identifying to generate 849 the UUIDs. If implementations are using a Name-Based UUID as 850 defined in Section 4.3 of [RFC4122], a name space ID generated 851 using Section 4.2 or 4.5 of [RFC4122] might be a good choice. 853 o The UUID is encoded using base64 as defined in [RFC4648] 855 The above mentioned unique-id mechanism SHOULD be used for each 856 metadata element. Multiple SRC's can refer to the same element/UUID 857 (how each SRC learns the UUID here is out of scope of this document). 858 If two SRCs use the same UUID, they MUST retain the UUID/element 859 mapping. If the SRS detects that a UUID is mapped to more than one 860 element at any point of time it MUST treat this as a error. For 861 example, the SRS may choose to reject or ignore the portions of 862 metadata where it detects same UUID is mapped to a different elements 863 other than the expected element (the SRS learns the mapped UUID when 864 it sees a element for the first time in a metadata instance). 866 6.11. Metadata version Indicator 868 Metadata version is defined to help SRC and SRS to know the version 869 of metadata XML schema used. SRCs and SRSs that support this 870 specification MUST use version 1 in the 871 namespace(urn:ietf:params:xml:ns:recording:1) in all the XML 872 documents. Implementations may not interoperate if the version 873 implemented by the sender is not known by the receiver. No 874 negotiation of versions is provided. There is no significance to the 875 version number although documents which update or obsolete this 876 document (possibly including drafts of such documents) should include 877 a higher version number if the metadata XML schema changes. 879 7. Recording metadata snapshot request format 881 SRS can explicitly request metadata snapshot from SRC. To request a 882 metadata snapshot the SRS MUST send a SIP request message with a XML 883 document having the namespace urn:ietf:params:xml:ns:recording:1. 884 The XML document has the following elements. 886 o A XML element MUST be present as the top level 887 element in the XML document. 889 o A XML element that indicates the reason for 890 requesting snapshot as a string MAY be present as a child XML 891 element of . 893 The example below shows a metadata snapshot request from SRS. 895 896 897 SRS internal error 898 900 Example metadata snapshot request from SRS to SRC 902 8. SIP Recording Metadata Example 904 8.1. Complete SIP Recording Metadata Example 906 The following example provides all the tuples involved in Recording 907 Metadata XML body. 909 910 911 complete 912 913 2010-12-16T23:41:07Z 914 915 916 sip:alice@atlanta.com 917 918 919 FOO! 920 bar 921 922 923 924 ab30317f1a784dc48ff824d0d3715d86; 925 remote=47755a9de7794ba387653f2099600ef2 926 7+OTCyoxTmqmqyA/1weDAg== 927 928 929 FOO! 930 bar 931 932 933 934 935 Bob B 936 937 938 939 FOO! 940 bar 941 942 943 944 945 Paul 946 947 948 949 FOO! 950 bar 951 952 953 955 956 957 959 960 961 963 964 965 967 968 969 970 2010-12-16T23:41:07Z 971 972 975 2010-12-16T23:41:07Z 976 977 980 2010-12-16T23:41:07Z 981 982 984 i1Pz3to5hGk8fuXl+PbwCw== 985 UAAMm5GRQKSCMVvLyl4rFw== 986 8zc6e0lYTlWIINA6GR+3ag== 987 EiXGlc+4TruqqoDaNE76ag== 988 989 991 8zc6e0lYTlWIINA6GR+3ag== 992 EiXGlc+4TruqqoDaNE76ag== 993 UAAMm5GRQKSCMVvLyl4rFw== 994 i1Pz3to5hGk8fuXl+PbwCw== 995 996 997 Example metadata snapshot from SRC to SRS 999 8.2. Partial Update of Recording metadata XML body 1001 The following example provides partial update in Recording metadata 1002 XML body for the above example. The example has a snapshot that 1003 carries the disassociate-time for a participant from a session. 1005 1006 1007 partial 1008 1010 1011 Bob R 1012 1013 1014 1017 2010-12-16T23:41:07Z 1018 1019 1021 Partial update of SIP Recording Example XML body 1023 9. XML Schema definition for Recording metadata 1025 This section defines XML schema for Recording metadata document 1027 1028 1033 1034 1036 1037 1038 1039 1041 1043 1045 1047 1049 1052 1055 1058 1062 1063 1064 1065 1066 1068 1070 1074 1075 1077 1078 1079 1080 1082 1084 1086 1088 1091 1095 1096 1098 1099 1100 1101 1103 1105 1109 1110 1112 1113 1114 1115 1117 1121 1122 1124 1125 1126 1127 1129 1131 1132 1133 1134 1135 1136 1137 1141 1142 1144 1146 1147 1148 1149 1151 1153 1155 1157 1161 1162 1164 1165 1166 1167 1169 1173 1174 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1214 1215 1216 1218 10. Security Considerations 1220 This document describes an extensive set of metadata that may be 1221 recorded by the SRS. Most of the metadata could be considered 1222 private data. The procedures mentioned in security consideration 1223 section of [I-D.ietf-siprec-protocol] MUST be followed by SRC and SRS 1224 for mutual authentication and to protect the content of the metadata 1225 in the RS. 1227 An SRC MAY, by policy, choose to limit the parts of the metadata sent 1228 to the SRS for recording. And the policy of the SRS might not 1229 require recording all the metadata it receives. For the sake of data 1230 minimization, the SRS MUST NOT record additional metadata that is not 1231 explicitly required by local policy. Metadata in storage needs to be 1232 provided with a level of security that is comparable to that of the 1233 recording session. 1235 11. IANA Considerations 1237 This specification registers a new XML namespace, and a new XML 1238 schema. 1240 11.1. SIP recording metadata Schema Registration 1242 URI: urn:ietf:params:xml:ns:recording:1 1244 Registrant Contact: IETF SIPREC working group, Ram Mohan 1245 R(rmohanr@cisco.com) 1247 XML: the XML schema to be registered is contained in Section 8. 1249 Its first line is and its last 1250 line is 1252 12. Acknowledgement 1254 Thanks to John Elwell, Henry Lum, Leon Portman, De Villers, Andrew 1255 Hutton, Deepanshu Gautam,Charles Eckel, Muthu Arul Mozhi, Michael 1256 Benenson, Hadriel Kaplan, Brian Rosen, Scott Orton, Ofir Roth, Mary 1257 Barnes, Ken Rehor, Gonzalo Salgueiro, Yaron Pdut, Alissa Cooper, 1258 Stephen Farrell and Ben Campbell for their valuable comments and 1259 inputs. 1261 Thanks to Joe Hildebrand, Peter Saint-Andre, Matt Miller for helping 1262 in writing the XML schema and Martin Thomson for validating the XML 1263 schema and providing comments on the same. 1265 13. References 1267 13.1. Normative References 1269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1270 Requirement Levels", BCP 14, RFC 2119, 1271 DOI 10.17487/RFC2119, March 1997, 1272 . 1274 [RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, 1275 May 1997, . 1277 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1278 A., Peterson, J., Sparks, R., Handley, M., and E. 1279 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1280 DOI 10.17487/RFC3261, June 2002, 1281 . 1283 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1284 DOI 10.17487/RFC3688, January 2004, 1285 . 1287 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1288 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1289 . 1291 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1292 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1293 July 2006, . 1295 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1296 Protocol (SDP) Label Attribute", RFC 4574, 1297 DOI 10.17487/RFC4574, August 2006, 1298 . 1300 [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description 1301 Protocol (SDP) Content Attribute", RFC 4796, 1302 DOI 10.17487/RFC4796, February 2007, 1303 . 1305 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1306 "Indicating User Agent Capabilities in the Session 1307 Initiation Protocol (SIP)", RFC 3840, 1308 DOI 10.17487/RFC3840, August 2004, 1309 . 1311 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1312 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1313 DOI 10.17487/RFC4122, July 2005, 1314 . 1316 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1317 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1318 . 1320 [I-D.ietf-siprec-protocol] 1321 Portman, L., Lum, H., Eckel, C., Johnston, A., and A. 1322 Hutton, "Session Recording Protocol", draft-ietf-siprec- 1323 protocol-18 (work in progress), September 2015. 1325 13.2. Informative References 1327 [RFC6341] Rehor, K., Ed., Portman, L., Ed., Hutton, A., and R. Jain, 1328 "Use Cases and Requirements for SIP-Based Media Recording 1329 (SIPREC)", RFC 6341, DOI 10.17487/RFC6341, August 2011, 1330 . 1332 [I-D.ietf-insipid-session-id] 1333 Jones, P., Salgueiro, G., Pearce, C., and P. Giralt, "End- 1334 to-End Session Identification in IP-Based Multimedia 1335 Communication Networks", draft-ietf-insipid-session-id-18 1336 (work in progress), February 2016. 1338 [RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor, 1339 "An Architecture for Media Recording Using the Session 1340 Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May 1341 2014, . 1343 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1344 DOI 10.17487/RFC2648, August 1999, 1345 . 1347 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 1348 Header Field for the Session Initiation Protocol (SIP)", 1349 RFC 3326, DOI 10.17487/RFC3326, December 2002, 1350 . 1352 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1353 Extensions to the Session Initiation Protocol (SIP) for 1354 Asserted Identity within Trusted Networks", RFC 3325, 1355 DOI 10.17487/RFC3325, November 2002, 1356 . 1358 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, Ed., "An 1359 INVITE-Initiated Dialog Event Package for the Session 1360 Initiation Protocol (SIP)", RFC 4235, 1361 DOI 10.17487/RFC4235, November 2005, 1362 . 1364 [UML-REF] OMG, "Unified Modeling Language (UML)", 2011, 1365 . 1367 Authors' Addresses 1369 Ram Mohan Ravindranath 1370 Cisco Systems 1371 Cessna Business Park 1372 Bangalore, Karnataka 1373 India 1375 Email: rmohanr@cisco.com 1376 Parthasarathi Ravindran 1377 Nokia Networks 1378 Bangalore, Karnataka 1379 India 1381 Email: partha@parthasarathi.co.in 1383 Paul Kyzivat 1384 Huawei 1385 Hudson, MA 1386 USA 1388 Email: pkyzivat@alum.mit.edu