idnits 2.17.1 draft-ietf-siprec-metadata-16.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 3 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 7, 2014) is 3549 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) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPREC R. Ravindranath 3 Internet-Draft Cisco 4 Intended status: Standards Track Parthasarathi. Ravindran 5 Expires: February 8, 2015 Nokia Networks 6 Paul. Kyzivat 7 Huawei 8 August 7, 2014 10 Session Initiation Protocol (SIP) Recording Metadata 11 draft-ietf-siprec-metadata-16 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 8, 2015. 41 Copyright Notice 43 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Metadata Model . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . 12 80 6.4.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 13 81 6.4.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 13 82 6.4.3. XML element . . . . . . . . . . . . . . . . . . . . . 13 83 6.5. Participant . . . . . . . . . . . . . . . . . . . . . . . 13 84 6.5.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 14 85 6.5.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 14 86 6.5.3. XML element . . . . . . . . . . . . . . . . . . . . . 14 87 6.6. ParticipantCSAssociation . . . . . . . . . . . . . . . . . 15 88 6.6.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 15 89 6.6.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 16 90 6.6.3. XML element . . . . . . . . . . . . . . . . . . . . . 16 91 6.7. Media Stream . . . . . . . . . . . . . . . . . . . . . . . 16 92 6.7.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 17 93 6.7.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 17 94 6.7.3. XML element . . . . . . . . . . . . . . . . . . . . . 17 95 6.8. ParticipantStream Association . . . . . . . . . . . . . . 18 96 6.8.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 18 97 6.8.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 18 98 6.8.3. XML element . . . . . . . . . . . . . . . . . . . . . 19 99 6.9. associate-time/disassociate-time . . . . . . . . . . . . . 19 100 6.10. Unique ID format . . . . . . . . . . . . . . . . . . . . . 19 101 6.11. Metadata version Indicator . . . . . . . . . . . . . . . . 19 102 7. SIP Recording Metadata Example . . . . . . . . . . . . . . . . 20 103 7.1. Complete SIP Recording Metadata Example . . . . . . . . . 20 104 7.2. Partial Update of Recording metadata XML body . . . . . . 22 105 8. XML Schema definition for Recording metadata . . . . . . . . . 22 106 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 107 9.1. Connection Security . . . . . . . . . . . . . . . . . . . 26 108 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 109 10.1. SIP recording metadata Schema Registration . . . . . . . . 27 110 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 27 111 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 112 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 113 12.2. Informative References . . . . . . . . . . . . . . . . . . 28 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 116 1. Introduction 118 Session recording is a critical requirement in many communications 119 environments such as call centers and financial trading. In some of 120 these environments, all calls must be recorded for regulatory, 121 compliance, and consumer protection reasons. Recording of a session 122 is typically performed by sending a copy of a media stream to a 123 recording device. This document focuses on the Recording metadata 124 which describes the communication session. The document describes a 125 metadata model as viewed by Session Recording Server and the 126 Recording metadata format, the requirements for which are described 127 in [RFC6341] and the architecture for which is described in 128 [RFC7245]. 130 2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. This 135 document only uses these key words when referencing normative 136 statements in existing RFCs." 138 3. Definitions 140 Metadata Model: An abstract representation of metadata using a 141 Unified Modelling Language(UML) class diagram. 143 Metadata classes: Each block in the model represents a class. A 144 class is a construct that is used as a blueprint to create 145 instances(called objects) of itself. The description of each class 146 also has representation of its attributes in a second compartment 147 below the class name. 149 Attributes: Attributes represent the elements listed in each of the 150 classes. The attributes of a class are listed in the second 151 compartment below the class name. Each instance of class conveys 152 values for these attributes which adds to the recording's Metadata. 154 Linkages: Linkages represent the relationship between the classes in 155 the model. Each represents a logical connection between classes(or 156 objects) in class diagrams/ object diagrams. The linkages used in 157 the Metadata model of this document are associations. 159 4. Metadata Model 161 Metadata is the information that describes recorded media and the CS 162 to which they relate. The diagram below shows a model for Metadata 163 as viewed by a Session Recording Server (SRS). 165 +-------------------------------+ 166 | Recording Session (RS) | 167 +-------------------------------+ 168 |1..* | 1..* 169 | | 170 | | 0..* 171 | +-----------------+ 172 +------------+ | | Communication | 173 | CSRS | | | Session (CS) | 174 | Association|--+ | Group | 175 | | | +-----------------+ 176 +------------+ | | 0..1 177 | | 178 |0..* | 1..* 179 +-------------------------------+ 180 | Communication Session (CS) | 181 | | 182 +-------------------------------+ 183 | 1..* |0..1 184 +-----+ | 185 | | 0..* |0..* 186 | +-------------+ receives +----------------+ 187 | | Participant |----------| Media Streams | 188 | | |0..* 0..*| | 189 | | | | | 190 | | | | | 191 | | | sends | | 192 | | |----------| | 193 | | |1.* 0..*| | 194 | +-------------+ +----------------+ 195 | | | 196 | | | 197 | +------------------------+------------+ 198 | | 199 | | 200 | +------------------+ +----------------------+ 201 | |ParticipantCS | | ParticipantStream | 202 +-----------| Association | | Association | 203 | | | | 204 +------------------+ +----------------------+ 206 The Metadata model is a class diagram in Unified Modelling 207 Language(UML). The model describes the structure of a metadata in 208 general by showing the classes, their attributes, and the 209 relationships among the classes. Each block in the model above 210 represents a class. The linkages between the classes represents the 211 relationships which can be associations or Composition. The metadata 212 is conveyed from SRC to SRS. 214 The model allows the capture of a snapshot of a recording's Metadata 215 at a given instant in time. Metadata changes to reflect changes in 216 what is being recorded. For example, if a participant joins a 217 conference, then the SRC sends the SRS a snapshot of metadata having 218 that participant information (with attributes like name/AoR pair and 219 associate-time.) 221 Some of the metadata is not required to be conveyed explicitly from 222 the SRC to the SRS, if it can be obtained contextually by the 223 SRS(e.g., from SIP or SDP signalling). 225 5. Recording Metadata Format 227 This section gives an overview of the Recording Metadata Format. 228 Some data from the metadata model is assumed to be made available to 229 the SRS through Session Description Protocol (SDP)[RFC4566], and 230 therefore this data is not represented in the XML document format 231 specified in this document. SDP attributes describe different media 232 formats like audio, video. The other metadata attributes, such as 233 participant details, are represented in a new Recording specific XML 234 document of type 'application/rs-metadata+xml'. The SDP label 235 attribute [RFC4574] provides an identifier by which a metadata XML 236 document can refer to a specific media description in the SDP sent 237 from the SRC to the SRS. 239 The XML document format can be used to represent either the complete 240 metadata or a partial update to the metadata. The latter includes 241 only elements that have changed compared to the previously reported 242 metadata. 244 5.1. XML data format 246 Every recording metadata XML document MUST contain a 247 element. The element acts as a container for all other 248 elements in this XML document. 250 A recording object is a XML document. It MUST have the XML 251 declaration and it SHOULD contain an encoding declaration in the XML 252 declaration, e.g., "". If the 253 charset parameter of the MIME content type declaration is present and 254 it is different from the encoding declaration, the charset parameter 255 takes precedence. 257 Every application conforming to this specification MUST accept the 258 UTF-8 character encoding to ensure the minimal interoperability. 260 Syntax and semantic errors in an XML document should be reported to 261 the originator using application specific mechanisms. 263 5.1.1. Namespace 265 The namespace URI for elements defined by this specification is a 266 Uniform Resource Namespace (URN) [RFC2141], using the namespace 267 identifier 'ietf' defined by [RFC2648] and extended by [RFC3688]. 269 The URN is: urn:ietf:params:xml:ns:recording 271 5.1.2. recording 273 The element MUST contain an xmlns namespace attribute 274 with value as urn:ietf:params:xml:ns:recording. One recording 275 element MUST be present in every recording metadata XML document. 277 A recording element MAY contain a element indicating 278 whether the XML document is a complete document or a partial update. 279 If no element is present then the default value is 280 "complete". 282 6. Recording Metadata classes 284 This section describes each class of the metadata model, and the 285 attributes of each class. This section also describes how different 286 classes are linked and the XML element for each of them. 288 6.1. Recording Session 290 +-------------------------------+ 291 | Recording Session (RS) | 292 +-------------------------------+ 293 | | 294 | Start/End Time | 295 | | 296 | | 297 | | 298 +-------------------------------+ 299 |1..* | 1..* 300 | | 301 |0..* | 0..* 302 Communication Communication 303 Session Session Group(CS Group) 305 Each instance of a Recording Session class (namely the Recording 306 Session Object) represents a SIP session created between an SRC and 307 SRS for the purpose of recording a Communication Session. 309 6.1.1. Attributes 311 A Recording Session class has the following attributes: 312 o Start/End Time - Represents the Start/End time of a Recording 313 Session object. 315 6.1.2. Linkages 317 Each instance of Recording Session has: 319 o Zero or more instances of Communication Session Group (CSG). 320 o Zero or more instances of Communication Session objects. 322 CSs and CSGs are optional to accommodate persistent recording, where 323 there may sometimes be none. 325 6.1.3. XML element 327 A Recording Session object is represented by a XML 328 element. That in turn relies on the SIP/SDP session with which the 329 XML document is associated to provide some of the attributes of the 330 Recording Session element. 332 Start and End time value are derivable from Date header(if present in 333 SIP message) in RS. In cases where Date header is not present, 334 Start/End time are derivable from the time at which SRS receives the 335 notification of SIP message to setup RS / disconnect RS. 337 6.2. Communication Session Group 339 Recording Session (RS) 340 | 1..* 341 | 342 | 0..* 343 +-------------------------------+ 344 | Communication Session | 345 | Group | 346 +-------------------------------+ 347 | Unique-ID | 348 | associate-time | 349 | disassociate-time | 350 | | 351 +-------------------------------+ 352 | 0..1 353 | 354 | 1..* 355 Communication Session (CS) 357 One instance of a Communication Session Group class (namely the 358 Communication Session Group object) provides association or linking 359 of Communication Sessions. 361 6.2.1. Attributes 363 A CS Group has the following attributes: 364 o Unique-ID - This Unique-ID is to group different CSs that are 365 related. SRC (or SRS) is responsible for ensuring the uniqueness 366 of Unique-ID in case multiple SRC interacts with the same SRS. 367 The mechanism by which SRC groups the CS is outside the scope of 368 SIPREC. 369 o Associate-time - Associate-time for CS-Group shall be calculated 370 by SRC as the time when a grouping is formed. The rules that 371 determine how a grouping of different Communication Session 372 objects is done by SRC is outside the scope of SIPREC. 373 o Disassociate-time - Disassociate-time for CS-Group shall be 374 calculated by SRC as the time when the grouping ends 376 6.2.2. Linkages 378 The linkages between Communication Session Group class and other 379 classes are associations. A communication Session Group is 380 associated with RS and CS in the following manner: 382 o There are one or more Recording Session objects per Communication 383 Session Group. 384 o Each Communication Session Group object has to be associated with 385 one or more RS [Here each RS can be setup by the potentially 386 different SRCs] 387 o There are one or more Communication Sessions per CS Group [e.g. 388 Consult Transfer] 390 6.2.3. XML element 392 The element is an optional element provides the information 393 about the communication session group 395 Each communication session group (CSG)object is represented using one 396 group element. Each element has a unique 'group-id' 397 attribute which uniquely identifies the CSG. 399 6.3. Communication Session 401 Recording Communication 402 Session Session Group(CS Group) 403 |1..* | 0..1 404 | | 405 |0..* | 1..* 406 +-------------------------------+ 407 | Communication Session (CS) | 408 | | 409 +-------------------------------+ 410 | CS Identifier | 411 | Termination Reason | 412 | Start-time | 413 | Stop-time | 414 +-------------------------------+ 415 | | 416 | 0..* |0..1 417 | | 418 | 0..* |0..* 419 Participant Media Stream 421 A Communication Session class and its object in the metadata model 422 represents a Communication Session and its properties needed as seen 423 by the SRC. 425 6.3.1. Attributes 427 A communication Session class has the following attributes: 429 o Termination Reason - This represents the reason why a CS was 430 terminated. The communication session MAY contain a Call 431 Termination Reason. This MAY be derived from SIP Reason header 432 [RFC3326] of CS. 433 o CS Identifier - This attribute is used to uniquely identify a CS. 434 o Start-time - This optional attribute represents start time of CS 435 as seen by SRC 436 o Stop-time - This optional attribute represents stop time of CS as 437 seen by SRC 439 This document does not specify attributes relating to what should 440 happen to a recording of a CS after it has been delivered to the SRS. 441 (E.g., how long to retain the recording, what access controls to 442 apply.) The SRS is assumed to behave in accordance with policy. The 443 ability for the SRC to influence this policy is outside the scope of 444 this document. However if there are implementations where SRC has 445 enough information, this could be sent as Extension Data attached to 446 the CS 448 6.3.2. Linkages 450 A Communication Session is linked to CS-Group, Participant, Media 451 Stream and Recording Session classes using the association 452 relationship. Association between CS and Participant allows: 454 o CS to have zero or more participants 455 o Participant is associated with zero or more CSs. This includes 456 participants who are not directly part of any CS. An example of 457 such a case is participants in a premixed media stream. The SRC 458 may have knowledge of such Participants, yet not have any 459 signaling relationship with them. This might arise if one 460 participant in CS is a conference focus. To summarize, even if 461 the SRC does not have direct signalling relationships with all 462 participants in a CS, it should nevertheless create a Participant 463 object for each participant that it knows about. 464 o The model also allows participants in CS that are not participants 465 in the media. An example is the identity of a 3pcc controller 466 that has initiated a CS to two or more participants of the CS. 467 Another example is the identity of a conference focus. Of course 468 a focus is probably in the media, but since it may only be there 469 as a mixer, it may not report itself as a participant in any of 470 the media streams. 472 Association between CS and Media Stream allows: 474 o A CS to have zero or more Streams 475 o A stream can be associated with at most one CS. Stream in 476 persistent RS is not required to be associated with any CS before 477 CS is created and hence the zero association is allowed. 479 Association between CS and RS allows: 481 o Each instance of RS has Zero or more instances of Communication 482 Session objects. 483 o Each CS has to be associated with one more RS [ Here each RS can 484 be potentially setup by different SRCs] 486 6.3.3. XML element 488 The element provides the information about the 489 Communication Session 491 Each communication session(CS) object is represented by one session 492 element. Each session element has unique 'session_id' attribute 493 which helps to uniquely identify the CS. 495 The XML element MAY be included in metadata to represent a 496 CS Termination Reason. There MAY be multiple instances of the XML 497 element inside a session element. The XML element 498 has 'protocol' as an attribute, which indicates the protocol from 499 which the reason string is derived. The default value for protocol 500 attribute is "SIP". The element can be derived from a SIP 501 Reason header in the CS. 503 A element MAY be present to indicate the group to which 504 the enclosing session belongs. 506 6.4. CSRSAssociation 508 1..* 0..* 509 Recording Communication 510 Session ----------+---------- Session 511 | 512 | 513 | 514 +-------------------+ 515 | CSRSAssociation | 516 +-------------------+ 517 | Association-Time | 518 | Disassociaton-Time| 519 +-------------------+ 521 The CSRS Association class describes the association of a CS to an RS 522 for a period of time. A single CS may be associated with different 523 RSs (perhaps by different SRCs) and may be associated and dissociated 524 several times. 526 6.4.1. Attributes 528 CSRS association class has the following attributes: 530 o Associate-time - associate-time is calculated by SRC as the time 531 it sees a CS is associated to a RS 532 o Disassociate-time- Disassociate-time is calculated by SRC as the 533 time it see a CS disassociate from a RS. 535 6.4.2. Linkages 537 CSRS association class is linked to CS and RS classes. 539 6.4.3. XML element 541 The XML element represents the CSRS 542 association object. The 'session_id' attribute is used to uniquely 543 identify this element and link with a specific session. The 544 recording object is implicitly defined by the enclosing 545 element. 547 6.5. Participant 549 Communication Session (CS) 550 | 0..* 551 | 552 | 0..* 553 +-------------------------------+ 554 | Participant | 555 | | 556 +-------------------------------+ 557 | AoR / Name Pair list | 558 | | 559 | | 560 +-------------------------------+ 561 | 0..* 1..*| 562 receives| |sends 563 | 0..* 0..*| 564 Media Stream 566 A Participant class and its objects has information about a device 567 that is part of a CS and/or contributes/consumes media stream(s) 568 belonging to a CS. 570 6.5.1. Attributes 572 Participant has a single defined attribute: 574 o AoR / Name pair list - This attribute is a list of Name/AoR 575 tuples. An AoR MAY be a SIP/SIPS/TEL URI. Name represents 576 Participant name(SIP display name) or dialed number (DN) (when 577 known). Multiple tuples are allowed for cases where a participant 578 has more than one AoR. (For example a P-Asserted-identity header 579 [RFC3325] can have both SIP and TEL URIs.) 581 This document does not specify other attributes relating to 582 participant e.g. Participant Role, Participant type. An SRC which 583 has information of these attributes can indicate the same as part of 584 extension data to Participant from SRC to SRS. 586 6.5.2. Linkages 588 The participant class is linked to MS and CS class using association 589 relationship. The association between participant and Media Stream 590 allows: 592 o Participant to receive zero or more media streams 593 o Participant to send zero or more media streams. (Same participant 594 provides multiple streams e.g. audio and video) 595 o Media stream to be received by zero or more participants. Its 596 possible, though perhaps unlikely, that a stream is generated but 597 sent only to the SRC and SRS, not to any participant. E.g. In 598 conferencing where all participants are on hold and the SRC is 599 collocated with the focus. Also a media stream may be received by 600 multiple participants (e.g. Whisper calls, side conversations). 601 o Media stream to be sent by one or more participants (pre-mixed 602 streams). 604 Example of a case where a participant receives zero or more streams - 605 a supervisor may have side conversation with agent, while agent 606 converses with customer. 608 6.5.3. XML element 610 A element represents a Participant object. 612 Participant MUST have a NameID complex element which contains AoR as 613 attribute and Name as element. AOR element is SIP/SIPS URI FQDN or 614 IP address which represents the user. name is an optional element to 615 represent display name. 617 Each participant has a unique 'participant_id' attribute. This MUST 618 be used for all references to a participant within a CSG, and MAY be 619 used to reference the same participant more globally. (The decision 620 to use a participant_id across multiple CSGs or recording sessions is 621 at the discretion of the implementer.) 623 6.6. ParticipantCSAssociation 625 1..* 0..* 626 Communication 627 Session ----------+---------- Participant 628 | 629 | 630 | 631 +-------------------+ 632 | ParticipantCS | 633 | Association | 634 +-------------------+ 635 | Capabilities | 636 | Association-Time | 637 | Disassociaton-Time| 638 +-------------------+ 640 The Participant CS Association class describes the association of a 641 Participant to an CS for a period of time. A participant may be 642 associated and dissociated from a CS several times. (For example, 643 connecting to a conference, then disconnecting, then connecting 644 again.) 646 6.6.1. Attributes 648 ParticipantCS association class has the following attributes: 650 o Associate-time - associate-time is calculated by SRC as the time 651 it sees a participant is associated to CS 652 o Disassociate-time- Disassociate-time is calculated by the SRC as 653 the time it sees a participant disassociate from a CS. It is 654 possible that a given participant can have multiple associate/ 655 disassociate times within given communication session. 656 o Capabilities - An optional attribute describing the capabilities 657 of a participant in a CS, as defined in [RFC3840]. Each 658 participant may have zero or more capabilities. A participant may 659 use different capabilities depending on the role it plays at a 660 particular instance. For example if a participant moves across 661 different CSs (e.g., due to transfer) or is simultaneously present 662 in different CSs its role may be different and hence the 663 capability used. 665 6.6.2. Linkages 667 The participantCS association class is linked to participant and CS 668 classes. 670 6.6.3. XML element 672 The XML element represents a participantCS 673 association object. The 'participant_id' and 'session_id' attributes 674 are used to uniquely identify this element. 676 NOTE: RFC 4235 encoding shall be used to represent capabilities 677 attribute in XML. 679 6.7. Media Stream 681 Participant 682 | 0..* 1..*| 683 receives| |sends 684 | 0..* 0..*| 685 +-------------------------+ 686 | Media Stream | 687 | | 688 Communication 0..1 0..* +-------------------------+ 689 Session ------------| | 690 | Media Stream Reference | 691 | Content-type | 692 | | 693 +-------------------------+ 695 A Media Stream class (and its objects) has the properties of media as 696 seen by SRC and sent to SRS. Different snapshots of a media stream 697 object may be sent whenever there is a change in media (e.g. 698 direction change like pause/resume and/or codec change and/or 699 participant change.). 701 6.7.1. Attributes 703 A Media Stream class has the the following attributes: 705 o Media Stream Reference - In implementations this references an 706 m-line 707 o Content - The content of an MS element will be described in terms 708 of value from the [RFC4796] registry. 710 The metadata model should include media streams that are not being 711 delivered to the SRS. Examples include cases where SRC offered 712 certain media types but SRS chooses to accept only a subset of them 713 OR an SRC may not even offer a certain media type due it its 714 restrictions to record 716 6.7.2. Linkages 718 A Media Stream is linked to participant and CS classes using the 719 association relationship. The details of association with the 720 Participant are described in the Participant class section. The 721 details of association with CS is mentioned in the CS section. 723 6.7.3. XML element 725 The element represents a Media Stream object. Stream 726 element indicates SDP media lines associated with the session and 727 participants. 729 The