idnits 2.17.1 draft-ietf-siprec-metadata-04.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 (September 1, 2011) is 4619 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-02 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: March 4, 2012 Sonus Networks 5 Paul. Kyzivat 6 Unaffiliated 7 September 1, 2011 9 Session Initiation Protocol (SIP) Recording Metadata 10 draft-ietf-siprec-metadata-04 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 March 4, 2012. 40 Copyright Notice 42 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . 7 62 5.1. XML data format . . . . . . . . . . . . . . . . . . . . . 7 63 5.1.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 8 64 5.1.2. recording . . . . . . . . . . . . . . . . . . . . . . 8 65 6. Recording Metadata classes . . . . . . . . . . . . . . . . . . 8 66 6.1. Recording Session . . . . . . . . . . . . . . . . . . . . 8 67 6.1.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 9 68 6.1.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 9 69 6.1.3. XML element . . . . . . . . . . . . . . . . . . . . . 9 70 6.2. Communication Session Group . . . . . . . . . . . . . . . 10 71 6.2.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 10 72 6.2.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 10 73 6.2.3. XML element . . . . . . . . . . . . . . . . . . . . . 11 74 6.3. Communication Session . . . . . . . . . . . . . . . . . . 11 75 6.3.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 12 76 6.3.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 12 77 6.3.3. XML element . . . . . . . . . . . . . . . . . . . . . 13 78 6.4. Participant . . . . . . . . . . . . . . . . . . . . . . . 13 79 6.4.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 14 80 6.4.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 14 81 6.4.3. XML element . . . . . . . . . . . . . . . . . . . . . 15 82 6.5. Media Stream . . . . . . . . . . . . . . . . . . . . . . . 15 83 6.5.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 16 84 6.5.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 17 85 6.5.3. XML element . . . . . . . . . . . . . . . . . . . . . 17 86 6.6. Extension Data . . . . . . . . . . . . . . . . . . . . . . 17 87 6.6.1. Linkages . . . . . . . . . . . . . . . . . . . . . . . 17 88 6.6.2. XML element . . . . . . . . . . . . . . . . . . . . . 17 89 6.7. associate-time/disassociate-time . . . . . . . . . . . . . 18 90 6.8. Unique ID format . . . . . . . . . . . . . . . . . . . . . 18 91 7. SIP Recording Metadata Example . . . . . . . . . . . . . . . . 18 92 7.1. Complete SIP Recording Metadata Example . . . . . . . . . 18 93 7.2. Partial Update of Recording metadata XML body . . . . . . 20 94 8. XML Schema definition for Recording metadata . . . . . . . . . 20 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 96 9.1. Connection Security . . . . . . . . . . . . . . . . . . . 23 97 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 98 10.1. SIP recording metadata Schema Registration . . . . . . . . 24 99 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 24 100 12. Appendix A: Metadata Model Object Instances . . . . . . . . . 24 101 12.1. Use case 1: Basic Call . . . . . . . . . . . . . . . . . . 24 102 12.2. Use case 2: Hold/Resume . . . . . . . . . . . . . . . . . 25 103 12.3. Use case 3: Basic call with Transfer . . . . . . . . . . . 27 104 12.4. Conference Use Cases . . . . . . . . . . . . . . . . . . . 28 105 12.4.1. Case 1: . . . . . . . . . . . . . . . . . . . . . . . 29 106 12.4.2. Case 2: . . . . . . . . . . . . . . . . . . . . . . . 31 107 12.4.3. Case 3: . . . . . . . . . . . . . . . . . . . . . . . 33 108 12.4.4. Case 4: . . . . . . . . . . . . . . . . . . . . . . . 34 109 13. Appendix B: Metadata XML schema Instances . . . . . . . . . . 35 110 13.1. Use case 1: Basic Call . . . . . . . . . . . . . . . . . . 35 111 13.2. Use case 2: Hold/resume . . . . . . . . . . . . . . . . . 37 112 13.3. Use case 3: Basic Call with transfer . . . . . . . . . . . 39 113 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 114 14.1. Normative References . . . . . . . . . . . . . . . . . . . 43 115 14.2. Informative References . . . . . . . . . . . . . . . . . . 44 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 118 1. Introduction 120 Session recording is a critical requirement in many communications 121 environments such as call centers and financial trading. In some of 122 these environments, all calls must be recorded for regulatory, 123 compliance, and consumer protection reasons. Recording of a session 124 is typically performed by sending a copy of a media stream to a 125 recording device. This document focuses on the Recording metadata 126 which describes the communication session. The document describes a 127 metadata model as viewed by Session Recording Server and the 128 Recording metadata format, the requirements for which are described 129 in [RFC6341] and the architecture for which is described in 130 [I-D.ietf-siprec-architecture]. 132 2. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. This 137 document only uses these key words when referencing normative 138 statements in existing RFCs." 140 3. Definitions 142 Metadata Model: The Metadata model is a class diagram in Unified 143 Modelling Language(UML). The model is a structure diagram that 144 describes the structure of a recording's Metadata by showing the 145 classes, their attributes, and the relationships among the classes. 146 Each block in the model above represents a class. The linkages 147 between the classes represents the relationships between the classes. 148 Object diagrams represents instance diagrams of the class diagram and 149 conveys snapshot of metadata. 151 Metadata classes: Each block in the model represents a class. In the 152 metadata model each class is represented as a block having the block 153 name. The description of each class also has representation of its 154 attributes in a second compartment below the class name. Each 155 instance of a class(namely the object) contributes some information 156 to the recording's Metadata. 158 Attributes: Attributes represents the attributes listed in each of 159 the classes. The attributes of a class are listed in the second 160 compartment below the class name. Each instance of class conveys 161 values for these attributes which adds to the recording's Metadata. 163 Linkages: Linkages represents the relationship between the classes in 164 the model. It represents the logical connections betweens classes(or 165 objects) in class diagrams/ object diagrams. The linkages can be 166 associations or composition in the Metadata model of this document. 167 An association represents a family of links. Binary associations 168 (with two ends) are normally represented as a line, with each end 169 connected to a class/object box. An association can be named, and 170 the ends of an association can be adorned with role names, ownership 171 indicators, multiplicity, visibility, and other properties. For 172 instance, in the metadata model we have "sends" association between 173 participant and media stream classes.The relation composition 174 represents owns/holds relationship to show classes contained in 175 another class. For instance, extension data class is contained in 176 one of the other class(like stream or participant or any of the other 177 in the model).The UML graphical representation of a composition 178 relationship is a filled diamond shape on the containing class end of 179 the tree of lines that connect contained class(es) to the containing 180 class. 182 XML element: An XML element represent one XML schema complexType 183 element (xs:complexType) of XML schema 185 XML attributes: An XML attribute represent one XML schema element 186 (xs:element) of XML schema 188 4. Metadata Model 190 Metadata is the information that describes recorded media and the CS 191 to which they relate. Below diagram shows a model for Metadata as 192 viewed by Session Recording Server (SRS). 194 +-------------------------------+ 1 195 | Recording Session (RS) |---------------+ 196 +-------------------------------+ | 197 |1..* | 1..* | 198 | | | 199 | | 0..* | 200 | +-----------------+ | 201 | | Communication | | 202 | | Session (CS) | 1 | 203 | | Group |--------------| 204 | +-----------------+ | 205 | | 0..1 | 206 | | | 207 |0..* | 1..* | 208 +-------------------------------+ | 209 | Communication Session (CS) | 1 | 210 | |---------------| 211 +-------------------------------+ | +------------+ 212 | 1..* |1..* | | | 213 | | | 0..* |Extension | 214 | 2..* |0..* |/\_____| Data | 215 +-------------+ receives +----------------+ |\/ | | 216 | Participant |----------| Media Streams | | +------------+ 217 | |0..* 0..*| | | 218 | | | | | 219 | | | | | 220 | | sends | | | 221 | |----------| | | 222 | |1.* 0..*| | | 223 +-------------+ +----------------+ | 224 | | | 225 |1 |1 | 226 | | | 227 +----------------------------------------+ 229 The Metadata model is a class diagram in Unified Modelling 230 Language(UML). The model is a structure diagram that describes the 231 structure of a recording's Metadata by showing the classes, their 232 attributes, and the relationships among the classes. Each block in 233 the model above represents a class. The linkages between the classes 234 represents the relationships which can be associations or 235 Composition. Session Recording Client (SRC) MAY initiate the 236 Recording Session. Here, Recording Session is a completely 237 independent from the Communication Session that is being recorded at 238 both the SIP dialog level and at the session level. The metadata 239 MUST be conveyed from SRC to SRS. 241 The model allows the capture of a snapshot of a recording's Metadata 242 at a given instant in time. Metadata changes to reflect changes in 243 what is being recorded. For example, if the call is transferred from 244 one participant to another, then the SRC conveys the changes in the 245 model ( In this instance change of participant and the properties of 246 the new media stream) to the SRS. 248 Some of the metadata is not required to be conveyed explicitly from 249 the SRC to the SRS, if it can be obtained contextually by the SRS. 250 For instance, the timing of RS object changes(like Start / Stop time) 251 may not be explicitly conveyed from the SRC to the SRS (The Date 252 header in RS dialog SIP message provides the timing, but it is 253 optional). In such cases the time a change occurred may be assumed 254 to be the same as the time when notification of the change is 255 received by the SRS. This is not true in cases where SRS requests a 256 snapshot of metadata from SRC. 258 5. Recording Metadata Format 260 This section gives an overview of Recording Metadata Format. Some 261 data from the metadata model is assumed to be made available to the 262 SRS through Session Description Protocol (SDP)[RFC4566], and 263 therefore this data is not represented in the XML document format 264 specified in this document. SDP attributes describes about different 265 media formats like audio, video. The other metadata attributes like 266 participant details are represented in a new Recording specific XML 267 document namely application/rs-metadata+xml. The SDP label attribute 268 [RFC4574] provides an identifier by which a metadata XML document can 269 refer to a specific media description in the SDP sent from the SRC to 270 the SRS. 272 The XML document format can be used to represent either the complete 273 metadata or a partial update to the metadata. The latter includes 274 only elements that have changed compared to the previously reported 275 metadata. 277 5.1. XML data format 279 Recording Metadata document is an XML document. recording element 280 MUST present in all recording metadata XML document. recording acts 281 as container for all other elements in this XML document. 283 Recording object is a XML document. It MUST have the XML declaration 284 and it SHOULD contain an encoding declaration in the XML declaration, 285 e.g., "". If the charset 286 parameter of the MIME content type declaration is present and it is 287 different from the encoding declaration, the charset parameter takes 288 precedence. 290 Every application conforming to this specification MUST accept the 291 UTF-8 character encoding to ensure the minimal interoperability. 293 Syntax and semantics error in recording XML document has to be 294 informed to the originator using application specific mechanism. 296 5.1.1. Namespace 298 The namespace URI for elements defined by this specification is a 299 Uniform Resource Namespace (URN) [RFC2141], using the namespace 300 identifier 'ietf' defined by [RFC2648] and extended by [RFC3688]. 302 The URN is as follows: urn:ietf:params:xml:ns:recording 304 5.1.2. recording 306 recording element MUST contain an xmlns namespace attribute with 307 value as urn:ietf:params:xml:ns:recording. One recording element 308 MUST present in the all recording metadata XML document. 310 dataMode element shows whether the XML document is complete document 311 or partial update. The default value is complete. 313 6. Recording Metadata classes 315 This section describes each class of the metadata model, and the 316 attributes of each class. This section also describes how different 317 classes are linked and the XML element for each of them. 319 6.1. Recording Session 320 +-------------------------------+ 321 | Recording Session (RS) | 322 +-------------------------------+ 323 | | +-----------------+ 324 | Start/End Time | 1 0..* | | 325 | |/\__________|Extension Data | 326 | |\/ | | 327 | | +-----------------+ 328 +-------------------------------+ 329 |1..* | 1..* 330 | | 331 |0..* | 0..* 332 Communication Communication 333 Session Session Group(CS Group) 335 Each instance of a Recording Session class (namely the Recording 336 Session Object) represents a SIP session created between an SRC and 337 SRS for the purpose of recording a Communication Session. 339 6.1.1. Attributes 341 A Recording Session class has the following attributes: 342 o Start/End Time - Represents the Start/End time of a Recording 343 Session object. 345 6.1.2. Linkages 347 Each instance of Recording Session has: 349 o Zero or more instances of Communication Session Group. CSG may be 350 zero because it is optional metadata object. Also the allowance 351 of zero instances is to accommodate persistent recording, where 352 there may be none. 353 o Zero or more instances of Communication Session objects. 355 6.1.3. XML element 357 Recording Session object is represented by recording XML element. 358 That in turn relies on the SIP/SDP session with which the XML 359 document is associated to provide some of the attributes of the 360 Recording Session element. 362 Start and End time value are derivable from Date header(if present in 363 SIP message) in RS. In cases where Date header is not present, 364 Start/End time are derivable from the time at which SRS receives the 365 notification of SIP message to setup RS / disconnect RS. 367 6.2. Communication Session Group 369 Recording Session (RS) 370 | 1..* 371 | 372 | 0..* 373 +-------------------------------+ 374 | Communication Session | 375 | Group | 376 +-------------------------------+ 377 | Unique-ID | +----------------+ 378 | associate-time | 1 0..* | | 379 | disassociate-time |/\_________|Extension Data | 380 | |\/ | | 381 +-------------------------------+ +----------------+ 382 | 0..1 383 | 384 | 1..* 385 Communication Session (CS) 387 One instance of a Communication Session Group class (namely the 388 Communication Session Group object) provides association or linking 389 of Communication Sessions. 391 6.2.1. Attributes 393 A CS Group has the following attributes: 394 o Unique-ID - This Unique-ID is to group different CSs that are 395 related. SRC (or SRS) is responsible for ensuring the uniqueness 396 of Unique-ID in case multiple SRC interacts with the same SRS. 397 The mechanism by which SRC groups the CS is outside the scope of 398 SIPREC. 399 o Associate-time - Associate-time for CS-Group shall be calculated 400 by SRC as the time when a grouping is formed. The rules that 401 determine how a grouping of different Communication Session 402 objects is done by SRC is outside the scope of SIPREC. 403 o Disassociate-time - Disassociate-time for CS-Group shall be 404 calculated by SRC as the time when the grouping ends 406 6.2.2. Linkages 408 The linkages between Communication Session Group class and other 409 classes is association. A communication Session Group is associated 410 with RS and CS in the following manner: 412 o There is one or more Recording Session objects per Communication 413 Session Group. 414 o Each Communication Session Group object has to be associated with 415 one or more RS [Here each RS can be setup by the potentially 416 different SRCs] 417 o There is one or more Communication Sessions per CS Group [e.g. 418 Consult Transfer] 420 6.2.3. XML element 422 Group element is an optional element provides the information about 423 the communication session group 425 Each communication session group (CSG)object is represented using one 426 group element. Each group element has unique URN UUID attribute 427 which helps to uniquely identify CSG. 429 6.3. Communication Session 431 Recording Communication 432 Session Session Group(CS Group) 433 |1..* | 0..1 434 | | 435 |0..* | 1..* 436 +-------------------------------+ +-----------------+ 437 | Communication Session (CS) | 1 0..* | | 438 | |/\_____________|Extension Data | 439 +-------------------------------+\/ | | 440 | CS Identifier | +-----------------+ 441 | Termination Reason | 442 | Start Time | 443 | End Time | 444 +-------------------------------+ 445 | | 446 | 1..* |1..* 447 | | 448 | 2..* |0..* 449 Participant Media Stream 451 A Communication Session class and its object in the metadata model 452 represents Communication Session and its properties needed as seen by 453 SRC. 455 6.3.1. Attributes 457 A communication Session class has the following attributes: 459 o Termination Reason - This represents the reason why a CS was 460 terminated. The communication session MAY contain a Call 461 Termination Reason. This MAY be derived from SIP Reason header of 462 CS. 463 o CS Identifier - This attribute is used to uniquely identify a CS. 464 o Start Time - This optional attribute represents CS start time 465 o End Time - This optional attribute represents CS end time 467 This document does not specify attributes relating to what should 468 happen to a recording of a CS after it has been delivered to the SRS, 469 e.g., how long to retain the recording, what access controls to 470 apply. The SRS is assumed to behave in accordance with policy. The 471 ability for the SRC to influence this policy is outside the scope of 472 this document. However if there are implementations where SRC has 473 enough information, this could be sent as Extension Data attached to 474 CS 476 6.3.2. Linkages 478 A Communication Session is linked to CS-Group, Participant, Media 479 Stream and Recording Session classes using the association 480 relationship. Association between CS and Participant allows: 482 o CS to have atleast two or more participants 483 o Participant is associated with one or more CS's. This includes 484 participants who are not directly part of any CS. An example of 485 such a case is participants in a premixed media stream. The SRC 486 may have knowledge of such Participants, yet not have any 487 signaling relationship with them. This might arise if one 488 participant in CS is a conf focus. To summarize even if SRC does 489 not have direct signalling relationships with all participants in 490 a CS, it should nevertheless create a Participant object for each 491 participant that it knows about 492 o The model also allows participants in CS that are not participants 493 in the media. An example is the identity of a 3pcc controller 494 that has initiated a CS to two or more participants of the CS. 495 Another example is the identity of a conference focus. Of course 496 a focus is probably in the media, but since it may only be there 497 as a mixer, it may not report itself as a participant in any of 498 the media streams. 500 Association between CS and Media Stream allows: 502 o A CS to have zero or more Streams 503 o A stream can be associated with 1 or more CS. An example is 504 multicast MoH stream which might be associated with many CSs. 506 Association between CS and RS allows: 508 o Each instance of RS has Zero or more instances of Communication 509 Session objects. 510 o Each CS has to be associated with one more RS [ Here each RS can 511 be potentially setup by different SRCs] 513 6.3.3. XML element 515 Session element provides the information about the communication 516 session 518 Each communication session(CS) object is represented by one session 519 element. Each session element has unique URN UUID attribute which 520 helps to uniquely identify CS. 522 Reason element MAY be included to represent the Termination Reason 523 attribute. group-ref element MAY exist to indicate the group where 524 the mentioned session belongs. 526 6.4. Participant 528 Communication Session (CS) 529 | 1..* 530 | 531 | 2..* 532 +-------------------------------+ 533 | Participant | 534 | | 535 +-------------------------------+ 536 | AoR list | +-----------------+ 537 | Name | 1 0..* | | 538 | Associate time |/\__________|Extension Data | 539 | Disassociate time |\/ | | 540 | Capabilities | | | 541 +-------------------------------+ +-----------------+ 542 | 0..* 1..*| 543 receives| |sends 544 | 0..* 0..*| 545 Media Stream 547 A Participant class and its objects has information about a device 548 that is part of a CS and/or contributes/consumes media stream(s) 549 belonging to a CS. 551 6.4.1. Attributes 553 Participant has attributes like: 555 o AoR list - Has list of AoRs. An AoR MAY be SIP/SIPS/TEL URI. 556 There are cases where a participant can have more than one AoR [ 557 e.g. P-Asserted-ID which can have both SIP and TEL URIs] 558 o Name - This attribute represents Participant name(SIP display 559 name) or DN number ( in case it is known) 560 o Associate-time - associate-time is calculated by SRC as the time 561 it sees a participant is associated to CS 562 o Disassociate-time- Disassociate-time is calculated by SRC as the 563 time it see a participant disassociate from a CS. It is possible 564 that a given participant can have multiple associate/disassociate 565 times within given communication session. 566 o Capabilities - A participant capabilities as defined in RFC 3840 567 [RFC3840] is an optional attribute that includes the capabilities 568 of a participant in a CS. This attribute is an attribute of 569 association of participant to CS. Each participant shall have 570 Zero or more capabilities. A participant may use different 571 capabilities depending on the role it plays at a particular 572 instance. IOW if a participants moves across different CSs ( due 573 to transfer e.t.c) OR is simultaneously present in different CSs 574 its role may be different and hence the capability used. 576 NOTE: How to represent capabilities attribute in XML is an open item. 578 This document does not specify other attributes relating to 579 participant e.g. Participant Role, Participant type. An SRC which 580 has information of these attributes can indicate the same as part of 581 extension data to Participant from SRC to SRS. 583 6.4.2. Linkages 585 The participant class is linked to MS and CS class using association 586 relationship. The association between participant and Media Stream 587 allows: 589 o Participant to receives zero or more media streams 590 o Participant to send zero or more media streams. (Same participant 591 provides multiple streams e.g. audio and video) 592 o Media stream to be received by zero or more participants. Its 593 possible, though perhaps unlikely, that a stream is generated but 594 sent only to the SRC and SRS, not to any participant. E.g. In 595 conferencing where all participants are on hold and the SRC is 596 collocated with the focus. Also a media stream may be received by 597 multiple participants (e.g. Whisper calls, side conversations). 598 o Media stream to be sent by one or more participants (pre-mixed 599 streams). 601 Example of a case where a participant receives Zero or more streams - 602 a Supervisor may have side conversation with Agent, while Agent 603 converses with customer. 605 6.4.3. XML element 607 A participant element represents a Participant object. 609 There MUST be atleast 2 participant for any given session. "send" or 610 "recv" element in each participant is associating SDP m-lines with 611 the participant. send element indicates that participant is sending 612 the stream of media with the mentioned media description. recv 613 element indicates that participant is receiving the stream and by 614 default all participant will receive the stream. recv element has 615 relevance in case whisper call scenario wherein few of the 616 participant in the session receives the stream and not others. 618 Participant MUST have AOR element which contains SIP/SIPS URI to 619 identify the participant. AOR element is SIP/SIPS URI FQDN or IP 620 address which represents the user. name is an optional element to 621 represent display name. 623 Each participant element has unique URN UUID attribute which helps to 624 uniquely identify participant and session URN UUID to associate 625 participant with specific session element. URN UUID of participant 626 *MUST* used in the scope of CSG and no new URN UUID has to be created 627 for the same element (participant, stream) between different CS in 628 the same CSG. In case URN UUID has to be used permanent, careful 629 usage of URN UUID to original AoR has to be decided by the 630 implementers and it is implementer's choice. 632 6.5. Media Stream 633 Participant 634 | 0..* 1..*| 635 receives| |sends 636 | 0..* 0..*| 637 +-------------------------+ 638 | Media Stream | 639 | | 640 Communication 1..* 0..* +-------------------------+ 641 Session ------------| | +----------+ 642 | Media Stream Reference |1 0..* | | 643 | Content-type |/\______|Extension | 644 | CSRC |\/ | Data | 645 +-------------------------+ +----------+ 647 A Media Stream class (and its objects) has the properties of media as 648 seen by SRC and sent to SRS. Different snapshots of media stream 649 object may be sent whenever there is a change in media (e.g. dir 650 change like pause/resume and/or codec change and/or participant 651 change.). 653 6.5.1. Attributes 655 A Media Stream class has the the following attributes: 657 o Media Stream Reference - In implementations this can reference to 658 m-line 659 o Content - The content of an MS element will be described in terms 660 of value from the RFC 4796 [RFC4796] registry. 661 o CSRC - The linkage between the participants to its contributing 662 media stream in a mixed RS stream is provided by CSRC attribute. 663 Not all SRC may have the capability to determine this and hence 664 this is a optional attribute. Having this info can allow the SRS 665 to determine which participants are part(contributors) of 666 particular parts of the mixed stream. 668 NOTE: How CSRC can be represented in XML is still an open item. CSRC 669 attribute is an attribute of media stream to participant association. 670 Another open items if there is a need for multiple CSRCs. A 671 participant may have multiple CSRCs - potentially a different one for 672 each stream in which it participates. 674 The metadata model should include media streams that are not being 675 delivered to the SRS. Examples include cases where SRC offered 676 certain media types but SRS chooses to accept only a subset of them 677 OR an SRC may not even offer a certain media type due it its 678 restrictions to record 680 6.5.2. Linkages 682 A Media Stream is linked to participant and CS classes using the 683 association relationship. The details of association with the 684 Participant are described in the Participant class section. The 685 details of association with CS is mentioned in the CS section. 687 6.5.3. XML element 689 stream element represents a Media Stream object. Stream element 690 indicates SDP media lines associated with the session and 691 participants. 693 This element indicates the SDP m-line properties like label 694 attributes, media mode. Label attribute is used to link m-line SDP 695 body using label attribute in SDP m-line. The media mode helps in 696 understanding whether the media is mixed or not. 698 Each stream element has unique URN UUID attribute which helps to 699 uniquely identify stream and session URN UUID to associate stream 700 with specific session element. 702 The content attribute if an SRC wishes to send is conveyed in RS SDP. 704 6.6. Extension Data 706 A recording metadata object contains additional data not specified as 707 part of siprec. This is intended to accommodate future standards 708 track extensions, as well as vendor and user specific extensions. 709 The mechanism MUST provide a means of unambiguously distinguishing 710 such extension data. 712 6.6.1. Linkages 714 Extension data class is linked to other classes using the composition 715 relationship. An extension data class ( and its objects) is 716 contained/owned by another Metadata class. Each instance of Metadata 717 class(except extension data class itself) has 719 o Zero or more instances of Extension data class 720 o Each Extension data class is contained/owned by a Metadata class 721 other than itself 723 6.6.2. XML element 725 Extensiondata element provides the mechanism by which namespace/ 726 element MAY be extended with standard or proprietary information. 728 extensiondata element MUST include any other XML namespace. Multiple 729 namespace MAY exists under extensiondata. extensiondata element exist 730 in each level like recording, session, participant, stream to provide 731 extensiondata specific to each element. extensiondata element MUST be 732 part of parent element for which the additional information is sent 733 and hence no Unique ID is needed. 735 6.7. associate-time/disassociate-time 737 associate-time/disassociate-time contains a string indicating the 738 date and time of the status change of this tuple. The value of this 739 element MUST follow the IMPP datetime format [RFC3339]. Timestamps 740 that contain 'T' or 'Z' MUST use the capitalized forms. At a time, 741 any of the time tuple associate-time or disassociate-time MAY exist 742 in the element namely group, session, participant and not both 743 timestamp at the same time. 745 As a security measure, the timestamp element SHOULD be included in 746 all tuples unless the exact time of the status change cannot be 747 determined. 749 6.8. Unique ID format 751 UUID encoded more densely than the UUID URN (e.g. radix64 of the 752 binary uuid form defined in RFC 4122 [RFC4122]) SHOULD be used as a 753 format for Unique ID. How to represent this id in XML is still an 754 open item. 756 7. SIP Recording Metadata Example 758 7.1. Complete SIP Recording Metadata Example 760 The following example provides all the tuples involved in Recording 761 Metadata XML body. 763 764 765 complete 766 767 2010-12-16T23:41:07Z 768 769 770 771 sip:alice@cisco.com 772 773 774 FOO! 775 bar 776 777 778 779 780 urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302 781 782 2010-12-16T23:41:07Z 783 784 FOO! 785 bar 786 787 788 791 sip:partha@blr.cisco.com 792 urn:uuid:8b53f3de-da39-4846-93c7-ee5e5f8f6f0b 793 urn:uuid:50000c9b-9191-40a4-8231-5bcbca5e2b17 794 urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a 795 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 796 2010-12-16T23:41:07Z 797 798 FOO! 799 bar 800 801 803 806 sip:paul@box.cisco.com 807 urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a 808 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 809 urn:uuid:50000c9b-9191-40a4-8231-5bcbca5e2b17 810 urn:uuid:8b53f3de-da39-4846-93c7-ee5e5f8f6f0b 811 2010-12-16T23:41:07Z 812 813 FOO! 814 bar 815 816 817 819 1 820 821 822 824 825 826 828 829 830 832 833 834 836 SIP Recording Metadata Example XML body 838 7.2. Partial Update of Recording metadata XML body 840 The following example provides partial update in Recording Metadata 841 XML body for the above example. The example illustrate the 842 disassociate-time for a participant from a session. 844 845 846 partial 847 850 sip:partha@blr.cisco.com 851 2010-12-16T23:41:07Z 852 853 FOO! 854 bar 855 856 857 859 Partial update of SIP Recording Example XML body 861 8. XML Schema definition for Recording metadata 863 This section defines XML schema for Recording metadata document 865 866 871 872 873 874 875 876 878 880 882 884 886 888 889 890 891 892 894 896 898 899 901 902 903 904 906 908 910 912 915 916 918 919 920 921 923 925 927 929 931 933 935 936 938 940 941 942 943 945 947 949 950 952 954 955 956 957 961 962 964 966 967 968 969 971 972 973 974 977 978 979 980 981 982 983 984 985 987 9. Security Considerations 989 The metadata information sent from SRC to SRS MAY reveal sensitive 990 information about different participants in a session. For this 991 reason, it is RECOMMENDED that a SRC use a strong means for 992 authentication and metadata information protection and that it apply 993 comprehensive authorization rules when using the metadata format 994 defined in this document. The following sections will discuss each 995 of these aspects in more detail. 997 9.1. Connection Security 999 It is RECOMMENDED that a SRC authenticate SRS using the normal SIP 1000 authentication mechanisms, such as Digest as defined in Section 22 of 1001 [RFC3261]. The mechanism used for conveying the metadata information 1002 MUST ensure integrity and SHOULD ensure confidentially of the 1003 information. In order to achieve these, an end-to-end SIP encryption 1004 mechanism, such as S/MIME described in [RFC3261], SHOULD be used. 1006 If a strong end-to-end security means (such as above) is not 1007 available, it is RECOMMENDED that a SRC use mutual hop-by-hop 1008 Transport Layer Security (TLS) authentication and encryption 1009 mechanisms described in "SIPS URI Scheme" and "Interdomain Requests" 1010 of [RFC3261]. 1012 10. IANA Considerations 1014 This specification registers a new XML namespace, and a new XML 1015 schema. 1017 10.1. SIP recording metadata Schema Registration 1019 URI: urn:ietf:params:xml:ns:recording 1021 Registrant Contact: IETF SIPREC working group, Ram mohan 1022 R(rmohanr@cisco.com) 1024 XML: the XML schema to be registered is contained in Section 6. 1026 Its first line is and its last 1027 line is 1029 11. Acknowledgement 1031 We wish to thank John Elwell(Siemens-Enterprise), Henry Lum(Alcatel- 1032 Lucent), Leon Portman(Nice), De Villers, Andrew Hutton(Siemens- 1033 Enterprise), Deepanshu Gautam(Huawei), Charles Eckel(Cisco), Muthu 1034 Arul(Cisco), Michael Benenson(Cisco), Hadriel Kaplan (ACME), Brian 1035 Rosen(Neustar), Scott Orton(Broadsoft) for their valuable comments 1036 and inputs. 1038 We wish to thank Joe Hildebrand(Cisco), Peter Saint-Andre(Cisco) for 1039 the valuable XML related guidance and Martin Thompson for validating 1040 the XML schema and providing comments on the same. 1042 12. Appendix A: Metadata Model Object Instances 1044 This section describes the metadata model object instances for 1045 different use cases of SIPREC. For the sake of simplicity as the 1046 media streams sent by each of the participants is received by every 1047 other participant in these use cases, it is NOT shown in the object 1048 instance diagrams below. Also for the sake of ease not all 1049 attributes of each object are shown in these instance diagrams. 1051 12.1. Use case 1: Basic Call 1053 Basic call between two Participants A and B. In this use case each 1054 participant sends one Media Stream. For the sake of simplicity 1055 "receives" lines are not shown in this instance diagram. Media 1056 Streams sent by each participant is received all other participants 1057 of that CS. 1059 +-------------------------------+ 1060 | Recording Session (RS) | 1061 +-------------------------------+ 1062 | 1063 | 1064 | 1065 +----------------+ 1066 | Communication | 1067 | Session (CS) | 1068 +----------------+-----------------------+ 1069 | Start Time | | 1070 +----------------+ | 1071 | | 1072 |-------------------+ | 1073 | | | 1074 +---------------+ +---------------+ | 1075 | ParticipantA | | ParticipantB | | 1076 | | | | | 1077 +---------------+ +---------------+ | 1078 | | | 1079 sends | | sends | 1080 | | | 1081 +---------------+ +---------------+ | 1082 |Media Stream A1| |Media Stream B1| | 1083 +---------------+ +---------------+ | 1084 |MediaStream Ref| |MediaStream Ref| | 1085 | | | | | 1086 +---------------+ +---------------+ | 1087 | | | 1088 +-----------------------------------+ 1090 12.2. Use case 2: Hold/Resume 1092 Basic call between two Participants A and B and with Participant A or 1093 B doing a Hold/Resume. In this use case each participant sends one 1094 Media Stream. After Hold/Resume the properties of Media can change. 1095 For the sake of simplicity "receives" lines are not shown in this 1096 instance diagram. Media Streams sent by each participant is received 1097 all other participants of that CS. 1099 +-------------------------------+ 1100 | Recording Session (RS) | 1101 +-------------------------------+ 1102 | | 1103 | | 1104 | | 1105 | +-------------------------------+ 1106 | | Communication Session (CS) | 1107 | +-----------| Group(CSG) | 1108 | | +-------------------------------+ 1109 | | | Unique-id1 | 1110 | | +-------------------------------+ 1111 | | 1112 | | 1113 | | 1114 +----------------+ 1115 | Communication | 1116 +-| Session (CS) |----------------------------------------------+ 1117 | +----------------+ | 1118 | | | | 1119 | +----------------+ | 1120 | | | 1121 | |-------------------+ | 1122 | | | | 1123 | +---------------+ +---------------+ | 1124 | | ParticipantA | | ParticipantB |-----------+ | 1125 | | |--+ | | | | 1126 | +---------------+ | +---------------+ |sends(After | 1127 | | | | | | | Resume) | 1128 | | | | | | +--------------+ | 1129 | sends | | +--+ | sends | |MediaStream B3| | 1130 | | -----+ | | +-----+ +--------------+ | 1131 | +---------------+ | | +---------------+ | |MediaStreamRef|-| 1132 | |Media Stream A1| | | |Media Stream B1| | | | | 1133 | +---------------+ | | +---------------+ | | | | 1134 +-|MediaStreamref | | | |MediaStreamRef | | +--------------+ | 1135 | | | | | |-|-------------------| 1136 +---------------+ | | +---------------+ | | 1137 | | | | 1138 +------------+ |sends |sends (hold) | 1139 | sends |(Resume) | | 1140 | (hold) +-------+ +-------+ | 1141 | | | | 1142 +---------------+ +---------------+ +--------------+ | 1143 |Media Stream A2| |Media Stream A3| |MediaStream B2| | 1144 +---------------+ +---------------+ | | | 1145 |MediaStreamref | |MediaStreamRef | +--------------+ | 1146 | | | | |Codec Params | | 1147 +---------------+ +---------------+ | | | 1148 | | | | | 1149 | | +--------------+ | 1150 | | | | 1151 +------------------------------------------------------+ 1153 12.3. Use case 3: Basic call with Transfer 1155 Basic call between two Participants A and B and with Participant A 1156 transfer(consult transfer) to Participant C. In this use case each 1157 participant sends one Media Stream. After transfer the properties of 1158 Participant A Media can change. For the sake of simplicity 1159 "receives" lines are not shown in this instance diagram. Media 1160 Streams sent by each participant is received all other participants 1161 of that CS. 1163 +-------------------------------+ 1164 | Recording Session (RS) |-------+ 1165 +-------------------------------+ | 1166 | | 1167 | | 1168 | | 1169 +-------------------------------+ | 1170 | Communication Session (CS) | | 1171 | Group(CSG) | | 1172 +-------------------------------+ | 1173 | Unique-id1 | | 1174 +-------------------------------+ | 1175 | | 1176 |----------------------------+ 1177 | 1178 |-----------------+ 1179 | | 1180 +----------------+ +----------------+ 1181 | Communication | | Communication | 1182 | Session (CS)1 | | Session (CS)2 | 1183 +----------------+ +----------------+-----------+ 1184 | | | | | 1185 +----------------+ +----------------+ | 1186 | | 1187 |-------------------+ | 1188 | | | | 1189 +---------------+ | +---------------+ | 1190 | ParticipantA | | | ParticipantB | | 1191 | | | | | | 1192 +---------------+ | +---------------+ | 1193 | | | | 1195 sends | | | sends | 1196 | | | | 1197 +---------------+ | +---------------+ | 1198 |Media Stream A1| | |Media Stream B1| | 1199 +---------------+ | +---------------+ | 1200 | | | | | | 1201 | | | | Media Stream | | 1202 | Media Stream |---+---| Ref | | 1203 | Ref | | | | 1204 +---------------+ +---------------+ | 1205 | 1206 | 1207 +----------------------------| 1208 | | 1209 +--------------------------------+ | 1210 | | | 1211 +---------------+ +---------------+ | 1212 | Participant A | | Participant C | | 1213 | (same) | | | | 1214 +---------------+ +---------------+ | 1215 | | | 1216 | sends (After transfer) | sends | 1217 +----------------+ +----------------+| 1218 | Media Stream A2| | Media Stream C1|| 1219 +----------------+ +----------------+| 1220 | Media StreamRef| | Media StreamRef|| 1221 | | | || 1222 | | | || 1223 +----------------+ +----------------+| 1224 | | | 1225 | | | 1226 | | | 1227 +-------------------------------------------+ 1229 12.4. Conference Use Cases 1231 Depending on who act as SRC and the information that an SRC has there 1232 can be several ways to model conference use cases. This section has 1233 instance diagrams for the following cases: 1235 o A CS where one of the participant (which is also SRC) is a user in 1236 a conference 1237 o A CS where one of the participant is focus ( which is also SRC) 1238 o A CS where one of the participant is user and the SRC is a 1239 different entity like B2BUA 1241 o A CS where one of the participant is focus and the SRC is a 1242 different entity like B2BUA 1244 NOTE: There MAY be other ways to model the same use cases depending 1245 on what information the SRC has. 1247 12.4.1. Case 1: 1249 This is the usecase where there is a CS with one of the participant 1250 (who is also SRC) as a user in a conference. For the sake of 1251 simplicity the receive lines for each of the participant is not 1252 shown. 1254 +---------------------------------------------------+ 1255 | Communication Session | 1256 | +-------------+ +--------------+ | 1257 | | | | | | 1258 | |Participant B| | Participant A| | 1259 | | (User in |--------------| | | 1260 | | conf/SRC) | | | | 1261 | +-------------+ +--------------+ | 1262 | | | | | | 1263 +---------------------------------------------------+ 1264 | | | | 1265 | | | | 1266 D E F G (Participants of Conference) 1268 Instance Diagram: 1270 +-------------------------------+ 1271 | Recording Session (RS) |--+ 1272 +-------------------------------+ | 1273 | | 1274 | | 1275 | | 1276 +-------------------------------+ | 1277 | Communication Session (CS) | | 1278 | Group(CSG) | | 1279 +-------------------------------+ | 1280 | Unique-id1 | | 1281 +-------------------------------+ | 1282 | | 1283 |-----------------------+ 1284 | 1285 +----------------+ 1286 | Communication | 1287 | Session (CS) |--+----------------+-----+ 1288 +----------------+ | | | 1289 | | | | | 1290 +----------------+ | | | 1291 | | | | 1292 | | | | 1293 | | | | 1294 +---------------+ | | | 1295 | ParticipantA | | | | 1296 | | | | | 1297 +---------------+ | | | 1298 | | | | 1299 sends | | | | 1300 | | | | 1301 +---------------+ | | | 1302 |Media Stream A1| | | | 1303 +---------------+ | | | 1304 |MediaStream Ref|-----|----------------+ | 1305 | | | | | 1306 +---------------+ | | | 1307 | | | 1308 | | | 1309 +-------------+ | | 1310 | | | 1311 | | | 1312 +----------------+ | | 1313 | Participant B | | | 1314 | (in conf) | | | 1315 +----------------+ | | 1316 | | | 1317 sends | | | 1318 | | | 1319 +----------------+ | | 1320 | Media Stream B1|---------------------+ | 1321 +----------------+ sends | 1322 | MediaStream Ref| | 1323 | | +-----------------+ 1324 +----------------+ | 1325 | | 1326 |sends | 1327 | | 1328 +-----------------+-------------+------------+ 1329 | | | | 1330 | | | | 1331 +------------+ +------------+ +------------+ +-------------+ 1332 |participantD| |ParticipantE| |ParticipantF| |Participant G| 1333 +------------+ +------------+ +------------+ +-------------+ 1334 In this example we have two participants A and B who are part of a 1335 Communication Session(CS). One of the participants B is part of a 1336 conference and also acts as SRC.There can be two cases here. B can 1337 be a participant of the conference or B can be a focus. In this 1338 instance diagram Participant B is a user in a conference. The SRC 1339 (Participant B) subscribes to conference event package to get the 1340 details of other particiants. Participant B(SRC) sends the same 1341 through the metadata to SRS. In this instance diagram the Media 1342 Stream(mixed stream) sent from Participant B has media streams 1343 contributed by conference participants (D,E,F and G). For the sake 1344 of simplicity the "receives" line is not shown here. In this example 1345 the media stream sent by each participant(A or B) of CS is received 1346 by all other participant(A or B). 1348 12.4.2. Case 2: 1350 This is the usecase where there is a CS where one of the participant 1351 is focus ( which is also SRC). 1353 +---------------------------------------------------+ 1354 | Communication Session | 1355 | +--------------+ +--------------+ | 1356 | | |--------------| | | 1357 | |Participant C | | Participant A| | 1358 | | (Focus in |------+ | | | 1359 | | conf and SRC)|---+ | +--------------+ | 1360 | +--------------+ | | | 1361 | | | +---------+ | 1362 | | | | | 1363 | +--------------+ | +---------------+ | 1364 | | Participant B| +---+ | Participant D | | 1365 | | | | | | | 1366 | +--------------+ | +---------------+ | 1367 | | | 1368 | +--------------+ | 1369 | |Participant E | | 1370 | | | | 1371 | +--------------+ | 1372 | | 1373 +---------------------------------------------------+ 1375 Instance Diagram: 1377 +-------------------------------+ 1378 | Recording Session (RS) | 1379 +-------------------------------+ 1380 |-------------------------+ 1381 | | 1382 | | 1383 +-------------------------------+ | 1384 | Communication Session (CS) | | 1385 | Group(CSG) | | 1386 +-------------------------------+ | 1387 | Unique-id1 | | 1388 +-------------------------------+ | 1389 | | 1390 |-------------------------+ 1391 | 1392 +----------------+ 1393 | Communication | 1394 | Session (CS) |----------------------+ 1395 +----------------+ | 1396 | | | 1397 +----------------+ | 1398 | | 1399 |-------------------+ | 1400 | | | | 1401 +---------------+ | +---------------+ | 1402 | ParticipantA | | | ParticipantB | | 1403 | | | | | | 1404 +---------------+ | +---------------+ | 1405 | | | | 1406 sends | | | sends | 1407 | | | | 1408 +---------------+ | +---------------+ | 1409 |Media Stream A1| | |Media Stream B1| | 1410 +---------------+ | +---------------+ | 1411 |MediaStream Ref| | |MediaStream Ref| | 1412 | |---+---| | | 1413 +---------------+ +---------------+ | 1414 | 1415 +----------------------------------+ 1416 | | | | 1417 | | | | 1418 +---------------+ | +---------------+ | 1419 | ParticipantD | | | ParticipantE | | 1420 | | | | | | 1421 +---------------+ | +---------------+ | 1422 | | | | 1423 sends | | | sends | 1424 | | | | 1425 +---------------+ | +---------------+ | 1426 |Media Stream D1| | |Media Stream E1| | 1427 +---------------+ | +---------------+ | 1428 |MediaStream Ref| | |MediaStream Ref| | 1429 | |---+---| | | 1430 +---------------+ +---------------+ | 1431 | 1432 | 1433 +----------+ 1434 +-----------------| 1435 | | 1436 | | 1437 +----------------+ | 1438 | Participant C | | 1439 | (focus +src) | | 1440 +----------------+ | 1441 | | 1442 Sends | +-------+ 1443 | | 1444 "sends" OR | | 1445 contributed +----------------+ 1446 by | Media Stream C1| 1447 Participants+----------------+ "receives" by participants A,B,D,E 1448 A,B,D,E | MediaStream Ref|------------------------------------ 1449 ------------| Codec Params | 1450 +----------------+ 1452 In this example we have two participants A and B who are part of a 1453 Communication Session(CS). One of the participants (C) is focus of a 1454 conference and also acts as SRC. The SRC (Participant C) being the 1455 Focus of the conference has access to the details of other 1456 particiants. SRC (Participant C) sends the same through the metadata 1457 to SRS. In this instance diagram the Media Stream(mixed stream) sent 1458 by C has media streams contributed by conference participants (A, B, 1459 D and E). Participants A, B,D and E sends Media Streams A1, B1, D1 1460 and E1 respectively. The media stream sent by Participant C(Focus) 1461 is received by all other participants of CS. For the sake of 1462 simplicity the "receives" line is not shown linked to all other 1463 participants. 1465 NOTE: SRC ( Participant C) can send mixed stream or seperate streams 1466 to SRS 1468 12.4.3. Case 3: 1470 A CS where one of the participant is user and the SRC is a different 1471 entity like B2BUA. In this case the SRC may not know that one of the 1472 user is part of conference. Hence the instance diagram will not have 1473 information about the conference participants. 1475 +---------------------------------------------------+ 1476 | Communication Session | 1477 | +-------------+ +------+ +--------------+ | 1478 | | | | (SRC)| | | | 1479 | |Participant B|--|B2BUA |----| Participant A| | 1480 | | (User in | +------+ | | | 1481 | | conf) | | | | 1482 | +-------------+ +--------------+ | 1483 | | | | | | 1484 +---------------------------------------------------+ 1485 | | | | 1486 | | | | 1487 D E F G (Participants of Conference) 1489 12.4.4. Case 4: 1491 A CS where one of the participant is focus and the SRC is a different 1492 entity like B2BUA. In this case the participant which is focus sends 1493 "isfocus" in SIP message to SRC. The SRC subscribe to conference 1494 event package on seeing this "isfocus". SRC learns the details of 1495 other participants of conference from the conference package and send 1496 the same in metadata to SRS. The instance diagram for this use case 1497 is same as Case 1. 1499 +--------------------------------+ 1500 | Conference Event Package | 1501 | | 1502 +--------------------------------+ 1503 | 1504 | subscribes 1505 | 1506 +---------------------|-----------------------------+ 1507 | Communication |Session | 1508 | +-------------+ +------+ +--------------+ | 1509 | | | | (SRC)| | | | 1510 | |Participant B|--|B2BUA |----| Participant A| | 1511 | | (FOCUS in | +------+ | | | 1512 | | conf) | | | | 1513 | +-------------+ +--------------+ | 1514 | | | | | | 1515 +---------------------------------------------------+ 1516 | | | | 1517 | | | | 1518 D E F G (Participants of Conference) 1520 13. Appendix B: Metadata XML schema Instances 1522 This section describes the metadata model XML instances for different 1523 use cases of SIPREC. For the sake of simplicity the complete SIP 1524 messages are NOT shown here. 1526 13.1. Use case 1: Basic Call 1528 Basic call between two Participants A(Ram) and B(Partha) who are part 1529 of one session. In this use case each participant sends two Media 1530 Streams. Media Streams sent by each participant is received all 1531 other participants of that CS in this use-case. Below is the initial 1532 snapshot sent by SRC that has complete metadata. For the sake of 1533 completeness even snippets of SDP is shown. For the sake of 1534 simplicity these use-cases assume the RS stream is unmixed. 1536 Content-Type: application/SDP 1537 ... 1538 m=audio 49170 RTP/AVP 0 1539 a=rtpmap:0 PCMU/8000 1540 a=label:96 1541 a=sendonly 1542 ... 1543 m=video 49174 RTP/AVPF 96 1544 a=rtpmap:96 H.264/90000 1545 a=label:97 1546 a=sendonly 1547 ... 1548 m=audio 51372 RTP/AVP 0 1549 a=rtpmap:0 PCMU/8000 1550 a=label:98 1551 a=sendonly 1552 ... 1553 m=video 49176 RTP/AVPF 96 1554 a=rtpmap:96 H.264/90000 1555 a=label:99 1556 a=sendonly 1557 .... 1558 1559 1560 complete 1561 1562 2010-12-16T23:41:07Z 1563 1564 1565 1566 sip:alice@cisco.com 1568 1569 1570 FOO! 1571 bar 1572 1573 1574 1575 1576 urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302 1577 1578 2010-12-16T23:41:07Z 1579 1580 FOO! 1581 bar 1582 1583 1584 1587 sip:ram@blr.cisco.com 1588 urn:uuid:8b53f3de-da39-4846-93c7-ee5e5f8f6f0b 1589 urn:uuid:50000c9b-9191-40a4-8231-5bcbca5e2b17 1590 urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a 1591 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 1592 2010-12-16T23:41:07Z 1593 1594 FOO! 1595 bar 1596 1597 1599 1602 sip:partha@blr.sonus.com 1603 urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a 1604 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 1605 urn:uuid:50000c9b-9191-40a4-8231-5bcbca5e2b17 1606 urn:uuid:8b53f3de-da39-4846-93c7-ee5e5f8f6f0b 1607 2010-12-16T23:41:07Z 1608 1609 FOO! 1610 bar 1611 1612 1613 1615 1617 1618 1620 1621 1622 1624 1625 1626 1628 1629 1630 1632 13.2. Use case 2: Hold/resume 1634 Basic call between two Participants A and B. This is the continuation 1635 of above use-case. One of the participants(say A) goes on hold and 1636 then resumes as part of the same session. The metadata snapshot 1637 looks as below 1639 During hold 1640 Content-Type: application/SDP 1641 ... 1642 m=audio 49170 RTP/AVP 0 1643 a=rtpmap:0 PCMU/8000 1644 a=label:96 1645 a=inactive 1646 ... 1647 m=video 49174 RTP/AVPF 96 1648 a=rtpmap:96 H.264/90000 1649 a=label:97 1650 a=inactive 1651 ... 1652 m=audio 51372 RTP/AVP 0 1653 a=rtpmap:0 PCMU/8000 1654 a=label:98 1655 a=sendonly 1656 ... 1657 m=video 49176 RTP/AVPF 96 1658 a=rtpmap:96 H.264/90000 1659 a=label:99 1660 a=sendonly 1661 .... 1663 1664 1665 partial 1666 1669 sip:ram@blr.cisco.com 1670 urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a 1671 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 1672 1673 1676 sip:partha@blr.cisco.com 1677 urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a 1678 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 1679 1680 1682 During resume 1684 The snapshot will look pretty much same as Use-case 1. 1686 13.3. Use case 3: Basic Call with transfer 1688 Basic call between two Participants A and B is connected as in Use- 1689 case 1. Transfer is initiated by one of the participants of by other 1690 entity(3PCC case). SRC sends a snapshot of the participant changes 1691 to SRS. In this instance participant A(Ram) drops out during the 1692 transfer and Participant C(Paul) joins the session. There can be two 1693 cases here, same session continues after transfer or a new session 1694 (e.g. REFER based transfer) is created 1696 Transfer with same session retained - (.e.g. RE-INVITE based 1697 transfer). Participant A drops out and C is added to the same 1698 session. No change to session/group element. C will be new stream 1699 element which maps to RS SDP using the same labels in this instance. 1701 Content-Type: application/SDP 1702 ... 1703 m=audio 49170 RTP/AVP 0 1704 a=rtpmap:0 PCMU/8000 1705 a=label:96 1706 a=sendonly 1707 ... 1708 m=video 49174 RTP/AVPF 96 1709 a=rtpmap:96 H.264/90000 1710 a=label:97 1711 a=sendonly 1712 ... 1713 m=audio 51372 RTP/AVP 0 1714 a=rtpmap:0 PCMU/8000 1715 a=label:98 1716 a=sendonly 1717 ... 1718 m=video 49176 RTP/AVPF 96 1719 a=rtpmap:96 H.264/90000 1720 a=label:99 1721 a=sendonly 1722 .... 1723 1724 1725 partial 1726 1729 sip:partha@blr.sonus.com 1730 urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a 1731 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 1732 urn:uuid:eb424026-6f54-4ef8-a4d0-bb658a1fc6cf 1733 urn:uuid:01c47915-4777-11d8-bc70-0090272ff725 1734 1736 1739 sip:paul@box.mit.com 1740 urn:uuid:eb424026-6f54-4ef8-a4d0-bb658a1fc6cf 1741 urn:uuid:01c47915-4777-11d8-bc70-0090272ff725 1742 urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a 1743 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 1744 2010-12-16T23:41:07Z 1745 1746 FOO! 1747 bar 1748 1749 1751 1753 1754 1755 1757 1758 1759 1761 1762 1763 1765 1766 1767 1769 Transfer with new session - (.e.g. REFER based transfer). In this 1770 case new session is part of same grouping (done by SRC). 1772 SRC may send an optional snapshot indicating stop for the old 1773 session. 1775 1776 1777 Partial 1778 1779 urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302 1780 1781 2010-12-16T23:41:07Z 1782 1783 FOO! 1784 bar 1785 1786 1787 1790 2010-12-16T23:41:07Z 1791 1793 1796 sip:partha@blr.sonus.com 1797 2010-12-16T23:41:07Z 1798 1800 1802 SRC sends a snapshot to indicate the participant change and new 1803 session information after transfer. In this example the same RS is 1804 used. 1806 Content-Type: application/SDP 1807 ... 1808 m=audio 49170 RTP/AVP 0 1809 a=rtpmap:0 PCMU/8000 1810 a=label:96 1811 a=sendonly 1812 ... 1813 m=video 49174 RTP/AVPF 96 1814 a=rtpmap:96 H.264/90000 1815 a=label:97 1816 a=sendonly 1817 ... 1818 m=audio 51372 RTP/AVP 0 1819 a=rtpmap:0 PCMU/8000 1820 a=label:98 1821 a=sendonly 1822 ... 1823 m=video 49176 RTP/AVPF 96 1824 a=rtpmap:96 H.264/90000 1825 a=label:99 1826 a=sendonly 1827 .... 1828 1829 1830 partial 1831 1832 urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302 1833 1834 2010-12-16T23:41:07Z 1835 1836 FOO! 1837 bar 1838 1839 1840 1843 sip:partha@blr.sonus.com 1844 urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a 1845 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 1846 urn:uuid:eb424026-6f54-4ef8-a4d0-bb658a1fc6cf 1847 urn:uuid:01c47915-4777-11d8-bc70-0090272ff725 1848 2010-12-16T23:32:03Z 1849 1850 FOO! 1851 bar 1852 1853 1855 1858 sip:paul@box.mit.com 1859 urn:uuid:eb424026-6f54-4ef8-a4d0-bb658a1fc6cf 1860 urn:uuid:01c47915-4777-11d8-bc70-0090272ff725 1861 urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a 1862 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 1863 2010-12-16T23:41:07Z 1864 1865 FOO! 1866 bar 1867 1868 1869 1871 1872 1873 1875 1876 1877 1879 1880 1881 1883 1884 1885 1887 14. References 1889 14.1. Normative References 1891 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1892 Requirement Levels", BCP 14, RFC 2119, March 1997. 1894 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1896 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1897 A., Peterson, J., Sparks, R., Handley, M., and E. 1898 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1899 June 2002. 1901 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1902 January 2004. 1904 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 1905 Internet: Timestamps", RFC 3339, July 2002. 1907 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1908 Description Protocol", RFC 4566, July 2006. 1910 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1911 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 1913 [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description 1914 Protocol (SDP) Content Attribute", RFC 4796, 1915 February 2007. 1917 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1918 "Indicating User Agent Capabilities in the Session 1919 Initiation Protocol (SIP)", RFC 3840, August 2004. 1921 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1922 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1923 July 2005. 1925 14.2. Informative References 1927 [RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use 1928 Cases and Requirements for SIP-Based Media Recording 1929 (SIPREC)", RFC 6341, August 2011. 1931 [I-D.ietf-siprec-architecture] 1932 Hutton, A., Portman, L., Jain, R., and K. Rehor, "An 1933 Architecture for Media Recording using the Session 1934 Initiation Protocol", draft-ietf-siprec-architecture-02 1935 (work in progress), April 2011. 1937 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1938 August 1999. 1940 Authors' Addresses 1942 Ram Mohan Ravindranath 1943 Cisco Systems, Inc. 1944 Cessna Business Park, 1945 Kadabeesanahalli Village, Varthur Hobli, 1946 Sarjapur-Marathahalli Outer Ring Road 1947 Bangalore, Karnataka 560103 1948 India 1950 Email: rmohanr@cisco.com 1952 Parthasarathi Ravindran 1953 Sonus Networks 1954 Prestige Shantiniketan - Business Precinct 1955 Whitefield Road 1956 Bangalore, Karnataka 560066 1957 India 1959 Email: pravindran@sonusnet.com 1960 Paul Kyzivat 1961 Unaffiliated 1962 Boxborough, MA 1963 USA 1965 Email: pkyzivat@alum.mit.edu