idnits 2.17.1 draft-ietf-siprec-metadata-05.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 (October 31, 2011) is 4560 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-03 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 3, 2012 Sonus Networks 5 Paul. Kyzivat 6 Unaffiliated 7 October 31, 2011 9 Session Initiation Protocol (SIP) Recording Metadata 10 draft-ietf-siprec-metadata-05 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 3, 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 . . . . . . . . . . . . . . . . . . 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. Participant . . . . . . . . . . . . . . . . . . . . . . . 12 79 6.4.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 13 80 6.4.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 13 81 6.4.3. XML element . . . . . . . . . . . . . . . . . . . . . 13 82 6.5. ParticipantCSAssociation . . . . . . . . . . . . . . . . . 14 83 6.5.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 14 84 6.5.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 15 85 6.5.3. XML element . . . . . . . . . . . . . . . . . . . . . 15 86 6.6. Media Stream . . . . . . . . . . . . . . . . . . . . . . . 15 87 6.6.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 16 88 6.6.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 16 89 6.6.3. XML element . . . . . . . . . . . . . . . . . . . . . 16 90 6.7. ParticipantStream Association . . . . . . . . . . . . . . 16 91 6.7.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 17 92 6.7.2. Linkages . . . . . . . . . . . . . . . . . . . . . . . 17 93 6.7.3. XML element . . . . . . . . . . . . . . . . . . . . . 17 94 6.8. associate-time/disassociate-time . . . . . . . . . . . . . 17 95 6.9. Unique ID format . . . . . . . . . . . . . . . . . . . . . 18 96 7. SIP Recording Metadata Example . . . . . . . . . . . . . . . . 18 97 7.1. Complete SIP Recording Metadata Example . . . . . . . . . 18 98 7.2. Partial Update of Recording metadata XML body . . . . . . 20 99 8. XML Schema definition for Recording metadata . . . . . . . . . 20 100 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 101 9.1. Connection Security . . . . . . . . . . . . . . . . . . . 23 102 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 103 10.1. SIP recording metadata Schema Registration . . . . . . . . 24 104 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 24 105 12. Appendix A: Metadata Model Object Instances . . . . . . . . . 24 106 12.1. Use case 1: Basic Call . . . . . . . . . . . . . . . . . . 24 107 12.2. Use case 2: Hold/Resume . . . . . . . . . . . . . . . . . 25 108 12.3. Use case 3: Basic call with Transfer . . . . . . . . . . . 27 109 12.4. Conference Use Cases . . . . . . . . . . . . . . . . . . . 28 110 12.4.1. Case 1: . . . . . . . . . . . . . . . . . . . . . . . 29 111 12.4.2. Case 2: . . . . . . . . . . . . . . . . . . . . . . . 31 112 12.4.3. Case 3: . . . . . . . . . . . . . . . . . . . . . . . 33 113 12.4.4. Case 4: . . . . . . . . . . . . . . . . . . . . . . . 34 114 13. Appendix B: Metadata XML schema Instances . . . . . . . . . . 35 115 13.1. Use case 1: Basic Call . . . . . . . . . . . . . . . . . . 35 116 13.2. Use case 2: Hold/resume . . . . . . . . . . . . . . . . . 37 117 13.3. Use case 3: Basic Call with transfer . . . . . . . . . . . 39 118 13.4. Use Case 4: Call disconnect . . . . . . . . . . . . . . . 43 119 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 120 14.1. Normative References . . . . . . . . . . . . . . . . . . . 44 121 14.2. Informative References . . . . . . . . . . . . . . . . . . 45 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 124 1. Introduction 126 Session recording is a critical requirement in many communications 127 environments such as call centers and financial trading. In some of 128 these environments, all calls must be recorded for regulatory, 129 compliance, and consumer protection reasons. Recording of a session 130 is typically performed by sending a copy of a media stream to a 131 recording device. This document focuses on the Recording metadata 132 which describes the communication session. The document describes a 133 metadata model as viewed by Session Recording Server and the 134 Recording metadata format, the requirements for which are described 135 in [RFC6341] and the architecture for which is described in 136 [I-D.ietf-siprec-architecture]. 138 2. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. This 143 document only uses these key words when referencing normative 144 statements in existing RFCs." 146 3. Definitions 148 Metadata Model: An abstract representation of metadata using a 149 Unified Modelling Language(UML) class diagram. 151 Metadata classes: Each block in the model represents a class. A 152 class is a construct that is used as a blueprint to create 153 instances(called objects) of itself. The description of each class 154 also has representation of its attributes in a second compartment 155 below the class name. 157 Attributes: Attributes represents the attributes listed in each of 158 the classes. The attributes of a class are listed in the second 159 compartment below the class name. Each instance of class conveys 160 values for these attributes which adds to the recording's Metadata. 162 Linkages: Linkages represents the relationship between the classes in 163 the model. It represents the logical connections betweens classes(or 164 objects) in class diagrams/ object diagrams. The linkages used in 165 the Metadata model of this document are associations. 167 4. Metadata Model 169 Metadata is the information that describes recorded media and the CS 170 to which they relate. Below diagram shows a model for Metadata as 171 viewed by Session Recording Server (SRS). 173 +-------------------------------+ 174 | Recording Session (RS) | 175 +-------------------------------+ 176 |1..* | 1..* 177 | | 178 | | 0..* 179 | +-----------------+ 180 | | Communication | 181 | | Session (CS) | 182 | | Group | 183 | +-----------------+ 184 | | 0..1 185 | | 186 |0..* | 1..* 187 +-------------------------------+ 188 | Communication Session (CS) | 189 | | 190 +-------------------------------+ 191 | 1..* |1..* 192 +-----+ | 193 | | 2..* |0..* 194 | +-------------+ receives +----------------+ 195 | | Participant |----------| Media Streams | 196 | | |0..* 0..*| | 197 | | | | | 198 | | | | | 199 | | | sends | | 200 | | |----------| | 201 | | |1.* 0..*| | 202 | +-------------+ +----------------+ 203 | | | 204 | | | 205 | +------------------------+------------+ 206 | | 207 | | 208 | +------------------+ +----------------------+ 209 | |ParticipantCS | | ParticipantStream | 210 +-----------| Association | | Association | 211 | | | | 212 +------------------+ +----------------------+ 214 The Metadata model is a class diagram in Unified Modelling 215 Language(UML). The model describes the structure of a metadata in 216 general by showing the classes, their attributes, and the 217 relationships among the classes. Each block in the model above 218 represents a class. The linkages between the classes represents the 219 relationships which can be associations or Composition. The metadata 220 is conveyed from SRC to SRS. 222 The model allows the capture of a snapshot of a recording's Metadata 223 at a given instant in time. Metadata changes to reflect changes in 224 what is being recorded. For example, if in a conference a 225 participant joins SRC sends a snapshot of metadata having that 226 participant information (with attributes like name/AoR pair and 227 associate-time) to the SRS. 229 Some of the metadata is not required to be conveyed explicitly from 230 the SRC to the SRS, if it can be obtained contextually by the 231 SRS(e.g., from SIP or SDP signalling). 233 5. Recording Metadata Format 235 This section gives an overview of Recording Metadata Format. Some 236 data from the metadata model is assumed to be made available to the 237 SRS through Session Description Protocol (SDP)[RFC4566], and 238 therefore this data is not represented in the XML document format 239 specified in this document. SDP attributes describes about different 240 media formats like audio, video. The other metadata attributes like 241 participant details are represented in a new Recording specific XML 242 document namely application/rs-metadata+xml. The SDP label attribute 243 [RFC4574] provides an identifier by which a metadata XML document can 244 refer to a specific media description in the SDP sent from the SRC to 245 the SRS. 247 The XML document format can be used to represent either the complete 248 metadata or a partial update to the metadata. The latter includes 249 only elements that have changed compared to the previously reported 250 metadata. 252 5.1. XML data format 254 Recording Metadata document is an XML document. recording element 255 MUST present in all recording metadata XML document. recording acts 256 as container for all other elements in this XML document. 258 Recording object is a XML document. It MUST have the XML declaration 259 and it SHOULD contain an encoding declaration in the XML declaration, 260 e.g., "". If the charset 261 parameter of the MIME content type declaration is present and it is 262 different from the encoding declaration, the charset parameter takes 263 precedence. 265 Every application conforming to this specification MUST accept the 266 UTF-8 character encoding to ensure the minimal interoperability. 268 Syntax and semantics error in recording XML document has to be 269 informed to the originator using application specific mechanism. 271 5.1.1. Namespace 273 The namespace URI for elements defined by this specification is a 274 Uniform Resource Namespace (URN) [RFC2141], using the namespace 275 identifier 'ietf' defined by [RFC2648] and extended by [RFC3688]. 277 The URN is as follows: urn:ietf:params:xml:ns:recording 279 5.1.2. recording 281 recording element MUST contain an xmlns namespace attribute with 282 value as urn:ietf:params:xml:ns:recording. One recording element 283 MUST present in the all recording metadata XML document. 285 dataMode element shows whether the XML document is complete document 286 or partial update. The default value is complete. 288 6. Recording Metadata classes 290 This section describes each class of the metadata model, and the 291 attributes of each class. This section also describes how different 292 classes are linked and the XML element for each of them. 294 6.1. Recording Session 295 +-------------------------------+ 296 | Recording Session (RS) | 297 +-------------------------------+ 298 | | 299 | Start/End Time | 300 | | 301 | | 302 | | 303 +-------------------------------+ 304 |1..* | 1..* 305 | | 306 |0..* | 0..* 307 Communication Communication 308 Session Session Group(CS Group) 310 Each instance of a Recording Session class (namely the Recording 311 Session Object) represents a SIP session created between an SRC and 312 SRS for the purpose of recording a Communication Session. 314 6.1.1. Attributes 316 A Recording Session class has the following attributes: 317 o Start/End Time - Represents the Start/End time of a Recording 318 Session object. 320 6.1.2. Linkages 322 Each instance of Recording Session has: 324 o Zero or more instances of Communication Session Group. CSG may be 325 zero because it is optional metadata object. Also the allowance 326 of zero instances is to accommodate persistent recording, where 327 there may be none. 328 o Zero or more instances of Communication Session objects. 330 6.1.3. XML element 332 Recording Session object is represented by recording XML element. 333 That in turn relies on the SIP/SDP session with which the XML 334 document is associated to provide some of the attributes of the 335 Recording Session element. 337 Start and End time value are derivable from Date header(if present in 338 SIP message) in RS. In cases where Date header is not present, 339 Start/End time are derivable from the time at which SRS receives the 340 notification of SIP message to setup RS / disconnect RS. 342 6.2. Communication Session Group 344 Recording Session (RS) 345 | 1..* 346 | 347 | 0..* 348 +-------------------------------+ 349 | Communication Session | 350 | Group | 351 +-------------------------------+ 352 | Unique-ID | 353 | associate-time | 354 | disassociate-time | 355 | | 356 +-------------------------------+ 357 | 0..1 358 | 359 | 1..* 360 Communication Session (CS) 362 One instance of a Communication Session Group class (namely the 363 Communication Session Group object) provides association or linking 364 of Communication Sessions. 366 6.2.1. Attributes 368 A CS Group has the following attributes: 369 o Unique-ID - This Unique-ID is to group different CSs that are 370 related. SRC (or SRS) is responsible for ensuring the uniqueness 371 of Unique-ID in case multiple SRC interacts with the same SRS. 372 The mechanism by which SRC groups the CS is outside the scope of 373 SIPREC. 374 o Associate-time - Associate-time for CS-Group shall be calculated 375 by SRC as the time when a grouping is formed. The rules that 376 determine how a grouping of different Communication Session 377 objects is done by SRC is outside the scope of SIPREC. 378 o Disassociate-time - Disassociate-time for CS-Group shall be 379 calculated by SRC as the time when the grouping ends 381 6.2.2. Linkages 383 The linkages between Communication Session Group class and other 384 classes is association. A communication Session Group is associated 385 with RS and CS in the following manner: 387 o There is one or more Recording Session objects per Communication 388 Session Group. 389 o Each Communication Session Group object has to be associated with 390 one or more RS [Here each RS can be setup by the potentially 391 different SRCs] 392 o There is one or more Communication Sessions per CS Group [e.g. 393 Consult Transfer] 395 6.2.3. XML element 397 Group element is an optional element provides the information about 398 the communication session group 400 Each communication session group (CSG)object is represented using one 401 group element. Each group element has unique Base 64 URN UUID 402 attribute which helps to uniquely identify CSG. 404 6.3. Communication Session 406 Recording Communication 407 Session Session Group(CS Group) 408 |1..* | 0..1 409 | | 410 |0..* | 1..* 411 +-------------------------------+ 412 | Communication Session (CS) | 413 | | 414 +-------------------------------+ 415 | CS Identifier | 416 | Termination Reason | 417 | Associate Time | 418 | Disassociate Time | 419 +-------------------------------+ 420 | | 421 | 1..* |1..* 422 | | 423 | 2..* |0..* 424 Participant Media Stream 426 A Communication Session class and its object in the metadata model 427 represents Communication Session and its properties needed as seen by 428 SRC. 430 6.3.1. Attributes 432 A communication Session class has the following attributes: 434 o Termination Reason - This represents the reason why a CS was 435 terminated. The communication session MAY contain a Call 436 Termination Reason. This MAY be derived from SIP Reason header of 437 CS. 438 o CS Identifier - This attribute is used to uniquely identify a CS. 439 o Associate Time - This optional attribute represents the time a CS 440 is associated with a RS 441 o Disassociate Time - This optional attribute represents the time a 442 CS is disassociated with a RS. 444 This document does not specify attributes relating to what should 445 happen to a recording of a CS after it has been delivered to the SRS, 446 e.g., how long to retain the recording, what access controls to 447 apply. The SRS is assumed to behave in accordance with policy. The 448 ability for the SRC to influence this policy is outside the scope of 449 this document. However if there are implementations where SRC has 450 enough information, this could be sent as Extension Data attached to 451 CS 453 6.3.2. Linkages 455 A Communication Session is linked to CS-Group, Participant, Media 456 Stream and Recording Session classes using the association 457 relationship. Association between CS and Participant allows: 459 o CS to have atleast two or more participants 460 o Participant is associated with one or more CS's. This includes 461 participants who are not directly part of any CS. An example of 462 such a case is participants in a premixed media stream. The SRC 463 may have knowledge of such Participants, yet not have any 464 signaling relationship with them. This might arise if one 465 participant in CS is a conf focus. To summarize even if SRC does 466 not have direct signalling relationships with all participants in 467 a CS, it should nevertheless create a Participant object for each 468 participant that it knows about 469 o The model also allows participants in CS that are not participants 470 in the media. An example is the identity of a 3pcc controller 471 that has initiated a CS to two or more participants of the CS. 472 Another example is the identity of a conference focus. Of course 473 a focus is probably in the media, but since it may only be there 474 as a mixer, it may not report itself as a participant in any of 475 the media streams. 477 Association between CS and Media Stream allows: 479 o A CS to have zero or more Streams 480 o A stream can be associated with 1 or more CS. An example is 481 multicast MoH stream which might be associated with many CSs. 483 Association between CS and RS allows: 485 o Each instance of RS has Zero or more instances of Communication 486 Session objects. 487 o Each CS has to be associated with one more RS [ Here each RS can 488 be potentially setup by different SRCs] 490 6.3.3. XML element 492 Session element provides the information about the communication 493 session 495 Each communication session(CS) object is represented by one session 496 element. Each session element has unique Base 64 URN UUID attribute 497 which helps to uniquely identify CS. 499 Reason element MAY be included to represent the Termination Reason 500 attribute. group-ref element MAY exist to indicate the group where 501 the mentioned session belongs. 503 6.4. Participant 505 Communication Session (CS) 506 | 1..* 507 | 508 | 2..* 509 +-------------------------------+ 510 | Participant | 511 | | 512 +-------------------------------+ 513 | AoR / Name Pair list | 514 | | 515 | | 516 +-------------------------------+ 517 | 0..* 1..*| 518 receives| |sends 519 | 0..* 0..*| 520 Media Stream 522 A Participant class and its objects has information about a device 523 that is part of a CS and/or contributes/consumes media stream(s) 524 belonging to a CS. 526 6.4.1. Attributes 528 Participant has attributes like: 530 o AoR / Name pair list - This attribute is a list of Name/AoR tuple. 531 An AoR MAY be SIP/SIPS/TEL URI. Name represents Participant 532 name(SIP display name) or DN number ( in case it is known). There 533 are cases where a participant can have more than one AoR [ e.g. 534 P-Asserted-ID which can have both SIP and TEL URIs] 536 This document does not specify other attributes relating to 537 participant e.g. Participant Role, Participant type. An SRC which 538 has information of these attributes can indicate the same as part of 539 extension data to Participant from SRC to SRS. 541 6.4.2. Linkages 543 The participant class is linked to MS and CS class using association 544 relationship. The association between participant and Media Stream 545 allows: 547 o Participant to receives zero or more media streams 548 o Participant to send zero or more media streams. (Same participant 549 provides multiple streams e.g. audio and video) 550 o Media stream to be received by zero or more participants. Its 551 possible, though perhaps unlikely, that a stream is generated but 552 sent only to the SRC and SRS, not to any participant. E.g. In 553 conferencing where all participants are on hold and the SRC is 554 collocated with the focus. Also a media stream may be received by 555 multiple participants (e.g. Whisper calls, side conversations). 556 o Media stream to be sent by one or more participants (pre-mixed 557 streams). 559 Example of a case where a participant receives Zero or more streams - 560 a Supervisor may have side conversation with Agent, while Agent 561 converses with customer. 563 6.4.3. XML element 565 A participant element represents a Participant object. 567 There MUST be atleast 2 participant for any given session. "send" or 568 "recv" element in each participant is associating SDP m-lines with 569 the participant. send element indicates that participant is sending 570 the stream of media with the mentioned media description. recv 571 element indicates that participant is receiving the stream and by 572 default all participant will receive the stream. recv element has 573 relevance in case whisper call scenario wherein few of the 574 participant in the session receives the stream and not others. 576 Participant MUST have a NameID complex element which contains AoR as 577 attribute and Name as element. AOR element is SIP/SIPS URI FQDN or 578 IP address which represents the user. name is an optional element to 579 represent display name. 581 Each participant element has unique ID (Base 64 URN UUID) attribute 582 which helps to uniquely identify participant and session Base 64 URN 583 UUID to associate participant with specific session element. Base 64 584 URN UUID of participant *MUST* used in the scope of CSG and no new 585 Base 64 URN UUID has to be created for the same element (participant, 586 stream) between different CS in the same CSG. In case Base 64 URN 587 UUID has to be used permanent, careful usage of Base 64 URN UUID to 588 original AoR has to be decided by the implementers and it is 589 implementer's choice. 591 6.5. ParticipantCSAssociation 593 1..* 2..* 594 Communication 595 Session ----------+---------- Participant 596 | 597 | 598 | 599 +-------------------+ 600 | ParticipantCS | 601 | Association | 602 +-------------------+ 603 | Capabilities | 604 | Association-Time | 605 | Disassociaton-Time| 606 +-------------------+ 608 A participantCS Association class and its objects has attributes of 609 participant object which are attributes of association of a 610 participant to a Session. 612 6.5.1. Attributes 614 ParticipantCS association class has the following attributes: 616 o Associate-time - associate-time is calculated by SRC as the time 617 it sees a participant is associated to CS 618 o Disassociate-time- Disassociate-time is calculated by SRC as the 619 time it see a participant disassociate from a CS. It is possible 620 that a given participant can have multiple associate/disassociate 621 times within given communication session. 622 o Capabilities - A participant capabilities as defined in RFC 3840 623 [RFC3840] is an optional attribute that includes the capabilities 624 of a participant in a CS. Each participant shall have Zero or 625 more capabilities. A participant may use different capabilities 626 depending on the role it plays at a particular instance. IOW if a 627 participants moves across different CSs ( due to transfer e.t.c) 628 OR is simultaneously present in different CSs its role may be 629 different and hence the capability used. 631 6.5.2. Linkages 633 The participantCS association class is linked to participant and CS 634 classes. There are no cardinalties for this linkage. 636 6.5.3. XML element 638 TBD 640 NOTE: RFC 4235 encoding shall be used to represent capabilities 641 attribute in XML. 643 6.6. Media Stream 645 Participant 646 | 0..* 1..*| 647 receives| |sends 648 | 0..* 0..*| 649 +-------------------------+ 650 | Media Stream | 651 | | 652 Communication 1..* 0..* +-------------------------+ 653 Session ------------| | 654 | Media Stream Reference | 655 | Content-type | 656 | | 657 +-------------------------+ 659 A Media Stream class (and its objects) has the properties of media as 660 seen by SRC and sent to SRS. Different snapshots of media stream 661 object may be sent whenever there is a change in media (e.g. dir 662 change like pause/resume and/or codec change and/or participant 663 change.). 665 6.6.1. Attributes 667 A Media Stream class has the the following attributes: 669 o Media Stream Reference - In implementations this can reference to 670 m-line 671 o Content - The content of an MS element will be described in terms 672 of value from the RFC 4796 [RFC4796] registry. 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.6.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.6.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 Base 64 URN UUID attribute which helps 699 to uniquely identify stream and session Base 64 URN UUID to associate 700 stream with specific session element. 702 The content attribute if an SRC wishes to send is conveyed in RS SDP. 704 6.7. ParticipantStream Association 705 +-------------------+ 706 | ParticipantSteam | 707 | Association | 708 +-------------------+ +----------Participant 709 | CSRC | | | | 710 | Association-Time | | 0..*| 1..*| 711 | Disassociaton-Time|---+ recv| |sends 712 | Recv | | 0..*| 0..*| 713 | Send | | | | 714 +-------------------+ | | | 715 +----------Media Stream 717 A ParticipantStream association class and its object has attributes 718 that are attributes of association of a Participant to a Stream. 720 6.7.1. Attributes 722 A participantStream association class has the following attributes: 724 o CSRC - The linkage between the participants to its contributing 725 media stream in a mixed RS stream is provided by CSRC attribute. 726 Not all SRC may have the capability to determine this and hence 727 this is a optional attribute. Having this info can allow the SRS 728 to determine which participants are part(contributors) of 729 particular parts of the mixed stream. This attribute carries SSRC 730 of contributing sender. 731 o Associate-Time: This attributes indicates the time a Participant 732 started contributing to a Media Stream 733 o Disassociate-Time: This attribute indicates the time a Participant 734 stopped contributing to a Media Stream 736 6.7.2. Linkages 738 The participantStream association class is linked to participant and 739 Stream classes. There are no cardinalties for this linkage. 741 6.7.3. XML element 743 TBD 745 6.8. associate-time/disassociate-time 747 associate-time/disassociate-time contains a string indicating the 748 date and time of the status change of this tuple. The value of this 749 element MUST follow the IMPP datetime format [RFC3339]. Timestamps 750 that contain 'T' or 'Z' MUST use the capitalized forms. At a time, 751 any of the time tuple associate-time or disassociate-time MAY exist 752 in the element namely group, session, participant and not both 753 timestamp at the same time. 755 As a security measure, the timestamp element SHOULD be included in 756 all tuples unless the exact time of the status change cannot be 757 determined. 759 6.9. Unique ID format 761 Unique id is generated in two steps: 762 o UUID is created using [RFC4122]) 763 o UUID is encoded using base64 as defined in RFC 4648 [RFC4648] 765 The above mentioned unique-id mechanism SHOULD be used for each 766 metadata element. 768 7. SIP Recording Metadata Example 770 7.1. Complete SIP Recording Metadata Example 772 The following example provides all the tuples involved in Recording 773 Metadata XML body. 775 776 777 complete 778 779 2010-12-16T23:41:07Z 780 781 782 sip:alice@cisco.com 783 784 785 FOO! 786 bar 787 788 789 790 7+OTCyoxTmqmqyA/1weDAg== 791 792 2010-12-16T23:41:07Z 793 794 FOO! 795 bar 796 797 800 801 RamMohan R 802 803 i1Pz3to5hGk8fuXl+PbwCw== 804 UAAMm5GRQKSCMVvLyl4rFw== 805 8zc6e0lYTlWIINA6GR+3ag== 806 EiXGlc+4TruqqoDaNE76ag== 807 2010-12-16T23:41:07Z 808 809 FOO! 810 bar 811 813 816 817 Paul Kyzivat 818 819 8zc6e0lYTlWIINA6GR+3ag== 820 EiXGlc+4TruqqoDaNE76ag== 821 UAAMm5GRQKSCMVvLyl4rFw== 822 i1Pz3to5hGk8fuXl+PbwCw== 823 2010-12-16T23:41:07Z 824 825 FOO! 826 bar 827 829 831 832 833 835 836 837 839 840 841 843 844 846 848 SIP Recording Metadata Example XML body 850 7.2. Partial Update of Recording metadata XML body 852 The following example provides partial update in Recording Metadata 853 XML body for the above example. The example has a snapshot that 854 carries the disassociate-time for a participant from a session. 856 857 858 partial 859 862 863 Parathasarathi R 864 865 2010-12-16T23:41:07Z 866 FOO! 867 bar 868 869 871 Partial update of SIP Recording Example XML body 873 8. XML Schema definition for Recording metadata 875 This section defines XML schema for Recording metadata document 877 878 883 884 885 886 887 888 890 892 894 896 898 902 903 904 905 906 908 910 914 915 917 918 919 920 922 924 926 928 932 933 935 936 937 938 940 942 944 946 948 952 953 955 957 958 959 960 962 964 966 968 972 973 975 977 978 979 980 981 982 983 984 985 986 987 988 989 991 992 993 994 995 996 997 999 1001 9. Security Considerations 1003 The metadata information sent from SRC to SRS MAY reveal sensitive 1004 information about different participants in a session. For this 1005 reason, it is RECOMMENDED that a SRC use a strong means for 1006 authentication and metadata information protection and that it apply 1007 comprehensive authorization rules when using the metadata format 1008 defined in this document. The following sections will discuss each 1009 of these aspects in more detail. 1011 9.1. Connection Security 1013 It is RECOMMENDED that a SRC authenticate SRS using the normal SIP 1014 authentication mechanisms, such as Digest as defined in Section 22 of 1015 [RFC3261]. The mechanism used for conveying the metadata information 1016 MUST ensure integrity and SHOULD ensure confidentially of the 1017 information. In order to achieve these, an end-to-end SIP encryption 1018 mechanism, such as S/MIME described in [RFC3261], SHOULD be used. 1020 If a strong end-to-end security means (such as above) is not 1021 available, it is RECOMMENDED that a SRC use mutual hop-by-hop 1022 Transport Layer Security (TLS) authentication and encryption 1023 mechanisms described in "SIPS URI Scheme" and "Interdomain Requests" 1024 of [RFC3261]. 1026 10. IANA Considerations 1028 This specification registers a new XML namespace, and a new XML 1029 schema. 1031 10.1. SIP recording metadata Schema Registration 1033 URI: urn:ietf:params:xml:ns:recording 1035 Registrant Contact: IETF SIPREC working group, Ram mohan 1036 R(rmohanr@cisco.com) 1038 XML: the XML schema to be registered is contained in Section 6. 1040 Its first line is and its last 1041 line is 1043 11. Acknowledgement 1045 We wish to thank John Elwell(Siemens-Enterprise), Henry Lum(Alcatel- 1046 Lucent), Leon Portman(Nice), De Villers, Andrew Hutton(Siemens- 1047 Enterprise), Deepanshu Gautam(Huawei), Charles Eckel(Cisco), Muthu 1048 Arul(Cisco), Michael Benenson(Cisco), Hadriel Kaplan (ACME), Brian 1049 Rosen(Neustar), Scott Orton(Broadsoft) for their valuable comments 1050 and inputs. 1052 We wish to thank Joe Hildebrand(Cisco), Peter Saint-Andre(Cisco) for 1053 the valuable XML related guidance and Martin Thompson for validating 1054 the XML schema and providing comments on the same. 1056 12. Appendix A: Metadata Model Object Instances 1058 This section describes the metadata model object instances for 1059 different use cases of SIPREC. For the sake of simplicity as the 1060 media streams sent by each of the participants is received by every 1061 other participant in these use cases, it is NOT shown in the object 1062 instance diagrams below. Also for the sake of ease not all 1063 attributes of each object are shown in these instance diagrams. 1065 12.1. Use case 1: Basic Call 1067 Basic call between two Participants A and B. In this use case each 1068 participant sends one Media Stream. For the sake of simplicity 1069 "receives" lines are not shown in this instance diagram. Media 1070 Streams sent by each participant is received all other participants 1071 of that CS. 1073 +-------------------------------+ 1074 | Recording Session (RS) | 1075 +-------------------------------+ 1076 | 1077 | 1078 | 1079 +----------------+ 1080 | Communication | 1081 | Session (CS) | 1082 +----------------+-----------------------+ 1083 | Start Time | | 1084 +----------------+ | 1085 | | 1086 |-------------------+ | 1087 | | | 1088 +---------------+ +---------------+ | 1089 | ParticipantA | | ParticipantB | | 1090 | | | | | 1091 +---------------+ +---------------+ | 1092 | | | 1093 sends | | sends | 1094 | | | 1095 +---------------+ +---------------+ | 1096 |Media Stream A1| |Media Stream B1| | 1097 +---------------+ +---------------+ | 1098 |MediaStream Ref| |MediaStream Ref| | 1099 | | | | | 1100 +---------------+ +---------------+ | 1101 | | | 1102 +-----------------------------------+ 1104 12.2. Use case 2: Hold/Resume 1106 Basic call between two Participants A and B and with Participant A or 1107 B doing a Hold/Resume. In this use case each participant sends one 1108 Media Stream. After Hold/Resume the properties of Media can change. 1109 For the sake of simplicity "receives" lines are not shown in this 1110 instance diagram. Media Streams sent by each participant is received 1111 all other participants of that CS. 1113 +-------------------------------+ 1114 | Recording Session (RS) | 1115 +-------------------------------+ 1116 | | 1117 | | 1118 | | 1119 | +-------------------------------+ 1120 | | Communication Session (CS) | 1121 | +-----------| Group(CSG) | 1122 | | +-------------------------------+ 1123 | | | Unique-id1 | 1124 | | +-------------------------------+ 1125 | | 1126 | | 1127 | | 1128 +----------------+ 1129 | Communication | 1130 +-| Session (CS) |----------------------------------------------+ 1131 | +----------------+ | 1132 | | | | 1133 | +----------------+ | 1134 | | | 1135 | |-------------------+ | 1136 | | | | 1137 | +---------------+ +---------------+ | 1138 | | ParticipantA | | ParticipantB |-----------+ | 1139 | | |--+ | | | | 1140 | +---------------+ | +---------------+ |sends(After | 1141 | | | | | | | Resume) | 1142 | | | | | | +--------------+ | 1143 | sends | | +--+ | sends | |MediaStream B3| | 1144 | | -----+ | | +-----+ +--------------+ | 1145 | +---------------+ | | +---------------+ | |MediaStreamRef|-| 1146 | |Media Stream A1| | | |Media Stream B1| | | | | 1147 | +---------------+ | | +---------------+ | | | | 1148 +-|MediaStreamref | | | |MediaStreamRef | | +--------------+ | 1149 | | | | | |-|-------------------| 1150 +---------------+ | | +---------------+ | | 1151 | | | | 1152 +------------+ |sends |sends (hold) | 1153 | sends |(Resume) | | 1154 | (hold) +-------+ +-------+ | 1155 | | | | 1156 +---------------+ +---------------+ +--------------+ | 1157 |Media Stream A2| |Media Stream A3| |MediaStream B2| | 1158 +---------------+ +---------------+ | | | 1159 |MediaStreamref | |MediaStreamRef | +--------------+ | 1160 | | | | |Codec Params | | 1161 +---------------+ +---------------+ | | | 1162 | | | | | 1163 | | +--------------+ | 1164 | | | | 1165 +------------------------------------------------------+ 1167 12.3. Use case 3: Basic call with Transfer 1169 Basic call between two Participants A and B and with Participant A 1170 transfer(consult transfer) to Participant C. In this use case each 1171 participant sends one Media Stream. After transfer the properties of 1172 Participant A Media can change. For the sake of simplicity 1173 "receives" lines are not shown in this instance diagram. Media 1174 Streams sent by each participant is received all other participants 1175 of that CS. 1177 +-------------------------------+ 1178 | Recording Session (RS) |-------+ 1179 +-------------------------------+ | 1180 | | 1181 | | 1182 | | 1183 +-------------------------------+ | 1184 | Communication Session (CS) | | 1185 | Group(CSG) | | 1186 +-------------------------------+ | 1187 | Unique-id1 | | 1188 +-------------------------------+ | 1189 | | 1190 |----------------------------+ 1191 | 1192 |-----------------+ 1193 | | 1194 +----------------+ +----------------+ 1195 | Communication | | Communication | 1196 | Session (CS)1 | | Session (CS)2 | 1197 +----------------+ +----------------+-----------+ 1198 | | | | | 1199 +----------------+ +----------------+ | 1200 | | 1201 |-------------------+ | 1202 | | | | 1203 +---------------+ | +---------------+ | 1204 | ParticipantA | | | ParticipantB | | 1205 | | | | | | 1206 +---------------+ | +---------------+ | 1207 | | | | 1208 sends | | | sends | 1209 | | | | 1210 +---------------+ | +---------------+ | 1211 |Media Stream A1| | |Media Stream B1| | 1212 +---------------+ | +---------------+ | 1213 | | | | | | 1214 | | | | Media Stream | | 1215 | Media Stream |---+---| Ref | | 1216 | Ref | | | | 1217 +---------------+ +---------------+ | 1218 | 1219 | 1220 +----------------------------| 1221 | | 1222 +--------------------------------+ | 1223 | | | 1224 +---------------+ +---------------+ | 1225 | Participant A | | Participant C | | 1226 | (same) | | | | 1227 +---------------+ +---------------+ | 1228 | | | 1229 | sends (After transfer) | sends | 1230 +----------------+ +----------------+| 1231 | Media Stream A2| | Media Stream C1|| 1232 +----------------+ +----------------+| 1233 | Media StreamRef| | Media StreamRef|| 1234 | | | || 1235 | | | || 1236 +----------------+ +----------------+| 1237 | | | 1238 | | | 1239 | | | 1240 +-------------------------------------------+ 1242 12.4. Conference Use Cases 1244 Depending on who act as SRC and the information that an SRC has there 1245 can be several ways to model conference use cases. This section has 1246 instance diagrams for the following cases: 1248 o A CS where one of the participant (which is also SRC) is a user in 1249 a conference 1250 o A CS where one of the participant is focus ( which is also SRC) 1251 o A CS where one of the participant is user and the SRC is a 1252 different entity like B2BUA 1253 o A CS where one of the participant is focus and the SRC is a 1254 different entity like B2BUA 1256 NOTE: There MAY be other ways to model the same use cases depending 1257 on what information the SRC has. 1259 12.4.1. Case 1: 1261 This is the usecase where there is a CS with one of the participant 1262 (who is also SRC) as a user in a conference. For the sake of 1263 simplicity the receive lines for each of the participant is not 1264 shown. 1266 +---------------------------------------------------+ 1267 | Communication Session | 1268 | +-------------+ +--------------+ | 1269 | | | | | | 1270 | |Participant B| | Participant A| | 1271 | | (User in |--------------| | | 1272 | | conf/SRC) | | | | 1273 | +-------------+ +--------------+ | 1274 | | | | | | 1275 +---------------------------------------------------+ 1276 | | | | 1277 | | | | 1278 D E F G (Participants of Conference) 1280 Instance Diagram: 1282 +-------------------------------+ 1283 | Recording Session (RS) |--+ 1284 +-------------------------------+ | 1285 | | 1286 | | 1287 | | 1288 +-------------------------------+ | 1289 | Communication Session (CS) | | 1290 | Group(CSG) | | 1291 +-------------------------------+ | 1292 | Unique-id1 | | 1293 +-------------------------------+ | 1294 | | 1295 |-----------------------+ 1296 | 1297 +----------------+ 1298 | Communication | 1299 | Session (CS) |--+----------------+-----+ 1300 +----------------+ | | | 1301 | | | | | 1302 +----------------+ | | | 1303 | | | | 1304 | | | | 1305 | | | | 1306 +---------------+ | | | 1307 | ParticipantA | | | | 1308 | | | | | 1309 +---------------+ | | | 1310 | | | | 1311 sends | | | | 1312 | | | | 1313 +---------------+ | | | 1314 |Media Stream A1| | | | 1315 +---------------+ | | | 1316 |MediaStream Ref|-----|----------------+ | 1317 | | | | | 1318 +---------------+ | | | 1319 | | | 1320 | | | 1321 +-------------+ | | 1322 | | | 1323 | | | 1324 +----------------+ | | 1325 | Participant B | | | 1326 | (in conf) | | | 1327 +----------------+ | | 1328 | | | 1329 sends | | | 1330 | | | 1331 +----------------+ | | 1332 | Media Stream B1|---------------------+ | 1333 +----------------+ sends | 1334 | MediaStream Ref| | 1335 | | +-----------------+ 1336 +----------------+ | 1337 | | 1338 |sends | 1339 | | 1340 +-----------------+-------------+------------+ 1341 | | | | 1342 | | | | 1343 +------------+ +------------+ +------------+ +-------------+ 1344 |participantD| |ParticipantE| |ParticipantF| |Participant G| 1345 +------------+ +------------+ +------------+ +-------------+ 1347 In this example we have two participants A and B who are part of a 1348 Communication Session(CS). One of the participants B is part of a 1349 conference and also acts as SRC.There can be two cases here. B can 1350 be a participant of the conference or B can be a focus. In this 1351 instance diagram Participant B is a user in a conference. The SRC 1352 (Participant B) subscribes to conference event package to get the 1353 details of other particiants. Participant B(SRC) sends the same 1354 through the metadata to SRS. In this instance diagram the Media 1355 Stream(mixed stream) sent from Participant B has media streams 1356 contributed by conference participants (D,E,F and G). For the sake 1357 of simplicity the "receives" line is not shown here. In this example 1358 the media stream sent by each participant(A or B) of CS is received 1359 by all other participant(A or B). 1361 12.4.2. Case 2: 1363 This is the usecase where there is a CS where one of the participant 1364 is focus ( which is also SRC). 1366 +---------------------------------------------------+ 1367 | Communication Session | 1368 | +--------------+ +--------------+ | 1369 | | |--------------| | | 1370 | |Participant C | | Participant A| | 1371 | | (Focus in |------+ | | | 1372 | | conf and SRC)|---+ | +--------------+ | 1373 | +--------------+ | | | 1374 | | | +---------+ | 1375 | | | | | 1376 | +--------------+ | +---------------+ | 1377 | | Participant B| +---+ | Participant D | | 1378 | | | | | | | 1379 | +--------------+ | +---------------+ | 1380 | | | 1381 | +--------------+ | 1382 | |Participant E | | 1383 | | | | 1384 | +--------------+ | 1385 | | 1386 +---------------------------------------------------+ 1388 Instance Diagram: 1390 +-------------------------------+ 1391 | Recording Session (RS) | 1392 +-------------------------------+ 1393 |-------------------------+ 1394 | | 1395 | | 1396 +-------------------------------+ | 1397 | Communication Session (CS) | | 1398 | Group(CSG) | | 1399 +-------------------------------+ | 1400 | Unique-id1 | | 1401 +-------------------------------+ | 1402 | | 1403 |-------------------------+ 1404 | 1405 +----------------+ 1406 | Communication | 1407 | Session (CS) |----------------------+ 1408 +----------------+ | 1409 | | | 1410 +----------------+ | 1411 | | 1412 |-------------------+ | 1413 | | | | 1414 +---------------+ | +---------------+ | 1415 | ParticipantA | | | ParticipantB | | 1416 | | | | | | 1417 +---------------+ | +---------------+ | 1418 | | | | 1419 sends | | | sends | 1420 | | | | 1421 +---------------+ | +---------------+ | 1422 |Media Stream A1| | |Media Stream B1| | 1423 +---------------+ | +---------------+ | 1424 |MediaStream Ref| | |MediaStream Ref| | 1425 | |---+---| | | 1426 +---------------+ +---------------+ | 1427 | 1428 +----------------------------------+ 1429 | | | | 1430 | | | | 1431 +---------------+ | +---------------+ | 1432 | ParticipantD | | | ParticipantE | | 1433 | | | | | | 1434 +---------------+ | +---------------+ | 1435 | | | | 1436 sends | | | sends | 1437 | | | | 1438 +---------------+ | +---------------+ | 1439 |Media Stream D1| | |Media Stream E1| | 1440 +---------------+ | +---------------+ | 1441 |MediaStream Ref| | |MediaStream Ref| | 1442 | |---+---| | | 1443 +---------------+ +---------------+ | 1444 | 1445 | 1446 +----------+ 1447 +-----------------| 1448 | | 1449 | | 1450 +----------------+ | 1451 | Participant C | | 1452 | (focus +src) | | 1453 +----------------+ | 1454 | | 1455 Sends | +-------+ 1456 | | 1457 "sends" OR | | 1458 contributed +----------------+ 1459 by | Media Stream C1| 1460 Participants+----------------+ "receives" by participants A,B,D,E 1461 A,B,D,E | MediaStream Ref|------------------------------------ 1462 ------------| Codec Params | 1463 +----------------+ 1465 In this example we have two participants A and B who are part of a 1466 Communication Session(CS). One of the participants (C) is focus of a 1467 conference and also acts as SRC. The SRC (Participant C) being the 1468 Focus of the conference has access to the details of other 1469 particiants. SRC (Participant C) sends the same through the metadata 1470 to SRS. In this instance diagram the Media Stream(mixed stream) sent 1471 by C has media streams contributed by conference participants (A, B, 1472 D and E). Participants A, B,D and E sends Media Streams A1, B1, D1 1473 and E1 respectively. The media stream sent by Participant C(Focus) 1474 is received by all other participants of CS. For the sake of 1475 simplicity the "receives" line is not shown linked to all other 1476 participants. 1478 NOTE: SRC ( Participant C) can send mixed stream or seperate streams 1479 to SRS 1481 12.4.3. Case 3: 1483 A CS where one of the participant is user and the SRC is a different 1484 entity like B2BUA. In this case the SRC may not know that one of the 1485 user is part of conference. Hence the instance diagram will not have 1486 information about the conference participants. 1488 +---------------------------------------------------+ 1489 | Communication Session | 1490 | +-------------+ +------+ +--------------+ | 1491 | | | | (SRC)| | | | 1492 | |Participant B|--|B2BUA |----| Participant A| | 1493 | | (User in | +------+ | | | 1494 | | conf) | | | | 1495 | +-------------+ +--------------+ | 1496 | | | | | | 1497 +---------------------------------------------------+ 1498 | | | | 1499 | | | | 1500 D E F G (Participants of Conference) 1502 12.4.4. Case 4: 1504 A CS where one of the participant is focus and the SRC is a different 1505 entity like B2BUA. In this case the participant which is focus sends 1506 "isfocus" in SIP message to SRC. The SRC subscribe to conference 1507 event package on seeing this "isfocus". SRC learns the details of 1508 other participants of conference from the conference package and send 1509 the same in metadata to SRS. The instance diagram for this use case 1510 is same as Case 1. 1512 +--------------------------------+ 1513 | Conference Event Package | 1514 | | 1515 +--------------------------------+ 1516 | 1517 | subscribes 1518 | 1519 +---------------------|-----------------------------+ 1520 | Communication |Session | 1521 | +-------------+ +------+ +--------------+ | 1522 | | | | (SRC)| | | | 1523 | |Participant B|--|B2BUA |----| Participant A| | 1524 | | (FOCUS in | +------+ | | | 1525 | | conf) | | | | 1526 | +-------------+ +--------------+ | 1527 | | | | | | 1528 +---------------------------------------------------+ 1529 | | | | 1530 | | | | 1531 D E F G (Participants of Conference) 1533 13. Appendix B: Metadata XML schema Instances 1535 This section describes the metadata model XML instances for different 1536 use cases of SIPREC. For the sake of simplicity the complete SIP 1537 messages are NOT shown here. 1539 13.1. Use case 1: Basic Call 1541 Basic call between two Participants A(Ram) and B(Partha) who are part 1542 of one session. In this use case each participant sends two Media 1543 Streams. Media Streams sent by each participant is received all 1544 other participants of that CS in this use-case. Below is the initial 1545 snapshot sent by SRC that has complete metadata. For the sake of 1546 completeness even snippets of SDP is shown. For the sake of 1547 simplicity these use-cases assume the RS stream is unmixed. 1549 Content-Type: application/SDP 1550 ... 1551 m=audio 49170 RTP/AVP 0 1552 a=rtpmap:0 PCMU/8000 1553 a=label:96 1554 a=sendonly 1555 ... 1556 m=video 49174 RTP/AVPF 96 1557 a=rtpmap:96 H.264/90000 1558 a=label:97 1559 a=sendonly 1560 ... 1561 m=audio 51372 RTP/AVP 0 1562 a=rtpmap:0 PCMU/8000 1563 a=label:98 1564 a=sendonly 1565 ... 1566 m=video 49176 RTP/AVPF 96 1567 a=rtpmap:96 H.264/90000 1568 a=label:99 1569 a=sendonly 1570 .... 1571 1572 1573 complete 1574 1575 2010-12-16T23:41:07Z 1576 1577 1578 sip:alice@cisco.com 1579 1580 1581 FOO! 1582 bar 1583 1584 1585 1586 7+OTCyoxTmqmqyA/1weDAg== 1587 1588 2010-12-16T23:41:07Z 1589 1590 FOO! 1591 bar 1592 1593 1596 1597 RamMohan R 1598 1599 i1Pz3to5hGk8fuXl+PbwCw== 1600 UAAMm5GRQKSCMVvLyl4rFw== 1601 8zc6e0lYTlWIINA6GR+3ag== 1602 EiXGlc+4TruqqoDaNE76ag== 1603 2010-12-16T23:41:07Z 1604 1605 FOO! 1606 bar 1607 1609 1612 1613 Parthasarathi R 1614 1615 8zc6e0lYTlWIINA6GR+3ag== 1616 EiXGlc+4TruqqoDaNE76ag== 1617 UAAMm5GRQKSCMVvLyl4rFw== 1618 i1Pz3to5hGk8fuXl+PbwCw== 1619 2010-12-16T23:41:07Z 1620 1621 FOO! 1622 bar 1623 1624 1626 1627 1628 1630 1631 1632 1634 1635 1636 1638 1639 1640 1642 13.2. Use case 2: Hold/resume 1644 Basic call between two Participants A and B. This is the continuation 1645 of above use-case. One of the participants(say A) goes on hold and 1646 then resumes as part of the same session. The metadata snapshot 1647 looks as below 1649 During hold 1650 Content-Type: application/SDP 1651 ... 1652 m=audio 49170 RTP/AVP 0 1653 a=rtpmap:0 PCMU/8000 1654 a=label:96 1655 a=inactive 1656 ... 1657 m=video 49174 RTP/AVPF 96 1658 a=rtpmap:96 H.264/90000 1659 a=label:97 1660 a=inactive 1661 ... 1662 m=audio 51372 RTP/AVP 0 1663 a=rtpmap:0 PCMU/8000 1664 a=label:98 1665 a=sendonly 1666 ... 1667 m=video 49176 RTP/AVPF 96 1668 a=rtpmap:96 H.264/90000 1669 a=label:99 1670 a=sendonly 1671 .... 1673 1674 1675 partial 1676 1679 1680 8zc6e0lYTlWIINA6GR+3ag== 1681 EiXGlc+4TruqqoDaNE76ag== 1682 1683 1686 1687 8zc6e0lYTlWIINA6GR+3ag== 1688 EiXGlc+4TruqqoDaNE76ag== 1689 1690 1692 During resume 1694 The snapshot will look pretty much same as Use-case 1. 1696 13.3. Use case 3: Basic Call with transfer 1698 Basic call between two Participants A and B is connected as in Use- 1699 case 1. Transfer is initiated by one of the participants of by other 1700 entity(3PCC case). SRC sends a snapshot of the participant changes 1701 to SRS. In this instance participant A(Ram) drops out during the 1702 transfer and Participant C(Paul) joins the session. There can be two 1703 cases here, same session continues after transfer or a new session 1704 (e.g. REFER based transfer) is created 1706 Transfer with same session retained - (.e.g. RE-INVITE based 1707 transfer). Participant A drops out and C is added to the same 1708 session. No change to session/group element. C will be new stream 1709 element which maps to RS SDP using the same labels in this instance. 1711 Content-Type: application/SDP 1712 ... 1713 m=audio 49170 RTP/AVP 0 1714 a=rtpmap:0 PCMU/8000 1715 a=label:96 1716 a=sendonly 1717 ... 1718 m=video 49174 RTP/AVPF 96 1719 a=rtpmap:96 H.264/90000 1720 a=label:97 1721 a=sendonly 1722 ... 1723 m=audio 51372 RTP/AVP 0 1724 a=rtpmap:0 PCMU/8000 1725 a=label:98 1726 a=sendonly 1727 ... 1728 m=video 49176 RTP/AVPF 96 1729 a=rtpmap:96 H.264/90000 1730 a=label:99 1731 a=sendonly 1732 .... 1733 1734 1735 partial 1736 1739 1740 8zc6e0lYTlWIINA6GR+3ag== 1741 EiXGlc+4TruqqoDaNE76ag== 1742 urn:uuid:60JAJm9UTvik0Ltlih/Gzw== 1743 AcR5FUd3Edi8cACQJy/3JQ== 1744 1746 1749 1750 Paul Kyzivat 1751 1752 60JAJm9UTvik0Ltlih/Gzw== 1753 AcR5FUd3Edi8cACQJy/3JQ== 1754 8zc6e0lYTlWIINA6GR+3ag== 1755 EiXGlc+4TruqqoDaNE76ag== 1756 2010-12-16T23:41:07Z 1757 1758 FOO! 1759 bar 1760 1762 1764 1765 1766 1768 1769 1770 1772 1773 1774 1776 1777 1778 1780 Transfer with new session - (.e.g. REFER based transfer). In this 1781 case new session is part of same grouping (done by SRC). 1783 SRC may send an optional snapshot indicating stop for the old 1784 session. 1786 1787 1788 Partial 1789 1790 7+OTCyoxTmqmqyA/1weDAg== 1791 1792 2010-12-16T23:41:07Z 1793 1794 FOO! 1795 bar 1796 1797 1800 1801 2010-12-16T23:41:07Z 1802 1804 1807 1808 2010-12-16T23:41:07Z 1809 1811 1813 SRC sends a snapshot to indicate the participant change and new 1814 session information after transfer. In this example the same RS is 1815 used. 1817 Content-Type: application/SDP 1818 ... 1819 m=audio 49170 RTP/AVP 0 1820 a=rtpmap:0 PCMU/8000 1821 a=label:96 1822 a=sendonly 1823 ... 1824 m=video 49174 RTP/AVPF 96 1825 a=rtpmap:96 H.264/90000 1826 a=label:97 1827 a=sendonly 1828 ... 1829 m=audio 51372 RTP/AVP 0 1830 a=rtpmap:0 PCMU/8000 1831 a=label:98 1832 a=sendonly 1833 ... 1834 m=video 49176 RTP/AVPF 96 1835 a=rtpmap:96 H.264/90000 1836 a=label:99 1837 a=sendonly 1838 .... 1839 1840 1841 partial 1842 1843 7+OTCyoxTmqmqyA/1weDAg== 1844 1845 2010-12-16T23:41:07Z 1846 1847 FOO! 1848 bar 1849 1850 1853 1854 8zc6e0lYTlWIINA6GR+3ag== 1855 EiXGlc+4TruqqoDaNE76ag== 1856 60JAJm9UTvik0Ltlih/Gzw== 1857 AcR5FUd3Edi8cACQJy/3JQ== 1858 2010-12-16T23:32:03Z 1859 1860 FOO! 1861 bar 1862 1864 1867 1868 60JAJm9UTvik0Ltlih/Gzw== 1869 AcR5FUd3Edi8cACQJy/3JQ== 1870 8zc6e0lYTlWIINA6GR+3ag== 1871 EiXGlc+4TruqqoDaNE76ag== 1872 2010-12-16T23:41:07Z 1873 1874 FOO! 1875 bar 1876 1878 1880 1881 1882 1884 1885 1886 1888 1889 1890 1892 1893 1894 1896 13.4. Use Case 4: Call disconnect 1898 This example shows a snapshot of metadata sent by an SRC at CS 1899 disconnect where the participants of CS are Ram and Partha 1901 1902 1903 Partial 1904 1905 7+OTCyoxTmqmqyA/1weDAg== 1906 1907 2010-12-16T23:41:07Z 1908 1909 FOO! 1910 bar 1911 1912 1915 1916 2010-12-16T23:41:07Z 1917 1919 1922 1923 2010-12-16T23:41:07Z 1924 1926 1928 14. References 1930 14.1. Normative References 1932 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1933 Requirement Levels", BCP 14, RFC 2119, March 1997. 1935 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 1937 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1938 A., Peterson, J., Sparks, R., Handley, M., and E. 1939 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1940 June 2002. 1942 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1943 January 2004. 1945 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 1946 Internet: Timestamps", RFC 3339, July 2002. 1948 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1949 Description Protocol", RFC 4566, July 2006. 1951 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1952 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 1954 [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description 1955 Protocol (SDP) Content Attribute", RFC 4796, 1956 February 2007. 1958 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1959 "Indicating User Agent Capabilities in the Session 1960 Initiation Protocol (SIP)", RFC 3840, August 2004. 1962 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1963 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1964 July 2005. 1966 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1967 Encodings", RFC 4648, October 2006. 1969 14.2. Informative References 1971 [RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use 1972 Cases and Requirements for SIP-Based Media Recording 1973 (SIPREC)", RFC 6341, August 2011. 1975 [I-D.ietf-siprec-architecture] 1976 Hutton, A., Portman, L., Jain, R., and K. Rehor, "An 1977 Architecture for Media Recording using the Session 1978 Initiation Protocol", draft-ietf-siprec-architecture-03 1979 (work in progress), October 2011. 1981 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 1982 August 1999. 1984 Authors' Addresses 1986 Ram Mohan Ravindranath 1987 Cisco Systems, Inc. 1988 Cessna Business Park, 1989 Kadabeesanahalli Village, Varthur Hobli, 1990 Sarjapur-Marathahalli Outer Ring Road 1991 Bangalore, Karnataka 560103 1992 India 1994 Email: rmohanr@cisco.com 1996 Parthasarathi Ravindran 1997 Sonus Networks 1998 Prestige Shantiniketan - Business Precinct 1999 Whitefield Road 2000 Bangalore, Karnataka 560066 2001 India 2003 Email: pravindran@sonusnet.com 2005 Paul Kyzivat 2006 Unaffiliated 2007 Boxborough, MA 2008 USA 2010 Email: pkyzivat@alum.mit.edu