idnits 2.17.1 draft-ietf-siprec-metadata-19.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 6 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 (January 30, 2016) is 2980 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) ** 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-16 Summary: 3 errors (**), 0 flaws (~~), 2 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: August 2, 2016 Nokia Networks 6 Paul. Kyzivat 7 Huawei 8 January 30, 2016 10 Session Initiation Protocol (SIP) Recording Metadata 11 draft-ietf-siprec-metadata-19 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 August 2, 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 . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 8 71 6.2.1. Attributes . . . . . . . . . . . . . . . . . . . . . 9 72 6.2.2. Linkages . . . . . . . . . . . . . . . . . . . . . . 9 73 6.3. Communication Session . . . . . . . . . . . . . . . . . . 10 74 6.3.1. Attributes . . . . . . . . . . . . . . . . . . . . . 10 75 6.3.2. Linkages . . . . . . . . . . . . . . . . . . . . . . 11 76 6.4. CSRSAssociation . . . . . . . . . . . . . . . . . . . . . 12 77 6.4.1. Attributes . . . . . . . . . . . . . . . . . . . . . 13 78 6.4.2. Linkages . . . . . . . . . . . . . . . . . . . . . . 13 79 6.5. Participant . . . . . . . . . . . . . . . . . . . . . . . 13 80 6.5.1. Attributes . . . . . . . . . . . . . . . . . . . . . 14 81 6.5.2. Linkages . . . . . . . . . . . . . . . . . . . . . . 14 82 6.6. ParticipantCSAssociation . . . . . . . . . . . . . . . . 15 83 6.6.1. Attributes . . . . . . . . . . . . . . . . . . . . . 15 84 6.6.2. Linkages . . . . . . . . . . . . . . . . . . . . . . 16 85 6.7. Media Stream . . . . . . . . . . . . . . . . . . . . . . 16 86 6.7.1. Attributes . . . . . . . . . . . . . . . . . . . . . 17 87 6.7.2. Linkages . . . . . . . . . . . . . . . . . . . . . . 17 88 6.8. ParticipantStream Association . . . . . . . . . . . . . . 17 89 6.8.1. Attributes . . . . . . . . . . . . . . . . . . . . . 18 90 6.8.2. Linkages . . . . . . . . . . . . . . . . . . . . . . 19 91 6.9. associate-time/disassociate-time . . . . . . . . . . . . 19 92 6.10. Unique ID format . . . . . . . . . . . . . . . . . . . . 19 93 6.11. Metadata version Indicator . . . . . . . . . . . . . . . 19 94 7. Recording metadata snapshot Request format . . . . . . . . . 20 95 8. SIP Recording Metadata Example . . . . . . . . . . . . . . . 20 96 8.1. Complete SIP Recording Metadata Example . . . . . . . . . 20 97 8.2. Partial Update of Recording metadata XML body . . . . . . 22 98 9. XML Schema definition for Recording metadata . . . . . . . . 23 99 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 100 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 101 11.1. SIP recording metadata Schema Registration . . . . . . . 28 102 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 28 103 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 104 13.1. Normative References . . . . . . . . . . . . . . . . . . 28 105 13.2. Informative References . . . . . . . . . . . . . . . . . 30 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 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) 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 +-------------------------------+ 160 | Recording Session (RS) | 161 +-------------------------------+ 162 |1..* | 1..* 163 | | 164 | | 0..* 165 | +-----------------+ 166 +------------+ | | Communication | 167 | CSRS | | | Session (CS) | 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..* 180 | +-------------+ receives +----------------+ 181 | | Participant |----------| Media Streams | 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 Unified Modelling 201 Language(UML). The model describes the structure of metadata in 202 general by showing the classes, their attributes, and the 203 relationships among the classes. Each block in the model above 204 represents a class. The linkages between the classes represent the 205 relationships which can be associations or composition. The metadata 206 is conveyed from SRC to SRS. 208 The model allows the capture of a snapshot of a recording's metadata 209 at a given instant in time. Metadata changes to reflect changes in 210 what is being recorded. For example, if a participant joins a 211 conference, then the SRC sends the SRS a snapshot of metadata having 212 that participant information (with attributes like name/AoR pair and 213 associate-time.) 215 Some of the metadata is not required to be conveyed explicitly from 216 the SRC to the SRS, if it can be obtained contextually by the 217 SRS(e.g., from SIP or SDP signalling). 219 5. Recording metadata Format 221 This section gives an overview of the Recording metadata format. 222 Some data from the metadata model is assumed to be made available to 223 the SRS through Session Description Protocol (SDP)[RFC4566], and 224 therefore this data is not represented in the XML document format 225 specified in this document. SDP attributes describe different media 226 formats like audio, video. The other metadata attributes, such as 227 participant details, are represented in a new Recording specific XML 228 document of type 'application/rs-metadata+xml'. The SDP label 229 attribute [RFC4574] provides an identifier by which a metadata XML 230 document can refer to a specific media description in the SDP sent 231 from the SRC to the SRS. 233 The XML document format can be used to represent either the complete 234 metadata or a partial update to the metadata. The latter includes 235 only elements that have changed compared to the previously reported 236 metadata. 238 5.1. XML data format 240 Every recording metadata XML document MUST contain a 241 element. The element acts as a container for all other 242 elements in this XML document. 244 A recording object is an XML document. It MUST have the XML 245 declaration and it SHOULD contain an encoding declaration in the XML 246 declaration, e.g., "". If the 247 charset parameter of the MIME content type declaration is present and 248 it is different from the encoding declaration, the charset parameter 249 takes precedence. 251 Every application conforming to this specification MUST accept the 252 UTF-8 character encoding to ensure the minimal interoperability. 254 Syntax and semantic errors in an XML document should be reported to 255 the originator using application specific mechanisms. 257 5.1.1. Namespace 259 The namespace URI for elements defined by this specification is a 260 Uniform Resource Namespace (URN) [RFC2141], using the namespace 261 identifier 'ietf' defined by [RFC2648] and extended by [RFC3688]. 263 The URN is: urn:ietf:params:xml:ns:recording:1 265 5.1.2. recording 267 The element MUST contain an xmlns namespace attribute 268 with value as urn:ietf:params:xml:ns:recording:1. One recording 269 element MUST be present in every recording metadata XML document. 271 A recording element MAY contain a element indicating 272 whether the XML document is a complete document or a partial update. 273 If no element is present then the default value is 274 "complete". 276 6. Recording Metadata classes 278 This section describes each class of the metadata model, and the 279 attributes of each class. This section also describes how different 280 classes are linked and the XML element for each of them. 282 6.1. Recording Session 284 +-------------------------------+ 285 | Recording Session (RS) | 286 +-------------------------------+ 287 | | 288 | start-time | 289 | end-time | 290 | | 291 | | 292 +-------------------------------+ 293 |1..* | 1..* 294 | | 295 |0..* | 0..* 296 Communication Communication 297 Session Session Group(CS Group) 299 Each instance of a Recording Session(RS) class namely the Recording 300 Session Object represents a SIP session created between an SRC and 301 SRS for the purpose of recording a Communication Session. 303 RS object is represented in XML schema using element. 304 That in turn relies on the SIP/SDP session with which the XML 305 document is associated to provide the attributes of the RS element. 307 6.1.1. Attributes 309 A RS class has the following attributes: 311 o start-time - Represents the start time of a Recording Session 312 object. 314 o end-time - Represents the end time of a Recording Session 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-time 320 is derivable from the time at which SRS receives disconnect on the RS 321 SIP dialog. 323 6.1.2. Linkages 325 Each instance of RS has: 327 o Zero or more instances of Communication Session Group (CSG). 329 o Zero or more instances of Communication Session(CS) objects. 331 CSs and CSGs are optional to accommodate persistent recording, where 332 there may sometimes be none. 334 6.2. Communication Session Group 335 Recording Session (RS) 336 | 1..* 337 | 338 | 0..* 339 +-------------------------------+ 340 | Communication Session | 341 | Group | 342 +-------------------------------+ 343 | group_id | 344 | associate-time | 345 | disassociate-time | 346 | | 347 +-------------------------------+ 348 | 0..1 349 | 350 | 1..* 351 Communication Session (CS) 353 One instance of a Communication Session Group(CS-Group) class namely 354 the Communication Session Group object provides association or 355 linking of Communication Sessions. 357 CS-Group object is represented in XML schema using element. 359 6.2.1. Attributes 361 A CS-Group has the following attributes: 363 o group_id - This is to group different CSs that are related. SRC 364 (or SRS) is responsible for ensuring the uniqueness of group_id in 365 case multiple SRC interacts with the same SRS. The mechanism by 366 which SRC groups the CS is outside the scope of SIPREC. 368 o associate-time - This is the time when a grouping is formed. The 369 rules that determine how a grouping of different CS objects is 370 done by SRC is outside the scope of SIPREC. 372 o disassociate-time - disassociate-time for CS-Group is calculated 373 by SRC as the time when the grouping ends. 375 6.2.2. Linkages 377 The linkages between CS-Group class and other classes are 378 associations. A CS-Group is associated with RS and CS in the 379 following manner: 381 o There are one or more RS objects per CS-Group. 383 o Each CS-Group object has to be associated with one or more RS. 384 Here each RS can be setup by the potentially different SRCs. 386 o There are one or more CSs per CS-Group (for example, in case where 387 the call is transferred). 389 6.3. Communication Session 391 Recording Communication 392 Session Session Group(CS Group) 393 |1..* | 0..1 394 | | 395 |0..* | 1..* 396 +-------------------------------+ 397 | Communication Session (CS) | 398 +-------------------------------+ 399 | session_id | 400 | sipSessionID | 401 | reason | 402 | group-ref | 403 | start-time | 404 | stop-time | 405 +-------------------------------+ 406 | | 407 | 0..* |0..1 408 | | 409 | 0..* |0..* 410 Participant Media Stream 412 A Communication Session(CS) class and its object in the metadata 413 model represents a Communication Session and its properties needed as 414 seen by SRC. 416 CS object is represented in XML schema using element. 418 6.3.1. Attributes 420 A CS class has the following attributes: 422 o session_id - This attribute is used to uniquely identify an 423 instance of CS object namely the session XML element with in the 424 metadata XML document. session_id is generated using the rules 425 mentioned in Section 6.10. 427 o reason - This represents the reason why a CS was terminated. The 428 value for this attribute is derived from SIP Reason header 429 [RFC3326] of CS. There MAY be multiple instances of the reason 430 XML element inside a session element. The reason XML element has 431 'protocol' as an attribute, which indicates the protocol from 432 which the reason string is derived. The default value for 433 protocol attribute is "SIP". The reason element can be derived 434 from a SIP Reason header in the CS. 436 o sipSessionID - This attribute carries sip Session-ID defined in 437 [I-D.ietf-insipid-session-id]. Each CS object can have zero or 438 more sipSessionID elements. More than one sipSessionID may be 439 present in a CS for Conference flows. For example, if three 440 participants A, B and C are in a conference that has a focus 441 acting as SRC, the metadata sent from the SRC to the SRS will 442 likely have three sipSessionID elements that correspond to the SIP 443 dialogs the focus has with each of the three participants. 445 o group-ref - A group-ref attribute MAY be present to indicate the 446 group to which the enclosing session belongs. 448 o start-time - This optional attribute represents start time of CS 449 as seen by SRC. 451 o Stop-time - This optional attribute represents stop time of CS as 452 seen by SRC. 454 This document does not specify attributes relating to what should 455 happen to a recording of a CS after it has been delivered to the SRS 456 (E.g., how long to retain the recording, what access controls to 457 apply.) The SRS is assumed to behave in accordance with its local 458 policy. The ability for the SRC to influence this policy is outside 459 the scope of this document. However if there are implementations 460 where SRC desires to specify its own policy preferences, this could 461 be sent as extension data attached to the CS. 463 6.3.2. Linkages 465 A CS is linked to CS-Group, Participant, Media Stream and RS classes 466 using the association relationship. Association between CS and 467 Participant allows: 469 o CS to have zero or more participants 471 o Participant is associated with zero or more CSs. This includes 472 participants who are not directly part of any CS. An example of 473 such a case is participants in a premixed media stream. The SRC 474 may have knowledge of such participants, yet not have any 475 signaling relationship with them. This might arise if one 476 participant in CS is a conference focus. To summarize, even if 477 the SRC does not have direct signalling relationships with all 478 participants in a CS, it should nevertheless create a participant 479 object for each participant that it knows about. 481 o The model also allows participants in CS that are not participants 482 in the media. An example is the identity of a Third Party Call 483 Control(3pcc) that has initiated a CS to two or more participants 484 of the CS. Another example is the identity of a conference focus. 485 Of course a focus is probably in the media, but since it may only 486 be there as a mixer, it may not report itself as a participant in 487 any of the media streams. 489 Association between CS and Media Stream allows: 491 o A CS to have zero or more streams 493 o A stream can be associated with at most one CS. A stream in a 494 persistent RS is not required to be associated with any CS before 495 the CS is created and hence the zero associationa is allowed. 497 Association between CS and RS allows: 499 o Each instance of RS has Zero or more instances of CS objects. 501 o Each CS has to be associated with one more RS. Each RS can be 502 potentially setup by different SRCs. 504 6.4. CSRSAssociation 506 1..* 0..* 507 Recording Communication 508 Session ----------+---------- Session 509 | 510 | 511 | 512 +-----------------------+ 513 | CSRSAssociation | 514 | | 515 +-----------------------+ 516 | association-time | 517 | disassociaton-time | 518 | session_id | 519 +-----------------------+ 521 The CSRSAssociation class describes the association of a CS to an RS 522 for a period of time. A single CS may be associated with different 523 RSs (perhaps by different SRCs) and may be associated and dissociated 524 several times. 526 The CSRSAssociation is represented in XML using sessionrecordingassoc 527 XML element. 529 6.4.1. Attributes 531 CSRSAssociation class has the following attributes: 533 o associate-time - associate-time is calculated by SRC as the time 534 it sees a CS is associated to a RS 536 o disassociate-time- disassociate-time is calculated by SRC as the 537 time it see a CS disassociate from a RS. 539 o session_id - Each instance of this class MUST have session_id 540 attribute that identifies the the CS to which this association 541 belongs to. 543 6.4.2. Linkages 545 CSRSAssociation class is linked to CS and RS classes. 547 6.5. Participant 549 Communication Session (CS) 550 | 0..* 551 | 552 | 0..* 553 +-------------------------------+ 554 | Participant | 555 +-------------------------------+ 556 | nameID | 557 | participant_id | 558 | | 559 +-------------------------------+ 560 | 0..* 1..*| 561 receives| |sends 562 | 0..* 0..*| 563 Media Stream 565 A Participant class and its objects has information about a device 566 that is part of a CS and/or contributes/consumes media stream(s) 567 belonging to a CS. 569 Participant object is represented in XML schema using 570 element. 572 6.5.1. Attributes 574 Participant has a single defined attribute: 576 o nameID - This attribute is a list of Name/AoR tuples. An AoR can 577 be one of SIP/SIPS/TEL URI, FQDN or IP address. The AoR MAY be 578 drawn from From header or P-Asserted-Identity header or Remote- 579 Party-ID header. SRCs local policy MAY also be used to decide on 580 where to draw the AoR from. Name represents participant name(SIP 581 display name) or dialed number (DN) (when known). Multiple tuples 582 are allowed for cases where a participant has more than one AoR. 583 (For example a P-Asserted-identity header [RFC3325] can have both 584 SIP and TEL URIs.) 586 o participant_id - This attribute is used to identify the 587 participant XML element with in the XML document. It is generated 588 using the rules mentioned in Section 6.10. This attribute MUST be 589 used for all references to a participant within a CSG, and MAY be 590 used to reference the same participant more globally. 592 This document does not specify other attributes relating to 593 participant e.g. participant role, participant type. An SRC which 594 has information of these attributes can indicate the same as part of 595 extension data to participant from SRC to SRS. 597 6.5.2. Linkages 599 The participant class is linked to MediaStream (MS) and CS class 600 using association relationship. The association between participant 601 and MS allows: 603 o participant to receive zero or more media streams 605 o participant to send zero or more media streams. (Same participant 606 provides multiple streams e.g. audio and video) 608 o media stream to be received by zero or more participants. Its 609 possible, though perhaps unlikely, that a stream is generated but 610 sent only to the SRC and SRS, not to any participant. E.g. In 611 conferencing where all participants are on hold and the SRC is 612 collocated with the focus. Also a media stream may be received by 613 multiple participants (e.g. Whisper calls, side conversations). 615 o media stream to be sent by one or more participants (pre-mixed 616 streams). 618 Example of a case where a participant receives zero or more streams - 619 a supervisor may have side conversation with agent, while agent 620 converses with customer. 622 6.6. ParticipantCSAssociation 624 1..* 0..* 625 Communication 626 Session ----------+---------- Participant 627 | 628 | 629 | 630 +-------------------------+ 631 | ParticipantCSAssociation| 632 | | 633 | | 634 +-------------------------+ 635 | associateTime | 636 | disassociateTime | 637 | param | 638 | participant_id | 639 | session_id | 640 +-------------------------+ 642 The ParticipantCSAssociation class describes the association of a 643 participant to an CS for a period of time. A participant may be 644 associated and dissociated from a CS several times. (For example, 645 connecting to a conference, then disconnecting, then connecting 646 again.) 648 ParticipantCSAssociation object is represented in XML schema using 649 element. 651 6.6.1. Attributes 653 ParticipantCS association class has the following attributes: 655 o associate-time - associate-time is calculated by SRC as the time 656 it sees a participant is associated to CS 658 o disassociate-time- disassociate-time is calculated by the SRC as 659 the time it sees a participant disassociate from a CS. It is 660 possible that a given participant can have multiple associate/ 661 disassociate times within given communication session. 663 o param - An optional attribute describing the capabilities of a 664 participant in a CS, as defined in [RFC3840]. The capablities are 665 represented using param XML element in the metadata. The 'param' 666 XML element encoding defined in [RFC4235] is used to represent the 667 capabilties attributes in metadata. Each participant may have 668 zero or more capabilities. A participant may use different 669 capabilities depending on the role it plays at a particular 670 instance. For example if a participant moves across different CSs 671 (e.g., due to transfer) or is simultaneously present in different 672 CSs with different roles. 674 o participant_id - This attribute identifies the participant to 675 which this association belongs to. 677 o session_id - This attribute identifies the session to which this 678 association belongs to. 680 6.6.2. Linkages 682 The participantCSAssociation class is linked to participant and CS 683 classes. 685 6.7. Media Stream 687 Participant 688 | 0..* 1..*| 689 receives| |sends 690 | 0..* 0..*| 691 +-------------------------+ 692 | Media Stream | 693 Communication 0..1 0..* +-------------------------+ 694 Session ------------| | 695 | label | 696 | content-type | 697 | stream_id | 698 | session_id | 699 +-------------------------+ 701 A MS class (and its objects) has the properties of media as seen by 702 SRC and sent to SRS. Different snapshots of a media stream object 703 may be sent whenever there is a change in media (e.g. direction 704 change like pause/resume and/or codec change and/or participant 705 change.). 707 MS object is represented in XML schema using element. 709 6.7.1. Attributes 711 A MS class has the the following attributes: 713 o label - The label attribute within the stream XML element 714 references an SDP "a=label" attribute that identifies an m-line 715 within the RS SDP. That m-line carries the media stream from the 716 SRC to the SRS. 718 o content-type - The content of an MS element will be described in 719 terms of value from the [RFC4796] registry. If the SRC wishes to 720 convey the Content-type to the SRS, it does so by including an 721 'a=content' attribute with the m-line in the RS SDP. 723 o stream_id - Each stream element has unique 'stream_id' attribute 724 which helps to uniquely identify stream. This identifier is 725 generated using the rules mentioned in Section 6.10. 727 o session_id - This attribute associates the stream with a specific 728 session element. 730 The metadata model should include media streams that are not being 731 delivered to the SRS. Examples include cases where SRC offered 732 certain media types but SRS chooses to accept only a subset of them 733 OR an SRC may not even offer a certain media type due it its 734 restrictions to record 736 6.7.2. Linkages 738 A MS class is linked to participant and CS classes using the 739 association relationship. The details of association with the 740 Participant are described in the Participant class section. The 741 details of association with CS is mentioned in the CS section. 743 6.8. ParticipantStream Association 744 +-------------------------+ 745 | ParticipantStream | 746 | Association | 747 +-------------------------+ +----------Participant 748 | association-time | | 0..*| 1..*| 749 | disassociaton-time |---+ recv| |sends 750 | send | | 0..*| 0..*| 751 | recv | | | | 752 | participant_id | | | | 753 +-------------------------+ | | | 754 +----------Media Stream 756 A ParticipantStream association class describes the association of a 757 Participant to a Media Stream for a period of time, as a sender or as 758 a receiver, or both. 760 This class is represented in XML using 761 element. 763 6.8.1. Attributes 765 A ParticipantStream association class has the following attributes: 767 o associate-time: This attribute indicates the time a participant 768 started contributing to a Media Stream 770 o disassociate-time: This attribute indicates the time a participant 771 stopped contributing to a Media Stream 773 o send: This attribute indicates whether a participant is 774 contributing to a stream or not. This attribute has a value which 775 points to stream represented by its unique_id. The presence of 776 this attribute indicates that a participant is contributing to a 777 stream represented by the Unique_id. If due to changes in CS if a 778 participant stops contributing to a stream, a snapshot MUST be 779 sent from SRC to SRS with no Send element for that stream. 781 o recv: This attribute indicates whether a participant is receiving 782 a media stream or not. This attribute has a value which points to 783 a stream represented by its Unique_id. The presence of this 784 attribute indicates that a participant is receiving a stream 785 represented by the Unique_id. If due to changes in CS(like hold) 786 the participants stops receiving a stream, a snapshot MUST be sent 787 from SRC to SRS with no Recv element for that stream. 789 o participant_id - This attributes points to the participant to 790 which this streams are associated with. 792 This XML element is used to represent a snapshot of a participant 793 association with a stream. The send and recv XML elements MUST be 794 used to indicate whether a participant is contributing to a stream or 795 receiving a stream. There MAY be multiple instances of the send and 796 recv XML elements inside a particpantstreamassoc element. If a 797 metadata snapshot is sent with a participantstreamassoc that does not 798 have any send and recv elements, it means that participant is neither 799 contributing to any streams nor receiving any streams. 801 6.8.2. Linkages 803 The participantStream association class is linked to participant and 804 Stream classes. 806 6.9. associate-time/disassociate-time 808 The XML and elements contain 809 strings indicating the date and time of the status change of this 810 tuple. The value of these elements MUST follow the IMPP datetime 811 format [RFC3339]. Timestamps that contain 'T' or 'Z' MUST use the 812 capitalized forms. At a time, any of the time tuple associate-time 813 or disassociate-time MAY exist in the element namely group, session, 814 participant and not both timestamp at the same time. 816 As a security measure, the timestamp element SHOULD be included in 817 all tuples unless the exact time of the status change cannot be 818 determined. 820 6.10. Unique ID format 822 A Unique id is generated in two steps: 824 o the UUID is created using [RFC4122] 826 o the UUID is encoded using base64 as defined in [RFC4648] 828 The above mentioned unique-id mechanism SHOULD be used for each 829 metadata element. Multiple SRCs can refer to the same element/UUID 830 (how each SRC learns the UUID here is out of scope of SIPREC) 832 6.11. Metadata version Indicator 834 This section defines a version indicator for metadata XML. 836 This version value allows the SRS to know the exact metadata XML 837 schema used by the SRC. This document describes version 1. 838 Implementations may not interoperate if the version implemented by 839 the sender is not known by the receiver. No negotiation of versions 840 is provided. There is no significance to the version number although 841 documents which update or obsolete this document (possibly including 842 drafts of such documents) should include a higher version number if 843 the metadata XML schema changes. 845 7. Recording metadata snapshot Request format 847 This section gives an details of metadata snapshot request format. 848 When SRS wishes to request metadata snapshot from SRC it MUST follow 849 the syntax described in this section. The SRS requests metadata 850 snapshot in a request message and SHOULD insert a XML document having 851 the namespace urn:ietf:params:xml:ns:recording:1. The Request can 852 have the following elements. 854 A XML element MUST be present as the top level 855 element in the XML document. A XML element that 856 indicates the reason for requesting snapshot as a string MAY be 857 present as a child XML element of . 859 8. SIP Recording Metadata Example 861 8.1. Complete SIP Recording Metadata Example 863 The following example provides all the tuples involved in Recording 864 Metadata XML body. 866 867 868 complete 869 870 2010-12-16T23:41:07Z 871 872 873 sip:alice@atlanta.com 874 875 876 FOO! 877 bar 878 879 880 881 ab30317f1a784dc48ff824d0d3715d86; 882 remote=47755a9de7794ba387653f2099600ef2 884 7+OTCyoxTmqmqyA/1weDAg== 885 886 887 888 FOO! 889 bar 890 891 892 894 895 Bob B 896 897 898 899 FOO! 900 bar 901 902 903 905 906 Paul 907 908 909 910 FOO! 911 bar 912 913 914 916 917 918 920 921 922 924 925 926 928 929 930 931 2010-12-16T23:41:07Z 933 934 937 2010-12-16T23:41:07Z 938 939 942 2010-12-16T23:41:07Z 943 944 946 i1Pz3to5hGk8fuXl+PbwCw== 947 UAAMm5GRQKSCMVvLyl4rFw== 948 8zc6e0lYTlWIINA6GR+3ag== 949 EiXGlc+4TruqqoDaNE76ag== 950 951 953 8zc6e0lYTlWIINA6GR+3ag== 954 EiXGlc+4TruqqoDaNE76ag== 955 UAAMm5GRQKSCMVvLyl4rFw== 956 i1Pz3to5hGk8fuXl+PbwCw== 957 958 960 SIP Recording Metadata Example XML body 962 8.2. Partial Update of Recording metadata XML body 964 The following example provides partial update in Recording metadata 965 XML body for the above example. The example has a snapshot that 966 carries the disassociate-time for a participant from a session. 968 969 970 partial 971 973 974 Bob R 975 976 FOO! 977 bar 978 979 982 2010-12-16T23:41:07Z 983 984 986 Partial update of SIP Recording Example XML body 988 9. XML Schema definition for Recording metadata 990 This section defines XML schema for Recording metadata document 992 993 998 999 1000 1001 1002 1003 1005 1007 1009 1011 1013 1016 1019 1022 1026 1027 1028 1029 1030 1032 1034 1038 1039 1041 1042 1043 1044 1046 1048 1050 1052 1054 1058 1059 1061 1062 1063 1064 1066 1068 1072 1073 1075 1076 1077 1078 1080 1084 1085 1087 1088 1089 1090 1092 1094 1095 1096 1097 1098 1099 1100 1104 1105 1107 1109 1110 1111 1112 1114 1116 1118 1120 1124 1125 1127 1128 1129 1130 1132 1136 1137 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1151 1152 1153 1154 1155 1156 1157 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1178 1179 1180 1182 10. Security Considerations 1184 This document describes an extensive set of metadata that may be 1185 recorded by the SRS. Most of the metadata could be considered 1186 private data. For this reason, it is RECOMMENDED that a SRC use a 1187 strong means for authentication and metadata information protection 1188 and that it apply comprehensive authorization rules when using the 1189 metadata format defined in this document. 1191 It is RECOMMENDED that a SRC authenticate the SRS using the normal 1192 SIP authentication mechanisms, such as Digest as defined in 1193 Section 22 of [RFC3261]. The mechanism used for conveying the 1194 metadata information MUST ensure integrity and confidentially of the 1195 information. In order to achieve these, an end-to-end SIP encryption 1196 mechanism, such as S/MIME described in [RFC3261], SHOULD be used. 1198 If a strong end-to-end security means (such as above) is not 1199 available, it is RECOMMENDED that a SRC use mutual hop-by-hop 1200 Transport Layer Security (TLS) authentication and encryption 1201 mechanisms described in "SIPS URI Scheme" and "Interdomain Requests" 1202 of [RFC3261]. 1204 Some implementations may have the SRC choose parts of metadata that 1205 can be sent to the SRS. In other cases, SRCs may send metadata that 1206 is not appropriate for the SRS to record. Which metadata is actually 1207 recorded by the SRS must be carefully considered to balance privacy 1208 concerns with usability. Implementations MUST control what metadata 1209 is recorded, and MUST NOT save metadata sent by the SRC that does not 1210 conform to the recording policy of the SRS. Metadata in storage 1211 needs to be provided with a level of security that is comparable to 1212 that of the recording session. 1214 11. IANA Considerations 1216 This specification registers a new XML namespace, and a new XML 1217 schema. 1219 11.1. SIP recording metadata Schema Registration 1221 URI: urn:ietf:params:xml:ns:recording:1 1223 Registrant Contact: IETF SIPREC working group, Ram mohan 1224 R(rmohanr@cisco.com) 1226 XML: the XML schema to be registered is contained in Section 8. 1228 Its first line is and its last 1229 line is 1231 12. Acknowledgement 1233 Thanks to John Elwell, Henry Lum, Leon Portman, De Villers, Andrew 1234 Hutton, Deepanshu Gautam,Charles Eckel, Muthu Arul Mozhi, Michael 1235 Benenson, Hadriel Kaplan, Brian Rosen, Scott Orton, Ofir Roth, Mary 1236 Barnes, Ken Rehor, Gonzalo Salgueiro, Yaron Pdut and Alissa Cooper 1237 for their valuable comments and inputs. 1239 Thanks to Joe Hildebrand, Peter Saint-Andre, Matt Miller for helping 1240 in writing the XML schema and Martin Thompson for validating the XML 1241 schema and providing comments on the same. 1243 13. References 1245 13.1. Normative References 1247 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1248 Requirement Levels", BCP 14, RFC 2119, 1249 DOI 10.17487/RFC2119, March 1997, 1250 . 1252 [RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, 1253 May 1997, . 1255 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1256 A., Peterson, J., Sparks, R., Handley, M., and E. 1257 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1258 DOI 10.17487/RFC3261, June 2002, 1259 . 1261 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1262 DOI 10.17487/RFC3688, January 2004, 1263 . 1265 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1266 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1267 . 1269 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1270 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1271 July 2006, . 1273 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1274 Protocol (SDP) Label Attribute", RFC 4574, 1275 DOI 10.17487/RFC4574, August 2006, 1276 . 1278 [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description 1279 Protocol (SDP) Content Attribute", RFC 4796, 1280 DOI 10.17487/RFC4796, February 2007, 1281 . 1283 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1284 "Indicating User Agent Capabilities in the Session 1285 Initiation Protocol (SIP)", RFC 3840, 1286 DOI 10.17487/RFC3840, August 2004, 1287 . 1289 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1290 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1291 DOI 10.17487/RFC4122, July 2005, 1292 . 1294 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1295 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1296 . 1298 [I-D.ietf-insipid-session-id] 1299 Jones, P., Salgueiro, G., and C. Pearce, "End-to-End 1300 Session Identification in IP-Based Multimedia 1301 Communication Networks", draft-ietf-insipid-session-id-16 1302 (work in progress), October 2015. 1304 13.2. Informative References 1306 [RFC6341] Rehor, K., Ed., Portman, L., Ed., Hutton, A., and R. Jain, 1307 "Use Cases and Requirements for SIP-Based Media Recording 1308 (SIPREC)", RFC 6341, DOI 10.17487/RFC6341, August 2011, 1309 . 1311 [RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor, 1312 "An Architecture for Media Recording Using the Session 1313 Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May 1314 2014, . 1316 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1317 DOI 10.17487/RFC2648, August 1999, 1318 . 1320 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 1321 Header Field for the Session Initiation Protocol (SIP)", 1322 RFC 3326, DOI 10.17487/RFC3326, December 2002, 1323 . 1325 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1326 Extensions to the Session Initiation Protocol (SIP) for 1327 Asserted Identity within Trusted Networks", RFC 3325, 1328 DOI 10.17487/RFC3325, November 2002, 1329 . 1331 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, Ed., "An 1332 INVITE-Initiated Dialog Event Package for the Session 1333 Initiation Protocol (SIP)", RFC 4235, 1334 DOI 10.17487/RFC4235, November 2005, 1335 . 1337 Authors' Addresses 1339 Ram Mohan Ravindranath 1340 Cisco Systems 1341 Cessna Business Park 1342 Bangalore, Karnataka 1343 India 1345 Email: rmohanr@cisco.com 1346 Parthasarathi Ravindran 1347 Nokia Networks 1348 Bangalore, Karnataka 1349 India 1351 Email: partha@parthasarathi.co.in 1353 Paul Kyzivat 1354 Huawei 1355 Hudson, MA 1356 USA 1358 Email: pkyzivat@alum.mit.edu