idnits 2.17.1 draft-ietf-siprec-metadata-01.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 (June 20, 2011) is 4692 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) == Outdated reference: A later version (-12) exists of draft-ietf-siprec-architecture-02 Summary: 0 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 Parthasarathi. Ravindran 3 Intended status: Standards Track Paul. Kyzivat 4 Expires: December 22, 2011 Cisco Systems, Inc. 5 June 20, 2011 7 Session Initiation Protocol (SIP) Recording Metadata 8 draft-ietf-siprec-metadata-01 10 Abstract 12 Session recording is a critical requirement in many communications 13 environments such as call centers and financial trading. In some of 14 these environments, all calls must be recorded for regulatory, 15 compliance, and consumer protection reasons. Recording of a session 16 is typically performed by sending a copy of a media stream to a 17 recording device. This document describes the metadata model as 18 viewed by Session Recording Server(SRS). 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 22, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Metadata Model . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Recording Metadata elements . . . . . . . . . . . . . . . . . 5 58 4.1. Recording Session . . . . . . . . . . . . . . . . . . . . 5 59 4.1.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 5 60 4.1.2. Associations . . . . . . . . . . . . . . . . . . . . . 6 61 4.2. Communication Session Group . . . . . . . . . . . . . . . 6 62 4.2.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 6 63 4.2.2. Associations . . . . . . . . . . . . . . . . . . . . . 7 64 4.3. Communication Session . . . . . . . . . . . . . . . . . . 7 65 4.3.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 8 66 4.3.2. Associations . . . . . . . . . . . . . . . . . . . . . 8 67 4.4. Participant . . . . . . . . . . . . . . . . . . . . . . . 9 68 4.4.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 9 69 4.4.2. Associations . . . . . . . . . . . . . . . . . . . . . 10 70 4.5. Media Stream . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.5.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 11 72 4.5.2. Associations . . . . . . . . . . . . . . . . . . . . . 11 73 4.6. Extension Data . . . . . . . . . . . . . . . . . . . . . . 11 74 5. Metadata Model Object Instances . . . . . . . . . . . . . . . 11 75 5.1. Use case 1: Basic Call . . . . . . . . . . . . . . . . . . 11 76 5.2. Use case 2: Basic Call with hold/resume . . . . . . . . . 12 77 5.3. Use case 3: Basic call with Transfer . . . . . . . . . . . 14 78 5.4. Conference Use Cases . . . . . . . . . . . . . . . . . . . 15 79 5.4.1. Case 1: . . . . . . . . . . . . . . . . . . . . . . . 16 80 5.4.2. Case 2: . . . . . . . . . . . . . . . . . . . . . . . 18 81 5.4.3. Case 3: . . . . . . . . . . . . . . . . . . . . . . . 20 82 5.4.4. Case 4: . . . . . . . . . . . . . . . . . . . . . . . 21 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 85 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 22 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 88 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 91 1. Introduction 93 Session recording is a critical requirement in many communications 94 environments such as call centers and financial trading. In some of 95 these environments, all calls must be recorded for regulatory, 96 compliance, and consumer protection reasons. Recording of a session 97 is typically performed by sending a copy of a media stream to a 98 recording device. This document focuses on the Recording metadata 99 which describes the communication session. The document describes a 100 metadata model as viewed by Session Recording Server, the 101 requirements for which are described in [I-D.ietf-siprec-req] and the 102 architecture for which is described in 103 [I-D.ietf-siprec-architecture]. 105 2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. This 110 document only uses these key words when referencing normative 111 statements in existing RFCs." 113 3. Metadata Model 115 Metadata is the information that describes recorded media and the CS 116 to which they relate. Below diagram shows a model for Metadata as 117 viewed by Session Recording Server (SRS). 119 +-------------------------------+ 1 120 | Recording Session (RS) |---------------+ 121 +-------------------------------+ | 122 |1..* | 1..* | 123 | | | 124 | | 0..* | 125 | +-----------------+ | 126 | | Communication | | 127 | | Session (CS) | 1 | 128 | | Group |--------------| 129 | +-----------------+ | 130 | | 0..1 | 131 | | | 132 |0..* | 1..* | 133 +-------------------------------+ | 134 | Communication Session (CS) | 1 | 135 | |---------------| 136 +-------------------------------+ | +------------+ 137 | 1..* |1..* | | | 138 | | | 0..* |Extension | 139 | 2..* |0..* |-------| Data | 140 +-------------+ receives +----------------+ | | | 141 | Participant |----------| Media Streams | | +------------+ 142 | |0..* 0..*| | | 143 | | | | | 144 | | | | | 145 | | sends | | | 146 | |----------| | | 147 | |1.* 0..*| | | 148 +-------------+ +----------------+ | 149 | | | 150 |1 |1 | 151 | | | 152 +----------------------------------------+ 154 The mechanism MUST provide a means to convey every attribute 155 mentioned in the metadata model. Session Recording Client (SRC) MAY 156 initiate the Recording Session. Here, Recording Session is a 157 completely independent from the Communication Session that is being 158 recorded at both the SIP dialog level and at the session level. The 159 metadata MUST be conveyed from SRC to SRS. The metadata MAY be 160 conveyed within the Recording Session Dialog. 162 Note that the metadata model captures changes that occur over the 163 duration of the recording session. For example, if the call is 164 transferred from one participant to another, then the SRC SHALL 165 convey a change of participant and the properties of the new media 166 stream to the SRS. 168 Some of the data in the model may not be conveyed explicitly from the 169 SRC to the SRS, if it can be obtained contextually by the SRS. For 170 instance, the timing of RS block changes(like Start / Stop time) may 171 not be explicitly conveyed from the SRC to the SRS (The Date header 172 in RS dialog SIP message MAY provide the timing, but it is optional). 173 In such cases the time a change occurred may be assumed to be the 174 same as the time when notification of the change is received by the 175 SRS. 177 4. Recording Metadata elements 179 This section describes each element of the metadata model, and the 180 attributes of each element. This section also describes how 181 different elements are associated. 183 4.1. Recording Session 185 +-------------------------------+ 186 | Recording Session (RS) | 187 +-------------------------------+ 188 | | +-----------------+ 189 | Start/End Time | 1 0..* | | 190 | |------------|Extension Data | 191 | | | | 192 | | +-----------------+ 193 +-------------------------------+ 194 |1..* | 1..* 195 | | 196 |0..* | 0..* 197 Communication Communication 198 Session Session Group(CS Group) 200 A Recording Session element represents a SIP session created between 201 an SRC and SRS for the purpose of recording a Communication Session. 202 A SIP RS dialog SHALL be mapped to this element and hence there is no 203 need for this element to be reflected in metadata XML. 205 4.1.1. Attributes 207 A Recording Session element MAY have attributes like: 209 o Start/End Time - Start and End time value SHALL be derived from 210 Date header(if present in SIP message) in RS. In cases where Date 211 header is not present, Start/End time SHALL be the time at which 212 SRS receive the SIP message to setup RS / disconnect RS. 214 4.1.2. Associations 216 One instance of Recording Session SHALL have: 218 o Zero or more instances of Communication Session Group. CSG may be 219 zero because it is optional metadata block. Also the allowance of 220 zero instances is to accommodate persistent recording, where there 221 may be none. 222 o Zero or more instances of Communication Session blocks. 223 o Each CS Group MUST be associated with one or more Recording 224 Sessions [Here each RS can be setup by the potentially different 225 SRCs.] 227 4.2. Communication Session Group 229 Recording Session (RS) 230 | 1..* 231 | 232 | 0..* 233 +-------------------------------+ 234 | Communication Session | 235 | Group | 236 +-------------------------------+ 237 | Unique-ID | +----------------+ 238 | | 1 0..* | | 239 | |-----------|Extension Data | 240 | | | | 241 +-------------------------------+ +----------------+ 242 | 0..1 243 | 244 | 1..* 245 Communication Session (CS) 247 A Communication Session Group provides association or linking of 248 Communication Sessions. 250 4.2.1. Attributes 252 A CS Group MUST have a Unique-ID attribute. This Unique-ID is to 253 group different CSs that are related. SRC (or MAY be SRS) MUST 254 ensure the uniqueness of Unique-ID in case multiple SRC interacts 255 with the same SRS. The mechanism by which SRC groups the CS is 256 outside the scope of SIPREC. 258 4.2.2. Associations 260 A communication Session Group SHALL be associated with RS and CS in 261 the following manner: 263 o There can be one or more Recording Session elements per 264 Communication Session Group. 265 o Each Communication Session Group MUST be associated with one or 266 more RS [Here each RS can be setup by the potentially different 267 SRCs] 268 o There MAY be one or more Communication Sessions per CS Group [e.g. 269 Consult Transfer] 270 o Each CS MAY be associated to zero or one CS-Group 272 4.3. Communication Session 274 Recording Communication 275 Session Session Group(CS Group) 276 |1..* | 0..1 277 | | 278 |0..* | 1..* 279 +-------------------------------+ +-----------------+ 280 | Communication Session (CS) | 1 0..* | | 281 | |---------------|Extension Data | 282 +-------------------------------+ | | 283 | CS Identifier | +-----------------+ 284 | Termination Reason | 285 | Start Time | 286 | End Time | 287 +-------------------------------+ 288 | | 289 | 1..* |1..* 290 | | 291 | 2..* |0..* 292 Participant Media Stream 294 A Communication Session block/element in the metadata model 295 represents Communication Session and its properties needed as seen by 296 SRC. 298 4.3.1. Attributes 300 A communication Session block SHALL have the following attributes: 302 o Termination Reason - This represents the reason why a CS was 303 terminated. The communication session MAY contain a Call 304 Termination Reason. This MAY be derived from SIP Reason header of 305 CS. 306 o CS Identifier - This attribute is used to uniquely identify a CS. 307 o Start Time - This optional attribute represents CS start time 308 o End Time - This optional attribute represents CS end time 310 Attributes like Retention (represent the value/duration for which 311 Media streams of the CS needs to be retained), Force Deletion, Access 312 Information e.t.c that are primarily related to policy will not be 313 passed in metadata from SRC to SRS. However if there are 314 implementations where SRC has enough information, this could be sent 315 as Extension Data attached to CS 317 4.3.2. Associations 319 A Communication Session SHALL be associated to CS-Group, Participant, 320 Media Stream and Recording Session blocks. Cardinalities between CS 321 and Participant allows: 323 o CS to have atleast two or more participants 324 o Participant SHALL be associated with one or more CS's. This may 325 even includes participants who are not directly part of any CS. 326 An example of such a case is participants in a premixed media 327 stream. The SRC may have knowledge of such Participants, yet not 328 have any signaling relationship with them. This might arise if 329 one participant in CS is a conf focus. Another use case is if one 330 UA in CS works in 3pcc mode to acquire an MoH media stream, this 331 might be reflected as unique source for media stream without 332 having a reported signaling relationship to it. In all these 333 cases if SRC can learn enough information about the Participant, 334 they SHALL be associated with CS. 335 o The model also allows participants in CS that are not participants 336 in the media. An example is the identity of a 3pcc controller 337 that has initiated a CS to two or more participants of the CS. 338 Another example is the identity of a conference focus. Of course 339 a focus is probably in the media, but since it may only be there 340 as a mixer, it may not report itself as a participant in any of 341 the media streams. 343 Cardinalities between CS and Media Stream allows: 345 o A CS to have zero or more Streams 346 o A stream can be associated with 1 or more CS. An example is 347 multicast MoH stream which might be associated with many CSs. 348 Also if we were to consider a B2BUA to have a separate CS on each 349 "side" then they might share a stream.(Though more likely this 350 would be treated as a single CS.) 352 Cardinalities between CS and RS allows: 354 o One instance of RS SHALL have Zero or more instances of 355 Communication Session blocks. 356 o Each CS SHALL be associated with one more RS [ Here each RS can be 357 potentially setup by different SRCs] 359 4.4. Participant 361 Communication Session (CS) 362 | 1..* 363 | 364 | 2..* 365 +-------------------------------+ 366 | Participant | 367 | | 368 +-------------------------------+ 369 | AoR list | +-----------------+ 370 | Name | 1 0..* | | 371 | Participant Type |------------|Extension Data | 372 | | | | 373 +-------------------------------+ +-----------------+ 374 | 0..* 1..*| 375 receives| |sends 376 | 0..* 0..*| 377 Media Stream 379 A Participant block has information about a device that is part of a 380 CS and/or contributes/consumes media stream(s) belonging to a CS. 382 4.4.1. Attributes 384 Participant has attributes like: 386 o AoR list - Has list of AoRs. An AoR MAY be SIP/SIPS/TEL URI. 387 There MAY be cases where a participant can have more than one AoR 388 [ e.g. P-Asserted-ID which can have both SIP and TEL URIs] 390 o Name - This attribute represents Participant name(SIP display 391 name) or DN number ( in case it is known) 393 Other attributes [ like Participant Role, Participant type ] MAY be 394 carried as part of extension data to Participant from SRC to SRS. 396 4.4.2. Associations 398 Cardinalities between participant and Media Stream allows: 400 o Participant to receives zero or more media streams 401 o Participant to send zero or more media streams. (Same participant 402 provides multiple streams e.g. audio and video) 403 o Media stream to be received by zero or more participants. Its 404 possible, though perhaps unlikely, that a stream is generated but 405 sent only to the SRC and SRS, not to any participant. E.g. In 406 conferencing where all participants are on hold and the SRC is 407 collocated with the focus. Also a media stream may be received by 408 multiple participants (e.g. Whisper calls, side conversations). 409 o Media stream to be sent by one or more participants (pre-mixed 410 streams). 412 Example of a case where a participant may receive Zero or more 413 streams - a Supervisor may have side conversation with Agent, while 414 Agent converses with customer. 416 4.5. Media Stream 418 Participant 419 | 0..* 1..*| 420 receives| |sends 421 | 0..* 0..*| 422 +-------------------------+ 423 | Media Stream | 424 | | 425 Communication 1..* 0..* +-------------------------+ 426 Session ------------| Start Time | +----------+ 427 | End Time |1 0..* | | 428 | Media Stream Reference |--------|Extension | 429 | | | Data | 430 +-------------------------+ +----------+ 432 A Media Stream block SHALL have properties of media as seen by SRC 433 and sent to SRS. Different instances of Media Stream block would be 434 created whenever there is a change in media (e.g. dir change like 435 pause/resume and/or codec change and/or participant change.). 437 4.5.1. Attributes 439 A Media Stream block SHALL have the following attributes: 441 o Start Time - Represents Media Start time at SRC. 442 o End Time - Represents Media End time at SRC. This is an optional 443 attribute and MAY be included after a stream ends 444 o Media Stream Reference - In implementations this can reference to 445 m-line 447 The metadata model should include media streams that are not being 448 delivered to the SRS. Examples include cases where SRC offered 449 certain media types but SRS chooses to accept only a subset of them 450 OR an SRC may not even offer a certain media type due it its 451 restrictions to record 453 4.5.2. Associations 455 A Media Stream SHALL be associated with Participant and CS. The 456 details of association with the Participant are described in the 457 Participant block section. The details of association with CS is 458 mentioned in the CS section. 460 4.6. Extension Data 462 A recording metadata object contains additional data not specified as 463 part of siprec. This is intended to accommodate future standards 464 track extensions, as well as vendor and user specific extensions. 465 The mechanism MUST provide a means of unambiguously distinguishing 466 such extension data. 468 5. Metadata Model Object Instances 470 This section describes the metadata model object instances for 471 different use cases of SIPREC. For the sake of simplicity as the 472 media streams sent by each of the participants is received by every 473 other participant in these use cases, it is NOT shown in the object 474 instance diagrams below. Also for the sake of ease not all 475 attributes of each block are shown in these instance diagrams. 477 5.1. Use case 1: Basic Call 479 Basic call between two Participants A and B. In this use case each 480 participant sends one Media Stream. For the sake of simplicity 481 "receives" lines are not shown in this instance diagram. Media 482 Streams sent by each participant is received all other participants 483 of that CS. 485 +-------------------------------+ 486 | Recording Session (RS) | 487 +-------------------------------+ 488 | 489 | 490 | 491 +----------------+ 492 | Communication | 493 | Session (CS) | 494 +----------------+-----------------------+ 495 | Start Time | | 496 +----------------+ | 497 | | 498 |-------------------+ | 499 | | | 500 +---------------+ +---------------+ | 501 | ParticipantA | | ParticipantB | | 502 | | | | | 503 +---------------+ +---------------+ | 504 | | | 505 sends | | sends | 506 | | | 507 +---------------+ +---------------+ | 508 |Media Stream A1| |Media Stream B1| | 509 +---------------+ +---------------+ | 510 |MediaStream Ref| |MediaStream Ref| | 511 |Start Time | |Start Time | | 512 +---------------+ +---------------+ | 513 | | | 514 +-----------------------------------+ 516 5.2. Use case 2: Basic Call with hold/resume 518 Basic call between two Participants A and B and with Participant A or 519 B doing a Hold/Resume. In this use case each participant sends one 520 Media Stream. After Hold/Resume the properties of Media MAY change. 521 For the sake of simplicity "receives" lines are not shown in this 522 instance diagram. Media Streams sent by each participant is received 523 all other participants of that CS. 525 +-------------------------------+ 526 | Recording Session (RS) | 527 +-------------------------------+ 528 | | 529 | | 530 | | 531 | +-------------------------------+ 532 | | Communication Session (CS) | 533 | +-----------| Group(CSG) | 534 | | +-------------------------------+ 535 | | | Unique-id1 | 536 | | +-------------------------------+ 537 | | 538 | | 539 | | 540 +----------------+ 541 | Communication | 542 +-| Session (CS) |----------------------------------------------+ 543 | +----------------+ | 544 | | | | 545 | +----------------+ | 546 | | | 547 | |-------------------+ | 548 | | | | 549 | +---------------+ +---------------+ | 550 | | ParticipantA | | ParticipantB |-----------+ | 551 | | |--+ | | | | 552 | +---------------+ | +---------------+ |sends(After | 553 | | | | | | | Resume) | 554 | | | | | | +--------------+ | 555 | sends | | +--+ | sends | |MediaStream B3| | 556 | | -----+ | | +-----+ +--------------+ | 557 | +---------------+ | | +---------------+ | |MediaStreamRef|-| 558 | |Media Stream A1| | | |Media Stream B1| | | Start Time | | 559 | +---------------+ | | +---------------+ | | | | 560 +-|MediaStreamref | | | |MediaStreamRef | | +--------------+ | 561 |Start Time | | | |Start Time |-|-------------------| 562 +---------------+ | | +---------------+ | | 563 | | | | 564 +------------+ |sends |sends (hold) | 565 | sends |(Resume) | | 566 | (hold) +-------+ +-------+ | 567 | | | | 568 +---------------+ +---------------+ +--------------+ | 569 |Media Stream A2| |Media Stream A3| |MediaStream B2| | 570 +---------------+ +---------------+ | | | 571 |MediaStreamref | |MediaStreamRef | +--------------+ | 572 |End Time | |Start Time | |Codec Params | | 573 +---------------+ +---------------+ |end Time | | 574 | | | | | 575 | | +--------------+ | 576 | | | | 577 +------------------------------------------------------+ 579 5.3. Use case 3: Basic call with Transfer 581 Basic call between two Participants A and B and with Participant A 582 transfer(consult transfer) to Participant C. In this use case each 583 participant sends one Media Stream. After transfer the properties of 584 Participant A Media MAY change. For the sake of simplicity 585 "receives" lines are not shown in this instance diagram. Media 586 Streams sent by each participant is received all other participants 587 of that CS. 589 +-------------------------------+ 590 | Recording Session (RS) |-------+ 591 +-------------------------------+ | 592 | | 593 | | 594 | | 595 +-------------------------------+ | 596 | Communication Session (CS) | | 597 | Group(CSG) | | 598 +-------------------------------+ | 599 | Unique-id1 | | 600 +-------------------------------+ | 601 | | 602 |----------------------------+ 603 | 604 |-----------------+ 605 | | 606 +----------------+ +----------------+ 607 | Communication | | Communication | 608 | Session (CS)1 | | Session (CS)2 | 609 +----------------+ +----------------+-----------+ 610 | | | | | 611 +----------------+ +----------------+ | 612 | | 613 |-------------------+ | 614 | | | | 615 +---------------+ | +---------------+ | 616 | ParticipantA | | | ParticipantB | | 617 | | | | | | 618 +---------------+ | +---------------+ | 619 | | | | 620 sends | | | sends | 621 | | | | 622 +---------------+ | +---------------+ | 623 |Media Stream A1| | |Media Stream B1| | 624 +---------------+ | +---------------+ | 625 | | | | | | 626 | | | | Media Stream | | 627 | Media Stream |---+---| Ref | | 628 | Ref | | | | 629 +---------------+ +---------------+ | 630 | 631 | 632 +----------------------------| 633 | | 634 +--------------------------------+ | 635 | | | 636 +---------------+ +---------------+ | 637 | Participant A | | Participant C | | 638 | (same) | | | | 639 +---------------+ +---------------+ | 640 | | | 641 | sends (After transfer) | sends | 642 +----------------+ +----------------+| 643 | Media Stream A2| | Media Stream C1|| 644 +----------------+ +----------------+| 645 | Media StreamRef| | Media StreamRef|| 646 | | | || 647 | | | || 648 +----------------+ +----------------+| 649 | | | 650 | | | 651 | | | 652 +-------------------------------------------+ 654 5.4. Conference Use Cases 656 Depending on who act as SRC and the information that an SRC has there 657 can be several ways to model conference use cases. This section has 658 instance diagrams for the following cases: 660 o A CS where one of the participant (which is also SRC) is a user in 661 a conference 662 o A CS where one of the participant is focus ( which is also SRC) 663 o A CS where one of the participant is user and the SRC is a 664 different entity like B2BUA 665 o A CS where one of the participant is focus and the SRC is a 666 different entity like B2BUA 668 NOTE: There MAY be other ways to model the same use cases depending 669 on what information the SRC has. 671 5.4.1. Case 1: 673 This is the usecase where there is a CS with one of the participant 674 (who is also SRC) as a user in a conference. For the sake of 675 simplicity the receive lines for each of the participant is not 676 shown. 678 +---------------------------------------------------+ 679 | Communication Session | 680 | +-------------+ +--------------+ | 681 | | | | | | 682 | |Participant B| | Participant A| | 683 | | (User in |--------------| | | 684 | | conf/SRC) | | | | 685 | +-------------+ +--------------+ | 686 | | | | | | 687 +---------------------------------------------------+ 688 | | | | 689 | | | | 690 D E F G (Participants of Conference) 692 Instance Diagram: 694 +-------------------------------+ 695 | Recording Session (RS) |--+ 696 +-------------------------------+ | 697 | | 698 | | 699 | | 700 +-------------------------------+ | 701 | Communication Session (CS) | | 702 | Group(CSG) | | 703 +-------------------------------+ | 704 | Unique-id1 | | 705 +-------------------------------+ | 706 | | 707 |-----------------------+ 708 | 709 +----------------+ 710 | Communication | 711 | Session (CS) |--+----------------+-----+ 712 +----------------+ | | | 713 | | | | | 714 +----------------+ | | | 715 | | | | 716 | | | | 717 | | | | 718 +---------------+ | | | 719 | ParticipantA | | | | 720 | | | | | 721 +---------------+ | | | 722 | | | | 723 sends | | | | 724 | | | | 725 +---------------+ | | | 726 |Media Stream A1| | | | 727 +---------------+ | | | 728 |MediaStream Ref|-----|----------------+ | 729 | | | | | 730 +---------------+ | | | 731 | | | 732 | | | 733 +-------------+ | | 734 | | | 735 | | | 736 +----------------+ | | 737 | Participant B | | | 738 | (in conf) | | | 739 +----------------+ | | 740 | | | 741 sends | | | 742 | | | 743 +----------------+ | | 744 | Media Stream B1|---------------------+ | 745 +----------------+ sends | 746 | MediaStream Ref| | 747 | | +-----------------+ 748 +----------------+ | 749 | | 750 |sends | 751 | | 752 +-----------------+-------------+------------+ 753 | | | | 754 | | | | 755 +------------+ +------------+ +------------+ +-------------+ 756 |participantD| |ParticipantE| |ParticipantF| |Participant G| 757 +------------+ +------------+ +------------+ +-------------+ 759 In this example we have two participants A and B who are part of a 760 Communication Session(CS). One of the participants B is part of a 761 conference and also acts as SRC.There can be two cases here. B can 762 be a participant of the conference or B can be a focus. In this 763 instance diagram Participant B is a user in a conference. The SRC 764 (Participant B) MAY subscribe to conference event package to get the 765 details of other particiants. Participant B(SRC) SHALL send the same 766 through the metadata to SRS. In this instance diagram the Media 767 Stream(mixed stream) sent from Participant B SHALL have media streams 768 contributed by conference participants (D,E,F and G). For the sake 769 of simplicity the "receives" line is not shown here. In this example 770 the media stream sent by each participant(A or B) of CS is received 771 by all other participant(A or B). 773 5.4.2. Case 2: 775 This is the usecase where there is a CS where one of the participant 776 is focus ( which is also SRC). 778 +---------------------------------------------------+ 779 | Communication Session | 780 | +--------------+ +--------------+ | 781 | | |--------------| | | 782 | |Participant C | | Participant A| | 783 | | (Focus in |------+ | | | 784 | | conf and SRC)|---+ | +--------------+ | 785 | +--------------+ | | | 786 | | | +---------+ | 787 | | | | | 788 | +--------------+ | +---------------+ | 789 | | Participant B| +---+ | Participant D | | 790 | | | | | | | 791 | +--------------+ | +---------------+ | 792 | | | 793 | +--------------+ | 794 | |Participant E | | 795 | | | | 796 | +--------------+ | 797 | | 798 +---------------------------------------------------+ 800 Instance Diagram: 802 +-------------------------------+ 803 | Recording Session (RS) | 804 +-------------------------------+ 805 |-------------------------+ 806 | | 807 | | 808 +-------------------------------+ | 809 | Communication Session (CS) | | 810 | Group(CSG) | | 811 +-------------------------------+ | 812 | Unique-id1 | | 813 +-------------------------------+ | 814 | | 815 |-------------------------+ 816 | 817 +----------------+ 818 | Communication | 819 | Session (CS) |----------------------+ 820 +----------------+ | 821 | | | 822 +----------------+ | 823 | | 824 |-------------------+ | 825 | | | | 826 +---------------+ | +---------------+ | 827 | ParticipantA | | | ParticipantB | | 828 | | | | | | 829 +---------------+ | +---------------+ | 830 | | | | 831 sends | | | sends | 832 | | | | 833 +---------------+ | +---------------+ | 834 |Media Stream A1| | |Media Stream B1| | 835 +---------------+ | +---------------+ | 836 |MediaStream Ref| | |MediaStream Ref| | 837 | |---+---| | | 838 +---------------+ +---------------+ | 839 | 840 +----------------------------------+ 841 | | | | 842 | | | | 843 +---------------+ | +---------------+ | 844 | ParticipantD | | | ParticipantE | | 845 | | | | | | 846 +---------------+ | +---------------+ | 847 | | | | 848 sends | | | sends | 849 | | | | 850 +---------------+ | +---------------+ | 851 |Media Stream D1| | |Media Stream E1| | 852 +---------------+ | +---------------+ | 853 |MediaStream Ref| | |MediaStream Ref| | 854 | |---+---| | | 855 +---------------+ +---------------+ | 856 | 857 | 858 +----------+ 859 +-----------------| 860 | | 861 | | 862 +----------------+ | 863 | Participant C | | 864 | (focus +src) | | 865 +----------------+ | 866 | | 867 Sends | +-------+ 868 | | 869 "sends" OR | | 870 contributed +----------------+ 871 by | Media Stream C1| 872 Participants+----------------+ "receives" by participants A,B,D,E 873 A,B,D,E | MediaStream Ref|------------------------------------ 874 ------------| Codec Params | 875 +----------------+ 877 In this example we have two participants A and B who are part of a 878 Communication Session(CS). One of the participants (C) is focus of a 879 conference and also acts as SRC. The SRC (Participant C) being the 880 Focus of the conference SHALL have access to the details of other 881 particiants. SRC (Participant C) SHALL send the same through the 882 metadata to SRS. In this instance diagram the Media Stream(mixed 883 stream) sent by C SHALL have media streams contributed by conference 884 participants (A, B, D and E). Participants A, B,D and E SHALL send 885 Media Streams A1, B1, D1 and E1 respectively. The media stream sent 886 by Participant C(Focus) shall be received by all other participants 887 of CS. For the sake of simplicity the "receives" line is not shown 888 linked to all other participants. 890 NOTE: SRC ( Participant C) MAY send mixed stream or seperate streams 891 to SRS 893 5.4.3. Case 3: 895 A CS where one of the participant is user and the SRC is a different 896 entity like B2BUA. In this case the SRC MAY not know that one of the 897 user is part of conference. Hence the instance diagram will not have 898 information about the conference participants. 900 +---------------------------------------------------+ 901 | Communication Session | 902 | +-------------+ +------+ +--------------+ | 903 | | | | (SRC)| | | | 904 | |Participant B|--|B2BUA |----| Participant A| | 905 | | (User in | +------+ | | | 906 | | conf) | | | | 907 | +-------------+ +--------------+ | 908 | | | | | | 909 +---------------------------------------------------+ 910 | | | | 911 | | | | 912 D E F G (Participants of Conference) 914 5.4.4. Case 4: 916 A CS where one of the participant is focus and the SRC is a different 917 entity like B2BUA. In this case the participant which is focus MAY 918 send "isfocus" in SIP message to SRC. The SRC MAY subscribe to 919 conference event package on seeing this "isfocus". SRC SHALL learn 920 the details of other participants of conference from the conference 921 package and send the same in metadata to SRS. The instance diagram 922 for this use case SHALL be same as Case 1. 924 +--------------------------------+ 925 | Conference Event Package | 926 | | 927 +--------------------------------+ 928 | 929 | subscribes 930 | 931 +---------------------|-----------------------------+ 932 | Communication |Session | 933 | +-------------+ +------+ +--------------+ | 934 | | | | (SRC)| | | | 935 | |Participant B|--|B2BUA |----| Participant A| | 936 | | (FOCUS in | +------+ | | | 937 | | conf) | | | | 938 | +-------------+ +--------------+ | 939 | | | | | | 940 +---------------------------------------------------+ 941 | | | | 942 | | | | 943 D E F G (Participants of Conference) 945 6. Security Considerations 947 The metadata information sent from SRC to SRS MAY reveal sensitive 948 Information about different participants of CS. For this reason, it 949 is RECOMMENDED that a SRC use a strong means for authentication and 950 metadata information protection and that it apply comprehensive 951 authorization rules when using the metadata model defined in this 952 document. The security considerations for this SHALL be defined in 953 the solution document. 955 7. IANA Considerations 957 Not Applicable 959 8. Acknowledgement 961 We wish to thank John Elwell, Henry Lum, Leon Portman, De Villers, 962 Andrew Hutton, Deepanshu Gautam, Charles Eckel, Muthu Arul for their 963 valuable comments. 965 9. References 967 9.1. Normative References 969 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 970 Requirement Levels", BCP 14, RFC 2119, March 1997. 972 9.2. Informative References 974 [I-D.ietf-siprec-req] 975 Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use 976 Cases and Requirements for SIP-based Media Recording 977 (SIPREC)", draft-ietf-siprec-req-12 (work in progress), 978 June 2011. 980 [I-D.ietf-siprec-architecture] 981 Hutton, A., Portman, L., Jain, R., and K. Rehor, "An 982 Architecture for Media Recording using the Session 983 Initiation Protocol", draft-ietf-siprec-architecture-02 984 (work in progress), April 2011. 986 Authors' Addresses 988 Ram Mohan Ravindranath 989 Cisco Systems, Inc. 990 Cessna Business Park, 991 Kadabeesanahalli Village, Varthur Hobli, 992 Sarjapur-Marathahalli Outer Ring Road 993 Bangalore, Karnataka 560103 994 India 996 Email: rmohanr@cisco.com 998 Parthasarathi Ravindran 999 Cisco Systems, Inc. 1000 Cessna Business Park, 1001 Kadabeesanahalli Village, Varthur Hobli, 1002 Sarjapur-Marathahalli Outer Ring Road 1003 Bangalore, Karnataka 560103 1004 India 1006 Email: partr@cisco.com 1008 Paul Kyzivat 1009 Cisco Systems, Inc. 1010 1414 Massachusetts Avenue 1011 Boxborough, MA 01719 1012 USA 1014 Email: pkyzivat@cisco.com