idnits 2.17.1 draft-ietf-siprec-metadata-09.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 (November 6, 2012) is 4188 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-06 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: May 10, 2013 Nokia Siemens Networks 5 Paul. Kyzivat 6 Huawei 7 November 6, 2012 9 Session Initiation Protocol (SIP) Recording Metadata 10 draft-ietf-siprec-metadata-09 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 May 10, 2013. 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 . . . . . . . . . . . . . . . . . . . . . 26 107 10.1. SIP recording metadata Schema Registration . . . . . . . . 26 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 | CSRS | | | Session (CS) | 186 | Association|--+ | Group | 187 | | | +-----------------+ 188 +------------+ | | 0..1 189 | | 190 |0..* | 1..* 191 +-------------------------------+ 192 | Communication Session (CS) | 193 | | 194 +-------------------------------+ 195 | 1..* |0..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 be present in all recording metadata XML document. recording 260 acts 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 be 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 | Start-time | 422 | Stop-time | 423 +-------------------------------+ 424 | | 425 | 0..* |0..1 426 | | 427 | 0..* |0..* 428 Participant Media Stream 430 A Communication Session class and its object in the metadata model 431 represents Communication Session and its properties needed as seen by 432 SRC. 434 6.3.1. Attributes 436 A communication Session class has the following attributes: 438 o Termination Reason - This represents the reason why a CS was 439 terminated. The communication session MAY contain a Call 440 Termination Reason. This MAY be derived from SIP Reason header 441 [RFC3326] of CS. 442 o CS Identifier - This attribute is used to uniquely identify a CS. 443 o Start-time - This optional attribute represents start time of CS 444 as seen by SRC 445 o Stop-time - This optional attribute represents stop time of CS as 446 seen by SRC 448 This document does not specify attributes relating to what should 449 happen to a recording of a CS after it has been delivered to the SRS, 450 e.g., how long to retain the recording, what access controls to 451 apply. The SRS is assumed to behave in accordance with policy. The 452 ability for the SRC to influence this policy is outside the scope of 453 this document. However if there are implementations where SRC has 454 enough information, this could be sent as Extension Data attached to 455 CS 457 6.3.2. Linkages 459 A Communication Session is linked to CS-Group, Participant, Media 460 Stream and Recording Session classes using the association 461 relationship. Association between CS and Participant allows: 463 o CS to have atleast zero or more participants 464 o Participant is associated with zero or more CSs. This includes 465 participants who are not directly part of any CS. An example of 466 such a case is participants in a premixed media stream. The SRC 467 may have knowledge of such Participants, yet not have any 468 signaling relationship with them. This might arise if one 469 participant in CS is a conf focus. To summarize even if SRC does 470 not have direct signalling relationships with all participants in 471 a CS, it should nevertheless create a Participant object for each 472 participant that it knows about. 473 o The model also allows participants in CS that are not participants 474 in the media. An example is the identity of a 3pcc controller 475 that has initiated a CS to two or more participants of the CS. 476 Another example is the identity of a conference focus. Of course 477 a focus is probably in the media, but since it may only be there 478 as a mixer, it may not report itself as a participant in any of 479 the media streams. 481 Association between CS and Media Stream allows: 483 o A CS to have zero or more Streams 484 o A stream can be associated with at most one CS. Stream in 485 persistent RS is not required to be associated with any CS before 486 CS is created and hence the zero association is allowed. 488 Association between CS and RS allows: 490 o Each instance of RS has Zero or more instances of Communication 491 Session objects. 492 o Each CS has to be associated with one more RS [ Here each RS can 493 be potentially setup by different SRCs] 495 6.3.3. XML element 497 Session element provides the information about the communication 498 session 500 Each communication session(CS) object is represented by one session 501 element. Each session element has unique Base 64 URN UUID attribute 502 which helps to uniquely identify CS. 504 Reason element MAY be included to represent the Termination Reason 505 attribute. group-ref element MAY exist to indicate the group where 506 the mentioned session belongs. 508 6.4. CSRSAssociation 510 1..* 0..* 511 Recording Communication 512 Session ----------+---------- Session 513 | 514 | 515 | 516 +-------------------+ 517 | CSRSAssociation | 518 +-------------------+ 519 | Association-Time | 520 | Disassociaton-Time| 521 +-------------------+ 523 A CSRS Association class and its objects has attributes of CS object 524 which are attributes of association of a session to a RS. 526 6.4.1. Attributes 528 CSRS association class has the following attributes: 530 o Associate-time - associate-time is calculated by SRC as the time 531 it sees a CS is associated to a RS 532 o Disassociate-time- Disassociate-time is calculated by SRC as the 533 time it see a CS disassociate from a RS. 534 It is possible that a given CS can have multiple associate/ 535 disassociate times within given RS. 537 6.4.2. Linkages 539 CSRS association class is linked to CS and RS classes. There are no 540 cardinalties for this linkage. 542 6.4.3. XML element 544 sessionrecordingassoc is the XML element to represent CSRS 545 association object. session URN UUID is used to uniquely identify 546 this element and link with the specific session. 548 6.5. Participant 550 Communication Session (CS) 551 | 0..* 552 | 553 | 0..* 554 +-------------------------------+ 555 | Participant | 556 | | 557 +-------------------------------+ 558 | AoR / Name Pair list | 559 | | 560 | | 561 +-------------------------------+ 562 | 0..* 1..*| 563 receives| |sends 564 | 0..* 0..*| 565 Media Stream 567 A Participant class and its objects has information about a device 568 that is part of a CS and/or contributes/consumes media stream(s) 569 belonging to a CS. 571 6.5.1. Attributes 573 Participant has attributes like: 575 o AoR / Name pair list - This attribute is a list of Name/AoR tuple. 576 An AoR MAY be SIP/SIPS/TEL URI. Name represents Participant 577 name(SIP display name) or DN number ( in case it is known). There 578 are cases where a participant can have more than one AoR [e.g. 579 P-Asserted-identity header [RFC3325] which can have both SIP and 580 TEL URIs] 582 This document does not specify other attributes relating to 583 participant e.g. Participant Role, Participant type. An SRC which 584 has information of these attributes can indicate the same as part of 585 extension data to Participant from SRC to SRS. 587 6.5.2. Linkages 589 The participant class is linked to MS and CS class using association 590 relationship. The association between participant and Media Stream 591 allows: 593 o Participant to receives zero or more media streams 594 o Participant to send zero or more media streams. (Same participant 595 provides multiple streams e.g. audio and video) 596 o Media stream to be received by zero or more participants. Its 597 possible, though perhaps unlikely, that a stream is generated but 598 sent only to the SRC and SRS, not to any participant. E.g. In 599 conferencing where all participants are on hold and the SRC is 600 collocated with the focus. Also a media stream may be received by 601 multiple participants (e.g. Whisper calls, side conversations). 602 o Media stream to be sent by one or more participants (pre-mixed 603 streams). 605 Example of a case where a participant receives Zero or more streams - 606 a Supervisor may have side conversation with Agent, while Agent 607 converses with customer. 609 6.5.3. XML element 611 A participant element represents a Participant object. 613 Participant MUST have a NameID complex element which contains AoR as 614 attribute and Name as element. AOR element is SIP/SIPS URI FQDN or 615 IP address which represents the user. name is an optional element to 616 represent display name. 618 Each participant element has unique ID (Base 64 URN UUID) attribute 619 which helps to uniquely identify participant and session Base 64 URN 620 UUID to associate participant with specific session element. Base 64 621 URN UUID of participant MUST used in the scope of CSG and no new Base 622 64 URN UUID has to be created for the same element (participant, 623 stream) between different CS in the same CSG. In case Base 64 URN 624 UUID has to be used permanent, careful usage of Base 64 URN UUID to 625 original AoR has to be decided by the implementers and it is 626 implementer's choice. 628 6.6. ParticipantCSAssociation 630 1..* 0..* 631 Communication 632 Session ----------+---------- Participant 633 | 634 | 635 | 636 +-------------------+ 637 | ParticipantCS | 638 | Association | 639 +-------------------+ 640 | Capabilities | 641 | Association-Time | 642 | Disassociaton-Time| 643 +-------------------+ 645 A participantCS Association class and its objects has attributes of 646 participant object which are attributes of association of a 647 participant to a Session. 649 6.6.1. Attributes 651 ParticipantCS association class has the following attributes: 653 o Associate-time - associate-time is calculated by SRC as the time 654 it sees a participant is associated to CS 655 o Disassociate-time- Disassociate-time is calculated by SRC as the 656 time it see a participant disassociate from a CS. It is possible 657 that a given participant can have multiple associate/disassociate 658 times within given communication session. 659 o Capabilities - A participant capabilities as defined in [RFC3840] 660 which is an optional attribute that includes the capabilities of a 661 participant in a CS. Each participant shall have Zero or more 662 capabilities. A participant may use different capabilities 663 depending on the role it plays at a particular instance. IOW if a 664 participants moves across different CSs ( due to transfer e.t.c) 665 OR is simultaneously present in different CSs its role may be 666 different and hence the capability used. 667 o "send" or "recv" element in each participant is associating SDP 668 m-lines with the participant. send element indicates that 669 participant is sending the stream of media with the mentioned 670 media description. recv element indicates that participant is 671 receiving the stream and by default all participant will receive 672 the stream. recv element has relevance in case whisper call 673 scenario wherein few of the participant in the session receives 674 the stream and not others. 676 6.6.2. Linkages 678 The participantCS association class is linked to participant and CS 679 classes. There are no cardinalties for this linkage. 681 6.6.3. XML element 683 participantsessionassoc XML element represent participantCS 684 association object. participant and session id is used to uniquely 685 identify this element 687 NOTE: RFC 4235 encoding shall be used to represent capabilities 688 attribute in XML. 690 6.7. Media Stream 692 Participant 693 | 0..* 1..*| 694 receives| |sends 695 | 0..* 0..*| 696 +-------------------------+ 697 | Media Stream | 698 | | 699 Communication 0..1 0..* +-------------------------+ 700 Session ------------| | 701 | Media Stream Reference | 702 | Content-type | 703 | | 704 +-------------------------+ 706 A Media Stream class (and its objects) has the properties of media as 707 seen by SRC and sent to SRS. Different snapshots of media stream 708 object may be sent whenever there is a change in media (e.g. dir 709 change like pause/resume and/or codec change and/or participant 710 change.). 712 6.7.1. Attributes 714 A Media Stream class has the the following attributes: 716 o Media Stream Reference - In implementations this can reference to 717 m-line 718 o Content - The content of an MS element will be described in terms 719 of value from the [RFC4796] registry. 721 The metadata model should include media streams that are not being 722 delivered to the SRS. Examples include cases where SRC offered 723 certain media types but SRS chooses to accept only a subset of them 724 OR an SRC may not even offer a certain media type due it its 725 restrictions to record 727 6.7.2. Linkages 729 A Media Stream is linked to participant and CS classes using the 730 association relationship. The details of association with the 731 Participant are described in the Participant class section. The 732 details of association with CS is mentioned in the CS section. 734 6.7.3. XML element 736 stream element represents a Media Stream object. Stream element 737 indicates SDP media lines associated with the session and 738 participants. 740 This element indicates the SDP m-line properties like label 741 attributes. Label attribute is used to link m-line SDP body using 742 label attribute in SDP m-line. 744 Each stream element has unique Base 64 URN UUID attribute which helps 745 to uniquely identify stream and session Base 64 URN UUID to associate 746 stream with specific session element. 748 The content attribute if an SRC wishes to send is conveyed in RS SDP. 750 6.8. ParticipantStream Association 751 +-------------------+ 752 | ParticipantSteam | 753 | Association | 754 +-------------------+ +----------Participant 755 | Association-Time | | 0..*| 1..*| 756 | Disassociaton-Time|---+ recv| |sends 757 | Recv | | 0..*| 0..*| 758 | Send | | | | 759 +-------------------+ | | | 760 +----------Media Stream 762 A ParticipantStream association class and its object has attributes 763 that are attributes of association of a Participant to a Stream. 765 6.8.1. Attributes 767 A participantStream association class has the following attributes: 769 o Associate-Time: This attributes indicates the time a Participant 770 started contributing to a Media Stream 771 o Disassociate-Time: This attribute indicates the time a Participant 772 stopped contributing to a Media Stream 774 6.8.2. Linkages 776 The participantStream association class is linked to participant and 777 Stream classes. There are no cardinalties for this linkage. 779 6.8.3. XML element 781 ParticipantStreamAssoc XML element represents participant to stream 782 association object. participant element is used to uniquely identify 783 this element and related with stream using stream unique URN id.. 785 6.9. associate-time/disassociate-time 787 associate-time/disassociate-time contains a string indicating the 788 date and time of the status change of this tuple. The value of this 789 element MUST follow the IMPP datetime format [RFC3339]. Timestamps 790 that contain 'T' or 'Z' MUST use the capitalized forms. At a time, 791 any of the time tuple associate-time or disassociate-time MAY exist 792 in the element namely group, session, participant and not both 793 timestamp at the same time. 795 As a security measure, the timestamp element SHOULD be included in 796 all tuples unless the exact time of the status change cannot be 797 determined. 799 6.10. Unique ID format 801 Unique id is generated in two steps: 802 o UUID is created using [RFC4122]) 803 o UUID is encoded using base64 as defined in [RFC4648] 805 The above mentioned unique-id mechanism SHOULD be used for each 806 metadata element. 808 7. SIP Recording Metadata Example 810 7.1. Complete SIP Recording Metadata Example 812 The following example provides all the tuples involved in Recording 813 Metadata XML body. 815 816 817 complete 818 819 2010-12-16T23:41:07Z 820 821 822 sip:alice@atlanta.com 823 FaXHlc+3WruaroDaNE87am== 824 825 826 FOO! 827 bar 828 829 830 831 7+OTCyoxTmqmqyA/1weDAg== 832 834 835 FOO! 836 bar 837 838 839 2010-12-16T23:41:07Z 840 841 843 844 Bob B 845 846 847 FOO! 848 bar 849 850 853 2010-12-16T23:41:07Z 854 855 857 i1Pz3to5hGk8fuXl+PbwCw== 858 UAAMm5GRQKSCMVvLyl4rFw== 859 8zc6e0lYTlWIINA6GR+3ag== 860 EiXGlc+4TruqqoDaNE76ag== 861 862 864 865 Paul 866 867 868 FOO! 869 bar 870 871 874 2010-12-16T23:41:07Z 875 876 878 8zc6e0lYTlWIINA6GR+3ag== 879 EiXGlc+4TruqqoDaNE76ag== 880 UAAMm5GRQKSCMVvLyl4rFw== 881 i1Pz3to5hGk8fuXl+PbwCw== 882 883 885 886 887 889 890 891 893 894 895 897 898 899 901 SIP Recording Metadata Example XML body 903 7.2. Partial Update of Recording metadata XML body 905 The following example provides partial update in Recording Metadata 906 XML body for the above example. The example has a snapshot that 907 carries the disassociate-time for a participant from a session. 909 910 911 partial 912 914 915 Bob R 916 917 FOO! 918 bar 919 920 923 2010-12-16T23:41:07Z 924 925 927 Partial update of SIP Recording Example XML body 929 8. XML Schema definition for Recording metadata 931 This section defines XML schema for Recording metadata document 933 934 939 940 941 942 943 944 946 948 950 952 954 957 960 963 967 968 969 970 971 973 975 979 980 983 984 985 986 988 990 992 994 998 999 1001 1002 1003 1004 1006 1008 1012 1013 1015 1016 1017 1018 1020 1024 1025 1027 1028 1029 1030 1032 1034 1038 1039 1041 1043 1044 1045 1046 1048 1050 1052 1054 1058 1059 1061 1062 1063 1064 1066 1070 1071 1073 1074 1075 1076 1077 1078 1080 1081 1083 1084 1085 1086 1087 1088 1090 1091 1092 1093 1094 1095 1096 1098 1100 9. Security Considerations 1102 The metadata information sent from SRC to SRS MAY reveal sensitive 1103 information about different participants in a session. For this 1104 reason, it is RECOMMENDED that a SRC use a strong means for 1105 authentication and metadata information protection and that it apply 1106 comprehensive authorization rules when using the metadata format 1107 defined in this document. The following sections will discuss each 1108 of these aspects in more detail. 1110 9.1. Connection Security 1112 It is RECOMMENDED that a SRC authenticate SRS using the normal SIP 1113 authentication mechanisms, such as Digest as defined in Section 22 of 1114 [RFC3261]. The mechanism used for conveying the metadata information 1115 MUST ensure integrity and SHOULD ensure confidentially of the 1116 information. In order to achieve these, an end-to-end SIP encryption 1117 mechanism, such as S/MIME described in [RFC3261], SHOULD be used. 1119 If a strong end-to-end security means (such as above) is not 1120 available, it is RECOMMENDED that a SRC use mutual hop-by-hop 1121 Transport Layer Security (TLS) authentication and encryption 1122 mechanisms described in "SIPS URI Scheme" and "Interdomain Requests" 1123 of [RFC3261]. 1125 10. IANA Considerations 1127 This specification registers a new XML namespace, and a new XML 1128 schema. 1130 10.1. SIP recording metadata Schema Registration 1132 URI: urn:ietf:params:xml:ns:recording 1134 Registrant Contact: IETF SIPREC working group, Ram mohan 1135 R(rmohanr@cisco.com) 1137 XML: the XML schema to be registered is contained in Section 6. 1139 Its first line is and its last 1140 line is 1142 11. Acknowledgement 1144 We wish to thank John Elwell, Henry Lum, Leon Portman, De Villers, 1145 Andrew Hutton(Siemens-Enterprise), Deepanshu Gautam(Huawei),Charles 1146 Eckel(Cisco), Muthu Arul Mozhi (Cisco), Michael Benenson(Cisco), 1147 Hadriel Kaplan (ACME), Brian Rosen, Scott Orton(Broadsoft), Ofir Roth 1148 (NICE) for their valuable comments and inputs. 1150 We wish to thank Joe Hildebrand(Cisco), Peter Saint-Andre(Cisco) for 1151 the valuable XML related guidance and Martin Thompson for validating 1152 the XML schema and providing comments on the same. 1154 12. Appendix A: Metadata Model Object Instances 1156 Note: This Appendix has to be moved to callflow document after the 1157 discussion in the mailing alias 1159 This section describes the metadata model object instances for 1160 different use cases of SIPREC. For the sake of simplicity as the 1161 media streams sent by each of the participants is received by every 1162 other participant in these use cases, it is NOT shown in the object 1163 instance diagrams below. Also for the sake of ease not all 1164 attributes of each object are shown in these instance diagrams. 1166 12.1. Use case 1: Basic Call 1168 Basic call between two Participants A and B. In this use case each 1169 participant sends one Media Stream. For the sake of simplicity 1170 "receives" lines are not shown in this instance diagram. Media 1171 Streams sent by each participant is received all other participants 1172 of that CS. 1174 +-------------------------------+ 1175 | Recording Session (RS) | 1176 +-------------------------------+ 1177 | 1178 | 1179 | 1180 +----------------+ 1181 | Communication | 1182 | Session (CS) | 1183 +----------------+-----------------------+ 1184 | Start Time | | 1185 +----------------+ | 1186 | | 1187 |-------------------+ | 1188 | | | 1189 +---------------+ +---------------+ | 1190 | ParticipantA | | ParticipantB | | 1191 | | | | | 1192 +---------------+ +---------------+ | 1193 | | | 1194 sends | | sends | 1195 | | | 1196 +---------------+ +---------------+ | 1197 |Media Stream A1| |Media Stream B1| | 1198 +---------------+ +---------------+ | 1199 |MediaStream Ref| |MediaStream Ref| | 1200 | | | | | 1201 +---------------+ +---------------+ | 1202 | | | 1203 +-----------------------------------+ 1205 12.2. Use case 2: Hold/Resume 1207 Basic call between two Participants A and B and with Participant A or 1208 B doing a Hold/Resume. In this use case each participant sends one 1209 Media Stream. After Hold/Resume the properties of Media can change. 1210 For the sake of simplicity "receives" lines are not shown in this 1211 instance diagram. Media Streams sent by each participant is received 1212 all other participants of that CS. 1214 +-------------------------------+ 1215 | Recording Session (RS) | 1216 +-------------------------------+ 1217 | | 1218 | | 1219 | | 1220 | +-------------------------------+ 1221 | | Communication Session (CS) | 1222 | +-----------| Group(CSG) | 1223 | | +-------------------------------+ 1224 | | | Unique-id1 | 1225 | | +-------------------------------+ 1226 | | 1227 | | 1228 | | 1229 +----------------+ 1230 | Communication | 1231 +-| Session (CS) |----------------------------------------------+ 1232 | +----------------+ | 1233 | | | | 1234 | +----------------+ | 1235 | | | 1236 | |-------------------+ | 1237 | | | | 1238 | +---------------+ +---------------+ | 1239 | | ParticipantA | | ParticipantB |-----------+ | 1240 | | |--+ | | | | 1241 | +---------------+ | +---------------+ |sends(After | 1242 | | | | | | | Resume) | 1243 | | | | | | +--------------+ | 1244 | sends | | +--+ | sends | |MediaStream B3| | 1245 | | -----+ | | +-----+ +--------------+ | 1246 | +---------------+ | | +---------------+ | |MediaStreamRef|-| 1247 | |Media Stream A1| | | |Media Stream B1| | | | | 1248 | +---------------+ | | +---------------+ | | | | 1249 +-|MediaStreamref | | | |MediaStreamRef | | +--------------+ | 1250 | | | | | |-|-------------------| 1251 +---------------+ | | +---------------+ | | 1252 | | | | 1253 +------------+ |sends |sends (hold) | 1254 | sends |(Resume) | | 1255 | (hold) +-------+ +-------+ | 1256 | | | | 1257 +---------------+ +---------------+ +--------------+ | 1258 |Media Stream A2| |Media Stream A3| |MediaStream B2| | 1259 +---------------+ +---------------+ | | | 1260 |MediaStreamref | |MediaStreamRef | +--------------+ | 1261 | | | | |Codec Params | | 1262 +---------------+ +---------------+ | | | 1263 | | | | | 1264 | | +--------------+ | 1265 | | | | 1266 +------------------------------------------------------+ 1268 12.3. Use case 3: Basic call with Transfer 1270 Basic call between two Participants A and B and with Participant A 1271 transfer(consult transfer) to Participant C. In this use case each 1272 participant sends one Media Stream. After transfer the properties of 1273 Participant A Media can change. For the sake of simplicity 1274 "receives" lines are not shown in this instance diagram. Media 1275 Streams sent by each participant is received all other participants 1276 of that CS. 1278 +-------------------------------+ 1279 | Recording Session (RS) |-------+ 1280 +-------------------------------+ | 1281 | | 1282 | | 1283 | | 1284 +-------------------------------+ | 1285 | Communication Session (CS) | | 1286 | Group(CSG) | | 1287 +-------------------------------+ | 1288 | Unique-id1 | | 1289 +-------------------------------+ | 1290 | | 1291 |----------------------------+ 1292 | 1293 |-----------------+ 1294 | | 1295 +----------------+ +----------------+ 1296 | Communication | | Communication | 1297 | Session (CS)1 | | Session (CS)2 | 1298 +----------------+ +----------------+-----------+ 1299 | | | | | 1300 +----------------+ +----------------+ | 1301 | | 1302 |-------------------+ | 1303 | | | | 1304 +---------------+ | +---------------+ | 1305 | ParticipantA | | | ParticipantB | | 1306 | | | | | | 1307 +---------------+ | +---------------+ | 1308 | | | | 1309 sends | | | sends | 1310 | | | | 1311 +---------------+ | +---------------+ | 1312 |Media Stream A1| | |Media Stream B1| | 1313 +---------------+ | +---------------+ | 1314 | | | | | | 1315 | | | | Media Stream | | 1316 | Media Stream |---+---| Ref | | 1317 | Ref | | | | 1318 +---------------+ +---------------+ | 1319 | 1320 | 1321 +----------------------------| 1322 | | 1323 +--------------------------------+ | 1324 | | | 1325 +---------------+ +---------------+ | 1326 | Participant A | | Participant C | | 1327 | (same) | | | | 1328 +---------------+ +---------------+ | 1329 | | | 1330 | sends (After transfer) | sends | 1331 +----------------+ +----------------+| 1332 | Media Stream A2| | Media Stream C1|| 1333 +----------------+ +----------------+| 1334 | Media StreamRef| | Media StreamRef|| 1335 | | | || 1336 | | | || 1337 +----------------+ +----------------+| 1338 | | | 1339 | | | 1340 | | | 1341 +-------------------------------------------+ 1343 12.4. Conference Use Cases 1345 Depending on who act as SRC and the information that an SRC has there 1346 can be several ways to model conference use cases. This section has 1347 instance diagrams for the following cases: 1349 o A CS where one of the participant (which is also SRC) is a user in 1350 a conference 1351 o A CS where one of the participant is focus ( which is also SRC) 1352 o A CS where one of the participant is user and the SRC is a 1353 different entity like B2BUA 1354 o A CS where one of the participant is focus and the SRC is a 1355 different entity like B2BUA 1357 NOTE: There MAY be other ways to model the same use cases depending 1358 on what information the SRC has. 1360 12.4.1. Case 1: 1362 This is the usecase where there is a CS with one of the participant 1363 (who is also SRC) as a user in a conference. For the sake of 1364 simplicity the receive lines for each of the participant is not 1365 shown. 1367 +---------------------------------------------------+ 1368 | Communication Session | 1369 | +-------------+ +--------------+ | 1370 | | | | | | 1371 | |Participant B| | Participant A| | 1372 | | (User in |--------------| | | 1373 | | conf/SRC) | | | | 1374 | +-------------+ +--------------+ | 1375 | | | | | | 1376 +---------------------------------------------------+ 1377 | | | | 1378 | | | | 1379 D E F G (Participants of Conference) 1381 Instance Diagram: 1383 +-------------------------------+ 1384 | Recording Session (RS) |--+ 1385 +-------------------------------+ | 1386 | | 1387 | | 1388 | | 1389 +-------------------------------+ | 1390 | Communication Session (CS) | | 1391 | Group(CSG) | | 1392 +-------------------------------+ | 1393 | Unique-id1 | | 1394 +-------------------------------+ | 1395 | | 1396 |-----------------------+ 1397 | 1398 +----------------+ 1399 | Communication | 1400 | Session (CS) |--+----------------+-----+ 1401 +----------------+ | | | 1402 | | | | | 1403 +----------------+ | | | 1404 | | | | 1405 | | | | 1406 | | | | 1407 +---------------+ | | | 1408 | ParticipantA | | | | 1409 | | | | | 1410 +---------------+ | | | 1411 | | | | 1412 sends | | | | 1413 | | | | 1414 +---------------+ | | | 1415 |Media Stream A1| | | | 1416 +---------------+ | | | 1417 |MediaStream Ref|-----|----------------+ | 1418 | | | | | 1419 +---------------+ | | | 1420 | | | 1421 | | | 1422 +-------------+ | | 1423 | | | 1424 | | | 1425 +----------------+ | | 1426 | Participant B | | | 1427 | (in conf) | | | 1428 +----------------+ | | 1429 | | | 1430 sends | | | 1431 | | | 1432 +----------------+ | | 1433 | Media Stream B1|---------------------+ | 1434 +----------------+ sends | 1435 | MediaStream Ref| | 1436 | | +-----------------+ 1437 +----------------+ | 1438 | | 1439 |sends | 1440 | | 1441 +-----------------+-------------+------------+ 1442 | | | | 1443 | | | | 1444 +------------+ +------------+ +------------+ +-------------+ 1445 |participantD| |ParticipantE| |ParticipantF| |Participant G| 1446 +------------+ +------------+ +------------+ +-------------+ 1448 In this example we have two participants A and B who are part of a 1449 Communication Session(CS). One of the participants B is part of a 1450 conference and also acts as SRC.There can be two cases here. B can 1451 be a participant of the conference or B can be a focus. In this 1452 instance diagram Participant B is a user in a conference. The SRC 1453 (Participant B) subscribes to conference event package to get the 1454 details of other particiants. Participant B(SRC) sends the same 1455 through the metadata to SRS. In this instance diagram the Media 1456 Stream(mixed stream) sent from Participant B has media streams 1457 contributed by conference participants (D,E,F and G). For the sake 1458 of simplicity the "receives" line is not shown here. In this example 1459 the media stream sent by each participant(A or B) of CS is received 1460 by all other participant(A or B). 1462 12.4.2. Case 2: 1464 This is the usecase where there is a CS where one of the participant 1465 is focus ( which is also SRC). 1467 +---------------------------------------------------+ 1468 | Communication Session | 1469 | +--------------+ +--------------+ | 1470 | | |--------------| | | 1471 | |Participant C | | Participant A| | 1472 | | (Focus in |------+ | | | 1473 | | conf and SRC)|---+ | +--------------+ | 1474 | +--------------+ | | | 1475 | | | +---------+ | 1476 | | | | | 1477 | +--------------+ | +---------------+ | 1478 | | Participant B| +---+ | Participant D | | 1479 | | | | | | | 1480 | +--------------+ | +---------------+ | 1481 | | | 1482 | +--------------+ | 1483 | |Participant E | | 1484 | | | | 1485 | +--------------+ | 1486 | | 1487 +---------------------------------------------------+ 1489 Instance Diagram: 1491 +-------------------------------+ 1492 | Recording Session (RS) | 1493 +-------------------------------+ 1494 |-------------------------+ 1495 | | 1496 | | 1497 +-------------------------------+ | 1498 | Communication Session (CS) | | 1499 | Group(CSG) | | 1500 +-------------------------------+ | 1501 | Unique-id1 | | 1502 +-------------------------------+ | 1503 | | 1504 |-------------------------+ 1505 | 1506 +----------------+ 1507 | Communication | 1508 | Session (CS) |----------------------+ 1509 +----------------+ | 1510 | | | 1511 +----------------+ | 1512 | | 1513 |-------------------+ | 1514 | | | | 1515 +---------------+ | +---------------+ | 1516 | ParticipantA | | | ParticipantB | | 1517 | | | | | | 1518 +---------------+ | +---------------+ | 1519 | | | | 1520 sends | | | sends | 1521 | | | | 1522 +---------------+ | +---------------+ | 1523 |Media Stream A1| | |Media Stream B1| | 1524 +---------------+ | +---------------+ | 1525 |MediaStream Ref| | |MediaStream Ref| | 1526 | |---+---| | | 1527 +---------------+ +---------------+ | 1528 | 1529 +----------------------------------+ 1530 | | | | 1531 | | | | 1532 +---------------+ | +---------------+ | 1533 | ParticipantD | | | ParticipantE | | 1534 | | | | | | 1535 +---------------+ | +---------------+ | 1536 | | | | 1537 sends | | | sends | 1538 | | | | 1539 +---------------+ | +---------------+ | 1540 |Media Stream D1| | |Media Stream E1| | 1541 +---------------+ | +---------------+ | 1542 |MediaStream Ref| | |MediaStream Ref| | 1543 | |---+---| | | 1544 +---------------+ +---------------+ | 1545 | 1546 | 1547 +----------+ 1548 +-----------------| 1549 | | 1550 | | 1551 +----------------+ | 1552 | Participant C | | 1553 | (focus +src) | | 1554 +----------------+ | 1555 | | 1556 Sends | +-------+ 1557 | | 1558 "sends" OR | | 1559 contributed +----------------+ 1560 by | Media Stream C1| 1561 Participants+----------------+ "receives" by participants A,B,D,E 1562 A,B,D,E | MediaStream Ref|------------------------------------ 1563 ------------| Codec Params | 1564 +----------------+ 1566 In this example we have two participants A and B who are part of a 1567 Communication Session(CS). One of the participants (C) is focus of a 1568 conference and also acts as SRC. The SRC (Participant C) being the 1569 Focus of the conference has access to the details of other 1570 particiants. SRC (Participant C) sends the same through the metadata 1571 to SRS. In this instance diagram the Media Stream(mixed stream) sent 1572 by C has media streams contributed by conference participants (A, B, 1573 D and E). Participants A, B,D and E sends Media Streams A1, B1, D1 1574 and E1 respectively. The media stream sent by Participant C(Focus) 1575 is received by all other participants of CS. For the sake of 1576 simplicity the "receives" line is not shown linked to all other 1577 participants. 1579 NOTE: SRC ( Participant C) can send mixed stream or seperate streams 1580 to SRS 1582 12.4.3. Case 3: 1584 A CS where one of the participant is user and the SRC is a different 1585 entity like B2BUA. In this case the SRC may not know that one of the 1586 user is part of conference. Hence the instance diagram will not have 1587 information about the conference participants. 1589 +---------------------------------------------------+ 1590 | Communication Session | 1591 | +-------------+ +------+ +--------------+ | 1592 | | | | (SRC)| | | | 1593 | |Participant B|--|B2BUA |----| Participant A| | 1594 | | (User in | +------+ | | | 1595 | | conf) | | | | 1596 | +-------------+ +--------------+ | 1597 | | | | | | 1598 +---------------------------------------------------+ 1599 | | | | 1600 | | | | 1601 D E F G (Participants of Conference) 1603 12.4.4. Case 4: 1605 A CS where one of the participant is focus and the SRC is a different 1606 entity like B2BUA. In this case the participant which is focus sends 1607 "isfocus" in SIP message to SRC. The SRC subscribe to conference 1608 event package on seeing this "isfocus". SRC learns the details of 1609 other participants of conference from the conference package and send 1610 the same in metadata to SRS. The instance diagram for this use case 1611 is same as Case 1. 1613 +--------------------------------+ 1614 | Conference Event Package | 1615 | | 1616 +--------------------------------+ 1617 | 1618 | subscribes 1619 | 1620 +---------------------|-----------------------------+ 1621 | Communication |Session | 1622 | +-------------+ +------+ +--------------+ | 1623 | | | | (SRC)| | | | 1624 | |Participant B|--|B2BUA |----| Participant A| | 1625 | | (FOCUS in | +------+ | | | 1626 | | conf) | | | | 1627 | +-------------+ +--------------+ | 1628 | | | | | | 1629 +---------------------------------------------------+ 1630 | | | | 1631 | | | | 1632 D E F G (Participants of Conference) 1634 13. Appendix B: Metadata XML schema Instances 1636 Note: This Appendix has to be moved to callflow document after the 1637 discussion in the mailing alias 1639 This section describes the metadata model XML instances for different 1640 use cases of SIPREC. For the sake of simplicity the complete SIP 1641 messages are NOT shown here. 1643 13.1. Use case 1: Basic Call 1645 Basic call between two Participants A(Alice) and B(Bob) who are part 1646 of one session. In this use case each participant sends two Media 1647 Streams. Media Streams sent by each participant is received all 1648 other participants of that CS in this use-case. Below is the initial 1649 snapshot sent by SRC that has complete metadata. For the sake of 1650 completeness even snippets of SDP is shown. For the sake of 1651 simplicity these use-cases assume the RS stream is unmixed. 1653 Content-Type: application/SDP 1654 ... 1655 m=audio 49170 RTP/AVP 0 1656 a=rtpmap:0 PCMU/8000 1657 a=label:96 1658 a=sendonly 1659 ... 1660 m=video 49174 RTP/AVPF 96 1661 a=rtpmap:96 H.264/90000 1662 a=label:97 1663 a=sendonly 1664 ... 1665 m=audio 51372 RTP/AVP 0 1666 a=rtpmap:0 PCMU/8000 1667 a=label:98 1668 a=sendonly 1669 ... 1670 m=video 49176 RTP/AVPF 96 1671 a=rtpmap:96 H.264/90000 1672 a=label:99 1673 a=sendonly 1674 .... 1675 1676 1677 complete 1678 1679 2010-12-16T23:41:07Z 1680 1681 1682 sip:alice@cisco.com 1683 1684 1685 FOO! 1686 bar 1687 1688 1689 1690 7+OTCyoxTmqmqyA/1weDAg== 1691 1692 2010-12-16T23:41:07Z 1693 1694 FOO! 1695 bar 1696 1697 1699 1700 Alice 1701 1702 1703 FOO! 1704 bar 1705 1706 1709 2010-12-16T23:41:07Z 1710 1711 1713 i1Pz3to5hGk8fuXl+PbwCw== 1714 UAAMm5GRQKSCMVvLyl4rFw== 1715 8zc6e0lYTlWIINA6GR+3ag== 1716 EiXGlc+4TruqqoDaNE76ag== 1717 1718 1720 1721 Bob 1722 1723 1724 FOO! 1725 bar 1726 1727 1730 2010-12-16T23:41:07Z 1731 1732 1734 8zc6e0lYTlWIINA6GR+3ag== 1735 EiXGlc+4TruqqoDaNE76ag== 1736 UAAMm5GRQKSCMVvLyl4rFw== 1737 i1Pz3to5hGk8fuXl+PbwCw== 1738 1739 1741 1742 1743 1745 1746 1747 1749 1750 1751 1753 1754 1755 1757 13.2. Use case 2: Hold/resume 1759 Basic call between two Participants A and B. This is the continuation 1760 of above use-case. One of the participants(say A) goes on hold and 1761 then resumes as part of the same session. The metadata snapshot 1762 looks as below 1764 During hold 1765 Content-Type: application/SDP 1766 ... 1767 m=audio 49170 RTP/AVP 0 1768 a=rtpmap:0 PCMU/8000 1769 a=label:96 1770 a=inactive 1771 ... 1772 m=video 49174 RTP/AVPF 96 1773 a=rtpmap:96 H.264/90000 1774 a=label:97 1775 a=inactive 1776 ... 1777 m=audio 51372 RTP/AVP 0 1778 a=rtpmap:0 PCMU/8000 1779 a=label:98 1780 a=sendonly 1781 ... 1782 m=video 49176 RTP/AVPF 96 1783 a=rtpmap:96 H.264/90000 1784 a=label:99 1785 a=sendonly 1786 .... 1788 1789 1790 partial 1791 1794 8zc6e0lYTlWIINA6GR+3ag== 1795 EiXGlc+4TruqqoDaNE76ag== 1796 1797 1800 8zc6e0lYTlWIINA6GR+3ag== 1801 EiXGlc+4TruqqoDaNE76ag== 1802 1804 1806 During resume 1808 The snapshot will look pretty much same as Use-case 1. 1810 13.3. Use case 3: Basic Call with transfer 1812 Basic call between two Participants A and B is connected as in Use- 1813 case 1. Transfer is initiated by one of the participants of by other 1814 entity(3PCC case). SRC sends a snapshot of the participant changes 1815 to SRS. In this instance participant A(Alice) drops out during the 1816 transfer and Participant C(Paul) joins the session. There can be two 1817 cases here, same session continues after transfer or a new session 1818 (e.g. REFER based transfer) is created 1820 Transfer with same session retained - (.e.g. RE-INVITE based 1821 transfer). Participant A drops out and C is added to the same 1822 session. No change to session/group element. C will be new stream 1823 element which maps to RS SDP using the same labels in this instance. 1825 Content-Type: application/SDP 1826 ... 1827 m=audio 49170 RTP/AVP 0 1828 a=rtpmap:0 PCMU/8000 1829 a=label:96 1830 a=sendonly 1831 ... 1832 m=video 49174 RTP/AVPF 96 1833 a=rtpmap:96 H.264/90000 1834 a=label:97 1835 a=sendonly 1836 ... 1837 m=audio 51372 RTP/AVP 0 1838 a=rtpmap:0 PCMU/8000 1839 a=label:98 1840 a=sendonly 1841 ... 1842 m=video 49176 RTP/AVPF 96 1843 a=rtpmap:96 H.264/90000 1844 a=label:99 1845 a=sendonly 1846 .... 1847 1848 1849 partial 1850 1852 8zc6e0lYTlWIINA6GR+3ag== 1853 EiXGlc+4TruqqoDaNE76ag== 1854 60JAJm9UTvik0Ltlih/Gzw== 1855 AcR5FUd3Edi8cACQJy/3JQ== 1856 1857 1859 1860 Paul 1861 1862 1863 FOO! 1864 bar 1865 1866 1869 2010-12-16T23:41:07Z 1870 1871 1873 60JAJm9UTvik0Ltlih/Gzw== 1874 AcR5FUd3Edi8cACQJy/3JQ== 1875 8zc6e0lYTlWIINA6GR+3ag== 1876 EiXGlc+4TruqqoDaNE76ag== 1877 1878 1880 1881 1882 1884 1885 1886 1888 1889 1890 1892 1893 1894 1896 Transfer with new session - (.e.g. REFER based transfer). In this 1897 case new session is part of same grouping (done by SRC). 1899 SRC may send an optional snapshot indicating stop for the old 1900 session. 1902 1903 1904 Partial 1905 1906 7+OTCyoxTmqmqyA/1weDAg== 1907 1908 2010-12-16T23:41:07Z 1909 1910 FOO! 1911 bar 1912 1913 1916 2010-12-16T23:41:07Z 1917 1918 1921 2010-12-16T23:41:07Z 1922 1923 1925 SRC sends a snapshot to indicate the participant change and new 1926 session information after transfer. In this example the same RS is 1927 used. 1929 Content-Type: application/SDP 1930 ... 1931 m=audio 49170 RTP/AVP 0 1932 a=rtpmap:0 PCMU/8000 1933 a=label:96 1934 a=sendonly 1935 ... 1936 m=video 49174 RTP/AVPF 96 1937 a=rtpmap:96 H.264/90000 1938 a=label:97 1939 a=sendonly 1940 ... 1941 m=audio 51372 RTP/AVP 0 1942 a=rtpmap:0 PCMU/8000 1943 a=label:98 1944 a=sendonly 1945 ... 1946 m=video 49176 RTP/AVPF 96 1947 a=rtpmap:96 H.264/90000 1948 a=label:99 1949 a=sendonly 1950 .... 1951 1952 1953 partial 1954 1955 7+OTCyoxTmqmqyA/1weDAg== 1956 1957 2010-12-16T23:41:07Z 1958 1959 FOO! 1960 bar 1961 1962 1964 1965 1966 FOO! 1967 bar 1968 1969 1972 2010-12-16T23:32:03Z 1973 1974 1976 8zc6e0lYTlWIINA6GR+3ag== 1977 EiXGlc+4TruqqoDaNE76ag== 1978 60JAJm9UTvik0Ltlih/Gzw== 1979 AcR5FUd3Edi8cACQJy/3JQ== 1980 1981 1983 1984 1985 FOO! 1986 bar 1987 1988 1991 2010-12-16T23:41:07Z 1992 1993 1995 60JAJm9UTvik0Ltlih/Gzw== 1996 AcR5FUd3Edi8cACQJy/3JQ== 1997 8zc6e0lYTlWIINA6GR+3ag== 1998 EiXGlc+4TruqqoDaNE76ag== 1999 2000 2002 2003 2004 2006 2007 2008 2010 2011 2012 2014 2015 2016 2018 13.4. Use Case 4: Call disconnect 2020 This example shows a snapshot of metadata sent by an SRC at CS 2021 disconnect where the participants of CS are Alice and Bob 2022 2023 2024 Partial 2025 2026 7+OTCyoxTmqmqyA/1weDAg== 2027 2028 2010-12-16T23:41:07Z 2029 2030 FOO! 2031 bar 2032 2033 2035 2036 2010-12-16T23:41:07Z 2037 2039 2041 2042 2010-12-16T23:41:07Z 2043 2044 2046 14. References 2048 14.1. Normative References 2050 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2051 Requirement Levels", BCP 14, RFC 2119, March 1997. 2053 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 2055 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2056 A., Peterson, J., Sparks, R., Handley, M., and E. 2057 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2058 June 2002. 2060 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2061 January 2004. 2063 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 2064 Internet: Timestamps", RFC 3339, July 2002. 2066 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2067 Description Protocol", RFC 4566, July 2006. 2069 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 2070 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 2072 [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description 2073 Protocol (SDP) Content Attribute", RFC 4796, 2074 February 2007. 2076 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 2077 "Indicating User Agent Capabilities in the Session 2078 Initiation Protocol (SIP)", RFC 3840, August 2004. 2080 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 2081 Unique IDentifier (UUID) URN Namespace", RFC 4122, 2082 July 2005. 2084 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2085 Encodings", RFC 4648, October 2006. 2087 14.2. Informative References 2089 [RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use 2090 Cases and Requirements for SIP-Based Media Recording 2091 (SIPREC)", RFC 6341, August 2011. 2093 [I-D.ietf-siprec-architecture] 2094 Hutton, A., Portman, L., Jain, R., and K. Rehor, "An 2095 Architecture for Media Recording using the Session 2096 Initiation Protocol", draft-ietf-siprec-architecture-06 2097 (work in progress), September 2012. 2099 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 2100 August 1999. 2102 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 2103 Header Field for the Session Initiation Protocol (SIP)", 2104 RFC 3326, December 2002. 2106 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 2107 Extensions to the Session Initiation Protocol (SIP) for 2108 Asserted Identity within Trusted Networks", RFC 3325, 2109 November 2002. 2111 Authors' Addresses 2113 Ram Mohan Ravindranath 2114 Cisco Systems, Inc. 2115 Cessna Business Park, 2116 Kadabeesanahalli Village, Varthur Hobli, 2117 Sarjapur-Marathahalli Outer Ring Road 2118 Bangalore, Karnataka 560103 2119 India 2121 Email: rmohanr@cisco.com 2123 Parthasarathi Ravindran 2124 Nokia Siemens Networks 2125 Bangalore, Karnataka 2126 India 2128 Email: partha@parthasarathi.co.in 2130 Paul Kyzivat 2131 Huawei 2132 Hudson, MA 2133 USA 2135 Email: pkyzivat@alum.mit.edu