idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** 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. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 140 has weird spacing: '... update n-1) ...' -- The document date (July 21, 2014) is 3538 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-15 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPREC Ram Mohan. Ravindranath 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track Parthasarathi. Ravindran 5 Expires: January 22, 2015 Nokia Networks 6 Paul. Kyzivat 7 Huawei 8 July 21, 2014 10 Session Initiation Protocol (SIP) Recording Call Flows 11 draft-ietf-siprec-callflows-03 13 Abstract 15 Session recording is a critical requirement in many communications 16 environments such as call centers and financial trading. In some of 17 these environments, all calls must be recorded for regulatory, 18 compliance, and consumer protection reasons. Recording of a session 19 is typically performed by sending a copy of a media stream to a 20 recording device. This document lists call flows that has snapshot 21 of metadata sent from SRC to SRS, the metadata format for which is 22 described in [I-D.ietf-siprec-metadata] . This is purely an 23 informational document that is written to support the model defined 24 in the metadata draft. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 22, 2015. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Metadata XML schema Instances . . . . . . . . . . . . . . . . 3 63 3.1. Sample Call flow . . . . . . . . . . . . . . . . . . . . . 3 64 3.2. Call Scenarios with SRC recording streams with out 65 mixing . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2.1. Example 1: Basic Call . . . . . . . . . . . . . . . . 5 67 3.2.2. Example 2: Hold/resume . . . . . . . . . . . . . . . . 7 68 3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) . 10 69 3.2.4. Example 4: Call disconnect . . . . . . . . . . . . . . 17 70 3.3. Call Scenarios with SRC recording streams by mixing . . . 19 71 3.3.1. Example 1: Basic call with SRC mixing streams . . . . 19 72 3.3.2. Example 2: Hold/resume with SRC recording by 73 mixing streams . . . . . . . . . . . . . . . . . . . . 21 74 3.3.3. Example 3: Metadata snapshot of joining/dropping 75 of a participant to a session . . . . . . . . . . . . 24 76 3.3.4. Example 4: Call disconnect . . . . . . . . . . . . . . 27 77 3.4. Call scenarios with persistent RS between SRC and SRS . . 27 78 3.4.1. Example 1: Metadata snapshot during CS disconnect 79 with persistent RS between SRC and SRS . . . . . . . . 27 80 3.5. Turrent-Case: Multiple CS into single RS with mixed 81 stream . . . . . . . . . . . . . . . . . . . . . . . . . . 28 82 4. Security Considerations . . . . . . . . . . . . . . . . . . . 30 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 84 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 31 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 86 7.1. Normative References . . . . . . . . . . . . . . . . . . . 31 87 7.2. Informative References . . . . . . . . . . . . . . . . . . 31 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 90 1. Overview 92 [I-D.ietf-siprec-metadata] document focuses on the Recording metadata 93 which describes the communication session. The document lists a few 94 examples and shows the snapshots of metadata sent from SRC to SRS. 95 For the sake of simplicity the entire SIP [RFC3261] messages are not 96 shown at various points, instead only a snippets of the SIP/SDP 97 messages and the XML snapshot of metadata is shown. 99 2. Terminology 101 The terms using in this defined are defined in 102 [I-D.ietf-siprec-metadata]. No new terms/definitions are introduced 103 in this document. 105 3. Metadata XML schema Instances 107 This section describes the metadata model XML instances for different 108 use cases of SIPREC. For the sake of simplicity the complete SIP/SDP 109 snippets are NOT shown here. 111 3.1. Sample Call flow 113 The following is a sample call flow that shows the SRC establishing a 114 recording session towards the SRS. The SRC in this example could be 115 part of any one of the architectures described in section 3 of 116 [RFC7245]. 118 SRC SRS 119 | | 120 |(1) INVITE (metadata snapshot) F1 | 121 |---------------------------------------------------->| 122 | 200 OK | 123 |<----------------------------------------------------| 124 |(3) ACK | 125 |---------------------------------------------------->| 126 |(4) RTP | 127 |====================================================>| 128 |====================================================>| 129 |====================================================>| 130 |====================================================>| 131 |(5) UPDATE/RE-INVITE (metadata update 1) F2 | 132 |---------------------------------------------------->| 133 | 200 OK | 134 |<----------------------------------------------------| 135 | ................................................... | 136 | ................................................... | 137 | | 138 |====================================================>| 139 |====================================================>| 140 |(7) UPDATE/RE-INVITE (metadata update n-1) Fn-1 | 141 |---------------------------------------------------->| 142 | 200 OK | 143 |<----------------------------------------------------| 145 For the sake of simplicity, ACKs to RE-INVITES and BYEs are not 146 shown. The subsequent sections describes the snapshot of metadata 147 sent from SRC to SRS for each of the above transactions (F1 ... 148 Fn-1). There may be multiple UPDATES/RE-INVITES mid call to 149 indicates snapshots of different CS changes. Depending on the 150 architecture described in section 3 of [RFC7245] an SRC may be a 151 endpoint or B2BUA or as part of MEDIACTRL or Conference Focus. The 152 subsequent sections in this document tries to list some example 153 metadata snapshots for three major categories. 155 o SRC recording streams unmixed to SRS. This includes cases where 156 SRC is SIP UA or B2BUA. 157 o SRC recording mixed streams to SRS. This includes cases where SRC 158 is part of SIP conference model explained in [RFC4353] 159 o SRC having a persistent RS with SRS 160 o Special flows like Turrent flows 162 Note that only those examples for which metadata changes are listed 163 in each category. For some of the call flows the snapshots may be 164 same (like in case of endpoint or B2BUA acting as SRC) and the same 165 is mentioned in the text preceding the example. 167 3.2. Call Scenarios with SRC recording streams with out mixing 169 The section covers the models mentioned in the architecture document 170 in section 3 of [RFC7245] where an SRC may be a SIP-UA or B2BUA. The 171 SRS here could be a SIP-UA or an entity part of MEDIACTRL 172 architecture described in [RFC6230]. 174 3.2.1. Example 1: Basic Call 176 Basic call between two Participants Alice and Bob who are part of one 177 CS. In this use case each participant sends two Media Streams. 178 Media Streams sent by each participant are received all other 179 participants in this use-case. Below is the initial snapshot sent by 180 SRC in the INVITE to SRS that has complete metadata. For the sake of 181 simplicity only snippets of SIP/SDP are shown. The SRCs records the 182 streams of each participant to SRS with out mixing in this example. 184 F1 INVITE SRC --------------> SRS 186 INVITE sip:recorder@example.com SIP/2.0 187 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 188 From: ;tag=35e195d2-947d-4585-946f-09839247 189 To: 190 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 191 CSeq: 101 INVITE 192 Max-Forwards: 70 193 Require: siprec 194 Accept: application/sdp, application/rs-metadata, 195 application/rs-metadata-request 196 Contact: ;+sip.src 197 Content-Type: multipart/mixed;boundary=foobar 198 Content-Length: [length] 200 --foobar 201 Content-Type: application/SDP 202 ... 203 m=audio 49170 RTP/AVP 0 204 a=rtpmap:0 PCMU/8000 205 a=label:96 206 a=sendonly 207 ... 208 m=video 49174 RTP/AVPF 96 209 a=rtpmap:96 H.264/90000 210 a=label:97 211 a=sendonly 212 ... 213 m=audio 51372 RTP/AVP 0 214 a=rtpmap:0 PCMU/8000 215 a=label:98 216 a=sendonly 217 ... 218 m=video 49176 RTP/AVPF 96 219 a=rtpmap:96 H.264/90000 220 a=label:99 221 a=sendonly 222 .... 223 --foobar 224 Content-Type: application/rs-metadata 225 Content-Disposition: recording-session 226 227 228 complete 229 230 2010-12-16T23:41:07Z 231 232 234 235 Alice 236 237 238 241 2010-12-16T23:41:07Z 242 243 245 i1Pz3to5hGk8fuXl+PbwCw== 246 UAAMm5GRQKSCMVvLyl4rFw== 247 8zc6e0lYTlWIINA6GR+3ag== 248 EiXGlc+4TruqqoDaNE76ag== 249 250 252 253 Bob 254 255 256 259 2010-12-16T23:41:07Z 260 261 263 8zc6e0lYTlWIINA6GR+3ag== 264 EiXGlc+4TruqqoDaNE76ag== 265 UAAMm5GRQKSCMVvLyl4rFw== 266 i1Pz3to5hGk8fuXl+PbwCw== 267 268 270 271 272 274 275 276 278 279 280 282 283 284 286 3.2.2. Example 2: Hold/resume 288 Assume a call between two Participants Alice and Bob is established 289 and a RS is created for recording as in example1. This is the 290 continuation of above use-case. One of the participants Bob puts 291 Alice hold and then resumes as part of the same session. The send 292 and recv XML elements of a participant is used to indicate whether a 293 participant is sending not sending a particular media stream whose 294 properties are represented by stream element. The metadata snapshot 295 looks as below 297 During hold 299 F2 mid call RE-INVITE SRC-------------------->SRS 300 INVITE sip:recorder@example.com SIP/2.0 301 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 302 From: ;tag=35e195d2-947d-4585-946f-09839247 303 To: 304 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 305 CSeq: 101 INVITE 306 Max-Forwards: 70 307 Require: siprec 308 Accept: application/sdp, application/rs-metadata, 309 application/rs-metadata-request 310 Contact: ;+sip.src 311 Content-Type: multipart/mixed;boundary=foobar 312 Content-Length: [length] 314 --foobar 315 Content-Type: application/SDP 316 ... 317 m=audio 49170 RTP/AVP 0 318 a=rtpmap:0 PCMU/8000 319 a=label:96 320 a=sendonly 321 ... 322 m=video 49174 RTP/AVPF 96 323 a=rtpmap:96 H.264/90000 324 a=label:97 325 a=sendonly 326 ... 327 m=audio 51372 RTP/AVP 0 328 a=rtpmap:0 PCMU/8000 329 a=label:98 330 a=sendonly 331 ... 332 m=video 49176 RTP/AVPF 96 333 a=rtpmap:96 H.264/90000 334 a=label:99 335 a=sendonly 336 .... 338 --foobar 339 Content-Type: application/rs-metadata 340 Content-Disposition: recording-session 342 343 344 partial 345 347 8zc6e0lYTlWIINA6GR+3ag== 348 EiXGlc+4TruqqoDaNE76ag== 349 350 352 8zc6e0lYTlWIINA6GR+3ag== 353 EiXGlc+4TruqqoDaNE76ag== 354 355 357 In the above snippet during Alice with participant_id 358 srfBElmCRp2QB23b7Mpk0w== only receives media streams since Alice is 359 put on hold and does not send any media. The same is indicated by 360 the absence of send XML element. Bob(participant_id 361 zSfPoSvdSDCmU3A3TRDxAw==) on the other hand would be sending media 362 but does not receive any media from Alice and so recv XML element is 363 absent in this instance. 365 During resume 367 The snapshot now has send and recv XML elements for both Alice and 368 Bob indicating that both are receiving and sending media. 370 F3 mid call RE-INVITE SRC-------------------->SRS 372 INVITE sip:recorder@example.com SIP/2.0 373 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 374 From: ;tag=35e195d2-947d-4585-946f-09839247 375 To: 376 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 377 CSeq: 101 INVITE 378 Max-Forwards: 70 379 Require: siprec 380 Accept: application/sdp, application/rs-metadata, 381 application/rs-metadata-request 382 Contact: ;+sip.src 383 Content-Type: multipart/mixed;boundary=foobar 384 Content-Length: [length] 386 --foobar 387 Content-Type: application/SDP 388 ... 389 m=audio 49170 RTP/AVP 0 390 a=rtpmap:0 PCMU/8000 391 a=label:96 392 a=sendonly 393 ... 394 m=video 49174 RTP/AVPF 96 395 a=rtpmap:96 H.264/90000 396 a=label:97 397 a=sendonly 398 ... 399 m=audio 51372 RTP/AVP 0 400 a=rtpmap:0 PCMU/8000 401 a=label:98 402 a=sendonly 403 ... 404 m=video 49176 RTP/AVPF 96 405 a=rtpmap:96 H.264/90000 406 a=label:99 407 a=sendonly 408 .... 409 --foobar 410 Content-Type: application/rs-metadata 411 Content-Disposition: recording-session 413 414 415 partial 416 418 8zc6e0lYTlWIINA6GR+3ag== 419 EiXGlc+4TruqqoDaNE76ag== 420 i1Pz3to5hGk8fuXl+PbwCw== 421 UAAMm5GRQKSCMVvLyl4rFw== 422 423 425 8zc6e0lYTlWIINA6GR+3ag== 426 EiXGlc+4TruqqoDaNE76ag== 427 i1Pz3to5hGk8fuXl+PbwCw== 428 UAAMm5GRQKSCMVvLyl4rFw== 429 430 432 3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) 434 Basic call between two Participants Alice and Bob is connected and 435 SRC has sent a snapshot as in example 1. Transfer is initiated by 436 one of the participants(Alice). After the transfer is completed, SRC 437 sends a snapshot of the participant changes to SRS. In this transfer 438 scenario, Alice drops out after transfer is completed and Bob and 439 Carol gets connected and recording of media between Bob and Carol is 440 done by SRC. There may be two cases here as described below. 442 Transfer with in the same session - (.e.g. RE-INVITE based 443 transfer). Participant Alice drops out and Carol is added to the 444 same session. No change to session/group element. A 445 participantsessassoc element indicating that Alice has disassociated 446 from the CS will be present in the snapshot. A new participant XML 447 element representing Carol with mapping to the same RS SDP stream 448 used for mapping earlier Alice's stream is sent in the snapshot. 450 mid call RE-INVITE SRC-------------------->SRS 452 INVITE sip:recorder@example.com SIP/2.0 453 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 454 From: ;tag=35e195d2-947d-4585-946f-09839247 455 To: 456 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 457 CSeq: 101 INVITE 458 Max-Forwards: 70 459 Require: siprec 460 Accept: application/sdp, application/rs-metadata, 461 application/rs-metadata-request 462 Contact: ;+sip.src 463 Content-Type: multipart/mixed;boundary=foobar 464 Content-Length: [length] 466 --foobar 467 Content-Type: application/SDP 468 ... 469 m=audio 49180 RTP/AVP 0 470 a=rtpmap:0 PCMU/8000 471 a=label:96 472 a=sendonly 473 ... 474 m=video 49182 RTP/AVPF 96 475 a=rtpmap:96 H.264/90000 476 a=label:97 477 a=sendonly 478 ... 479 m=audio 51374 RTP/AVP 0 480 a=rtpmap:0 PCMU/8000 481 a=label:98 482 a=sendonly 483 ... 484 m=video 49178 RTP/AVPF 96 485 a=rtpmap:96 H.264/90000 486 a=label:99 487 a=sendonly 488 .... 489 --foobar 490 Content-Type: application/rs-metadata 491 Content-Disposition: recording-session 493 494 495 partial 496 499 2013-12-16T23:41:07Z 500 501 503 8zc6e0lYTlWIINA6GR+3ag== 504 EiXGlc+4TruqqoDaNE76ag== 505 60JAJm9UTvik0Ltlih/Gzw== 506 AcR5FUd3Edi8cACQJy/3JQ== 507 508 510 511 Carol 512 513 514 517 2013-12-16T23:41:07Z 518 519 521 60JAJm9UTvik0Ltlih/Gzw== 522 AcR5FUd3Edi8cACQJy/3JQ== 523 8zc6e0lYTlWIINA6GR+3ag== 524 EiXGlc+4TruqqoDaNE76ag== 525 2013-12-16T23:42:07Z 526 527 529 Transfer with new session - (.e.g. REFER based transfer). In this 530 case a new session (CS) is created and shall be part of same CS-group 531 (done by SRC). 533 SRC first sends an optional snapshot indicating disassociation of 534 participant from the old CS. Please note this is a optional message. 535 An SRC may choose to just send a INVITE with a new session element to 536 implicitly indicate that the participants are now part of a different 537 CS with out sending disassociation from the old CS. Also note that 538 the SRC in this example uses the same RS. In case it decides to use 539 a new RS, it will tear down the current RS using normal SIP 540 procedures (BYE) with metadata as in example 4. 542 mid call RE-INVITE SRC-------------------->SRS 544 INVITE sip:recorder@example.com SIP/2.0 545 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 546 From: ;tag=35e195d2-947d-4585-946f-09839247 547 To: 548 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 549 CSeq: 101 INVITE 550 Max-Forwards: 70 551 Require: siprec 552 Accept: application/sdp, application/rs-metadata, 553 application/rs-metadata-request 554 Contact: ;+sip.src 555 Content-Type: multipart/mixed;boundary=foobar 556 Content-Length: [length] 558 --foobar 559 Content-Type: application/SDP 560 ... 561 m=audio 49180 RTP/AVP 0 562 a=rtpmap:0 PCMU/8000 563 a=label:96 564 a=sendonly 565 ... 566 m=video 49182 RTP/AVPF 96 567 a=rtpmap:96 H.264/90000 568 a=label:97 569 a=sendonly 570 ... 571 m=audio 51374 RTP/AVP 0 572 a=rtpmap:0 PCMU/8000 573 a=label:98 574 a=sendonly 575 ... 576 m=video 49178 RTP/AVPF 96 577 a=rtpmap:96 H.264/90000 578 a=label:99 579 a=sendonly 580 .... 582 --foobar 583 Content-Type: application/rs-metadata 584 Content-Disposition: recording-session 586 587 588 Partial 589 590 2010-12-16T23:41:07Z 591 592 595 2010-12-16T23:41:07Z 596 597 600 2010-12-16T23:41:07Z 601 602 604 Note in the above snapshot the participantsessionassoc element is 605 optional as indicating session XML element with a stop-time 606 implicitly means that all the participants associated with that 607 session have been disassociated. 609 SRC sends another snapshot to indicate the participant change (due to 610 REFER) and new session information after transfer. In this example 611 it is assumed SRC uses the same. 613 mid call RE-INVITE SRC-------------------->SRS 615 INVITE sip:recorder@example.com SIP/2.0 616 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 617 From: ;tag=35e195d2-947d-4585-946f-09839247 618 To: 619 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 620 CSeq: 101 INVITE 621 Max-Forwards: 70 622 Require: siprec 623 Accept: application/sdp, application/rs-metadata, 624 application/rs-metadata-request 625 Contact: ;+sip.src 626 Content-Type: multipart/mixed;boundary=foobar 627 Content-Length: [length] 629 --foobar 630 Content-Type: application/SDP 631 ... 632 m=audio 49180 RTP/AVP 0 633 a=rtpmap:0 PCMU/8000 634 a=label:96 635 a=sendonly 636 ... 637 m=video 49182 RTP/AVPF 96 638 a=rtpmap:96 H.264/90000 639 a=label:97 640 a=sendonly 641 ... 642 m=audio 51374 RTP/AVP 0 643 a=rtpmap:0 PCMU/8000 644 a=label:98 645 a=sendonly 646 ... 647 m=video 49178 RTP/AVPF 96 648 a=rtpmap:96 H.264/90000 649 a=label:99 650 a=sendonly 651 .... 653 --foobar 654 Content-Type: application/rs-metadata 656 657 658 complete 659 660 2010-12-16T23:41:07Z 661 662 664 666 667 670 2010-12-16T23:32:03Z 671 672 674 8zc6e0lYTlWIINA6GR+3ag== 675 EiXGlc+4TruqqoDaNE76ag== 676 60JAJm9UTvik0Ltlih/Gzw== 677 AcR5FUd3Edi8cACQJy/3JQ== 678 679 681 682 683 686 2010-12-16T23:41:07Z 687 688 690 60JAJm9UTvik0Ltlih/Gzw== 691 AcR5FUd3Edi8cACQJy/3JQ== 692 8zc6e0lYTlWIINA6GR+3ag== 693 EiXGlc+4TruqqoDaNE76ag== 694 695 697 698 699 701 702 703 705 706 707 709 710 711 713 3.2.4. Example 4: Call disconnect 715 This example shows a snapshot of metadata sent by an SRC at CS 716 disconnect where the participants of CS are Alice and Bob 717 SRC SRS 718 | | 719 |(1) BYE (metadata snapshot) F1 | 720 |---------------------------------------------------->| 721 | 200 OK F2 | 722 |<----------------------------------------------------| 724 F1 BYE SRC -----------> SRS 726 BYE sip:2001@8.3.2.12:5060 SIP/2.0 727 Via: SIP/2.0/UDP 8.3.2.34:5060;branch=z9hG4bK47c8eb30 728 From: ;tag=35e195d2-947d-4585-946f-09839247 729 To: 730 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 731 CSeq: 102 BYE 732 Max-Forwards: 70 733 Require: siprec 734 Accept: application/rs-metadata, 735 application/rs-metadata-request 736 Contact: ;+sip.src 737 Content-Type: multipart/mixed;boundary=foobar 738 Content-Length: [length] 740 --foobar 741 Content-Type: application/rs-metadata 743 744 745 Partial 746 747 2010-12-16T23:41:07Z 748 749 752 2010-12-16T23:41:07Z 753 755 758 2010-12-16T23:41:07Z 759 760 762 3.3. Call Scenarios with SRC recording streams by mixing 764 The section covers the models mentioned in the architecture document 765 in section 3 of [RFC7245] where an SRC may be part of Conference 766 model either as Focus or a participant in Conference. The SRS here 767 could be a SIP UA or an entity part of MEDIACTRL architecture. Note 768 that the disconnect case is not shown since the metadata snapshot 769 will be same as for a non-mixing case. 771 3.3.1. Example 1: Basic call with SRC mixing streams 773 Basic call between two Participants Alice and Bob who are part of one 774 CS. In this use case each participant sends one Media Streams. 775 Media Streams sent by each participant is received by the other 776 participant. Below is the initial snapshot sent by SRC in the INVITE 777 to SRS that has complete metadata. For the sake of simplicity only 778 snippets of SIP/SDP are shown. The SRCs records the streams of each 779 participant to SRS by mixing in this example. The SRC here could be 780 part of conference Focus model described in section 3 of [RFC7245]. 782 F1 INVITE SRC --------------> SRS 784 INVITE sip:recorder@example.com SIP/2.0 785 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 786 From: ;tag=35e195d2-947d-4585-946f-09839247 787 To: 788 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 789 CSeq: 101 INVITE 790 Max-Forwards: 70 791 Require: siprec 792 Accept: application/sdp, application/rs-metadata, 793 application/rs-metadata-request 794 Contact: ;+sip.src 795 Content-Type: multipart/mixed;boundary=foobar 796 Content-Length: [length] 798 --foobar 799 Content-Type: application/SDP 800 ... 801 m=audio 49170 RTP/AVP 0 802 a=rtpmap:0 PCMU/8000 803 a=label:96 804 a=sendonly 806 .... 807 --foobar 808 Content-Type: application/rs-metadata 809 Content-Disposition: recording-session 810 811 812 complete 813 814 2010-12-16T23:41:07Z 815 816 818 819 Alice 820 821 822 825 2010-12-16T23:41:07Z 826 827 829 i1Pz3to5hGk8fuXl+PbwCw== 830 i1Pz3to5hGk8fuXl+PbwCw== 831 832 834 835 Bob 836 837 838 841 2010-12-16T23:41:07Z 842 843 845 i1Pz3to5hGk8fuXl+PbwCw== 846 i1Pz3to5hGk8fuXl+PbwCw== 847 848 850 851 852 854 3.3.2. Example 2: Hold/resume with SRC recording by mixing streams 856 Assume a call between two Participants Alice and Bob is established 857 and a RS is created for recording as in example 5. This is the 858 continuation of above use-case. One of the participants Bob puts 859 Alice hold and then resumes as part of the same session. The send 860 and recv XML elements of a participant is used to indicate whether a 861 participant is sending not sending a particular media stream whose 862 properties are represented by stream element. The metadata snapshot 863 looks as below: 865 During hold 866 mid call hold RE-INVITE SRC --------------> SRS 868 INVITE sip:recorder@example.com SIP/2.0 869 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 870 From: ;tag=35e195d2-947d-4585-946f-09839247 871 To: 872 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 873 CSeq: 101 INVITE 874 Max-Forwards: 70 875 Require: siprec 876 Accept: application/sdp, application/rs-metadata, 877 application/rs-metadata-request 878 Contact: ;+sip.src 879 Content-Type: multipart/mixed;boundary=foobar 880 Content-Length: [length] 882 --foobar 883 Content-Type: application/SDP 884 ... 885 m=audio 49170 RTP/AVP 0 886 a=rtpmap:0 PCMU/8000 887 a=label:96 888 a=sendonly 890 .... 891 --foobar 892 Content-Type: application/rs-metadata 893 Content-Disposition: recording-session 894 895 896 partial 897 899 i1Pz3to5hGk8fuXl+PbwCw== 900 901 903 i1Pz3to5hGk8fuXl+PbwCw== 904 905 907 908 909 911 During resume a snapshot shown below will be sent from SRC to SRS 912 mid call resume RE-INVITE SRC --------------> SRS 914 INVITE sip:recorder@example.com SIP/2.0 915 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 916 From: ;tag=35e195d2-947d-4585-946f-09839247 917 To: 918 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 919 CSeq: 101 INVITE 920 Max-Forwards: 70 921 Require: siprec 922 Accept: application/sdp, application/rs-metadata, 923 application/rs-metadata-request 924 Contact: ;+sip.src 925 Content-Type: multipart/mixed;boundary=foobar 926 Content-Length: [length] 928 --foobar 929 Content-Type: application/SDP 930 ... 931 m=audio 49170 RTP/AVP 0 932 a=rtpmap:0 PCMU/8000 933 a=label:96 934 a=sendonly 936 .... 937 --foobar 938 Content-Type: application/rs-metadata 939 Content-Disposition: recording-session 940 941 942 partial 943 945 i1Pz3to5hGk8fuXl+PbwCw== 946 i1Pz3to5hGk8fuXl+PbwCw== 947 948 950 i1Pz3to5hGk8fuXl+PbwCw== 951 i1Pz3to5hGk8fuXl+PbwCw== 952 953 955 956 957 959 3.3.3. Example 3: Metadata snapshot of joining/dropping of a 960 participant to a session 962 In a conference model, participants can join and drop a session any 963 time during the session. The below shows a snapshot sent from SRC to 964 SRC in these case. Note the SRC here can be a focus or a participant 965 in the conference. In case where the SRC is a participant it may 966 learn the information required for metadata by subscribing to 967 conference event package [RFC4575]. Assume Alice and Bob were in the 968 conference and a third participant Carol joins, then SRC sends the 969 below snapshot with the indication of new participant. 971 mid call resume RE-INVITE SRC --------------> SRS 973 INVITE sip:recorder@example.com SIP/2.0 974 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 975 From: ;tag=35e195d2-947d-4585-946f-09839247 976 To: 977 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 978 CSeq: 101 INVITE 979 Max-Forwards: 70 980 Require: siprec 981 Accept: application/sdp, application/rs-metadata, 982 application/rs-metadata-request 983 Contact: ;+sip.src 984 Content-Type: multipart/mixed;boundary=foobar 985 Content-Length: [length] 987 --foobar 988 Content-Type: application/SDP 989 ... 990 m=audio 49170 RTP/AVP 0 991 a=rtpmap:0 PCMU/8000 992 a=label:96 993 a=sendonly 995 .... 996 --foobar 997 Content-Type: application/rs-metadata 998 Content-Disposition: recording-session 999 1000 1001 partial 1002 1004 1005 Carol 1006 1007 1008 1011 2013-12-16T23:41:07Z 1012 1013 1015 i1Pz3to5hGk8fuXl+PbwCw== 1016 i1Pz3to5hGk8fuXl+PbwCw== 1017 1018 1020 Assume Alice drops after some time from the conference. SRC 1021 generates a new snapshot showing Alice disassociating from the 1022 session 1024 mid call resume RE-INVITE SRC --------------> SRS 1026 INVITE sip:recorder@example.com SIP/2.0 1027 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 1028 From: ;tag=35e195d2-947d-4585-946f-09839247 1029 To: 1030 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1031 CSeq: 101 INVITE 1032 Max-Forwards: 70 1033 Require: siprec 1034 Accept: application/sdp, application/rs-metadata, 1035 application/rs-metadata-request 1036 Contact: ;+sip.src 1037 Content-Type: multipart/mixed;boundary=foobar 1038 Content-Length: [length] 1040 --foobar 1041 Content-Type: application/SDP 1042 ... 1043 m=audio 49170 RTP/AVP 0 1044 a=rtpmap:0 PCMU/8000 1045 a=label:96 1046 a=sendonly 1048 .... 1049 --foobar 1050 Content-Type: application/rs-metadata 1051 Content-Disposition: recording-session 1052 1053 1054 partial 1055 1058 2010-12-16T23:41:07Z 1059 1060 1062 3.3.4. Example 4: Call disconnect 1064 When a CS is disconnected, SRC sends BYE with a snapshot of metadata 1065 having session stop-time and participant dis-associate times. The 1066 snapshot looks same as listed in section 3.2.4 1068 3.4. Call scenarios with persistent RS between SRC and SRS 1070 The section shows the snapshots of metadata for the cases there a 1071 persistent RS exists between SRC and SRS. An SRC here may be SIP UA 1072 or a B2BUA or may be part of Conference model either as Focus or a 1073 participant in Conference. The SRS here could be a SIP UA or an 1074 entity part of MEDIACTRL architecture. Except disconnect case, the 1075 snapshot remains same as one of the examples mentioned in previous 1076 sections. 1078 3.4.1. Example 1: Metadata snapshot during CS disconnect with 1079 persistent RS between SRC and SRS 1081 RE-INVITE sent from SRC -----------> SRS 1083 INVITE sip:2001@8.3.2.12:5060 SIP/2.0 1084 Via: SIP/2.0/UDP 8.3.2.34:5060;branch=z9hG4bK47c8eb30 1085 From: ;tag=35e195d2-947d-4585-946f-09839247 1086 To: 1087 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1088 CSeq: 101 INVITE 1089 Max-Forwards: 70 1090 Require: siprec 1091 Accept: application/rs-metadata, 1092 application/rs-metadata-request 1093 Contact: ;+sip.src 1094 Content-Type: multipart/mixed;boundary=foobar 1095 Content-Length: [length] 1097 --foobar 1098 Content-Type: application/rs-metadata 1100 1101 1102 Partial 1103 1104 2010-12-16T23:41:07Z 1105 1106 1109 2010-12-16T23:41:07Z 1110 1112 1115 2010-12-16T23:41:07Z 1116 1117 1119 3.5. Turrent-Case: Multiple CS into single RS with mixed stream 1121 In trading turret, audio mixing is done locally before forwarding to 1122 the recording server. Sender and receiver audio is mixed for each 1123 communication session. The audio from multiple communication 1124 sessions is also mixed, or multiplexed, in a single RTP session to 1125 the recording server. 1127 snapshot of metadata INVITE SRC --------------> SRS 1129 Content-Type: application/SDP 1130 ... 1131 m=audio 49170 RTP/AVP 0 1132 a=rtpmap:0 PCMU/8000 1133 a=label:96 1134 a=sendonly 1135 ... 1136 1137 1138 complete 1139 1140 2010-12-16T23:41:07Z 1141 1142 1143 7+OTCyoxTmqmqyA/1weDAg== 1144 2010-12-16T23:41:07Z 1145 1146 1147 7+OTCyoxTmqmqyA/1weDAg== 1148 2010-12-16T23:43:07Z 1149 1150 1152 1153 RamMohan R 1154 1155 1156 1159 2010-12-16T23:41:07Z 1160 1161 1163 UAAMm5GRQKSCMVvLyl4rFw== 1164 UAAMm5GRQKSCMVvLyl4rFw== 1165 1166 1168 1169 Parthasarathi R 1170 1171 1172 1176 2010-12-16T23:41:07Z 1177 1178 1181 2010-12-16T23:43:07Z 1182 1183 1185 UAAMm5GRQKSCMVvLyl4rFw== 1186 UAAMm5GRQKSCMVvLyl4rFw== 1187 1188 1190 1191 Paul 1192 1193 1194 1197 2010-12-16T23:43:07Z 1198 1199 1201 UAAMm5GRQKSCMVvLyl4rFw== 1202 UAAMm5GRQKSCMVvLyl4rFw== 1203 1205 1207 1208 1209 1211 4. Security Considerations 1213 There is no security consideration as it is informatioal callflow 1214 document. 1216 5. IANA Considerations 1218 This document has no IANA considerations 1220 6. Acknowledgement 1222 Thanks to Ofir Rath, Charles Eckel for their review comments. 1224 7. References 1226 7.1. Normative References 1228 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1229 A., Peterson, J., Sparks, R., Handley, M., and E. 1230 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1231 June 2002. 1233 7.2. Informative References 1235 [I-D.ietf-siprec-metadata] 1236 R, R., Ravindran, P., and P. Kyzivat, "Session Initiation 1237 Protocol (SIP) Recording Metadata", 1238 draft-ietf-siprec-metadata-15 (work in progress), 1239 February 2014. 1241 [RFC7245] Hutton, A., Portman, L., Jain, R., and K. Rehor, "An 1242 Architecture for Media Recording Using the Session 1243 Initiation Protocol", RFC 7245, May 2014. 1245 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 1246 Initiation Protocol (SIP) Event Package for Conference 1247 State", RFC 4575, August 2006. 1249 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1250 Session Initiation Protocol (SIP)", RFC 4353, 1251 February 2006. 1253 [RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media 1254 Control Channel Framework", RFC 6230, May 2011. 1256 Authors' Addresses 1258 Ram Mohan Ravindranath 1259 Cisco Systems, Inc. 1260 Cessna Business Park, 1261 Kadabeesanahalli Village, Varthur Hobli, 1262 Sarjapur-Marathahalli Outer Ring Road 1263 Bangalore, Karnataka 560103 1264 India 1266 Email: rmohanr@cisco.com 1268 Parthasarathi Ravindran 1269 Nokia Networks 1270 Bangalore, Karnataka 1271 India 1273 Email: partha@parthasarathi.co.in 1275 Paul Kyzivat 1276 Huawei 1277 Hudson, MA 1278 USA 1280 Email: pkyzivat@alum.mit.edu