idnits 2.17.1 draft-ietf-siprec-metadata-20.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 (February 7, 2016) is 3001 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 10, 2016 Nokia Networks 6 Paul. Kyzivat 7 Huawei 8 February 7, 2016 10 Session Initiation Protocol (SIP) Recording Metadata 11 draft-ietf-siprec-metadata-20 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 10, 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 . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 20 94 7. Recording metadata snapshot request format . . . . . . . . . 21 95 8. SIP Recording Metadata Example . . . . . . . . . . . . . . . 21 96 8.1. Complete SIP Recording Metadata Example . . . . . . . . . 21 97 8.2. Partial Update of Recording metadata XML body . . . . . . 23 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 . . . . . . . . . . . . . . . . . 31 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) 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 from SRC to SRS 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 sent from SRC to SRS MUST 241 contain a element. The element acts as a 242 container for all other 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(CS). 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 RS object. 313 o end-time - Represents the end time of a RS object. 315 start-time and end-time attribute values are derivable from Date 316 header(if present in SIP message) in RS. In cases where Date header 317 is not present, start-time is derivable from the time at which SRS 318 receives the notification of SIP message to setup RS and and end-time 319 is derivable from the time at which SRS receives disconnect on the RS 320 SIP dialog. 322 6.1.2. Linkages 324 Each instance of RS has: 326 o Zero or more instances of Communication Session Group (CSG). 328 o Zero or more instances of CS objects. 330 CSs and CSGs are optional to accommodate persistent recording, where 331 there may sometimes be none. 333 6.2. Communication Session Group 334 Recording Session (RS) 335 | 1..* 336 | 337 | 0..* 338 +-------------------------------+ 339 | Communication Session | 340 | Group | 341 +-------------------------------+ 342 | group_id | 343 | associate-time | 344 | disassociate-time | 345 | | 346 +-------------------------------+ 347 | 0..1 348 | 349 | 1..* 350 Communication Session (CS) 352 One instance of a Communication Session Group(CS-Group) class namely 353 the Communication Session Group object provides association or 354 linking of Communication Sessions. 356 CS-Group object is represented in XML schema using element. 358 6.2.1. Attributes 360 A CS-Group has the following attributes: 362 o group_id - This is to group different CSs that are related. SRC 363 (or SRS) is responsible for ensuring the uniqueness of group_id in 364 case multiple SRC interacts with the same SRS. The mechanism by 365 which SRC groups the CS is outside the scope of SIPREC. 367 o associate-time - This is the time when a grouping is formed. The 368 rules that determine how a grouping of different CS objects is 369 done by SRC is outside the scope of SIPREC. 371 o disassociate-time - disassociate-time for CS-Group is calculated 372 by SRC as the time when the grouping ends. 374 6.2.2. Linkages 376 The linkages between CS-Group class and other classes are 377 associations. A CS-Group is associated with RS and CS in the 378 following manner: 380 o There are one or more RS objects per CS-Group. 382 o Each CS-Group object has to be associated with one or more RS. 383 Here each RS can be setup by the potentially different SRCs. 385 o There are one or more CSs per CS-Group (for example, in case where 386 the call is transferred). 388 6.3. Communication Session 390 Recording Communication 391 Session Session Group(CS Group) 392 |1..* | 0..1 393 | | 394 |0..* | 1..* 395 +-------------------------------+ 396 | Communication Session (CS) | 397 +-------------------------------+ 398 | session_id | 399 | sipSessionID | 400 | reason | 401 | group-ref | 402 | start-time | 403 | stop-time | 404 +-------------------------------+ 405 | | 406 | 0..* |0..1 407 | | 408 | 0..* |0..* 409 Participant Media Stream 411 A Communication Session(CS) class and its object in the metadata 412 model represents a CS and its properties needed as seen by SRC. 414 CS object is represented in XML schema using element. 416 6.3.1. Attributes 418 A CS class has the following attributes: 420 o session_id - This attribute is used to uniquely identify an 421 instance of CS object namely the session XML element with in the 422 metadata XML document. session_id is generated using the rules 423 mentioned in Section 6.10. 425 o reason - This represents the reason why a CS was terminated. The 426 value for this attribute is derived from SIP Reason header 427 [RFC3326] of CS. There MAY be multiple instances of the reason 428 XML element inside a session element. The reason XML element has 429 'protocol' as an attribute, which indicates the protocol from 430 which the reason string is derived. The default value for 431 protocol attribute is "SIP". The reason element can be derived 432 from a SIP Reason header in the CS. 434 o sipSessionID - This attribute carries sip Session-ID defined in 435 [I-D.ietf-insipid-session-id]. Each CS object can have zero or 436 more sipSessionID elements. More than one sipSessionID may be 437 present in a CS for conference flows. For example, if three 438 participants A, B and C are in a conference that has a focus 439 acting as SRC, the metadata sent from the SRC to the SRS will 440 likely have three sipSessionID elements that correspond to the SIP 441 dialogs the focus has with each of the three participants. 443 o group-ref - A group-ref attribute MAY be present to indicate the 444 group(identified by group_id) to which the enclosing session 445 belongs. 447 o start-time - This optional attribute represents start time of CS 448 as seen by SRC. 450 o stop-time - This optional attribute represents stop time of CS as 451 seen by SRC. 453 This document does not specify attributes relating to what should 454 happen to a recording of a CS after it has been delivered to the SRS 455 (E.g., how long to retain the recording, what access controls to 456 apply.) The SRS is assumed to behave in accordance with its local 457 policy. The ability for the SRC to influence this policy is outside 458 the scope of this document. However if there are implementations 459 where SRC desires to specify its own policy preferences, this could 460 be sent as extension data attached to the CS. 462 6.3.2. Linkages 464 A CS is linked to CS-Group, Participant, Media Stream and RS classes 465 using the association relationship. Association between CS and 466 participant allows: 468 o CS to have zero or more participants 470 o Participant is associated with zero or more CSs. This includes 471 participants who are not directly part of any CS. An example of 472 such a case is participants in a premixed media stream. The SRC 473 may have knowledge of such participants, yet not have any 474 signaling relationship with them. This might arise if one 475 participant in CS is a conference focus. To summarize, even if 476 the SRC does not have direct signalling relationships with all 477 participants in a CS, it should nevertheless create a participant 478 object for each participant that it knows about. 480 o The model also allows participants in CS that are not participants 481 in the media. An example is the identity of a Third Party Call 482 Control(3pcc) that has initiated a CS to two or more participants 483 of the CS. Another example is the identity of a conference focus. 484 Of course a focus is probably in the media, but since it may only 485 be there as a mixer, it may not report itself as a participant in 486 any of the media streams. 488 Association between CS and Media Stream allows: 490 o A CS to have zero or more streams 492 o A stream can be associated with at most one CS. A stream in a 493 persistent RS is not required to be associated with any CS before 494 the CS is created and hence the zero association is allowed. 496 Association between CS and RS allows: 498 o Each instance of RS has zero or more instances of CS objects. 500 o Each CS has to be associated with one more RS. Each RS can be 501 potentially setup by different SRCs. 503 6.4. CSRSAssociation 504 1..* 0..* 505 Recording Communication 506 Session ----------+---------- Session 507 | 508 | 509 | 510 +-----------------------+ 511 | CSRSAssociation | 512 | | 513 +-----------------------+ 514 | associate-time | 515 | disassociate-time | 516 | session_id | 517 +-----------------------+ 519 The CSRSAssociation class describes the association of a CS to an RS 520 for a period of time. A single CS may be associated with different 521 RSs (perhaps by different SRCs) and may be associated and dissociated 522 several times. 524 The CSRSAssociation is represented in XML using sessionrecordingassoc 525 XML element. 527 6.4.1. Attributes 529 CSRSAssociation class has the following attributes: 531 o associate-time - associate-time is calculated by SRC as the time 532 it sees a CS associated to a RS 534 o disassociate-time- disassociate-time is calculated by SRC as the 535 time it see a CS disassociate from a RS. 537 o session_id - Each instance of this class MUST have session_id 538 attribute that identifies the the CS to which this association 539 belongs to. 541 6.4.2. Linkages 543 CSRSAssociation class is linked to CS and RS classes. 545 6.5. Participant 546 Communication Session (CS) 547 | 0..* 548 | 549 | 0..* 550 +-------------------------------+ 551 | Participant | 552 +-------------------------------+ 553 | nameID | 554 | participant_id | 555 | | 556 +-------------------------------+ 557 | 0..* 1..*| 558 receives| |sends 559 | 0..* 0..*| 560 Media Stream 562 A participant class and its objects has information about a device 563 that is part of a CS and/or contributes/consumes media stream(s) 564 belonging to a CS. 566 Participant object is represented in XML schema using 567 element. 569 6.5.1. Attributes 571 A participant class has two attributes: 573 o nameID - This attribute is a list of Name/AoR tuples. An AoR can 574 be one of SIP/SIPS/TEL URI, FQDN or IP address. The AoR MAY be 575 drawn from From header or P-Asserted-Identity header or Remote- 576 Party-ID header. SRC's local policy is used to decide on where to 577 draw the AoR from. Name represents participant name(SIP display 578 name) or dialed number (DN) (when known). Multiple tuples are 579 allowed for cases where a participant has more than one AoR. (For 580 example a P-Asserted-identity header [RFC3325] can have both SIP 581 and TEL URIs.) 583 o participant_id - This attribute is used to identify the 584 participant XML element with in the XML document. It is generated 585 using the rules mentioned in Section 6.10. This attribute MUST be 586 used for all references to a participant within a CSG, and MAY be 587 used to reference the same participant more globally. 589 This document does not specify other attributes relating to 590 participant e.g. participant role, participant type. An SRC which 591 has information of these attributes can indicate the same as part of 592 extension data to participant from SRC to SRS. 594 6.5.2. Linkages 596 The participant class is linked to MediaStream (MS) and CS class 597 using association relationship. The association between participant 598 and MS allows: 600 o participant to receive zero or more media streams. 602 o participant to send zero or more media streams. (Same participant 603 provides multiple streams e.g. audio and video) 605 o media stream to be received by zero or more participants. Its 606 possible, though perhaps unlikely, that a stream is generated but 607 sent only to the SRC and SRS, not to any participant. E.g. In 608 conferencing where all participants are on hold and the SRC is 609 collocated with the focus. Also a media stream may be received by 610 multiple participants (e.g. Whisper calls, side conversations). 612 o media stream to be sent by one or more participants (pre-mixed 613 streams). 615 Example of a case where a participant receives zero or more streams - 616 a supervisor may have side conversation with agent, while agent 617 converses with customer. 619 6.6. ParticipantCSAssociation 620 1..* 0..* 621 Communication 622 Session ----------+---------- Participant 623 | 624 | 625 | 626 +-------------------------+ 627 | ParticipantCSAssociation| 628 | | 629 | | 630 +-------------------------+ 631 | associate-time | 632 | disassociate-time | 633 | param | 634 | participant_id | 635 | session_id | 636 +-------------------------+ 638 The ParticipantCSAssociation class describes the association of a 639 participant to an CS for a period of time. A participant may be 640 associated and dissociated from a CS several times. (For example, 641 connecting to a conference, then disconnecting, then connecting 642 again.) 644 ParticipantCSAssociation object is represented in XML schema using 645 element. 647 6.6.1. Attributes 649 ParticipantCS association class has the following attributes: 651 o associate-time - associate-time is calculated by SRC as the time 652 it sees a participant associated to a CS. 654 o disassociate-time- disassociate-time is calculated by the SRC as 655 the time it sees a participant disassociate from a CS. It is 656 possible that a given participant can have multiple associate/ 657 disassociate times within given communication session. 659 o param - An optional attribute describing the capabilities of a 660 participant in a CS, as defined in [RFC3840]. For example, in a 661 CS(which can be a conference), you can have participants who are 662 playing the role of "focus". These participants does not 663 contribute to media in the CS, however they switch the media 664 received from one participant to every other participant in the 665 CS. Indicating the capability of participant (here "focus") would 666 be useful for recorder to learn about these kind of participants. 668 The capablities are represented using param XML element in the 669 metadata. The 'param' XML element encoding defined in [RFC4235] 670 is used to represent the capabilties attributes in metadata. Each 671 participant may have zero or more capabilities. A participant may 672 use different capabilities depending on the role it plays at a 673 particular instance. For example, if a participant moves across 674 different CSs (e.g., due to transfer) or is simultaneously present 675 in different CSs with different roles. 677 o participant_id - This attribute identifies the participant to 678 which this association belongs to. 680 o session_id - This attribute identifies the session to which this 681 association belongs to. 683 6.6.2. Linkages 685 The participantCSAssociation class is linked to participant and CS 686 classes. 688 6.7. Media Stream 690 Participant 691 | 0..* 1..*| 692 receives| |sends 693 | 0..* 0..*| 694 +-------------------------+ 695 | Media Stream | 696 Communication 0..1 0..* +-------------------------+ 697 Session ------------| | 698 | label | 699 | content-type | 700 | stream_id | 701 | session_id | 702 +-------------------------+ 704 A MS class (and its objects) has the properties of media as seen by 705 SRC and sent to SRS. Different snapshots of a MS objects may be sent 706 whenever there is a change in media (e.g. direction change like 707 pause/resume and/or codec change and/or participant change.). 709 MS object is represented in XML schema using element. 711 6.7.1. Attributes 713 A MS class has the the following attributes: 715 o label - The label attribute within the stream XML element 716 references an SDP "a=label" attribute that identifies an m-line 717 within the RS SDP. That m-line carries the media stream from the 718 SRC to the SRS. 720 o content-type - The content of an MS element will be described in 721 terms of value from the [RFC4796] registry. If the SRC wishes to 722 convey the Content-type to the SRS, it does so by including an 723 'a=content' attribute with the m-line in the RS SDP. 725 o stream_id - Each stream element has unique 'stream_id' attribute 726 which helps to uniquely identify stream. This identifier is 727 generated using the rules mentioned in Section 6.10. 729 o session_id - This attribute associates the stream with a specific 730 session element. 732 The metadata model can include media streams that are not being 733 delivered to the SRS. For example, an SRC offers audio, video 734 towards SRS which in response accepts only audio. The metadata 735 snapshots sent from SRC to SRS can continue to indicate the changes 736 to video stream as well. 738 6.7.2. Linkages 740 A MS class is linked to participant and CS classes using the 741 association relationship. The details of association with the 742 participant are described in the participant class section. The 743 details of association with CS is mentioned in the CS section. 745 6.8. ParticipantStreamAssociation 746 +-------------------------+ 747 | ParticipantStream | 748 | Association | 749 +-------------------------+ +----------Participant 750 | association-time | | 0..*| 1..*| 751 | disassociaton-time |---+ recv| |sends 752 | send | | 0..*| 0..*| 753 | recv | | | | 754 | participant_id | | | | 755 +-------------------------+ | | | 756 +----------Media Stream 758 A ParticipantStreamAssociation class describes the association of a 759 Participant to a MS for a period of time, as a sender or as a 760 receiver, or both. 762 This class is represented in XML using 763 element. 765 6.8.1. Attributes 767 A ParticipantStreamAssociation class has the following attributes: 769 o associate-time: This attribute indicates the time a participant 770 started contributing to a MS. 772 o disassociate-time: This attribute indicates the time a participant 773 stopped contributing to a MS. 775 o send: This attribute indicates whether a participant is 776 contributing to a stream or not. This attribute has a value which 777 points to stream represented by its unique_id. The presence of 778 this attribute indicates that a participant is contributing to a 779 stream. If due to changes in CS if a participant stops 780 contributing to a stream, a snapshot MUST be sent from SRC to SRS 781 with no send element for that stream. 783 o recv: This attribute indicates whether a participant is receiving 784 a media stream or not. This attribute has a value which points to 785 a stream represented by its unique_id. The presence of this 786 attribute indicates that a participant is receiving a stream. If 787 due to changes in CS(like hold) the participants stops receiving a 788 stream, a snapshot MUST be sent from SRC to SRS with no recv 789 element for that stream. 791 o participant_id - This attributes points to the participant to 792 which a stream element is associated with. 794 XML element is used to represent a 795 participant association with a stream. The send and recv XML 796 elements MUST be used to indicate whether a participant is 797 contributing to a stream or receiving a stream. There MAY be 798 multiple instances of the send and recv XML elements inside a 799 particpantstreamassoc element. If a metadata snapshot is sent with a 800 participantstreamassoc that does not have any send and recv elements, 801 it means that participant is neither contributing to any streams nor 802 receiving any streams. 804 6.8.2. Linkages 806 The ParticipantStreamAssociation class is linked to participant and 807 MS classes. 809 6.9. Syntax of date/time XML elements 811 XML elements , , and 812 contain strings representing the date and time. The 813 value of these elements MUST follow the IMPP datetime format 814 [RFC3339]. Timestamps that contain 'T' or 'Z' MUST use the 815 capitalized forms. 817 As a security measure, the timestamp element SHOULD be included in 818 all tuples unless the exact time of the status change cannot be 819 determined. 821 6.10. Unique ID format 823 A Unique id is generated in two steps: 825 o the UUID is created using [RFC4122] 827 o the UUID is encoded using base64 as defined in [RFC4648] 829 The above mentioned unique-id mechanism SHOULD be used for each 830 metadata element. Multiple SRC's can refer to the same element/UUID 831 (how each SRC learns the UUID here is out of scope of SIPREC) 833 6.11. Metadata version Indicator 835 Metadata version is defined to help SRC and SRS to know the version 836 of metadata XML schema used. SRCs and SRSs that support this 837 specification MUST use version 1 in the 838 namespace(urn:ietf:params:xml:ns:recording:1) in all the XML 839 documents. Implementations may not interoperate if the version 840 implemented by the sender is not known by the receiver. No 841 negotiation of versions is provided. There is no significance to the 842 version number although documents which update or obsolete this 843 document (possibly including drafts of such documents) should include 844 a higher version number if the metadata XML schema changes. 846 7. Recording metadata snapshot request format 848 SRS can explicitly request metadata snapshot from SRC. To request a 849 metadata snapshot the SRS MUST send a SIP request message with a XML 850 document having the namespace urn:ietf:params:xml:ns:recording:1. 851 The XML document has the following elements. 853 o A XML element MUST be present as the top level 854 element in the XML document. 856 o A XML element that indicates the reason for 857 requesting snapshot as a string MAY be present as a child XML 858 element of . 860 The example below shows a metadata snapshot request from SRS. 862 863 864 SRS internal error 865 867 Example metadata snapshot request from SRS to SRC 869 8. SIP Recording Metadata Example 871 8.1. Complete SIP Recording Metadata Example 873 The following example provides all the tuples involved in Recording 874 Metadata XML body. 876 877 878 complete 879 880 2010-12-16T23:41:07Z 881 882 883 sip:alice@atlanta.com 885 886 887 FOO! 888 bar 889 890 891 892 ab30317f1a784dc48ff824d0d3715d86; 893 remote=47755a9de7794ba387653f2099600ef2 894 7+OTCyoxTmqmqyA/1weDAg== 895 896 897 898 FOO! 899 bar 900 901 902 904 905 Bob B 906 907 908 909 FOO! 910 bar 911 912 913 915 916 Paul 917 918 919 920 FOO! 921 bar 922 923 924 926 927 928 930 931 932 934 935 936 938 939 940 941 2010-12-16T23:41:07Z 942 943 946 2010-12-16T23:41:07Z 947 948 951 2010-12-16T23:41:07Z 952 953 955 i1Pz3to5hGk8fuXl+PbwCw== 956 UAAMm5GRQKSCMVvLyl4rFw== 957 8zc6e0lYTlWIINA6GR+3ag== 958 EiXGlc+4TruqqoDaNE76ag== 959 960 962 8zc6e0lYTlWIINA6GR+3ag== 963 EiXGlc+4TruqqoDaNE76ag== 964 UAAMm5GRQKSCMVvLyl4rFw== 965 i1Pz3to5hGk8fuXl+PbwCw== 966 967 969 Example metadata snapshot from SRC to SRS 971 8.2. Partial Update of Recording metadata XML body 973 The following example provides partial update in Recording metadata 974 XML body for the above example. The example has a snapshot that 975 carries the disassociate-time for a participant from a session. 977 978 979 partial 980 982 983 Bob R 984 985 986 989 2010-12-16T23:41:07Z 990 991 993 Partial update of SIP Recording Example XML body 995 9. XML Schema definition for Recording metadata 997 This section defines XML schema for Recording metadata document 999 1000 1005 1006 1008 1009 1010 1011 1013 1015 1017 1019 1021 1024 1027 1030 1034 1035 1036 1037 1038 1040 1042 1046 1047 1049 1050 1051 1052 1054 1056 1058 1060 1062 1066 1067 1069 1070 1071 1072 1074 1076 1080 1081 1083 1084 1085 1086 1088 1092 1093 1095 1096 1097 1098 1100 1102 1103 1104 1105 1106 1107 1108 1112 1113 1115 1117 1118 1119 1120 1122 1124 1126 1128 1132 1133 1135 1136 1137 1138 1140 1144 1145 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1159 1160 1161 1162 1163 1164 1165 1166 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1186 1187 1188 1190 10. Security Considerations 1192 This document describes an extensive set of metadata that may be 1193 recorded by the SRS. Most of the metadata could be considered 1194 private data. For this reason, it is RECOMMENDED that a SRC use a 1195 strong means for authentication and metadata information protection 1196 and that it apply comprehensive authorization rules when using the 1197 metadata format defined in this document. 1199 It is RECOMMENDED that a SRC authenticate the SRS using the normal 1200 SIP authentication mechanisms, such as Digest as defined in 1201 Section 22 of [RFC3261]. The mechanism used for conveying the 1202 metadata information MUST ensure integrity and confidentially of the 1203 information. In order to achieve these, an end-to-end SIP encryption 1204 mechanism, such as S/MIME described in [RFC3261], SHOULD be used. 1206 If a strong end-to-end security means (such as above) is not 1207 available, it is RECOMMENDED that a SRC use mutual hop-by-hop 1208 Transport Layer Security (TLS) authentication and encryption 1209 mechanisms described in "SIPS URI Scheme" and "Interdomain Requests" 1210 of [RFC3261]. 1212 Some implementations may have the SRC choose parts of metadata that 1213 can be sent to the SRS. In other cases, SRCs may send metadata that 1214 is not appropriate for the SRS to record. Which metadata is actually 1215 recorded by the SRS must be carefully considered to balance privacy 1216 concerns with usability. Implementations MUST control what metadata 1217 is recorded, and MUST NOT save metadata sent by the SRC that does not 1218 conform to the recording policy of the SRS. Metadata in storage 1219 needs to be provided with a level of security that is comparable to 1220 that of the recording session. 1222 11. IANA Considerations 1224 This specification registers a new XML namespace, and a new XML 1225 schema. 1227 11.1. SIP recording metadata Schema Registration 1229 URI: urn:ietf:params:xml:ns:recording:1 1231 Registrant Contact: IETF SIPREC working group, Ram mohan 1232 R(rmohanr@cisco.com) 1234 XML: the XML schema to be registered is contained in Section 8. 1236 Its first line is and its last 1237 line is 1239 12. Acknowledgement 1241 Thanks to John Elwell, Henry Lum, Leon Portman, De Villers, Andrew 1242 Hutton, Deepanshu Gautam,Charles Eckel, Muthu Arul Mozhi, Michael 1243 Benenson, Hadriel Kaplan, Brian Rosen, Scott Orton, Ofir Roth, Mary 1244 Barnes, Ken Rehor, Gonzalo Salgueiro, Yaron Pdut and Alissa Cooper 1245 for their valuable comments and inputs. 1247 Thanks to Joe Hildebrand, Peter Saint-Andre, Matt Miller for helping 1248 in writing the XML schema and Martin Thompson for validating the XML 1249 schema and providing comments on the same. 1251 13. References 1253 13.1. Normative References 1255 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1256 Requirement Levels", BCP 14, RFC 2119, 1257 DOI 10.17487/RFC2119, March 1997, 1258 . 1260 [RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, 1261 May 1997, . 1263 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1264 A., Peterson, J., Sparks, R., Handley, M., and E. 1265 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1266 DOI 10.17487/RFC3261, June 2002, 1267 . 1269 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1270 DOI 10.17487/RFC3688, January 2004, 1271 . 1273 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1274 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1275 . 1277 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1278 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1279 July 2006, . 1281 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1282 Protocol (SDP) Label Attribute", RFC 4574, 1283 DOI 10.17487/RFC4574, August 2006, 1284 . 1286 [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description 1287 Protocol (SDP) Content Attribute", RFC 4796, 1288 DOI 10.17487/RFC4796, February 2007, 1289 . 1291 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1292 "Indicating User Agent Capabilities in the Session 1293 Initiation Protocol (SIP)", RFC 3840, 1294 DOI 10.17487/RFC3840, August 2004, 1295 . 1297 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1298 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1299 DOI 10.17487/RFC4122, July 2005, 1300 . 1302 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1303 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1304 . 1306 [I-D.ietf-insipid-session-id] 1307 Jones, P., Salgueiro, G., and C. Pearce, "End-to-End 1308 Session Identification in IP-Based Multimedia 1309 Communication Networks", draft-ietf-insipid-session-id-16 1310 (work in progress), October 2015. 1312 13.2. Informative References 1314 [RFC6341] Rehor, K., Ed., Portman, L., Ed., Hutton, A., and R. Jain, 1315 "Use Cases and Requirements for SIP-Based Media Recording 1316 (SIPREC)", RFC 6341, DOI 10.17487/RFC6341, August 2011, 1317 . 1319 [RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor, 1320 "An Architecture for Media Recording Using the Session 1321 Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May 1322 2014, . 1324 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1325 DOI 10.17487/RFC2648, August 1999, 1326 . 1328 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 1329 Header Field for the Session Initiation Protocol (SIP)", 1330 RFC 3326, DOI 10.17487/RFC3326, December 2002, 1331 . 1333 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1334 Extensions to the Session Initiation Protocol (SIP) for 1335 Asserted Identity within Trusted Networks", RFC 3325, 1336 DOI 10.17487/RFC3325, November 2002, 1337 . 1339 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, Ed., "An 1340 INVITE-Initiated Dialog Event Package for the Session 1341 Initiation Protocol (SIP)", RFC 4235, 1342 DOI 10.17487/RFC4235, November 2005, 1343 . 1345 Authors' Addresses 1347 Ram Mohan Ravindranath 1348 Cisco Systems 1349 Cessna Business Park 1350 Bangalore, Karnataka 1351 India 1353 Email: rmohanr@cisco.com 1354 Parthasarathi Ravindran 1355 Nokia Networks 1356 Bangalore, Karnataka 1357 India 1359 Email: partha@parthasarathi.co.in 1361 Paul Kyzivat 1362 Huawei 1363 Hudson, MA 1364 USA 1366 Email: pkyzivat@alum.mit.edu