idnits 2.17.1 draft-ietf-siprec-metadata-06.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2012) is 4427 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-04 Summary: 2 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: September 13, 2012 Sonus Networks 5 Paul. Kyzivat 6 Unaffiliated 7 March 12, 2012 9 Session Initiation Protocol (SIP) Recording Metadata 10 draft-ietf-siprec-metadata-06 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 September 13, 2012. 40 Copyright Notice 42 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . 17 95 6.8.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 18 96 6.8.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 18 97 6.8.3. XML element . . . . . . . . . . . . . . . . . . . . . 18 98 6.9. associate-time/disassociate-time . . . . . . . . . . . . . 18 99 6.10. Unique ID format . . . . . . . . . . . . . . . . . . . . . 19 100 7. SIP Recording Metadata Example . . . . . . . . . . . . . . . . 19 101 7.1. Complete SIP Recording Metadata Example . . . . . . . . . 19 102 7.2. Partial Update of Recording metadata XML body . . . . . . 21 103 8. XML Schema definition for Recording metadata . . . . . . . . . 21 104 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 105 9.1. Connection Security . . . . . . . . . . . . . . . . . . . 25 106 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 107 10.1. SIP recording metadata Schema Registration . . . . . . . . 25 108 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 26 109 12. Appendix A: Metadata Model Object Instances . . . . . . . . . 26 110 12.1. Use case 1: Basic Call . . . . . . . . . . . . . . . . . . 26 111 12.2. Use case 2: Hold/Resume . . . . . . . . . . . . . . . . . 27 112 12.3. Use case 3: Basic call with Transfer . . . . . . . . . . . 29 113 12.4. Conference Use Cases . . . . . . . . . . . . . . . . . . . 30 114 12.4.1. Case 1: . . . . . . . . . . . . . . . . . . . . . . . 31 115 12.4.2. Case 2: . . . . . . . . . . . . . . . . . . . . . . . 33 116 12.4.3. Case 3: . . . . . . . . . . . . . . . . . . . . . . . 35 117 12.4.4. Case 4: . . . . . . . . . . . . . . . . . . . . . . . 36 118 13. Appendix B: Metadata XML schema Instances . . . . . . . . . . 37 119 13.1. Use case 1: Basic Call . . . . . . . . . . . . . . . . . . 37 120 13.2. Use case 2: Hold/resume . . . . . . . . . . . . . . . . . 39 121 13.3. Use case 3: Basic Call with transfer . . . . . . . . . . . 41 122 13.4. Use Case 4: Call disconnect . . . . . . . . . . . . . . . 45 123 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 124 14.1. Normative References . . . . . . . . . . . . . . . . . . . 46 125 14.2. Informative References . . . . . . . . . . . . . . . . . . 47 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 128 1. Introduction 130 Session recording is a critical requirement in many communications 131 environments such as call centers and financial trading. In some of 132 these environments, all calls must be recorded for regulatory, 133 compliance, and consumer protection reasons. Recording of a session 134 is typically performed by sending a copy of a media stream to a 135 recording device. This document focuses on the Recording metadata 136 which describes the communication session. The document describes a 137 metadata model as viewed by Session Recording Server and the 138 Recording metadata format, the requirements for which are described 139 in [RFC6341] and the architecture for which is described in 140 [I-D.ietf-siprec-architecture]. 142 2. Terminology 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. This 147 document only uses these key words when referencing normative 148 statements in existing RFCs." 150 3. Definitions 152 Metadata Model: An abstract representation of metadata using a 153 Unified Modelling Language(UML) class diagram. 155 Metadata classes: Each block in the model represents a class. A 156 class is a construct that is used as a blueprint to create 157 instances(called objects) of itself. The description of each class 158 also has representation of its attributes in a second compartment 159 below the class name. 161 Attributes: Attributes represents the attributes listed in each of 162 the classes. The attributes of a class are listed in the second 163 compartment below the class name. Each instance of class conveys 164 values for these attributes which adds to the recording's Metadata. 166 Linkages: Linkages represents the relationship between the classes in 167 the model. It represents the logical connections betweens classes(or 168 objects) in class diagrams/ object diagrams. The linkages used in 169 the Metadata model of this document are associations. 171 4. Metadata Model 173 Metadata is the information that describes recorded media and the CS 174 to which they relate. Below diagram shows a model for Metadata as 175 viewed by Session Recording Server (SRS). 177 +-------------------------------+ 178 | Recording Session (RS) | 179 +-------------------------------+ 180 |1..* | 1..* 181 | | 182 | | 0..* 183 | +-----------------+ 184 | | Communication | 185 | | Session (CS) | 186 | | Group | 187 | +-----------------+ 188 | | 0..1 189 | | 190 |0..* | 1..* 191 +-------------------------------+ 192 | Communication Session (CS) | 193 | | 194 +-------------------------------+ 195 | 1..* |1..* 196 +-----+ | 197 | | 0..* |0..* 198 | +-------------+ receives +----------------+ 199 | | Participant |----------| Media Streams | 200 | | |0..* 0..*| | 201 | | | | | 202 | | | | | 203 | | | sends | | 204 | | |----------| | 205 | | |1.* 0..*| | 206 | +-------------+ +----------------+ 207 | | | 208 | | | 209 | +------------------------+------------+ 210 | | 211 | | 212 | +------------------+ +----------------------+ 213 | |ParticipantCS | | ParticipantStream | 214 +-----------| Association | | Association | 215 | | | | 216 +------------------+ +----------------------+ 218 The Metadata model is a class diagram in Unified Modelling 219 Language(UML). The model describes the structure of a metadata in 220 general by showing the classes, their attributes, and the 221 relationships among the classes. Each block in the model above 222 represents a class. The linkages between the classes represents the 223 relationships which can be associations or Composition. The metadata 224 is conveyed from SRC to SRS. 226 The model allows the capture of a snapshot of a recording's Metadata 227 at a given instant in time. Metadata changes to reflect changes in 228 what is being recorded. For example, if in a conference a 229 participant joins SRC sends a snapshot of metadata having that 230 participant information (with attributes like name/AoR pair and 231 associate-time) to the SRS. 233 Some of the metadata is not required to be conveyed explicitly from 234 the SRC to the SRS, if it can be obtained contextually by the 235 SRS(e.g., from SIP or SDP signalling). 237 5. Recording Metadata Format 239 This section gives an overview of Recording Metadata Format. Some 240 data from the metadata model is assumed to be made available to the 241 SRS through Session Description Protocol (SDP)[RFC4566], and 242 therefore this data is not represented in the XML document format 243 specified in this document. SDP attributes describes about different 244 media formats like audio, video. The other metadata attributes like 245 participant details are represented in a new Recording specific XML 246 document namely application/rs-metadata+xml. The SDP label attribute 247 [RFC4574] provides an identifier by which a metadata XML document can 248 refer to a specific media description in the SDP sent from the SRC to 249 the SRS. 251 The XML document format can be used to represent either the complete 252 metadata or a partial update to the metadata. The latter includes 253 only elements that have changed compared to the previously reported 254 metadata. 256 5.1. XML data format 258 Recording Metadata document is an XML document. recording element 259 MUST present in all recording metadata XML document. recording acts 260 as container for all other elements in this XML document. 262 Recording object is a XML document. It MUST have the XML declaration 263 and it SHOULD contain an encoding declaration in the XML declaration, 264 e.g., "". If the charset 265 parameter of the MIME content type declaration is present and it is 266 different from the encoding declaration, the charset parameter takes 267 precedence. 269 Every application conforming to this specification MUST accept the 270 UTF-8 character encoding to ensure the minimal interoperability. 272 Syntax and semantics error in recording XML document has to be 273 informed to the originator using application specific mechanism. 275 5.1.1. Namespace 277 The namespace URI for elements defined by this specification is a 278 Uniform Resource Namespace (URN) [RFC2141], using the namespace 279 identifier 'ietf' defined by [RFC2648] and extended by [RFC3688]. 281 The URN is as follows: urn:ietf:params:xml:ns:recording 283 5.1.2. recording 285 recording element MUST contain an xmlns namespace attribute with 286 value as urn:ietf:params:xml:ns:recording. One recording element 287 MUST present in the all recording metadata XML document. 289 dataMode element shows whether the XML document is complete document 290 or partial update. The default value is complete. 292 6. Recording Metadata classes 294 This section describes each class of the metadata model, and the 295 attributes of each class. This section also describes how different 296 classes are linked and the XML element for each of them. 298 6.1. Recording Session 299 +-------------------------------+ 300 | Recording Session (RS) | 301 +-------------------------------+ 302 | | 303 | Start/End Time | 304 | | 305 | | 306 | | 307 +-------------------------------+ 308 |1..* | 1..* 309 | | 310 |0..* | 0..* 311 Communication Communication 312 Session Session Group(CS Group) 314 Each instance of a Recording Session class (namely the Recording 315 Session Object) represents a SIP session created between an SRC and 316 SRS for the purpose of recording a Communication Session. 318 6.1.1. Attributes 320 A Recording Session class has the following attributes: 321 o Start/End Time - Represents the Start/End time of a Recording 322 Session object. 324 6.1.2. Linkages 326 Each instance of Recording Session has: 328 o Zero or more instances of Communication Session Group. CSG may be 329 zero because it is optional metadata object. Also the allowance 330 of zero instances is to accommodate persistent recording, where 331 there may be none. 332 o Zero or more instances of Communication Session objects. 334 6.1.3. XML element 336 Recording Session object is represented by recording XML element. 337 That in turn relies on the SIP/SDP session with which the XML 338 document is associated to provide some of the attributes of the 339 Recording Session element. 341 Start and End time value are derivable from Date header(if present in 342 SIP message) in RS. In cases where Date header is not present, 343 Start/End time are derivable from the time at which SRS receives the 344 notification of SIP message to setup RS / disconnect RS. 346 6.2. Communication Session Group 348 Recording Session (RS) 349 | 1..* 350 | 351 | 0..* 352 +-------------------------------+ 353 | Communication Session | 354 | Group | 355 +-------------------------------+ 356 | Unique-ID | 357 | associate-time | 358 | disassociate-time | 359 | | 360 +-------------------------------+ 361 | 0..1 362 | 363 | 1..* 364 Communication Session (CS) 366 One instance of a Communication Session Group class (namely the 367 Communication Session Group object) provides association or linking 368 of Communication Sessions. 370 6.2.1. Attributes 372 A CS Group has the following attributes: 373 o Unique-ID - This Unique-ID is to group different CSs that are 374 related. SRC (or SRS) is responsible for ensuring the uniqueness 375 of Unique-ID in case multiple SRC interacts with the same SRS. 376 The mechanism by which SRC groups the CS is outside the scope of 377 SIPREC. 378 o Associate-time - Associate-time for CS-Group shall be calculated 379 by SRC as the time when a grouping is formed. The rules that 380 determine how a grouping of different Communication Session 381 objects is done by SRC is outside the scope of SIPREC. 382 o Disassociate-time - Disassociate-time for CS-Group shall be 383 calculated by SRC as the time when the grouping ends 385 6.2.2. Linkages 387 The linkages between Communication Session Group class and other 388 classes is association. A communication Session Group is associated 389 with RS and CS in the following manner: 391 o There is one or more Recording Session objects per Communication 392 Session Group. 393 o Each Communication Session Group object has to be associated with 394 one or more RS [Here each RS can be setup by the potentially 395 different SRCs] 396 o There is one or more Communication Sessions per CS Group [e.g. 397 Consult Transfer] 399 6.2.3. XML element 401 Group element is an optional element provides the information about 402 the communication session group 404 Each communication session group (CSG)object is represented using one 405 group element. Each group element has unique Base 64 URN UUID 406 attribute which helps to uniquely identify CSG. 408 6.3. Communication Session 410 Recording Communication 411 Session Session Group(CS Group) 412 |1..* | 0..1 413 | | 414 |0..* | 1..* 415 +-------------------------------+ 416 | Communication Session (CS) | 417 | | 418 +-------------------------------+ 419 | CS Identifier | 420 | Termination Reason | 421 +-------------------------------+ 422 | | 423 | 0..* |0..* 424 | | 425 | 0..* |0..* 426 Participant Media Stream 428 A Communication Session class and its object in the metadata model 429 represents Communication Session and its properties needed as seen by 430 SRC. 432 6.3.1. Attributes 434 A communication Session class has the following attributes: 436 o Termination Reason - This represents the reason why a CS was 437 terminated. The communication session MAY contain a Call 438 Termination Reason. This MAY be derived from SIP Reason header 439 [RFC3326] of CS. 440 o CS Identifier - This attribute is used to uniquely identify a CS. 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 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 atleast 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 conf focus. To summarize even if SRC does 464 not have direct signalling relationships with all participants in 465 a CS, it should nevertheless create a Participant object for each 466 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 zero or more CS. An example is 479 multicast MoH stream which might be associated with many CSs. 480 stream in persistent RS is not required to be associated with any 481 CS before CS is created. 483 Association between CS and RS allows: 485 o Each instance of RS has Zero or more instances of Communication 486 Session objects. 487 o Each CS has to be associated with one more RS [ Here each RS can 488 be potentially setup by different SRCs] 490 6.3.3. XML element 492 Session element provides the information about the communication 493 session 495 Each communication session(CS) object is represented by one session 496 element. Each session element has unique Base 64 URN UUID attribute 497 which helps to uniquely identify CS. 499 Reason element MAY be included to represent the Termination Reason 500 attribute. group-ref element MAY exist to indicate the group where 501 the mentioned session belongs. 503 6.4. CSRSAssociation 505 1..* 1..* 506 Recording Communication 507 Session ----------+---------- Session 508 | 509 | 510 | 511 +-------------------+ 512 | CSRSAssociation | 513 +-------------------+ 514 | Association-Time | 515 | Disassociaton-Time| 516 +-------------------+ 518 A CSRS Association class and its objects has attributes of CS object 519 which are attributes of association of a session to a RS 521 6.4.1. Attributes 523 CSRS association class has the following attributes: 525 o Associate-time - associate-time is calculated by SRC as the time 526 it sees a CS is associated to RS 527 o Disassociate-time- Disassociate-time is calculated by SRC as the 528 time it see a CS disassociate from a RS. It is possible that a 529 given CS can have multiple associate/disassociate times within 530 given RS. 532 6.4.2. Linkages 534 CSRS association class is linked to CS and RS classes. There are no 535 cardinalties for this linkage. 537 6.4.3. XML element 539 sessionrecordingassoc is the XML element to represent CSRS 540 association object. session URN UUID is used to uniquely identify 541 this element and link with the specific session. 543 6.5. Participant 545 Communication Session (CS) 546 | 0..* 547 | 548 | 0..* 549 +-------------------------------+ 550 | Participant | 551 | | 552 +-------------------------------+ 553 | AoR / Name Pair list | 554 | | 555 | | 556 +-------------------------------+ 557 | 0..* 1..*| 558 receives| |sends 559 | 0..* 0..*| 560 Media Stream 562 A Participant class and its objects has information about a device 563 that is part of a CS and/or contributes/consumes media stream(s) 564 belonging to a CS. 566 6.5.1. Attributes 568 Participant has attributes like: 570 o AoR / Name pair list - This attribute is a list of Name/AoR tuple. 571 An AoR MAY be SIP/SIPS/TEL URI. Name represents Participant 572 name(SIP display name) or DN number ( in case it is known). There 573 are cases where a participant can have more than one AoR [e.g. 574 P-Asserted-identity header [RFC3325] which can have both SIP and 575 TEL URIs] 577 This document does not specify other attributes relating to 578 participant e.g. Participant Role, Participant type. An SRC which 579 has information of these attributes can indicate the same as part of 580 extension data to Participant from SRC to SRS. 582 6.5.2. Linkages 584 The participant class is linked to MS and CS class using association 585 relationship. The association between participant and Media Stream 586 allows: 588 o Participant to receives zero or more media streams 589 o Participant to send zero or more media streams. (Same participant 590 provides multiple streams e.g. audio and video) 591 o Media stream to be received by zero or more participants. Its 592 possible, though perhaps unlikely, that a stream is generated but 593 sent only to the SRC and SRS, not to any participant. E.g. In 594 conferencing where all participants are on hold and the SRC is 595 collocated with the focus. Also a media stream may be received by 596 multiple participants (e.g. Whisper calls, side conversations). 597 o Media stream to be sent by one or more participants (pre-mixed 598 streams). 600 Example of a case where a participant receives Zero or more streams - 601 a Supervisor may have side conversation with Agent, while Agent 602 converses with customer. 604 6.5.3. XML element 606 A participant element represents a Participant object. 608 Participant MUST have a NameID complex element which contains AoR as 609 attribute and Name as element. AOR element is SIP/SIPS URI FQDN or 610 IP address which represents the user. name is an optional element to 611 represent display name. 613 Each participant element has unique ID (Base 64 URN UUID) attribute 614 which helps to uniquely identify participant and session Base 64 URN 615 UUID to associate participant with specific session element. Base 64 616 URN UUID of participant MUST used in the scope of CSG and no new Base 617 64 URN UUID has to be created for the same element (participant, 618 stream) between different CS in the same CSG. In case Base 64 URN 619 UUID has to be used permanent, careful usage of Base 64 URN UUID to 620 original AoR has to be decided by the implementers and it is 621 implementer's choice. 623 6.6. ParticipantCSAssociation 625 1..* 1..* 626 Communication 627 Session ----------+---------- Participant 628 | 629 | 630 | 631 +-------------------+ 632 | ParticipantCS | 633 | Association | 634 +-------------------+ 635 | Capabilities | 636 | Association-Time | 637 | Disassociaton-Time| 638 +-------------------+ 640 A participantCS Association class and its objects has attributes of 641 participant object which are attributes of association of a 642 participant to a Session. 644 6.6.1. Attributes 646 ParticipantCS association class has the following attributes: 648 o Associate-time - associate-time is calculated by SRC as the time 649 it sees a participant is associated to CS 650 o Disassociate-time- Disassociate-time is calculated by SRC as the 651 time it see a participant disassociate from a CS. It is possible 652 that a given participant can have multiple associate/disassociate 653 times within given communication session. 654 o Capabilities - A participant capabilities as defined in [RFC3840] 655 which is an optional attribute that includes the capabilities of a 656 participant in a CS. Each participant shall have Zero or more 657 capabilities. A participant may use different capabilities 658 depending on the role it plays at a particular instance. IOW if a 659 participants moves across different CSs ( due to transfer e.t.c) 660 OR is simultaneously present in different CSs its role may be 661 different and hence the capability used. 662 o "send" or "recv" element in each participant is associating SDP 663 m-lines with the participant. send element indicates that 664 participant is sending the stream of media with the mentioned 665 media description. recv element indicates that participant is 666 receiving the stream and by default all participant will receive 667 the stream. recv element has relevance in case whisper call 668 scenario wherein few of the participant in the session receives 669 the stream and not others. 671 6.6.2. Linkages 673 The participantCS association class is linked to participant and CS 674 classes. There are no cardinalties for this linkage. 676 6.6.3. XML element 678 participantsessionassoc XML element represent participantCS 679 association object. participant and session id is used to uniquely 680 identify this element 682 NOTE: RFC 4235 encoding shall be used to represent capabilities 683 attribute in XML. 685 6.7. Media Stream 687 Participant 688 | 0..* 1..*| 689 receives| |sends 690 | 0..* 0..*| 691 +-------------------------+ 692 | Media Stream | 693 | | 694 Communication 1..* 0..* +-------------------------+ 695 Session ------------| | 696 | Media Stream Reference | 697 | Content-type | 698 | | 699 +-------------------------+ 701 A Media Stream class (and its objects) has the properties of media as 702 seen by SRC and sent to SRS. Different snapshots of media stream 703 object may be sent whenever there is a change in media (e.g. dir 704 change like pause/resume and/or codec change and/or participant 705 change.). 707 6.7.1. Attributes 709 A Media Stream class has the the following attributes: 711 o Media Stream Reference - In implementations this can reference to 712 m-line 713 o Content - The content of an MS element will be described in terms 714 of value from the [RFC4796] registry. 716 The metadata model should include media streams that are not being 717 delivered to the SRS. Examples include cases where SRC offered 718 certain media types but SRS chooses to accept only a subset of them 719 OR an SRC may not even offer a certain media type due it its 720 restrictions to record 722 6.7.2. Linkages 724 A Media Stream is linked to participant and CS classes using the 725 association relationship. The details of association with the 726 Participant are described in the Participant class section. The 727 details of association with CS is mentioned in the CS section. 729 6.7.3. XML element 731 stream element represents a Media Stream object. Stream element 732 indicates SDP media lines associated with the session and 733 participants. 735 This element indicates the SDP m-line properties like label 736 attributes, media mode. Label attribute is used to link m-line SDP 737 body using label attribute in SDP m-line. The media mode helps in 738 understanding whether the media is mixed or not. 740 Each stream element has unique Base 64 URN UUID attribute which helps 741 to uniquely identify stream and session Base 64 URN UUID to associate 742 stream with specific session element. 744 The content attribute if an SRC wishes to send is conveyed in RS SDP. 746 6.8. ParticipantStream Association 747 +-------------------+ 748 | ParticipantSteam | 749 | Association | 750 +-------------------+ +----------Participant 751 | Association-Time | | 0..*| 1..*| 752 | Disassociaton-Time|---+ recv| |sends 753 | Recv | | 0..*| 0..*| 754 | Send | | | | 755 +-------------------+ | | | 756 +----------Media Stream 758 A ParticipantStream association class and its object has attributes 759 that are attributes of association of a Participant to a Stream. 761 6.8.1. Attributes 763 A participantStream association class has the following attributes: 765 o Associate-Time: This attributes indicates the time a Participant 766 started contributing to a Media Stream 767 o Disassociate-Time: This attribute indicates the time a Participant 768 stopped contributing to a Media Stream 770 6.8.2. Linkages 772 The participantStream association class is linked to participant and 773 Stream classes. There are no cardinalties for this linkage. 775 6.8.3. XML element 777 ParticipantStreamAssoc XML element represents participant to stream 778 association object. participant element is used to uniquely identify 779 this element and related with stream using stream unique URN id.. 781 6.9. associate-time/disassociate-time 783 associate-time/disassociate-time contains a string indicating the 784 date and time of the status change of this tuple. The value of this 785 element MUST follow the IMPP datetime format [RFC3339]. Timestamps 786 that contain 'T' or 'Z' MUST use the capitalized forms. At a time, 787 any of the time tuple associate-time or disassociate-time MAY exist 788 in the element namely group, session, participant and not both 789 timestamp at the same time. 791 As a security measure, the timestamp element SHOULD be included in 792 all tuples unless the exact time of the status change cannot be 793 determined. 795 6.10. Unique ID format 797 Unique id is generated in two steps: 798 o UUID is created using [RFC4122]) 799 o UUID is encoded using base64 as defined in [RFC4648] 801 The above mentioned unique-id mechanism SHOULD be used for each 802 metadata element. 804 7. SIP Recording Metadata Example 806 7.1. Complete SIP Recording Metadata Example 808 The following example provides all the tuples involved in Recording 809 Metadata XML body. 811 812 813 complete 814 815 2010-12-16T23:41:07Z 816 817 818 sip:pravindran@sonusnet.com 819 FaXHlc+3WruaroDaNE87am== 820 821 822 FOO! 823 bar 824 825 826 827 7+OTCyoxTmqmqyA/1weDAg== 828 829 2010-12-16T23:41:07Z 830 831 FOO! 832 bar 833 834 837 838 RamMohan R 840 841 842 FOO! 843 bar 844 845 848 2010-12-16T23:41:07Z 849 850 852 i1Pz3to5hGk8fuXl+PbwCw== 853 UAAMm5GRQKSCMVvLyl4rFw== 854 8zc6e0lYTlWIINA6GR+3ag== 855 EiXGlc+4TruqqoDaNE76ag== 856 857 860 861 Paul Kyzivat 862 863 864 FOO! 865 bar 866 867 870 2010-12-16T23:41:07Z 871 872 874 8zc6e0lYTlWIINA6GR+3ag== 875 EiXGlc+4TruqqoDaNE76ag== 876 UAAMm5GRQKSCMVvLyl4rFw== 877 i1Pz3to5hGk8fuXl+PbwCw== 878 879 881 882 883 885 886 887 889 890 891 893 894 895 897 SIP Recording Metadata Example XML body 899 7.2. Partial Update of Recording metadata XML body 901 The following example provides partial update in Recording Metadata 902 XML body for the above example. The example has a snapshot that 903 carries the disassociate-time for a participant from a session. 905 906 907 partial 908 911 912 Parathasarathi R 913 914 FOO! 915 bar 916 917 920 2010-12-16T23:41:07Z 921 922 924 Partial update of SIP Recording Example XML body 926 8. XML Schema definition for Recording metadata 928 This section defines XML schema for Recording metadata document 930 931 936 937 938 939 940 941 943 945 947 949 951 955 956 957 958 959 961 963 967 968 970 971 972 973 975 977 981 982 984 985 986 987 989 991 995 996 998 999 1000 1001 1003 1007 1008 1010 1012 1013 1014 1015 1017 1019 1023 1024 1026 1028 1029 1030 1031 1033 1035 1039 1040 1042 1043 1044 1045 1047 1049 1051 1053 1057 1058 1060 1062 1063 1064 1065 1066 1067 1068 1070 1071 1072 1073 1074 1075 1077 1078 1079 1080 1081 1082 1083 1085 1087 9. Security Considerations 1089 The metadata information sent from SRC to SRS MAY reveal sensitive 1090 information about different participants in a session. For this 1091 reason, it is RECOMMENDED that a SRC use a strong means for 1092 authentication and metadata information protection and that it apply 1093 comprehensive authorization rules when using the metadata format 1094 defined in this document. The following sections will discuss each 1095 of these aspects in more detail. 1097 9.1. Connection Security 1099 It is RECOMMENDED that a SRC authenticate SRS using the normal SIP 1100 authentication mechanisms, such as Digest as defined in Section 22 of 1101 [RFC3261]. The mechanism used for conveying the metadata information 1102 MUST ensure integrity and SHOULD ensure confidentially of the 1103 information. In order to achieve these, an end-to-end SIP encryption 1104 mechanism, such as S/MIME described in [RFC3261], SHOULD be used. 1106 If a strong end-to-end security means (such as above) is not 1107 available, it is RECOMMENDED that a SRC use mutual hop-by-hop 1108 Transport Layer Security (TLS) authentication and encryption 1109 mechanisms described in "SIPS URI Scheme" and "Interdomain Requests" 1110 of [RFC3261]. 1112 10. IANA Considerations 1114 This specification registers a new XML namespace, and a new XML 1115 schema. 1117 10.1. SIP recording metadata Schema Registration 1119 URI: urn:ietf:params:xml:ns:recording 1121 Registrant Contact: IETF SIPREC working group, Ram mohan 1122 R(rmohanr@cisco.com) 1124 XML: the XML schema to be registered is contained in Section 6. 1126 Its first line is and its last 1127 line is 1129 11. Acknowledgement 1131 We wish to thank John Elwell(Siemens-Enterprise), Henry Lum(Alcatel- 1132 Lucent), Leon Portman(Nice), De Villers, Andrew Hutton(Siemens- 1133 Enterprise), Deepanshu Gautam(Huawei), Charles Eckel(Cisco), Muthu 1134 Arul(Cisco), Michael Benenson(Cisco), Hadriel Kaplan (ACME), Brian 1135 Rosen(Neustar), Scott Orton(Broadsoft) for their valuable comments 1136 and inputs. 1138 We wish to thank Joe Hildebrand(Cisco), Peter Saint-Andre(Cisco) for 1139 the valuable XML related guidance and Martin Thompson for validating 1140 the XML schema and providing comments on the same. 1142 12. Appendix A: Metadata Model Object Instances 1144 This section describes the metadata model object instances for 1145 different use cases of SIPREC. For the sake of simplicity as the 1146 media streams sent by each of the participants is received by every 1147 other participant in these use cases, it is NOT shown in the object 1148 instance diagrams below. Also for the sake of ease not all 1149 attributes of each object are shown in these instance diagrams. 1151 12.1. Use case 1: Basic Call 1153 Basic call between two Participants A and B. In this use case each 1154 participant sends one Media Stream. For the sake of simplicity 1155 "receives" lines are not shown in this instance diagram. Media 1156 Streams sent by each participant is received all other participants 1157 of that CS. 1159 +-------------------------------+ 1160 | Recording Session (RS) | 1161 +-------------------------------+ 1162 | 1163 | 1164 | 1165 +----------------+ 1166 | Communication | 1167 | Session (CS) | 1168 +----------------+-----------------------+ 1169 | Start Time | | 1170 +----------------+ | 1171 | | 1172 |-------------------+ | 1173 | | | 1174 +---------------+ +---------------+ | 1175 | ParticipantA | | ParticipantB | | 1176 | | | | | 1177 +---------------+ +---------------+ | 1178 | | | 1179 sends | | sends | 1180 | | | 1181 +---------------+ +---------------+ | 1182 |Media Stream A1| |Media Stream B1| | 1183 +---------------+ +---------------+ | 1184 |MediaStream Ref| |MediaStream Ref| | 1185 | | | | | 1186 +---------------+ +---------------+ | 1187 | | | 1188 +-----------------------------------+ 1190 12.2. Use case 2: Hold/Resume 1192 Basic call between two Participants A and B and with Participant A or 1193 B doing a Hold/Resume. In this use case each participant sends one 1194 Media Stream. After Hold/Resume the properties of Media can change. 1195 For the sake of simplicity "receives" lines are not shown in this 1196 instance diagram. Media Streams sent by each participant is received 1197 all other participants of that CS. 1199 +-------------------------------+ 1200 | Recording Session (RS) | 1201 +-------------------------------+ 1202 | | 1203 | | 1204 | | 1205 | +-------------------------------+ 1206 | | Communication Session (CS) | 1207 | +-----------| Group(CSG) | 1208 | | +-------------------------------+ 1209 | | | Unique-id1 | 1210 | | +-------------------------------+ 1211 | | 1212 | | 1213 | | 1214 +----------------+ 1215 | Communication | 1216 +-| Session (CS) |----------------------------------------------+ 1217 | +----------------+ | 1218 | | | | 1219 | +----------------+ | 1220 | | | 1221 | |-------------------+ | 1222 | | | | 1223 | +---------------+ +---------------+ | 1224 | | ParticipantA | | ParticipantB |-----------+ | 1225 | | |--+ | | | | 1226 | +---------------+ | +---------------+ |sends(After | 1227 | | | | | | | Resume) | 1228 | | | | | | +--------------+ | 1229 | sends | | +--+ | sends | |MediaStream B3| | 1230 | | -----+ | | +-----+ +--------------+ | 1231 | +---------------+ | | +---------------+ | |MediaStreamRef|-| 1232 | |Media Stream A1| | | |Media Stream B1| | | | | 1233 | +---------------+ | | +---------------+ | | | | 1234 +-|MediaStreamref | | | |MediaStreamRef | | +--------------+ | 1235 | | | | | |-|-------------------| 1236 +---------------+ | | +---------------+ | | 1237 | | | | 1238 +------------+ |sends |sends (hold) | 1239 | sends |(Resume) | | 1240 | (hold) +-------+ +-------+ | 1241 | | | | 1242 +---------------+ +---------------+ +--------------+ | 1243 |Media Stream A2| |Media Stream A3| |MediaStream B2| | 1244 +---------------+ +---------------+ | | | 1245 |MediaStreamref | |MediaStreamRef | +--------------+ | 1246 | | | | |Codec Params | | 1247 +---------------+ +---------------+ | | | 1248 | | | | | 1249 | | +--------------+ | 1250 | | | | 1251 +------------------------------------------------------+ 1253 12.3. Use case 3: Basic call with Transfer 1255 Basic call between two Participants A and B and with Participant A 1256 transfer(consult transfer) to Participant C. In this use case each 1257 participant sends one Media Stream. After transfer the properties of 1258 Participant A Media can change. For the sake of simplicity 1259 "receives" lines are not shown in this instance diagram. Media 1260 Streams sent by each participant is received all other participants 1261 of that CS. 1263 +-------------------------------+ 1264 | Recording Session (RS) |-------+ 1265 +-------------------------------+ | 1266 | | 1267 | | 1268 | | 1269 +-------------------------------+ | 1270 | Communication Session (CS) | | 1271 | Group(CSG) | | 1272 +-------------------------------+ | 1273 | Unique-id1 | | 1274 +-------------------------------+ | 1275 | | 1276 |----------------------------+ 1277 | 1278 |-----------------+ 1279 | | 1280 +----------------+ +----------------+ 1281 | Communication | | Communication | 1282 | Session (CS)1 | | Session (CS)2 | 1283 +----------------+ +----------------+-----------+ 1284 | | | | | 1285 +----------------+ +----------------+ | 1286 | | 1287 |-------------------+ | 1288 | | | | 1289 +---------------+ | +---------------+ | 1290 | ParticipantA | | | ParticipantB | | 1291 | | | | | | 1292 +---------------+ | +---------------+ | 1293 | | | | 1294 sends | | | sends | 1295 | | | | 1296 +---------------+ | +---------------+ | 1297 |Media Stream A1| | |Media Stream B1| | 1298 +---------------+ | +---------------+ | 1299 | | | | | | 1300 | | | | Media Stream | | 1301 | Media Stream |---+---| Ref | | 1302 | Ref | | | | 1303 +---------------+ +---------------+ | 1304 | 1305 | 1306 +----------------------------| 1307 | | 1308 +--------------------------------+ | 1309 | | | 1310 +---------------+ +---------------+ | 1311 | Participant A | | Participant C | | 1312 | (same) | | | | 1313 +---------------+ +---------------+ | 1314 | | | 1315 | sends (After transfer) | sends | 1316 +----------------+ +----------------+| 1317 | Media Stream A2| | Media Stream C1|| 1318 +----------------+ +----------------+| 1319 | Media StreamRef| | Media StreamRef|| 1320 | | | || 1321 | | | || 1322 +----------------+ +----------------+| 1323 | | | 1324 | | | 1325 | | | 1326 +-------------------------------------------+ 1328 12.4. Conference Use Cases 1330 Depending on who act as SRC and the information that an SRC has there 1331 can be several ways to model conference use cases. This section has 1332 instance diagrams for the following cases: 1334 o A CS where one of the participant (which is also SRC) is a user in 1335 a conference 1336 o A CS where one of the participant is focus ( which is also SRC) 1337 o A CS where one of the participant is user and the SRC is a 1338 different entity like B2BUA 1339 o A CS where one of the participant is focus and the SRC is a 1340 different entity like B2BUA 1342 NOTE: There MAY be other ways to model the same use cases depending 1343 on what information the SRC has. 1345 12.4.1. Case 1: 1347 This is the usecase where there is a CS with one of the participant 1348 (who is also SRC) as a user in a conference. For the sake of 1349 simplicity the receive lines for each of the participant is not 1350 shown. 1352 +---------------------------------------------------+ 1353 | Communication Session | 1354 | +-------------+ +--------------+ | 1355 | | | | | | 1356 | |Participant B| | Participant A| | 1357 | | (User in |--------------| | | 1358 | | conf/SRC) | | | | 1359 | +-------------+ +--------------+ | 1360 | | | | | | 1361 +---------------------------------------------------+ 1362 | | | | 1363 | | | | 1364 D E F G (Participants of Conference) 1366 Instance Diagram: 1368 +-------------------------------+ 1369 | Recording Session (RS) |--+ 1370 +-------------------------------+ | 1371 | | 1372 | | 1373 | | 1374 +-------------------------------+ | 1375 | Communication Session (CS) | | 1376 | Group(CSG) | | 1377 +-------------------------------+ | 1378 | Unique-id1 | | 1379 +-------------------------------+ | 1380 | | 1381 |-----------------------+ 1382 | 1383 +----------------+ 1384 | Communication | 1385 | Session (CS) |--+----------------+-----+ 1386 +----------------+ | | | 1387 | | | | | 1388 +----------------+ | | | 1389 | | | | 1390 | | | | 1391 | | | | 1392 +---------------+ | | | 1393 | ParticipantA | | | | 1394 | | | | | 1395 +---------------+ | | | 1396 | | | | 1397 sends | | | | 1398 | | | | 1399 +---------------+ | | | 1400 |Media Stream A1| | | | 1401 +---------------+ | | | 1402 |MediaStream Ref|-----|----------------+ | 1403 | | | | | 1404 +---------------+ | | | 1405 | | | 1406 | | | 1407 +-------------+ | | 1408 | | | 1409 | | | 1410 +----------------+ | | 1411 | Participant B | | | 1412 | (in conf) | | | 1413 +----------------+ | | 1414 | | | 1415 sends | | | 1416 | | | 1417 +----------------+ | | 1418 | Media Stream B1|---------------------+ | 1419 +----------------+ sends | 1420 | MediaStream Ref| | 1421 | | +-----------------+ 1422 +----------------+ | 1423 | | 1424 |sends | 1425 | | 1426 +-----------------+-------------+------------+ 1427 | | | | 1428 | | | | 1429 +------------+ +------------+ +------------+ +-------------+ 1430 |participantD| |ParticipantE| |ParticipantF| |Participant G| 1431 +------------+ +------------+ +------------+ +-------------+ 1433 In this example we have two participants A and B who are part of a 1434 Communication Session(CS). One of the participants B is part of a 1435 conference and also acts as SRC.There can be two cases here. B can 1436 be a participant of the conference or B can be a focus. In this 1437 instance diagram Participant B is a user in a conference. The SRC 1438 (Participant B) subscribes to conference event package to get the 1439 details of other particiants. Participant B(SRC) sends the same 1440 through the metadata to SRS. In this instance diagram the Media 1441 Stream(mixed stream) sent from Participant B has media streams 1442 contributed by conference participants (D,E,F and G). For the sake 1443 of simplicity the "receives" line is not shown here. In this example 1444 the media stream sent by each participant(A or B) of CS is received 1445 by all other participant(A or B). 1447 12.4.2. Case 2: 1449 This is the usecase where there is a CS where one of the participant 1450 is focus ( which is also SRC). 1452 +---------------------------------------------------+ 1453 | Communication Session | 1454 | +--------------+ +--------------+ | 1455 | | |--------------| | | 1456 | |Participant C | | Participant A| | 1457 | | (Focus in |------+ | | | 1458 | | conf and SRC)|---+ | +--------------+ | 1459 | +--------------+ | | | 1460 | | | +---------+ | 1461 | | | | | 1462 | +--------------+ | +---------------+ | 1463 | | Participant B| +---+ | Participant D | | 1464 | | | | | | | 1465 | +--------------+ | +---------------+ | 1466 | | | 1467 | +--------------+ | 1468 | |Participant E | | 1469 | | | | 1470 | +--------------+ | 1471 | | 1472 +---------------------------------------------------+ 1474 Instance Diagram: 1476 +-------------------------------+ 1477 | Recording Session (RS) | 1478 +-------------------------------+ 1479 |-------------------------+ 1480 | | 1481 | | 1482 +-------------------------------+ | 1483 | Communication Session (CS) | | 1484 | Group(CSG) | | 1485 +-------------------------------+ | 1486 | Unique-id1 | | 1487 +-------------------------------+ | 1488 | | 1489 |-------------------------+ 1490 | 1491 +----------------+ 1492 | Communication | 1493 | Session (CS) |----------------------+ 1494 +----------------+ | 1495 | | | 1496 +----------------+ | 1497 | | 1498 |-------------------+ | 1499 | | | | 1500 +---------------+ | +---------------+ | 1501 | ParticipantA | | | ParticipantB | | 1502 | | | | | | 1503 +---------------+ | +---------------+ | 1504 | | | | 1505 sends | | | sends | 1506 | | | | 1507 +---------------+ | +---------------+ | 1508 |Media Stream A1| | |Media Stream B1| | 1509 +---------------+ | +---------------+ | 1510 |MediaStream Ref| | |MediaStream Ref| | 1511 | |---+---| | | 1512 +---------------+ +---------------+ | 1513 | 1514 +----------------------------------+ 1515 | | | | 1516 | | | | 1517 +---------------+ | +---------------+ | 1518 | ParticipantD | | | ParticipantE | | 1519 | | | | | | 1520 +---------------+ | +---------------+ | 1521 | | | | 1522 sends | | | sends | 1523 | | | | 1524 +---------------+ | +---------------+ | 1525 |Media Stream D1| | |Media Stream E1| | 1526 +---------------+ | +---------------+ | 1527 |MediaStream Ref| | |MediaStream Ref| | 1528 | |---+---| | | 1529 +---------------+ +---------------+ | 1530 | 1531 | 1532 +----------+ 1533 +-----------------| 1534 | | 1535 | | 1536 +----------------+ | 1537 | Participant C | | 1538 | (focus +src) | | 1539 +----------------+ | 1540 | | 1541 Sends | +-------+ 1542 | | 1543 "sends" OR | | 1544 contributed +----------------+ 1545 by | Media Stream C1| 1546 Participants+----------------+ "receives" by participants A,B,D,E 1547 A,B,D,E | MediaStream Ref|------------------------------------ 1548 ------------| Codec Params | 1549 +----------------+ 1551 In this example we have two participants A and B who are part of a 1552 Communication Session(CS). One of the participants (C) is focus of a 1553 conference and also acts as SRC. The SRC (Participant C) being the 1554 Focus of the conference has access to the details of other 1555 particiants. SRC (Participant C) sends the same through the metadata 1556 to SRS. In this instance diagram the Media Stream(mixed stream) sent 1557 by C has media streams contributed by conference participants (A, B, 1558 D and E). Participants A, B,D and E sends Media Streams A1, B1, D1 1559 and E1 respectively. The media stream sent by Participant C(Focus) 1560 is received by all other participants of CS. For the sake of 1561 simplicity the "receives" line is not shown linked to all other 1562 participants. 1564 NOTE: SRC ( Participant C) can send mixed stream or seperate streams 1565 to SRS 1567 12.4.3. Case 3: 1569 A CS where one of the participant is user and the SRC is a different 1570 entity like B2BUA. In this case the SRC may not know that one of the 1571 user is part of conference. Hence the instance diagram will not have 1572 information about the conference participants. 1574 +---------------------------------------------------+ 1575 | Communication Session | 1576 | +-------------+ +------+ +--------------+ | 1577 | | | | (SRC)| | | | 1578 | |Participant B|--|B2BUA |----| Participant A| | 1579 | | (User in | +------+ | | | 1580 | | conf) | | | | 1581 | +-------------+ +--------------+ | 1582 | | | | | | 1583 +---------------------------------------------------+ 1584 | | | | 1585 | | | | 1586 D E F G (Participants of Conference) 1588 12.4.4. Case 4: 1590 A CS where one of the participant is focus and the SRC is a different 1591 entity like B2BUA. In this case the participant which is focus sends 1592 "isfocus" in SIP message to SRC. The SRC subscribe to conference 1593 event package on seeing this "isfocus". SRC learns the details of 1594 other participants of conference from the conference package and send 1595 the same in metadata to SRS. The instance diagram for this use case 1596 is same as Case 1. 1598 +--------------------------------+ 1599 | Conference Event Package | 1600 | | 1601 +--------------------------------+ 1602 | 1603 | subscribes 1604 | 1605 +---------------------|-----------------------------+ 1606 | Communication |Session | 1607 | +-------------+ +------+ +--------------+ | 1608 | | | | (SRC)| | | | 1609 | |Participant B|--|B2BUA |----| Participant A| | 1610 | | (FOCUS in | +------+ | | | 1611 | | conf) | | | | 1612 | +-------------+ +--------------+ | 1613 | | | | | | 1614 +---------------------------------------------------+ 1615 | | | | 1616 | | | | 1617 D E F G (Participants of Conference) 1619 13. Appendix B: Metadata XML schema Instances 1621 This section describes the metadata model XML instances for different 1622 use cases of SIPREC. For the sake of simplicity the complete SIP 1623 messages are NOT shown here. 1625 13.1. Use case 1: Basic Call 1627 Basic call between two Participants A(Ram) and B(Partha) who are part 1628 of one session. In this use case each participant sends two Media 1629 Streams. Media Streams sent by each participant is received all 1630 other participants of that CS in this use-case. Below is the initial 1631 snapshot sent by SRC that has complete metadata. For the sake of 1632 completeness even snippets of SDP is shown. For the sake of 1633 simplicity these use-cases assume the RS stream is unmixed. 1635 Content-Type: application/SDP 1636 ... 1637 m=audio 49170 RTP/AVP 0 1638 a=rtpmap:0 PCMU/8000 1639 a=label:96 1640 a=sendonly 1641 ... 1642 m=video 49174 RTP/AVPF 96 1643 a=rtpmap:96 H.264/90000 1644 a=label:97 1645 a=sendonly 1646 ... 1647 m=audio 51372 RTP/AVP 0 1648 a=rtpmap:0 PCMU/8000 1649 a=label:98 1650 a=sendonly 1651 ... 1652 m=video 49176 RTP/AVPF 96 1653 a=rtpmap:96 H.264/90000 1654 a=label:99 1655 a=sendonly 1656 .... 1657 1658 1659 complete 1660 1661 2010-12-16T23:41:07Z 1662 1663 1664 sip:alice@cisco.com 1665 1666 1667 FOO! 1668 bar 1669 1670 1671 1672 7+OTCyoxTmqmqyA/1weDAg== 1673 1674 2010-12-16T23:41:07Z 1675 1676 FOO! 1677 bar 1678 1679 1682 1683 RamMohan R 1684 1685 1686 FOO! 1687 bar 1688 1689 1692 2010-12-16T23:41:07Z 1693 1694 1696 i1Pz3to5hGk8fuXl+PbwCw== 1697 UAAMm5GRQKSCMVvLyl4rFw== 1698 8zc6e0lYTlWIINA6GR+3ag== 1699 EiXGlc+4TruqqoDaNE76ag== 1700 1701 1704 1705 Parthasarathi R 1706 1707 1708 FOO! 1709 bar 1710 1711 1715 2010-12-16T23:41:07Z 1716 1717 1719 8zc6e0lYTlWIINA6GR+3ag== 1720 EiXGlc+4TruqqoDaNE76ag== 1721 UAAMm5GRQKSCMVvLyl4rFw== 1722 i1Pz3to5hGk8fuXl+PbwCw== 1723 1724 1726 1727 1728 1730 1731 1732 1734 1735 1736 1738 1739 1740 1742 13.2. Use case 2: Hold/resume 1744 Basic call between two Participants A and B. This is the continuation 1745 of above use-case. One of the participants(say A) goes on hold and 1746 then resumes as part of the same session. The metadata snapshot 1747 looks as below 1749 During hold 1750 Content-Type: application/SDP 1751 ... 1752 m=audio 49170 RTP/AVP 0 1753 a=rtpmap:0 PCMU/8000 1754 a=label:96 1755 a=inactive 1756 ... 1757 m=video 49174 RTP/AVPF 96 1758 a=rtpmap:96 H.264/90000 1759 a=label:97 1760 a=inactive 1761 ... 1762 m=audio 51372 RTP/AVP 0 1763 a=rtpmap:0 PCMU/8000 1764 a=label:98 1765 a=sendonly 1766 ... 1767 m=video 49176 RTP/AVPF 96 1768 a=rtpmap:96 H.264/90000 1769 a=label:99 1770 a=sendonly 1771 .... 1773 1774 1775 partial 1776 1779 8zc6e0lYTlWIINA6GR+3ag== 1780 EiXGlc+4TruqqoDaNE76ag== 1781 1782 1785 8zc6e0lYTlWIINA6GR+3ag== 1786 EiXGlc+4TruqqoDaNE76ag== 1787 1789 1791 During resume 1793 The snapshot will look pretty much same as Use-case 1. 1795 13.3. Use case 3: Basic Call with transfer 1797 Basic call between two Participants A and B is connected as in Use- 1798 case 1. Transfer is initiated by one of the participants of by other 1799 entity(3PCC case). SRC sends a snapshot of the participant changes 1800 to SRS. In this instance participant A(Ram) drops out during the 1801 transfer and Participant C(Paul) joins the session. There can be two 1802 cases here, same session continues after transfer or a new session 1803 (e.g. REFER based transfer) is created 1805 Transfer with same session retained - (.e.g. RE-INVITE based 1806 transfer). Participant A drops out and C is added to the same 1807 session. No change to session/group element. C will be new stream 1808 element which maps to RS SDP using the same labels in this instance. 1810 Content-Type: application/SDP 1811 ... 1812 m=audio 49170 RTP/AVP 0 1813 a=rtpmap:0 PCMU/8000 1814 a=label:96 1815 a=sendonly 1816 ... 1817 m=video 49174 RTP/AVPF 96 1818 a=rtpmap:96 H.264/90000 1819 a=label:97 1820 a=sendonly 1821 ... 1822 m=audio 51372 RTP/AVP 0 1823 a=rtpmap:0 PCMU/8000 1824 a=label:98 1825 a=sendonly 1826 ... 1827 m=video 49176 RTP/AVPF 96 1828 a=rtpmap:96 H.264/90000 1829 a=label:99 1830 a=sendonly 1831 .... 1832 1833 1834 partial 1835 1837 8zc6e0lYTlWIINA6GR+3ag== 1838 EiXGlc+4TruqqoDaNE76ag== 1839 60JAJm9UTvik0Ltlih/Gzw== 1840 AcR5FUd3Edi8cACQJy/3JQ== 1841 1842 1845 1846 Paul Kyzivat 1847 1848 60JAJm9UTvik0Ltlih/Gzw== 1849 AcR5FUd3Edi8cACQJy/3JQ== 1850 8zc6e0lYTlWIINA6GR+3ag== 1851 EiXGlc+4TruqqoDaNE76ag== 1852 2010-12-16T23:41:07Z 1853 1854 FOO! 1855 bar 1856 1857 1860 2010-12-16T23:41:07Z 1861 1862 1864 60JAJm9UTvik0Ltlih/Gzw== 1865 AcR5FUd3Edi8cACQJy/3JQ== 1866 8zc6e0lYTlWIINA6GR+3ag== 1867 EiXGlc+4TruqqoDaNE76ag== 1868 1869 1871 1872 1873 1875 1876 1877 1879 1880 1881 1883 1884 1885 1887 Transfer with new session - (.e.g. REFER based transfer). In this 1888 case new session is part of same grouping (done by SRC). 1890 SRC may send an optional snapshot indicating stop for the old 1891 session. 1893 1894 1895 Partial 1896 1897 7+OTCyoxTmqmqyA/1weDAg== 1898 1899 2010-12-16T23:41:07Z 1900 1901 FOO! 1902 bar 1903 1904 1907 2010-12-16T23:41:07Z 1908 1909 1912 2010-12-16T23:41:07Z 1913 1914 1916 SRC sends a snapshot to indicate the participant change and new 1917 session information after transfer. In this example the same RS is 1918 used. 1920 Content-Type: application/SDP 1921 ... 1922 m=audio 49170 RTP/AVP 0 1923 a=rtpmap:0 PCMU/8000 1924 a=label:96 1925 a=sendonly 1926 ... 1927 m=video 49174 RTP/AVPF 96 1928 a=rtpmap:96 H.264/90000 1929 a=label:97 1930 a=sendonly 1931 ... 1932 m=audio 51372 RTP/AVP 0 1933 a=rtpmap:0 PCMU/8000 1934 a=label:98 1935 a=sendonly 1936 ... 1937 m=video 49176 RTP/AVPF 96 1938 a=rtpmap:96 H.264/90000 1939 a=label:99 1940 a=sendonly 1941 .... 1942 1943 1944 partial 1945 1946 7+OTCyoxTmqmqyA/1weDAg== 1947 1948 2010-12-16T23:41:07Z 1949 1950 FOO! 1951 bar 1952 1953 1956 1957 1958 FOO! 1959 bar 1960 1961 1964 2010-12-16T23:32:03Z 1965 1966 1968 8zc6e0lYTlWIINA6GR+3ag== 1969 EiXGlc+4TruqqoDaNE76ag== 1970 60JAJm9UTvik0Ltlih/Gzw== 1971 AcR5FUd3Edi8cACQJy/3JQ== 1972 1973 1976 1977 1978 FOO! 1979 bar 1980 1981 1984 2010-12-16T23:41:07Z 1985 1986 1988 60JAJm9UTvik0Ltlih/Gzw== 1989 AcR5FUd3Edi8cACQJy/3JQ== 1990 8zc6e0lYTlWIINA6GR+3ag== 1991 EiXGlc+4TruqqoDaNE76ag== 1992 1993 1995 1996 1997 1999 2000 2001 2003 2004 2005 2007 2008 2009 2011 13.4. Use Case 4: Call disconnect 2013 This example shows a snapshot of metadata sent by an SRC at CS 2014 disconnect where the participants of CS are Ram and Partha 2015 2016 2017 Partial 2018 2019 7+OTCyoxTmqmqyA/1weDAg== 2020 2021 2010-12-16T23:41:07Z 2022 2023 FOO! 2024 bar 2025 2026 2029 2030 2010-12-16T23:41:07Z 2031 2033 2036 2037 2010-12-16T23:41:07Z 2038 2039 2041 14. References 2043 14.1. Normative References 2045 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2046 Requirement Levels", BCP 14, RFC 2119, March 1997. 2048 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 2050 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2051 A., Peterson, J., Sparks, R., Handley, M., and E. 2052 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2053 June 2002. 2055 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2056 January 2004. 2058 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 2059 Internet: Timestamps", RFC 3339, July 2002. 2061 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2062 Description Protocol", RFC 4566, July 2006. 2064 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 2065 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 2067 [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description 2068 Protocol (SDP) Content Attribute", RFC 4796, 2069 February 2007. 2071 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 2072 "Indicating User Agent Capabilities in the Session 2073 Initiation Protocol (SIP)", RFC 3840, August 2004. 2075 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 2076 Unique IDentifier (UUID) URN Namespace", RFC 4122, 2077 July 2005. 2079 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2080 Encodings", RFC 4648, October 2006. 2082 14.2. Informative References 2084 [RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use 2085 Cases and Requirements for SIP-Based Media Recording 2086 (SIPREC)", RFC 6341, August 2011. 2088 [I-D.ietf-siprec-architecture] 2089 Hutton, A., Portman, L., Jain, R., and K. Rehor, "An 2090 Architecture for Media Recording using the Session 2091 Initiation Protocol", draft-ietf-siprec-architecture-04 2092 (work in progress), March 2012. 2094 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 2095 August 1999. 2097 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 2098 Header Field for the Session Initiation Protocol (SIP)", 2099 RFC 3326, December 2002. 2101 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 2102 Extensions to the Session Initiation Protocol (SIP) for 2103 Asserted Identity within Trusted Networks", RFC 3325, 2104 November 2002. 2106 Authors' Addresses 2108 Ram Mohan Ravindranath 2109 Cisco Systems, Inc. 2110 Cessna Business Park, 2111 Kadabeesanahalli Village, Varthur Hobli, 2112 Sarjapur-Marathahalli Outer Ring Road 2113 Bangalore, Karnataka 560103 2114 India 2116 Email: rmohanr@cisco.com 2118 Parthasarathi Ravindran 2119 Sonus Networks 2120 Prestige Shantiniketan - Business Precinct 2121 Whitefield Road 2122 Bangalore, Karnataka 560066 2123 India 2125 Email: pravindran@sonusnet.com 2127 Paul Kyzivat 2128 Unaffiliated 2129 Boxborough, MA 2130 USA 2132 Email: pkyzivat@alum.mit.edu