idnits 2.17.1 draft-ram-siprec-callflows-03.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-siprec-metadata]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2013) is 4076 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 (-22) exists of draft-ietf-siprec-metadata-11 Summary: 1 error (**), 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: August 29, 2013 Nokia Siemens Networks 5 Paul. Kyzivat 6 Huawei 7 February 25, 2013 9 Session Initiation Protocol (SIP) Recording Call Flows 10 draft-ram-siprec-callflows-03 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 lists call flows that has snapshot 20 of metadata sent from SRC to SRS, the metadata format for which is 21 described in [I-D.ietf-siprec-metadata] . This is purely an 22 informational document that is written to support the model defined 23 in the metadata draft. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 29, 2013. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Metadata XML schema Instances . . . . . . . . . . . . . . . . 3 62 3.1. Sample Call flow . . . . . . . . . . . . . . . . . . . . . 3 63 3.2. Example 1: Basic Call . . . . . . . . . . . . . . . . . . 5 64 3.3. Example 2: Hold/resume . . . . . . . . . . . . . . . . . . 7 65 3.4. Example 3: Basic Call with transfer . . . . . . . . . . . 10 66 3.5. Example 4: Call disconnect . . . . . . . . . . . . . . . . 14 67 3.6. Example 5: Multiple CS into single RS with mixed stream . 15 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 70 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 72 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 73 7.2. Informative References . . . . . . . . . . . . . . . . . . 18 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 76 1. Overview 78 [I-D.ietf-siprec-metadata] document focuses on the Recording metadata 79 which describes the communication session. The document lists a few 80 examples and shows the snapshots of metadata sent from SRC to SRS. 81 For the sake of simplicity the entire SIP [RFC3261] messages are not 82 shown at various points, instead only a snip of the SIP/SDP message 83 and the XML snapshot of metadata is shown. This document is 84 informational and is not normative on any aspect of SIPREC. 86 2. Terminology 88 The terms using in this defined are defined in 89 [I-D.ietf-siprec-metadata]. No new terms/definitions are introduced 90 in this document. 92 3. Metadata XML schema Instances 94 This section describes the metadata model XML instances for different 95 use cases of SIPREC. For the sake of simplicity the complete SIP 96 messages are NOT shown here. 98 3.1. Sample Call flow 100 The following is a sample call flow that shows the SRC establishing a 101 recording session towards the SRS. The call flow is essentially 102 identical when the SRC is a B2BUA or as the endpoint itself. Note 103 that the SRC can choose when to establish the Recording Session 104 independent of the Communication Session, even though the following 105 call flow suggests that the SRC is establishing the Recording Session 106 (message #5) after the Communication Session is established. 108 UA A SRC UA B SRS 109 |(1)CS INVITE | | | 110 |------------->| | | 111 | |(2)CS INVITE | | 112 | |---------------------->| | 113 | | (3) 200 OK | | 114 | |<----------------------| | 115 | (4) 200 OK | | | 116 |<-------------| | | 117 | |(5)RS INVITE with SDP | | 118 | |--------------------------------------------->| 119 | | | (6) 200 OK with SDP | 120 | |<---------------------------------------------| 121 |(7)CS RTP | | | 122 |=============>|======================>| | 123 |<=============|<======================| | 124 | |(8)RS RTP | | 125 | |=============================================>| 126 | |=============================================>| 127 | | | | 128 | Mid call updates(hold/resume/re-invite(new offer) | 129 | | | | 130 |(9)CS BYE | | | 131 |------------->| | | 132 | |(10)CS BYE | | 133 | |---------------------->| | 134 | |(11)RS BYE | | 135 | |--------------------------------------------->| 136 | | | | 138 The above call flow can also apply to the case of a centralized 139 conference with a mixer. For clarity, ACKs to INVITEs and 200 OKs to 140 BYEs are not shown. The conference focus can provide the SRC 141 functionality since the conference focus has access to all the media 142 from each conference participant. When a recording is requested, the 143 SRC delivers the metadata and the media streams to the SRS. Since 144 the conference focus has access to a mixer, the SRC may choose to mix 145 the media streams from all participants as a single mixed media 146 stream towards the SRS. 148 An SRC can use a single recording session to record multiple 149 communication sessions. Every time the SRC wants to record a new 150 call, the SRC updates the recording session with a new SDP offer to 151 add new recorded streams to the recording session, and 152 correspondingly also update the metadata for the new call. 154 3.2. Example 1: Basic Call 156 SRC SRS 157 | | 158 |(1) INVITE (metadata snapshot) F1 | 159 |---------------------------------------------------->| 160 | 200 OK F2 | 161 |<----------------------------------------------------| 162 |(3) ACK F3 | 163 |---------------------------------------------------->| 164 |(4) RTP | 165 |====================================================>| 166 |====================================================>| 167 |====================================================>| 168 |====================================================>| 169 |(5) UPDATE/RE-INVITE (metadata update 1) F4 | 170 |---------------------------------------------------->| 171 | 200 OK F5 | 172 |<----------------------------------------------------| 173 |====================================================>| 174 |====================================================>| 175 |(7) UPDATE/RE-INVITE (metadata update 2) F6 | 176 |---------------------------------------------------->| 177 | 200 OK F7 | 178 |<----------------------------------------------------| 180 Basic call between two Participants Ram and Partha who are part of 181 one session. In this use case each participant sends two Media 182 Streams. Media Streams sent by each participant are received all 183 other participants of that CS in this use-case. Below is the initial 184 snapshot sent by SRC in the INVITE to SRS that has complete metadata. 185 For the sake of simplicity snippets of SDP are shown. Here the RS 186 stream is unmixed. 188 F1 INVITE SRC --------------> SRS 190 Content-Type: application/SDP 191 ... 192 m=audio 49170 RTP/AVP 0 193 a=rtpmap:0 PCMU/8000 194 a=label:96 195 a=sendonly 196 ... 198 m=video 49174 RTP/AVPF 96 199 a=rtpmap:96 H.264/90000 200 a=label:97 201 a=sendonly 202 ... 203 m=audio 51372 RTP/AVP 0 204 a=rtpmap:0 PCMU/8000 205 a=label:98 206 a=sendonly 207 ... 208 m=video 49176 RTP/AVPF 96 209 a=rtpmap:96 H.264/90000 210 a=label:99 211 a=sendonly 212 .... 213 214 215 complete 216 217 2010-12-16T23:41:07Z 218 219 221 222 RamMohan R 223 224 225 228 2010-12-16T23:41:07Z 229 230 232 i1Pz3to5hGk8fuXl+PbwCw== 233 UAAMm5GRQKSCMVvLyl4rFw== 234 8zc6e0lYTlWIINA6GR+3ag== 235 EiXGlc+4TruqqoDaNE76ag== 236 237 239 240 Parthasarathi R 241 242 243 247 2010-12-16T23:41:07Z 248 249 251 8zc6e0lYTlWIINA6GR+3ag== 252 EiXGlc+4TruqqoDaNE76ag== 253 UAAMm5GRQKSCMVvLyl4rFw== 254 i1Pz3to5hGk8fuXl+PbwCw== 255 256 258 259 260 262 263 264 266 267 268 270 271 272 274 3.3. Example 2: Hold/resume 276 Basic call between two Participants Ram and Partha. This is the 277 continuation of above use-case. One of the participants(say Ram) 278 goes on hold and then resumes as part of the same session. The 279 metadata snapshot looks as below 281 During hold 283 F4 RE-INVITE SRC-------------------->SRS 285 Content-Type: application/SDP 286 ... 287 m=audio 49170 RTP/AVP 0 288 a=rtpmap:0 PCMU/8000 289 a=label:96 290 a=inactive 291 ... 292 m=video 49174 RTP/AVPF 96 293 a=rtpmap:96 H.264/90000 294 a=label:97 295 a=inactive 296 ... 297 m=audio 51372 RTP/AVP 0 298 a=rtpmap:0 PCMU/8000 299 a=label:98 300 a=sendonly 301 ... 302 m=video 49176 RTP/AVPF 96 303 a=rtpmap:96 H.264/90000 304 a=label:99 305 a=sendonly 306 .... 308 309 310 partial 311 313 8zc6e0lYTlWIINA6GR+3ag== 314 EiXGlc+4TruqqoDaNE76ag== 315 316 318 8zc6e0lYTlWIINA6GR+3ag== 319 EiXGlc+4TruqqoDaNE76ag== 320 321 323 324 325 327 328 329 331 332 333 335 336 338 340 During resume 342 The snapshot will look pretty much same as above with just the SDP 343 dir change. 345 F5 RE-INVITE SRC-------------------->SRS 347 Content-Type: application/SDP 348 ... 349 m=audio 49170 RTP/AVP 0 350 a=rtpmap:0 PCMU/8000 351 a=label:96 352 a=sendonly 353 ... 354 m=video 49174 RTP/AVPF 96 355 a=rtpmap:96 H.264/90000 356 a=label:97 357 a=sendonly 358 ... 359 m=audio 51372 RTP/AVP 0 360 a=rtpmap:0 PCMU/8000 361 a=label:98 362 a=sendonly 363 ... 364 m=video 49176 RTP/AVPF 96 365 a=rtpmap:96 H.264/90000 366 a=label:99 367 a=sendonly 368 .... 370 371 372 partial 373 375 i1Pz3to5hGk8fuXl+PbwCw== 376 UAAMm5GRQKSCMVvLyl4rFw== 377 8zc6e0lYTlWIINA6GR+3ag== 378 EiXGlc+4TruqqoDaNE76ag== 379 380 382 8zc6e0lYTlWIINA6GR+3ag== 383 EiXGlc+4TruqqoDaNE76ag== 384 UAAMm5GRQKSCMVvLyl4rFw== 385 i1Pz3to5hGk8fuXl+PbwCw== 386 388 390 391 392 394 395 396 398 399 400 402 403 405 407 3.4. Example 3: Basic Call with transfer 409 Basic call between two Participants Ram and Partha is connected as in 410 Use-case 1. Transfer is initiated by one of the participants or by 411 other entity(3PCC case). SRC sends a snapshot of the participant 412 changes to SRS. In this instance participant Ram drops out during 413 the transfer and Participant Paul joins the session. There can be 414 two cases here, same session continues after transfer or a new 415 session (e.g. REFER based transfer) is created 417 Transfer with same session retained - (.e.g. RE-INVITE based 418 transfer). Participant Ram drops out and Paul is added to the same 419 session. No change to session/group element. Paul will have new 420 stream element which maps to RS SDP using the same labels in this 421 instance. 423 Content-Type: application/SDP 424 ... 425 m=audio 49170 RTP/AVP 0 426 a=rtpmap:0 PCMU/8000 427 a=label:96 428 a=sendonly 429 ... 430 m=video 49174 RTP/AVPF 96 431 a=rtpmap:96 H.264/90000 432 a=label:97 433 a=sendonly 434 ... 435 m=audio 51372 RTP/AVP 0 436 a=rtpmap:0 PCMU/8000 437 a=label:98 438 a=sendonly 439 ... 440 m=video 49176 RTP/AVPF 96 441 a=rtpmap:96 H.264/90000 442 a=label:99 443 a=sendonly 444 .... 445 446 447 partial 448 450 8zc6e0lYTlWIINA6GR+3ag== 451 EiXGlc+4TruqqoDaNE76ag== 452 60JAJm9UTvik0Ltlih/Gzw== 453 AcR5FUd3Edi8cACQJy/3JQ== 454 455 457 458 Paul Kyzivat 459 460 461 464 2010-12-16T23:41:07Z 465 466 468 60JAJm9UTvik0Ltlih/Gzw== 469 AcR5FUd3Edi8cACQJy/3JQ== 470 8zc6e0lYTlWIINA6GR+3ag== 471 EiXGlc+4TruqqoDaNE76ag== 472 2010-12-16T23:41:07Z 473 474 476 477 478 480 481 482 484 485 486 488 489 490 492 Transfer with new session - (.e.g. REFER based transfer). In this 493 case new session is part of same grouping (done by SRC). 495 SRC may send an optional snapshot indicating stop for the old 496 session. 498 499 500 Partial 501 502 2010-12-16T23:41:07Z 503 504 507 2010-12-16T23:41:07Z 508 509 512 2010-12-16T23:41:07Z 513 514 516 SRC sends a snapshot to indicate the participant change and new 517 session information after transfer. In this example the same RS is 518 used. 520 Content-Type: application/SDP 521 ... 522 m=audio 49170 RTP/AVP 0 523 a=rtpmap:0 PCMU/8000 524 a=label:96 525 a=sendonly 526 ... 527 m=video 49174 RTP/AVPF 96 528 a=rtpmap:96 H.264/90000 529 a=label:97 530 a=sendonly 531 ... 532 m=audio 51372 RTP/AVP 0 533 a=rtpmap:0 PCMU/8000 534 a=label:98 535 a=sendonly 536 ... 537 m=video 49176 RTP/AVPF 96 538 a=rtpmap:96 H.264/90000 539 a=label:99 540 a=sendonly 541 .... 542 543 544 partial 545 546 2010-12-16T23:41:07Z 547 548 550 551 552 555 2010-12-16T23:32:03Z 556 557 559 8zc6e0lYTlWIINA6GR+3ag== 560 EiXGlc+4TruqqoDaNE76ag== 561 60JAJm9UTvik0Ltlih/Gzw== 562 AcR5FUd3Edi8cACQJy/3JQ== 563 564 566 567 568 572 2010-12-16T23:41:07Z 573 574 576 60JAJm9UTvik0Ltlih/Gzw== 577 AcR5FUd3Edi8cACQJy/3JQ== 578 8zc6e0lYTlWIINA6GR+3ag== 579 EiXGlc+4TruqqoDaNE76ag== 580 581 583 584 585 587 588 589 591 592 593 595 596 597 599 3.5. Example 4: Call disconnect 601 This example shows a snapshot of metadata sent by an SRC at CS 602 disconnect where the participants of CS are Ram and Partha 603 SRC SRS 604 | | 605 |(1) BYE (metadata snapshot) F1 | 606 |---------------------------------------------------->| 607 | 200 OK F2 | 608 |<----------------------------------------------------| 610 F1 BYE SRC -----------> SRS 612 613 614 Partial 615 616 2010-12-16T23:41:07Z 617 618 621 2010-12-16T23:41:07Z 622 624 627 2010-12-16T23:41:07Z 628 629 631 3.6. Example 5: Multiple CS into single RS with mixed stream 633 In trading turret, audio mixing is done locally before forwarding to 634 the recording server. Sender and receiver audio is mixed for each 635 communication session. The audio from multiple communication 636 sessions is also mixed, or multiplexed, in a single RTP session to 637 the recording server. 639 F1 INVITE SRC --------------> SRS 641 Content-Type: application/SDP 642 ... 643 m=audio 49170 RTP/AVP 0 644 a=rtpmap:0 PCMU/8000 645 a=label:96 646 a=sendonly 647 ... 648 649 650 complete 651 652 2010-12-16T23:41:07Z 653 654 655 7+OTCyoxTmqmqyA/1weDAg== 656 2010-12-16T23:41:07Z 657 658 659 7+OTCyoxTmqmqyA/1weDAg== 660 2010-12-16T23:43:07Z 661 662 664 665 RamMohan R 666 667 668 671 2010-12-16T23:41:07Z 672 673 675 UAAMm5GRQKSCMVvLyl4rFw== 676 UAAMm5GRQKSCMVvLyl4rFw== 677 678 680 681 Parthasarathi R 682 683 684 687 2010-12-16T23:41:07Z 688 689 692 2010-12-16T23:43:07Z 693 694 696 UAAMm5GRQKSCMVvLyl4rFw== 697 UAAMm5GRQKSCMVvLyl4rFw== 698 699 701 702 Paul 703 704 705 708 2010-12-16T23:43:07Z 709 710 712 UAAMm5GRQKSCMVvLyl4rFw== 713 UAAMm5GRQKSCMVvLyl4rFw== 714 716 718 719 720 722 4. Security Considerations 724 There is no security consideration as it is informatioal callflow 725 document. 727 5. IANA Considerations 729 This document has no IANA considerations 731 6. Acknowledgement 733 Thanks to Ofir Rath, Charles Eckel for their review comments. 735 7. References 736 7.1. Normative References 738 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 739 A., Peterson, J., Sparks, R., Handley, M., and E. 740 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 741 June 2002. 743 7.2. Informative References 745 [I-D.ietf-siprec-metadata] 746 R, R., Ravindran, P., and P. Kyzivat, "Session Initiation 747 Protocol (SIP) Recording Metadata", 748 draft-ietf-siprec-metadata-11 (work in progress), 749 January 2013. 751 Authors' Addresses 753 Ram Mohan Ravindranath 754 Cisco Systems, Inc. 755 Cessna Business Park, 756 Kadabeesanahalli Village, Varthur Hobli, 757 Sarjapur-Marathahalli Outer Ring Road 758 Bangalore, Karnataka 560103 759 India 761 Email: rmohanr@cisco.com 763 Parthasarathi Ravindran 764 Nokia Siemens Networks 765 Bangalore, Karnataka 766 India 768 Email: partha@parthasarathi.co.in 770 Paul Kyzivat 771 Huawei 772 Hudson, MA 773 USA 775 Email: pkyzivat@alum.mit.edu