idnits 2.17.1 draft-ietf-siprec-metadata-18.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 5 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 (August 12, 2015) is 3173 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-14 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: February 13, 2016 Nokia Networks 6 Paul. Kyzivat 7 Huawei 8 August 12, 2015 10 Session Initiation Protocol (SIP) Recording Metadata 11 draft-ietf-siprec-metadata-18 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 February 13, 2016. 41 Copyright Notice 43 Copyright (c) 2015 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.1.3. XML element . . . . . . . . . . . . . . . . . . . . . 8 71 6.2. Communication Session Group . . . . . . . . . . . . . . . 8 72 6.2.1. Attributes . . . . . . . . . . . . . . . . . . . . . 9 73 6.2.2. Linkages . . . . . . . . . . . . . . . . . . . . . . 9 74 6.2.3. XML element . . . . . . . . . . . . . . . . . . . . . 10 75 6.3. Communication Session . . . . . . . . . . . . . . . . . . 10 76 6.3.1. Attributes . . . . . . . . . . . . . . . . . . . . . 11 77 6.3.2. Linkages . . . . . . . . . . . . . . . . . . . . . . 11 78 6.3.3. XML element . . . . . . . . . . . . . . . . . . . . . 12 79 6.4. CSRSAssociation . . . . . . . . . . . . . . . . . . . . . 13 80 6.4.1. Attributes . . . . . . . . . . . . . . . . . . . . . 13 81 6.4.2. Linkages . . . . . . . . . . . . . . . . . . . . . . 14 82 6.4.3. XML element . . . . . . . . . . . . . . . . . . . . . 14 83 6.5. Participant . . . . . . . . . . . . . . . . . . . . . . . 14 84 6.5.1. Attributes . . . . . . . . . . . . . . . . . . . . . 14 85 6.5.2. Linkages . . . . . . . . . . . . . . . . . . . . . . 15 86 6.5.3. XML element . . . . . . . . . . . . . . . . . . . . . 15 87 6.6. ParticipantCSAssociation . . . . . . . . . . . . . . . . 16 88 6.6.1. Attributes . . . . . . . . . . . . . . . . . . . . . 16 89 6.6.2. Linkages . . . . . . . . . . . . . . . . . . . . . . 17 90 6.6.3. XML element . . . . . . . . . . . . . . . . . . . . . 17 91 6.7. Media Stream . . . . . . . . . . . . . . . . . . . . . . 17 92 6.7.1. Attributes . . . . . . . . . . . . . . . . . . . . . 17 93 6.7.2. Linkages . . . . . . . . . . . . . . . . . . . . . . 18 94 6.7.3. XML element . . . . . . . . . . . . . . . . . . . . . 18 95 6.8. ParticipantStream Association . . . . . . . . . . . . . . 18 96 6.8.1. Attributes . . . . . . . . . . . . . . . . . . . . . 19 97 6.8.2. Linkages . . . . . . . . . . . . . . . . . . . . . . 19 98 6.8.3. XML element . . . . . . . . . . . . . . . . . . . . . 19 99 6.9. associate-time/disassociate-time . . . . . . . . . . . . 20 100 6.10. Unique ID format . . . . . . . . . . . . . . . . . . . . 20 101 6.11. Metadata version Indicator . . . . . . . . . . . . . . . 20 102 7. Recording Metadata snapshot Request format . . . . . . . . . 20 103 8. SIP Recording Metadata Example . . . . . . . . . . . . . . . 21 104 8.1. Complete SIP Recording Metadata Example . . . . . . . . . 21 105 8.2. Partial Update of Recording metadata XML body . . . . . . 23 106 9. XML Schema definition for Recording metadata . . . . . . . . 23 107 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 108 10.1. Connection Security . . . . . . . . . . . . . . . . . . 28 109 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 110 11.1. SIP recording metadata Schema Registration . . . . . . . 28 111 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 29 112 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 113 13.1. Normative References . . . . . . . . . . . . . . . . . . 29 114 13.2. Informative References . . . . . . . . . . . . . . . . . 30 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 117 1. Introduction 119 Session recording is a critical requirement in many communications 120 environments such as call centers and financial trading. In some of 121 these environments, all calls must be recorded for regulatory, 122 compliance, and consumer protection reasons. Recording of a session 123 is typically performed by sending a copy of a media stream to a 124 recording device. This document focuses on the Recording metadata 125 which describes the communication session. The document describes a 126 metadata model as viewed by Session Recording Server and the 127 Recording metadata format, the requirements for which are described 128 in [RFC6341] and the architecture for which is described in 129 [RFC7245]. 131 2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. This 136 document only uses these key words when referencing normative 137 statements in existing RFCs." 139 3. Definitions 141 Metadata Model: An abstract representation of metadata using a 142 Unified Modelling Language(UML) class diagram. 144 Metadata classes: Each block in the model represents a class. A 145 class is a construct that is used as a blueprint to create 146 instances(called objects) of itself. The description of each class 147 also has representation of its attributes in a second compartment 148 below the class name. 150 Attributes: Attributes represent the elements listed in each of the 151 classes. The attributes of a class are listed in the second 152 compartment below the class name. Each instance of class conveys 153 values for these attributes which adds to the recording's Metadata. 155 Linkages: Linkages represent the relationship between the classes in 156 the model. Each represents a logical connection between classes(or 157 objects) in class diagrams/ object diagrams. The linkages used in 158 the Metadata model of this document are associations. 160 4. Metadata Model 162 Metadata is the information that describes recorded media and the CS 163 to which they relate. The diagram below shows a model for Metadata 164 as viewed by a Session Recording Server (SRS). 166 +-------------------------------+ 167 | Recording Session (RS) | 168 +-------------------------------+ 169 |1..* | 1..* 170 | | 171 | | 0..* 172 | +-----------------+ 173 +------------+ | | Communication | 174 | CSRS | | | Session (CS) | 175 | Association|--+ | Group | 176 | | | +-----------------+ 177 +------------+ | | 0..1 178 | | 179 |0..* | 1..* 180 +-------------------------------+ 181 | Communication Session (CS) | 182 | | 183 +-------------------------------+ 184 | 1..* |0..1 185 +-----+ | 186 | | 0..* |0..* 187 | +-------------+ receives +----------------+ 188 | | Participant |----------| Media Streams | 189 | | |0..* 0..*| | 190 | | | | | 191 | | | | | 192 | | | sends | | 193 | | |----------| | 194 | | |1.* 0..*| | 195 | +-------------+ +----------------+ 196 | | | 197 | | | 198 | +------------------------+------------+ 199 | | 200 | | 201 | +------------------+ +----------------------+ 202 | |ParticipantCS | | ParticipantStream | 203 +-----------| Association | | Association | 204 | | | | 205 +------------------+ +----------------------+ 207 The Metadata model is a class diagram in Unified Modelling 208 Language(UML). The model describes the structure of a metadata in 209 general by showing the classes, their attributes, and the 210 relationships among the classes. Each block in the model above 211 represents a class. The linkages between the classes represents the 212 relationships which can be associations or Composition. The metadata 213 is conveyed from SRC to SRS. 215 The model allows the capture of a snapshot of a recording's Metadata 216 at a given instant in time. Metadata changes to reflect changes in 217 what is being recorded. For example, if a participant joins a 218 conference, then the SRC sends the SRS a snapshot of metadata having 219 that participant information (with attributes like name/AoR pair and 220 associate-time.) 222 Some of the metadata is not required to be conveyed explicitly from 223 the SRC to the SRS, if it can be obtained contextually by the 224 SRS(e.g., from SIP or SDP signalling). 226 5. Recording Metadata Format 228 This section gives an overview of the Recording Metadata Format. 229 Some data from the metadata model is assumed to be made available to 230 the SRS through Session Description Protocol (SDP)[RFC4566], and 231 therefore this data is not represented in the XML document format 232 specified in this document. SDP attributes describe different media 233 formats like audio, video. The other metadata attributes, such as 234 participant details, are represented in a new Recording specific XML 235 document of type 'application/rs-metadata+xml'. The SDP label 236 attribute [RFC4574] provides an identifier by which a metadata XML 237 document can refer to a specific media description in the SDP sent 238 from the SRC to the SRS. 240 The XML document format can be used to represent either the complete 241 metadata or a partial update to the metadata. The latter includes 242 only elements that have changed compared to the previously reported 243 metadata. 245 5.1. XML data format 247 Every recording metadata XML document MUST contain a 248 element. The element acts as a container for all other 249 elements in this XML document. 251 A recording object is a XML document. It MUST have the XML 252 declaration and it SHOULD contain an encoding declaration in the XML 253 declaration, e.g., "". If the 254 charset parameter of the MIME content type declaration is present and 255 it is different from the encoding declaration, the charset parameter 256 takes precedence. 258 Every application conforming to this specification MUST accept the 259 UTF-8 character encoding to ensure the minimal interoperability. 261 Syntax and semantic errors in an XML document should be reported to 262 the originator using application specific mechanisms. 264 5.1.1. Namespace 266 The namespace URI for elements defined by this specification is a 267 Uniform Resource Namespace (URN) [RFC2141], using the namespace 268 identifier 'ietf' defined by [RFC2648] and extended by [RFC3688]. 270 The URN is: urn:ietf:params:xml:ns:recording 272 5.1.2. recording 274 The element MUST contain an xmlns namespace attribute 275 with value as urn:ietf:params:xml:ns:recording. One recording 276 element MUST be present in every recording metadata XML document. 278 A recording element MAY contain a element indicating 279 whether the XML document is a complete document or a partial update. 280 If no element is present then the default value is 281 "complete". 283 6. Recording Metadata classes 285 This section describes each class of the metadata model, and the 286 attributes of each class. This section also describes how different 287 classes are linked and the XML element for each of them. 289 6.1. Recording Session 291 +-------------------------------+ 292 | Recording Session (RS) | 293 +-------------------------------+ 294 | | 295 | Start/End Time | 296 | | 297 | | 298 | | 299 +-------------------------------+ 300 |1..* | 1..* 301 | | 302 |0..* | 0..* 303 Communication Communication 304 Session Session Group(CS Group) 306 Each instance of a Recording Session class (namely the Recording 307 Session Object) represents a SIP session created between an SRC and 308 SRS for the purpose of recording a Communication Session. 310 6.1.1. Attributes 312 A Recording Session class has the following attributes: 314 o Start/End Time - Represents the Start/End time of a Recording 315 Session object. 317 6.1.2. Linkages 319 Each instance of Recording Session has: 321 o Zero or more instances of Communication Session Group (CSG). 323 o Zero or more instances of Communication Session objects. 325 CSs and CSGs are optional to accommodate persistent recording, where 326 there may sometimes be none. 328 6.1.3. XML element 330 A Recording Session object is represented by a XML 331 element. That in turn relies on the SIP/SDP session with which the 332 XML document is associated to provide some of the attributes of the 333 Recording Session element. 335 Start and End time value are derivable from Date header(if present in 336 SIP message) in RS. In cases where Date header is not present, 337 Start/End time are derivable from the time at which SRS receives the 338 notification of SIP message to setup RS / disconnect RS. 340 6.2. Communication Session Group 341 Recording Session (RS) 342 | 1..* 343 | 344 | 0..* 345 +-------------------------------+ 346 | Communication Session | 347 | Group | 348 +-------------------------------+ 349 | Unique-ID | 350 | associate-time | 351 | disassociate-time | 352 | | 353 +-------------------------------+ 354 | 0..1 355 | 356 | 1..* 357 Communication Session (CS) 359 One instance of a Communication Session Group class (namely the 360 Communication Session Group object) provides association or linking 361 of Communication Sessions. 363 6.2.1. Attributes 365 A CS Group has the following attributes: 367 o Unique-ID - This Unique-ID is to group different CSs that are 368 related. SRC (or SRS) is responsible for ensuring the uniqueness 369 of Unique-ID in case multiple SRC interacts with the same SRS. 370 The mechanism by which SRC groups the CS is outside the scope of 371 SIPREC. 373 o Associate-time - Associate-time for CS-Group shall be calculated 374 by SRC as the time when a grouping is formed. The rules that 375 determine how a grouping of different Communication Session 376 objects is done by SRC is outside the scope of SIPREC. 378 o Disassociate-time - Disassociate-time for CS-Group shall be 379 calculated by SRC as the time when the grouping ends 381 6.2.2. Linkages 383 The linkages between Communication Session Group class and other 384 classes are associations. A communication Session Group is 385 associated with RS and CS in the following manner: 387 o There are one or more Recording Session objects per Communication 388 Session Group. 390 o Each Communication Session Group object has to be associated with 391 one or more RS [Here each RS can be setup by the potentially 392 different SRCs] 394 o There are one or more Communication Sessions per CS Group [e.g. 395 Consult Transfer] 397 6.2.3. XML element 399 The element is an optional element provides the information 400 about the communication session group 402 Each communication session group (CSG)object is represented using one 403 group element. Each element has a unique 'group-id' 404 attribute which uniquely identifies the CSG. 406 6.3. Communication Session 408 Recording Communication 409 Session Session Group(CS Group) 410 |1..* | 0..1 411 | | 412 |0..* | 1..* 413 +-------------------------------+ 414 | Communication Session (CS) | 415 | | 416 +-------------------------------+ 417 | CS Identifier | 418 | sip Session-ID | 419 | Termination Reason | 420 | Start-time | 421 | Stop-time | 422 +-------------------------------+ 423 | | 424 | 0..* |0..1 425 | | 426 | 0..* |0..* 427 Participant Media Stream 428 A Communication Session class and its object in the metadata model 429 represents a Communication Session and its properties needed as seen 430 by the SRC. 432 6.3.1. Attributes 434 A communication Session class has the following attributes: 436 o Termination Reason - This represents the reason why a CS was 437 terminated. The communication session MAY contain a Call 438 Termination Reason. This MAY be derived from SIP Reason header 439 [RFC3326] of CS. 441 o CS Identifier - This attribute is used to uniquely identify a CS. 443 o sip Session-ID - This attribute carries sip Session-ID defined in 444 [I-D.ietf-insipid-session-id]. 446 o Start-time - This optional attribute represents start time of CS 447 as seen by SRC 449 o Stop-time - This optional attribute represents stop time of CS as 450 seen by SRC 452 This document does not specify attributes relating to what should 453 happen to a recording of a CS after it has been delivered to the SRS. 454 (E.g., how long to retain the recording, what access controls to 455 apply.) The SRS is assumed to behave in accordance with policy. The 456 ability for the SRC to influence this policy is outside the scope of 457 this document. However if there are implementations where SRC has 458 enough information, this could be sent as Extension Data attached to 459 the CS 461 6.3.2. Linkages 463 A Communication Session is linked to CS-Group, Participant, Media 464 Stream and Recording Session classes using the association 465 relationship. Association between CS and Participant allows: 467 o CS to have zero or more participants 469 o Participant is associated with zero or more CSs. This includes 470 participants who are not directly part of any CS. An example of 471 such a case is participants in a premixed media stream. The SRC 472 may have knowledge of such Participants, yet not have any 473 signaling relationship with them. This might arise if one 474 participant in CS is a conference focus. To summarize, even if 475 the SRC does not have direct signalling relationships with all 476 participants in a CS, it should nevertheless create a Participant 477 object for each participant that it knows about. 479 o The model also allows participants in CS that are not participants 480 in the media. An example is the identity of a 3pcc controller 481 that has initiated a CS to two or more participants of the CS. 482 Another example is the identity of a conference focus. Of course 483 a focus is probably in the media, but since it may only be there 484 as a mixer, it may not report itself as a participant in any of 485 the media streams. 487 Association between CS and Media Stream allows: 489 o A CS to have zero or more Streams 491 o A stream can be associated with at most one CS. Stream in 492 persistent RS is not required to be associated with any CS before 493 CS is created and hence the zero association is allowed. 495 Association between CS and RS allows: 497 o Each instance of RS has Zero or more instances of Communication 498 Session objects. 500 o Each CS has to be associated with one more RS [ Here each RS can 501 be potentially setup by different SRCs] 503 6.3.3. XML element 505 The element provides the information about the 506 Communication Session 508 Each communication session(CS) object is represented by one session 509 element. Each session element has unique 'session_id' attribute 510 which helps to uniquely identify the CS. 512 Each Communication Session (CS) element MAY have zero or more 513 XML elements. More than one sipSession-ID element may 514 be present in a session element for Conference flows. For e.g., 515 Three participants A, B and C are in conference that has a Focus(F) 516 acting as SRC. The metadata sent from SRC to SRS will likely have 517 three sipSession-Id elements that correspond to the SIP dialog's the 518 Focus has with each of the three participants. 520 The sipSessionID XML element MUST follow the ABNF format of session- 521 id-value defined in section 5 of [I-D.ietf-insipid-session-id]. If 522 there are changes in CS, the same will be indicated in the metadata 523 snapshot from SRC to SRS and this MAY include any sipSessionID 524 changes as well. For e.g., Assume A and B are two participants in a 525 CS having a B2BUA acting as SRC. The SRC (B2BUA) reports the session 526 id snapshot as A;remote=B at time t1 to SRS. At a later time if 527 there is transfer in the same CS and B drops and C joins, then the 528 SRC(B2BUA) reports the session id as A;remote=C at time t2 to SRS. 530 The XML element MAY be included in metadata to represent a 531 CS Termination Reason. There MAY be multiple instances of the XML 532 element inside a session element. The XML element 533 has 'protocol' as an attribute, which indicates the protocol from 534 which the reason string is derived. The default value for protocol 535 attribute is "SIP". The element can be derived from a SIP 536 Reason header in the CS. 538 A element MAY be present to indicate the group to which 539 the enclosing session belongs. 541 6.4. CSRSAssociation 543 1..* 0..* 544 Recording Communication 545 Session ----------+---------- Session 546 | 547 | 548 | 549 +-------------------+ 550 | CSRSAssociation | 551 +-------------------+ 552 | Association-Time | 553 | Disassociaton-Time| 554 +-------------------+ 556 The CSRS Association class describes the association of a CS to an RS 557 for a period of time. A single CS may be associated with different 558 RSs (perhaps by different SRCs) and may be associated and dissociated 559 several times. 561 6.4.1. Attributes 563 CSRS association class has the following attributes: 565 o Associate-time - associate-time is calculated by SRC as the time 566 it sees a CS is associated to a RS 568 o Disassociate-time- Disassociate-time is calculated by SRC as the 569 time it see a CS disassociate from a RS. 571 6.4.2. Linkages 573 CSRS association class is linked to CS and RS classes. 575 6.4.3. XML element 577 The XML element represents the CSRS 578 association object. The 'session_id' attribute is used to uniquely 579 identify this element and link with a specific session. The 580 recording object is implicitly defined by the enclosing 581 element. 583 6.5. Participant 585 Communication Session (CS) 586 | 0..* 587 | 588 | 0..* 589 +-------------------------------+ 590 | Participant | 591 | | 592 +-------------------------------+ 593 | AoR / Name Pair list | 594 | | 595 | | 596 +-------------------------------+ 597 | 0..* 1..*| 598 receives| |sends 599 | 0..* 0..*| 600 Media Stream 602 A Participant class and its objects has information about a device 603 that is part of a CS and/or contributes/consumes media stream(s) 604 belonging to a CS. 606 6.5.1. Attributes 608 Participant has a single defined attribute: 610 o AoR / Name pair list - This attribute is a list of Name/AoR 611 tuples. An AoR MAY be a SIP/SIPS/TEL URI. Name represents 612 Participant name(SIP display name) or dialed number (DN) (when 613 known). Multiple tuples are allowed for cases where a participant 614 has more than one AoR. (For example a P-Asserted-identity header 615 [RFC3325] can have both SIP and TEL URIs.) 617 This document does not specify other attributes relating to 618 participant e.g. Participant Role, Participant type. An SRC which 619 has information of these attributes can indicate the same as part of 620 extension data to Participant from SRC to SRS. 622 6.5.2. Linkages 624 The participant class is linked to MS and CS class using association 625 relationship. The association between participant and Media Stream 626 allows: 628 o Participant to receive zero or more media streams 630 o Participant to send zero or more media streams. (Same participant 631 provides multiple streams e.g. audio and video) 633 o Media stream to be received by zero or more participants. Its 634 possible, though perhaps unlikely, that a stream is generated but 635 sent only to the SRC and SRS, not to any participant. E.g. In 636 conferencing where all participants are on hold and the SRC is 637 collocated with the focus. Also a media stream may be received by 638 multiple participants (e.g. Whisper calls, side conversations). 640 o Media stream to be sent by one or more participants (pre-mixed 641 streams). 643 Example of a case where a participant receives zero or more streams - 644 a supervisor may have side conversation with agent, while agent 645 converses with customer. 647 6.5.3. XML element 649 A element represents a Participant object. 651 Participant MUST have a NameID complex element which contains AoR as 652 attribute and Name as element. AOR element is SIP/SIPS URI FQDN or 653 IP address which represents the user. name is an optional element to 654 represent display name. 656 Each participant has a unique 'participant_id' attribute. This MUST 657 be used for all references to a participant within a CSG, and MAY be 658 used to reference the same participant more globally. (The decision 659 to use a participant_id across multiple CSGs or recording sessions is 660 at the discretion of the implementer.) 662 6.6. ParticipantCSAssociation 664 1..* 0..* 665 Communication 666 Session ----------+---------- Participant 667 | 668 | 669 | 670 +-------------------+ 671 | ParticipantCS | 672 | Association | 673 +-------------------+ 674 | Capabilities | 675 | Association-Time | 676 | Disassociaton-Time| 677 +-------------------+ 679 The Participant CS Association class describes the association of a 680 Participant to an CS for a period of time. A participant may be 681 associated and dissociated from a CS several times. (For example, 682 connecting to a conference, then disconnecting, then connecting 683 again.) 685 6.6.1. Attributes 687 ParticipantCS association class has the following attributes: 689 o Associate-time - associate-time is calculated by SRC as the time 690 it sees a participant is associated to CS 692 o Disassociate-time- Disassociate-time is calculated by the SRC as 693 the time it sees a participant disassociate from a CS. It is 694 possible that a given participant can have multiple associate/ 695 disassociate times within given communication session. 697 o Capabilities - An optional attribute describing the capabilities 698 of a participant in a CS, as defined in [RFC3840]. Each 699 participant may have zero or more capabilities. A participant may 700 use different capabilities depending on the role it plays at a 701 particular instance. For example if a participant moves across 702 different CSs (e.g., due to transfer) or is simultaneously present 703 in different CSs its role may be different and hence the 704 capability used. 706 6.6.2. Linkages 708 The participantCS association class is linked to participant and CS 709 classes. 711 6.6.3. XML element 713 The XML element represents a participantCS 714 association object. The 'participant_id' and 'session_id' attributes 715 are used to uniquely identify this element. 717 NOTE: RFC 4235 encoding shall be used to represent capabilities 718 attribute in XML. 720 6.7. Media Stream 722 Participant 723 | 0..* 1..*| 724 receives| |sends 725 | 0..* 0..*| 726 +-------------------------+ 727 | Media Stream | 728 | | 729 Communication 0..1 0..* +-------------------------+ 730 Session ------------| | 731 | Media Stream Reference | 732 | Content-type | 733 | | 734 +-------------------------+ 736 A Media Stream class (and its objects) has the properties of media as 737 seen by SRC and sent to SRS. Different snapshots of a media stream 738 object may be sent whenever there is a change in media (e.g. 739 direction change like pause/resume and/or codec change and/or 740 participant change.). 742 6.7.1. Attributes 744 A Media Stream class has the the following attributes: 746 o Media Stream Reference - In implementations this references an 747 m-line 749 o Content - The content of an MS element will be described in terms 750 of value from the [RFC4796] registry. 752 The metadata model should include media streams that are not being 753 delivered to the SRS. Examples include cases where SRC offered 754 certain media types but SRS chooses to accept only a subset of them 755 OR an SRC may not even offer a certain media type due it its 756 restrictions to record 758 6.7.2. Linkages 760 A Media Stream is linked to participant and CS classes using the 761 association relationship. The details of association with the 762 Participant are described in the Participant class section. The 763 details of association with CS is mentioned in the CS section. 765 6.7.3. XML element 767 The element represents a Media Stream object. Stream 768 element indicates SDP media lines associated with the session and 769 participants. 771 The