idnits 2.17.1 draft-ietf-siprec-metadata-17.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 (February 12, 2015) is 3351 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-13 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 4 Intended status: Standards Track Parthasarathi. Ravindran 5 Expires: August 16, 2015 Nokia Networks 6 Paul. Kyzivat 7 Huawei 8 February 12, 2015 10 Session Initiation Protocol (SIP) Recording Metadata 11 draft-ietf-siprec-metadata-17 13 Abstract 15 Session recording is a critical requirement in many communications 16 environments such as call centers and financial trading. In some of 17 these environments, all calls must be recorded for regulatory, 18 compliance, and consumer protection reasons. Recording of a session 19 is typically performed by sending a copy of a media stream to a 20 recording device. This document describes the metadata model as 21 viewed by Session Recording Server(SRS) and the Recording metadata 22 format. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 16, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 13 80 6.4.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 13 81 6.4.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 13 82 6.4.3. XML element . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . 19 100 6.10. Unique ID format . . . . . . . . . . . . . . . . . . . . . 20 101 6.11. Metadata version Indicator . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . 23 106 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 107 9.1. Connection Security . . . . . . . . . . . . . . . . . . . 27 108 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 109 10.1. SIP recording metadata Schema Registration . . . . . . . . 28 110 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 28 111 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 112 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 113 12.2. Informative References . . . . . . . . . . . . . . . . . . 29 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 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 | sip Session-ID | 412 | Termination Reason | 413 | Start-time | 414 | Stop-time | 415 +-------------------------------+ 416 | | 417 | 0..* |0..1 418 | | 419 | 0..* |0..* 420 Participant Media Stream 422 A Communication Session class and its object in the metadata model 423 represents a Communication Session and its properties needed as seen 424 by the SRC. 426 6.3.1. Attributes 428 A communication Session class has the following attributes: 430 o Termination Reason - This represents the reason why a CS was 431 terminated. The communication session MAY contain a Call 432 Termination Reason. This MAY be derived from SIP Reason header 433 [RFC3326] of CS. 434 o CS Identifier - This attribute is used to uniquely identify a CS. 435 o sip Session-ID - This attribute carries sip Session-ID defined in 436 [I-D.ietf-insipid-session-id]. 437 o Start-time - This optional attribute represents start time of CS 438 as seen by SRC 439 o Stop-time - This optional attribute represents stop time of CS as 440 seen by SRC 442 This document does not specify attributes relating to what should 443 happen to a recording of a CS after it has been delivered to the SRS. 444 (E.g., how long to retain the recording, what access controls to 445 apply.) The SRS is assumed to behave in accordance with policy. The 446 ability for the SRC to influence this policy is outside the scope of 447 this document. However if there are implementations where SRC has 448 enough information, this could be sent as Extension Data attached to 449 the CS 451 6.3.2. Linkages 453 A Communication Session is linked to CS-Group, Participant, Media 454 Stream and Recording Session classes using the association 455 relationship. Association between CS and Participant allows: 457 o CS to have zero or more participants 458 o Participant is associated with zero or more CSs. This includes 459 participants who are not directly part of any CS. An example of 460 such a case is participants in a premixed media stream. The SRC 461 may have knowledge of such Participants, yet not have any 462 signaling relationship with them. This might arise if one 463 participant in CS is a conference focus. To summarize, even if 464 the SRC does not have direct signalling relationships with all 465 participants in a CS, it should nevertheless create a Participant 466 object for each participant that it knows about. 467 o The model also allows participants in CS that are not participants 468 in the media. An example is the identity of a 3pcc controller 469 that has initiated a CS to two or more participants of the CS. 470 Another example is the identity of a conference focus. Of course 471 a focus is probably in the media, but since it may only be there 472 as a mixer, it may not report itself as a participant in any of 473 the media streams. 475 Association between CS and Media Stream allows: 477 o A CS to have zero or more Streams 478 o A stream can be associated with at most one CS. Stream in 479 persistent RS is not required to be associated with any CS before 480 CS is created and hence the zero association is allowed. 482 Association between CS and RS allows: 484 o Each instance of RS has Zero or more instances of Communication 485 Session objects. 486 o Each CS has to be associated with one more RS [ Here each RS can 487 be potentially setup by different SRCs] 489 6.3.3. XML element 491 The element provides the information about the 492 Communication Session 494 Each communication session(CS) object is represented by one session 495 element. Each session element has unique 'session_id' attribute 496 which helps to uniquely identify the CS. 498 Each Communication Session (CS) element MAY have zero or more 499 XML elements. More than one sipSession-ID element may 500 be present in a session element for Conference flows. For e.g., 501 Three participants A, B and C are in conference that has a Focus(F) 502 acting as SRC. The metadata sent from SRC to SRS will likely have 503 three sipSession-Id elements that correspond to the SIP dialog's the 504 Focus has with each of the three participants. 506 The sipSessionID XML element MUST follow the ABNF format of session- 507 id-value defined in section 5 of [I-D.ietf-insipid-session-id]. If 508 there are changes in CS, the same will be indicated in the metadata 509 snapshot from SRC to SRS and this MAY include any sipSessionID 510 changes as well. For e.g., Assume A and B are two participants in a 511 CS having a B2BUA acting as SRC. The SRC (B2BUA) reports the session 512 id snapshot as A;remote=B at time t1 to SRS. At a later time if 513 there is transfer in the same CS and B drops and C joins, then the 514 SRC(B2BUA) reports the session id as A;remote=C at time t2 to SRS. 516 The XML element MAY be included in metadata to represent a 517 CS Termination Reason. There MAY be multiple instances of the XML 518 element inside a session element. The XML element 519 has 'protocol' as an attribute, which indicates the protocol from 520 which the reason string is derived. The default value for protocol 521 attribute is "SIP". The element can be derived from a SIP 522 Reason header in the CS. 524 A element MAY be present to indicate the group to which 525 the enclosing session belongs. 527 6.4. CSRSAssociation 529 1..* 0..* 530 Recording Communication 531 Session ----------+---------- Session 532 | 533 | 534 | 535 +-------------------+ 536 | CSRSAssociation | 537 +-------------------+ 538 | Association-Time | 539 | Disassociaton-Time| 540 +-------------------+ 542 The CSRS Association class describes the association of a CS to an RS 543 for a period of time. A single CS may be associated with different 544 RSs (perhaps by different SRCs) and may be associated and dissociated 545 several times. 547 6.4.1. Attributes 549 CSRS association class has the following attributes: 551 o Associate-time - associate-time is calculated by SRC as the time 552 it sees a CS is associated to a RS 553 o Disassociate-time- Disassociate-time is calculated by SRC as the 554 time it see a CS disassociate from a RS. 556 6.4.2. Linkages 558 CSRS association class is linked to CS and RS classes. 560 6.4.3. XML element 562 The XML element represents the CSRS 563 association object. The 'session_id' attribute is used to uniquely 564 identify this element and link with a specific session. The 565 recording object is implicitly defined by the enclosing 566 element. 568 6.5. Participant 570 Communication Session (CS) 571 | 0..* 572 | 573 | 0..* 574 +-------------------------------+ 575 | Participant | 576 | | 577 +-------------------------------+ 578 | AoR / Name Pair list | 579 | | 580 | | 581 +-------------------------------+ 582 | 0..* 1..*| 583 receives| |sends 584 | 0..* 0..*| 585 Media Stream 587 A Participant class and its objects has information about a device 588 that is part of a CS and/or contributes/consumes media stream(s) 589 belonging to a CS. 591 6.5.1. Attributes 593 Participant has a single defined attribute: 595 o AoR / Name pair list - This attribute is a list of Name/AoR 596 tuples. An AoR MAY be a SIP/SIPS/TEL URI. Name represents 597 Participant name(SIP display name) or dialed number (DN) (when 598 known). Multiple tuples are allowed for cases where a participant 599 has more than one AoR. (For example a P-Asserted-identity header 600 [RFC3325] can have both SIP and TEL URIs.) 602 This document does not specify other attributes relating to 603 participant e.g. Participant Role, Participant type. An SRC which 604 has information of these attributes can indicate the same as part of 605 extension data to Participant from SRC to SRS. 607 6.5.2. Linkages 609 The participant class is linked to MS and CS class using association 610 relationship. The association between participant and Media Stream 611 allows: 613 o Participant to receive zero or more media streams 614 o Participant to send zero or more media streams. (Same participant 615 provides multiple streams e.g. audio and video) 616 o Media stream to be received by zero or more participants. Its 617 possible, though perhaps unlikely, that a stream is generated but 618 sent only to the SRC and SRS, not to any participant. E.g. In 619 conferencing where all participants are on hold and the SRC is 620 collocated with the focus. Also a media stream may be received by 621 multiple participants (e.g. Whisper calls, side conversations). 622 o Media stream to be sent by one or more participants (pre-mixed 623 streams). 625 Example of a case where a participant receives zero or more streams - 626 a supervisor may have side conversation with agent, while agent 627 converses with customer. 629 6.5.3. XML element 631 A element represents a Participant object. 633 Participant MUST have a NameID complex element which contains AoR as 634 attribute and Name as element. AOR element is SIP/SIPS URI FQDN or 635 IP address which represents the user. name is an optional element to 636 represent display name. 638 Each participant has a unique 'participant_id' attribute. This MUST 639 be used for all references to a participant within a CSG, and MAY be 640 used to reference the same participant more globally. (The decision 641 to use a participant_id across multiple CSGs or recording sessions is 642 at the discretion of the implementer.) 644 6.6. ParticipantCSAssociation 646 1..* 0..* 647 Communication 648 Session ----------+---------- Participant 649 | 650 | 651 | 652 +-------------------+ 653 | ParticipantCS | 654 | Association | 655 +-------------------+ 656 | Capabilities | 657 | Association-Time | 658 | Disassociaton-Time| 659 +-------------------+ 661 The Participant CS Association class describes the association of a 662 Participant to an CS for a period of time. A participant may be 663 associated and dissociated from a CS several times. (For example, 664 connecting to a conference, then disconnecting, then connecting 665 again.) 667 6.6.1. Attributes 669 ParticipantCS association class has the following attributes: 671 o Associate-time - associate-time is calculated by SRC as the time 672 it sees a participant is associated to CS 673 o Disassociate-time- Disassociate-time is calculated by the SRC as 674 the time it sees a participant disassociate from a CS. It is 675 possible that a given participant can have multiple associate/ 676 disassociate times within given communication session. 677 o Capabilities - An optional attribute describing the capabilities 678 of a participant in a CS, as defined in [RFC3840]. Each 679 participant may have zero or more capabilities. A participant may 680 use different capabilities depending on the role it plays at a 681 particular instance. For example if a participant moves across 682 different CSs (e.g., due to transfer) or is simultaneously present 683 in different CSs its role may be different and hence the 684 capability used. 686 6.6.2. Linkages 688 The participantCS association class is linked to participant and CS 689 classes. 691 6.6.3. XML element 693 The XML element represents a participantCS 694 association object. The 'participant_id' and 'session_id' attributes 695 are used to uniquely identify this element. 697 NOTE: RFC 4235 encoding shall be used to represent capabilities 698 attribute in XML. 700 6.7. Media Stream 702 Participant 703 | 0..* 1..*| 704 receives| |sends 705 | 0..* 0..*| 706 +-------------------------+ 707 | Media Stream | 708 | | 709 Communication 0..1 0..* +-------------------------+ 710 Session ------------| | 711 | Media Stream Reference | 712 | Content-type | 713 | | 714 +-------------------------+ 716 A Media Stream class (and its objects) has the properties of media as 717 seen by SRC and sent to SRS. Different snapshots of a media stream 718 object may be sent whenever there is a change in media (e.g. 719 direction change like pause/resume and/or codec change and/or 720 participant change.). 722 6.7.1. Attributes 724 A Media Stream class has the the following attributes: 726 o Media Stream Reference - In implementations this references an 727 m-line 728 o Content - The content of an MS element will be described in terms 729 of value from the [RFC4796] registry. 731 The metadata model should include media streams that are not being 732 delivered to the SRS. Examples include cases where SRC offered 733 certain media types but SRS chooses to accept only a subset of them 734 OR an SRC may not even offer a certain media type due it its 735 restrictions to record 737 6.7.2. Linkages 739 A Media Stream is linked to participant and CS classes using the 740 association relationship. The details of association with the 741 Participant are described in the Participant class section. The 742 details of association with CS is mentioned in the CS section. 744 6.7.3. XML element 746 The element represents a Media Stream object. Stream 747 element indicates SDP media lines associated with the session and 748 participants. 750 The