idnits 2.17.1 draft-ietf-siprec-metadata-14.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 16 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 11, 2014) is 3717 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 (-12) exists of draft-ietf-siprec-architecture-11 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPREC Ram Mohan. Ravindranath 2 Internet-Draft Cisco Systems, Inc. 3 Intended status: Standards Track Parthasarathi. Ravindran 4 Expires: August 15, 2014 Nokia Solutions and Networks 5 Paul. Kyzivat 6 Huawei 7 February 11, 2014 9 Session Initiation Protocol (SIP) Recording Metadata 10 draft-ietf-siprec-metadata-14 12 Abstract 14 Session recording is a critical requirement in many communications 15 environments such as call centers and financial trading. In some of 16 these environments, all calls must be recorded for regulatory, 17 compliance, and consumer protection reasons. Recording of a session 18 is typically performed by sending a copy of a media stream to a 19 recording device. This document describes the metadata model as 20 viewed by Session Recording Server(SRS) and the Recording metadata 21 format. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 15, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Metadata Model . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Recording Metadata Format . . . . . . . . . . . . . . . . . . 6 62 5.1. XML data format . . . . . . . . . . . . . . . . . . . . . 6 63 5.1.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 7 64 5.1.2. recording . . . . . . . . . . . . . . . . . . . . . . 7 65 6. Recording Metadata classes . . . . . . . . . . . . . . . . . . 7 66 6.1. Recording Session . . . . . . . . . . . . . . . . . . . . 8 67 6.1.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 8 68 6.1.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 8 69 6.1.3. XML element . . . . . . . . . . . . . . . . . . . . . 8 70 6.2. Communication Session Group . . . . . . . . . . . . . . . 9 71 6.2.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 9 72 6.2.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 9 73 6.2.3. XML element . . . . . . . . . . . . . . . . . . . . . 10 74 6.3. Communication Session . . . . . . . . . . . . . . . . . . 10 75 6.3.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 11 76 6.3.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 11 77 6.3.3. XML element . . . . . . . . . . . . . . . . . . . . . 12 78 6.4. CSRSAssociation . . . . . . . . . . . . . . . . . . . . . 12 79 6.4.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 13 80 6.4.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 13 81 6.4.3. XML element . . . . . . . . . . . . . . . . . . . . . 13 82 6.5. Participant . . . . . . . . . . . . . . . . . . . . . . . 13 83 6.5.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 14 84 6.5.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 14 85 6.5.3. XML element . . . . . . . . . . . . . . . . . . . . . 14 86 6.6. ParticipantCSAssociation . . . . . . . . . . . . . . . . . 15 87 6.6.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 15 88 6.6.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 16 89 6.6.3. XML element . . . . . . . . . . . . . . . . . . . . . 16 90 6.7. Media Stream . . . . . . . . . . . . . . . . . . . . . . . 16 91 6.7.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 17 92 6.7.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 17 93 6.7.3. XML element . . . . . . . . . . . . . . . . . . . . . 17 94 6.8. ParticipantStream Association . . . . . . . . . . . . . . 18 95 6.8.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 18 96 6.8.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 18 97 6.8.3. XML element . . . . . . . . . . . . . . . . . . . . . 19 98 6.9. associate-time/disassociate-time . . . . . . . . . . . . . 19 99 6.10. Unique ID format . . . . . . . . . . . . . . . . . . . . . 19 100 6.11. Metadata version Indicator . . . . . . . . . . . . . . . . 19 101 7. SIP Recording Metadata Example . . . . . . . . . . . . . . . . 20 102 7.1. Complete SIP Recording Metadata Example . . . . . . . . . 20 103 7.2. Partial Update of Recording metadata XML body . . . . . . 22 104 8. XML Schema definition for Recording metadata . . . . . . . . . 22 105 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 106 9.1. Connection Security . . . . . . . . . . . . . . . . . . . 26 107 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 108 10.1. SIP recording metadata Schema Registration . . . . . . . . 27 109 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 27 110 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 111 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 112 12.2. Informative References . . . . . . . . . . . . . . . . . . 29 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 115 1. Introduction 117 Session recording is a critical requirement in many communications 118 environments such as call centers and financial trading. In some of 119 these environments, all calls must be recorded for regulatory, 120 compliance, and consumer protection reasons. Recording of a session 121 is typically performed by sending a copy of a media stream to a 122 recording device. This document focuses on the Recording metadata 123 which describes the communication session. The document describes a 124 metadata model as viewed by Session Recording Server and the 125 Recording metadata format, the requirements for which are described 126 in [RFC6341] and the architecture for which is described in 127 [I-D.ietf-siprec-architecture]. 129 2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. This 134 document only uses these key words when referencing normative 135 statements in existing RFCs." 137 3. Definitions 139 Metadata Model: An abstract representation of metadata using a 140 Unified Modelling Language(UML) class diagram. 142 Metadata classes: Each block in the model represents a class. A 143 class is a construct that is used as a blueprint to create 144 instances(called objects) of itself. The description of each class 145 also has representation of its attributes in a second compartment 146 below the class name. 148 Attributes: Attributes represent the elements listed in each of the 149 classes. The attributes of a class are listed in the second 150 compartment below the class name. Each instance of class conveys 151 values for these attributes which adds to the recording's Metadata. 153 Linkages: Linkages represent the relationship between the classes in 154 the model. Each represents a logical connection between classes(or 155 objects) in class diagrams/ object diagrams. The linkages used in 156 the Metadata model of this document are associations. 158 4. Metadata Model 160 Metadata is the information that describes recorded media and the CS 161 to which they relate. The diagram below shows a model for Metadata 162 as viewed by a Session Recording Server (SRS). 164 +-------------------------------+ 165 | Recording Session (RS) | 166 +-------------------------------+ 167 |1..* | 1..* 168 | | 169 | | 0..* 170 | +-----------------+ 171 +------------+ | | Communication | 172 | CSRS | | | Session (CS) | 173 | Association|--+ | Group | 174 | | | +-----------------+ 175 +------------+ | | 0..1 176 | | 177 |0..* | 1..* 178 +-------------------------------+ 179 | Communication Session (CS) | 180 | | 181 +-------------------------------+ 182 | 1..* |0..1 183 +-----+ | 184 | | 0..* |0..* 185 | +-------------+ receives +----------------+ 186 | | Participant |----------| Media Streams | 187 | | |0..* 0..*| | 188 | | | | | 189 | | | | | 190 | | | sends | | 191 | | |----------| | 192 | | |1.* 0..*| | 193 | +-------------+ +----------------+ 194 | | | 195 | | | 196 | +------------------------+------------+ 197 | | 198 | | 199 | +------------------+ +----------------------+ 200 | |ParticipantCS | | ParticipantStream | 201 +-----------| Association | | Association | 202 | | | | 203 +------------------+ +----------------------+ 205 The Metadata model is a class diagram in Unified Modelling 206 Language(UML). The model describes the structure of a metadata in 207 general by showing the classes, their attributes, and the 208 relationships among the classes. Each block in the model above 209 represents a class. The linkages between the classes represents the 210 relationships which can be associations or Composition. The metadata 211 is conveyed from SRC to SRS. 213 The model allows the capture of a snapshot of a recording's Metadata 214 at a given instant in time. Metadata changes to reflect changes in 215 what is being recorded. For example, if a participant joins a 216 conference, then the SRC sends the SRS a snapshot of metadata having 217 that participant information (with attributes like name/AoR pair and 218 associate-time.) 220 Some of the metadata is not required to be conveyed explicitly from 221 the SRC to the SRS, if it can be obtained contextually by the 222 SRS(e.g., from SIP or SDP signalling). 224 5. Recording Metadata Format 226 This section gives an overview of the Recording Metadata Format. 227 Some data from the metadata model is assumed to be made available to 228 the SRS through Session Description Protocol (SDP)[RFC4566], and 229 therefore this data is not represented in the XML document format 230 specified in this document. SDP attributes describe different media 231 formats like audio, video. The other metadata attributes, such as 232 participant details, are represented in a new Recording specific XML 233 document of type 'application/rs-metadata+xml'. The SDP label 234 attribute [RFC4574] provides an identifier by which a metadata XML 235 document can refer to a specific media description in the SDP sent 236 from the SRC to the SRS. 238 The XML document format can be used to represent either the complete 239 metadata or a partial update to the metadata. The latter includes 240 only elements that have changed compared to the previously reported 241 metadata. 243 5.1. XML data format 245 Every recording metadata XML document MUST contain a 246 element. The element acts as a container for all other 247 elements in this XML document. 249 A recording object is a XML document. It MUST have the XML 250 declaration and it SHOULD contain an encoding declaration in the XML 251 declaration, e.g., "". If the 252 charset parameter of the MIME content type declaration is present and 253 it is different from the encoding declaration, the charset parameter 254 takes precedence. 256 Every application conforming to this specification MUST accept the 257 UTF-8 character encoding to ensure the minimal interoperability. 259 Syntax and semantic errors in an XML document should be reported to 260 the originator using application specific mechanisms. 262 5.1.1. Namespace 264 The namespace URI for elements defined by this specification is a 265 Uniform Resource Namespace (URN) [RFC2141], using the namespace 266 identifier 'ietf' defined by [RFC2648] and extended by [RFC3688]. 268 The URN is: urn:ietf:params:xml:ns:recording 270 5.1.2. recording 272 The element MUST contain an xmlns namespace attribute 273 with value as urn:ietf:params:xml:ns:recording. One recording 274 element MUST be present in every recording metadata XML document. 276 A recording element MAY contain a element indicating 277 whether the XML document is a complete document or a partial update. 278 If no element is present then the default value is 279 "complete". 281 6. Recording Metadata classes 283 This section describes each class of the metadata model, and the 284 attributes of each class. This section also describes how different 285 classes are linked and the XML element for each of them. 287 6.1. Recording Session 289 +-------------------------------+ 290 | Recording Session (RS) | 291 +-------------------------------+ 292 | | 293 | Start/End Time | 294 | | 295 | | 296 | | 297 +-------------------------------+ 298 |1..* | 1..* 299 | | 300 |0..* | 0..* 301 Communication Communication 302 Session Session Group(CS Group) 304 Each instance of a Recording Session class (namely the Recording 305 Session Object) represents a SIP session created between an SRC and 306 SRS for the purpose of recording a Communication Session. 308 6.1.1. Attributes 310 A Recording Session class has the following attributes: 311 o Start/End Time - Represents the Start/End time of a Recording 312 Session object. 314 6.1.2. Linkages 316 Each instance of Recording Session has: 318 o Zero or more instances of Communication Session Group (CSG). 319 o Zero or more instances of Communication Session objects. 321 CSs and CSGs are optional to accommodate persistent recording, where 322 there may sometimes be none. 324 6.1.3. XML element 326 A Recording Session object is represented by a XML 327 element. That in turn relies on the SIP/SDP session with which the 328 XML document is associated to provide some of the attributes of the 329 Recording Session element. 331 Start and End time value are derivable from Date header(if present in 332 SIP message) in RS. In cases where Date header is not present, 333 Start/End time are derivable from the time at which SRS receives the 334 notification of SIP message to setup RS / disconnect RS. 336 6.2. Communication Session Group 338 Recording Session (RS) 339 | 1..* 340 | 341 | 0..* 342 +-------------------------------+ 343 | Communication Session | 344 | Group | 345 +-------------------------------+ 346 | Unique-ID | 347 | associate-time | 348 | disassociate-time | 349 | | 350 +-------------------------------+ 351 | 0..1 352 | 353 | 1..* 354 Communication Session (CS) 356 One instance of a Communication Session Group class (namely the 357 Communication Session Group object) provides association or linking 358 of Communication Sessions. 360 6.2.1. Attributes 362 A CS Group has the following attributes: 363 o Unique-ID - This Unique-ID is to group different CSs that are 364 related. SRC (or SRS) is responsible for ensuring the uniqueness 365 of Unique-ID in case multiple SRC interacts with the same SRS. 366 The mechanism by which SRC groups the CS is outside the scope of 367 SIPREC. 368 o Associate-time - Associate-time for CS-Group shall be calculated 369 by SRC as the time when a grouping is formed. The rules that 370 determine how a grouping of different Communication Session 371 objects is done by SRC is outside the scope of SIPREC. 372 o Disassociate-time - Disassociate-time for CS-Group shall be 373 calculated by SRC as the time when the grouping ends 375 6.2.2. Linkages 377 The linkages between Communication Session Group class and other 378 classes are associations. A communication Session Group is 379 associated with RS and CS in the following manner: 381 o There are one or more Recording Session objects per Communication 382 Session Group. 383 o Each Communication Session Group object has to be associated with 384 one or more RS [Here each RS can be setup by the potentially 385 different SRCs] 386 o There are one or more Communication Sessions per CS Group [e.g. 387 Consult Transfer] 389 6.2.3. XML element 391 The element is an optional element provides the information 392 about the communication session group 394 Each communication session group (CSG)object is represented using one 395 group element. Each element has a unique 'group-id' 396 attribute which uniquely identifies the CSG. 398 6.3. Communication Session 400 Recording Communication 401 Session Session Group(CS Group) 402 |1..* | 0..1 403 | | 404 |0..* | 1..* 405 +-------------------------------+ 406 | Communication Session (CS) | 407 | | 408 +-------------------------------+ 409 | CS Identifier | 410 | Termination Reason | 411 | Start-time | 412 | Stop-time | 413 +-------------------------------+ 414 | | 415 | 0..* |0..1 416 | | 417 | 0..* |0..* 418 Participant Media Stream 420 A Communication Session class and its object in the metadata model 421 represents a Communication Session and its properties needed as seen 422 by the SRC. 424 6.3.1. Attributes 426 A communication Session class has the following attributes: 428 o Termination Reason - This represents the reason why a CS was 429 terminated. The communication session MAY contain a Call 430 Termination Reason. This MAY be derived from SIP Reason header 431 [RFC3326] of CS. 432 o CS Identifier - This attribute is used to uniquely identify a CS. 433 o Start-time - This optional attribute represents start time of CS 434 as seen by SRC 435 o Stop-time - This optional attribute represents stop time of CS as 436 seen by SRC 438 This document does not specify attributes relating to what should 439 happen to a recording of a CS after it has been delivered to the SRS. 440 (E.g., how long to retain the recording, what access controls to 441 apply.) The SRS is assumed to behave in accordance with policy. The 442 ability for the SRC to influence this policy is outside the scope of 443 this document. However if there are implementations where SRC has 444 enough information, this could be sent as Extension Data attached to 445 the CS 447 6.3.2. Linkages 449 A Communication Session is linked to CS-Group, Participant, Media 450 Stream and Recording Session classes using the association 451 relationship. Association between CS and Participant allows: 453 o CS to have zero or more participants 454 o Participant is associated with zero or more CSs. This includes 455 participants who are not directly part of any CS. An example of 456 such a case is participants in a premixed media stream. The SRC 457 may have knowledge of such Participants, yet not have any 458 signaling relationship with them. This might arise if one 459 participant in CS is a conference focus. To summarize, even if 460 the SRC does not have direct signalling relationships with all 461 participants in a CS, it should nevertheless create a Participant 462 object for each participant that it knows about. 463 o The model also allows participants in CS that are not participants 464 in the media. An example is the identity of a 3pcc controller 465 that has initiated a CS to two or more participants of the CS. 466 Another example is the identity of a conference focus. Of course 467 a focus is probably in the media, but since it may only be there 468 as a mixer, it may not report itself as a participant in any of 469 the media streams. 471 Association between CS and Media Stream allows: 473 o A CS to have zero or more Streams 474 o A stream can be associated with at most one CS. Stream in 475 persistent RS is not required to be associated with any CS before 476 CS is created and hence the zero association is allowed. 478 Association between CS and RS allows: 480 o Each instance of RS has Zero or more instances of Communication 481 Session objects. 482 o Each CS has to be associated with one more RS [ Here each RS can 483 be potentially setup by different SRCs] 485 6.3.3. XML element 487 The element provides the information about the 488 Communication Session 490 Each communication session(CS) object is represented by one session 491 element. Each session element has unique 'session_id' attribute 492 which helps to uniquely identify the CS. 494 The XML element MAY be included in metadata to represent a 495 CS Termination Reason. There MAY be multiple instances of the XML 496 element inside a session element. The XML element 497 has 'protocol' as an attribute, which indicates the protocol from 498 which the reason string is derived. The default value for protocol 499 attribute is "SIP". The element can be derived from a SIP 500 Reason header in the CS. 502 A element MAY be present to indicate the group to which 503 the enclosing session belongs. 505 6.4. CSRSAssociation 507 1..* 0..* 508 Recording Communication 509 Session ----------+---------- Session 510 | 511 | 512 | 513 +-------------------+ 514 | CSRSAssociation | 515 +-------------------+ 516 | Association-Time | 517 | Disassociaton-Time| 518 +-------------------+ 520 The CSRS Association class describes the association of a CS to an RS 521 for a period of time. A single CS may be associated with different 522 RSs (perhaps by different SRCs) and may be associated and dissociated 523 several times. 525 6.4.1. Attributes 527 CSRS association class has the following attributes: 529 o Associate-time - associate-time is calculated by SRC as the time 530 it sees a CS is associated to a RS 531 o Disassociate-time- Disassociate-time is calculated by SRC as the 532 time it see a CS disassociate from a RS. 534 6.4.2. Linkages 536 CSRS association class is linked to CS and RS classes. 538 6.4.3. XML element 540 The XML element represents the CSRS 541 association object. The 'session_id' attribute is used to uniquely 542 identify this element and link with a specific session. The 543 recording object is implicitly defined by the enclosing 544 element. 546 6.5. Participant 548 Communication Session (CS) 549 | 0..* 550 | 551 | 0..* 552 +-------------------------------+ 553 | Participant | 554 | | 555 +-------------------------------+ 556 | AoR / Name Pair list | 557 | | 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 6.5.1. Attributes 571 Participant has a single defined attribute: 573 o AoR / Name pair list - This attribute is a list of Name/AoR 574 tuples. An AoR MAY be a SIP/SIPS/TEL URI. Name represents 575 Participant name(SIP display name) or dialed number (DN) (when 576 known). Multiple tuples are allowed for cases where a participant 577 has more than one AoR. (For example a P-Asserted-identity header 578 [RFC3325] can have both SIP and TEL URIs.) 580 This document does not specify other attributes relating to 581 participant e.g. Participant Role, Participant type. An SRC which 582 has information of these attributes can indicate the same as part of 583 extension data to Participant from SRC to SRS. 585 6.5.2. Linkages 587 The participant class is linked to MS and CS class using association 588 relationship. The association between participant and Media Stream 589 allows: 591 o Participant to receive zero or more media streams 592 o Participant to send zero or more media streams. (Same participant 593 provides multiple streams e.g. audio and video) 594 o Media stream to be received by zero or more participants. Its 595 possible, though perhaps unlikely, that a stream is generated but 596 sent only to the SRC and SRS, not to any participant. E.g. In 597 conferencing where all participants are on hold and the SRC is 598 collocated with the focus. Also a media stream may be received by 599 multiple participants (e.g. Whisper calls, side conversations). 600 o Media stream to be sent by one or more participants (pre-mixed 601 streams). 603 Example of a case where a participant receives zero or more streams - 604 a supervisor may have side conversation with agent, while agent 605 converses with customer. 607 6.5.3. XML element 609 A element represents a Participant object. 611 Participant MUST have a NameID complex element which contains AoR as 612 attribute and Name as element. AOR element is SIP/SIPS URI FQDN or 613 IP address which represents the user. name is an optional element to 614 represent display name. 616 Each participant has a unique 'participant_id' attribute. This MUST 617 be used for all references to a participant within a CSG, and MAY be 618 used to reference the same participant more globally. (The decision 619 to use a participant_id across multiple CSGs or recording sessions is 620 at the discretion of the implementer.) 622 6.6. ParticipantCSAssociation 624 1..* 0..* 625 Communication 626 Session ----------+---------- Participant 627 | 628 | 629 | 630 +-------------------+ 631 | ParticipantCS | 632 | Association | 633 +-------------------+ 634 | Capabilities | 635 | Association-Time | 636 | Disassociaton-Time| 637 +-------------------+ 639 The Participant CS Association class describes the association of a 640 Participant to an CS for a period of time. A participant may be 641 associated and dissociated from a CS several times. (For example, 642 connecting to a conference, then disconnecting, then connecting 643 again.) 645 6.6.1. Attributes 647 ParticipantCS association class has the following attributes: 649 o Associate-time - associate-time is calculated by SRC as the time 650 it sees a participant is associated to CS 651 o Disassociate-time- Disassociate-time is calculated by the SRC as 652 the time it sees a participant disassociate from a CS. It is 653 possible that a given participant can have multiple associate/ 654 disassociate times within given communication session. 655 o Capabilities - An optional attribute describing the capabilities 656 of a participant in a CS, as defined in [RFC3840]. Each 657 participant may have zero or more capabilities. A participant may 658 use different capabilities depending on the role it plays at a 659 particular instance. For example if a participant moves across 660 different CSs (e.g., due to transfer) or is simultaneously present 661 in different CSs its role may be different and hence the 662 capability used. 664 6.6.2. Linkages 666 The participantCS association class is linked to participant and CS 667 classes. 669 6.6.3. XML element 671 The XML element represents a participantCS 672 association object. The 'participant_id' and 'session_id' attributes 673 are used to uniquely identify this element. 675 NOTE: RFC 4235 encoding shall be used to represent capabilities 676 attribute in XML. 678 6.7. Media Stream 680 Participant 681 | 0..* 1..*| 682 receives| |sends 683 | 0..* 0..*| 684 +-------------------------+ 685 | Media Stream | 686 | | 687 Communication 0..1 0..* +-------------------------+ 688 Session ------------| | 689 | Media Stream Reference | 690 | Content-type | 691 | | 692 +-------------------------+ 694 A Media Stream class (and its objects) has the properties of media as 695 seen by SRC and sent to SRS. Different snapshots of a media stream 696 object may be sent whenever there is a change in media (e.g. 697 direction change like pause/resume and/or codec change and/or 698 participant change.). 700 6.7.1. Attributes 702 A Media Stream class has the the following attributes: 704 o Media Stream Reference - In implementations this references an 705 m-line 706 o Content - The content of an MS element will be described in terms 707 of value from the [RFC4796] registry. 709 The metadata model should include media streams that are not being 710 delivered to the SRS. Examples include cases where SRC offered 711 certain media types but SRS chooses to accept only a subset of them 712 OR an SRC may not even offer a certain media type due it its 713 restrictions to record 715 6.7.2. Linkages 717 A Media Stream is linked to participant and CS classes using the 718 association relationship. The details of association with the 719 Participant are described in the Participant class section. The 720 details of association with CS is mentioned in the CS section. 722 6.7.3. XML element 724 The element represents a Media Stream object. Stream 725 element indicates SDP media lines associated with the session and 726 participants. 728 The