idnits 2.17.1 draft-ietf-siprec-callflows-02.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 (January 14, 2014) is 3755 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-13 == Outdated reference: A later version (-12) exists of draft-ietf-siprec-architecture-11 Summary: 2 errors (**), 0 flaws (~~), 5 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: July 18, 2014 Nokia Solutions and Networks 6 Paul. Kyzivat 7 Huawei 8 January 14, 2014 10 Session Initiation Protocol (SIP) Recording Call Flows 11 draft-ietf-siprec-callflows-02 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 July 18, 2014. 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 [I-D.ietf-siprec-architecture]. 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 [I-D.ietf-siprec-architecture] 151 an SRC may be a endpoint or B2BUA or as part of MEDIACTRL or 152 Conference Focus. The subsequent sections in this document tries to 153 list some example 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 [I-D.ietf-siprec-architecture] where an SRC may be a 171 SIP-UA or B2BUA. The SRS here could be a SIP-UA or an entity part of 172 MEDIACTRL 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 [I-D.ietf-siprec-architecture] where an SRC may be 766 part of Conference model either as Focus or a participant in 767 Conference. The SRS here could be a SIP UA or an entity part of 768 MEDIACTRL architecture. Note that the disconnect case is not shown 769 since the metadata snapshot 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 781 [I-D.ietf-siprec-architecture]. 783 F1 INVITE SRC --------------> SRS 785 INVITE sip:recorder@example.com SIP/2.0 786 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 787 From: ;tag=35e195d2-947d-4585-946f-09839247 788 To: 789 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 790 CSeq: 101 INVITE 791 Max-Forwards: 70 792 Require: siprec 793 Accept: application/sdp, application/rs-metadata, 794 application/rs-metadata-request 795 Contact: ;+sip.src 796 Content-Type: multipart/mixed;boundary=foobar 797 Content-Length: [length] 799 --foobar 800 Content-Type: application/SDP 801 ... 802 m=audio 49170 RTP/AVP 0 803 a=rtpmap:0 PCMU/8000 804 a=label:96 805 a=sendonly 807 .... 809 --foobar 810 Content-Type: application/rs-metadata 811 Content-Disposition: recording-session 812 813 814 complete 815 816 2010-12-16T23:41:07Z 817 818 820 821 Alice 822 823 824 827 2010-12-16T23:41:07Z 828 829 831 i1Pz3to5hGk8fuXl+PbwCw== 832 i1Pz3to5hGk8fuXl+PbwCw== 833 834 836 837 Bob 838 839 840 843 2010-12-16T23:41:07Z 844 845 847 i1Pz3to5hGk8fuXl+PbwCw== 848 i1Pz3to5hGk8fuXl+PbwCw== 849 850 852 853 854 856 3.3.2. Example 2: Hold/resume with SRC recording by mixing streams 858 Assume a call between two Participants Alice and Bob is established 859 and a RS is created for recording as in example 5. This is the 860 continuation of above use-case. One of the participants Bob puts 861 Alice hold and then resumes as part of the same session. The send 862 and recv XML elements of a participant is used to indicate whether a 863 participant is sending not sending a particular media stream whose 864 properties are represented by stream element. The metadata snapshot 865 looks as below: 867 During hold 868 mid call hold RE-INVITE SRC --------------> SRS 870 INVITE sip:recorder@example.com SIP/2.0 871 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 872 From: ;tag=35e195d2-947d-4585-946f-09839247 873 To: 874 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 875 CSeq: 101 INVITE 876 Max-Forwards: 70 877 Require: siprec 878 Accept: application/sdp, application/rs-metadata, 879 application/rs-metadata-request 880 Contact: ;+sip.src 881 Content-Type: multipart/mixed;boundary=foobar 882 Content-Length: [length] 884 --foobar 885 Content-Type: application/SDP 886 ... 887 m=audio 49170 RTP/AVP 0 888 a=rtpmap:0 PCMU/8000 889 a=label:96 890 a=sendonly 892 .... 893 --foobar 894 Content-Type: application/rs-metadata 895 Content-Disposition: recording-session 896 897 898 partial 899 901 i1Pz3to5hGk8fuXl+PbwCw== 902 903 905 i1Pz3to5hGk8fuXl+PbwCw== 906 907 909 910 911 913 During resume a snapshot shown below will be sent from SRC to SRS 914 mid call resume RE-INVITE SRC --------------> SRS 916 INVITE sip:recorder@example.com SIP/2.0 917 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 918 From: ;tag=35e195d2-947d-4585-946f-09839247 919 To: 920 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 921 CSeq: 101 INVITE 922 Max-Forwards: 70 923 Require: siprec 924 Accept: application/sdp, application/rs-metadata, 925 application/rs-metadata-request 926 Contact: ;+sip.src 927 Content-Type: multipart/mixed;boundary=foobar 928 Content-Length: [length] 930 --foobar 931 Content-Type: application/SDP 932 ... 933 m=audio 49170 RTP/AVP 0 934 a=rtpmap:0 PCMU/8000 935 a=label:96 936 a=sendonly 938 .... 939 --foobar 940 Content-Type: application/rs-metadata 941 Content-Disposition: recording-session 942 943 944 partial 945 947 i1Pz3to5hGk8fuXl+PbwCw== 948 i1Pz3to5hGk8fuXl+PbwCw== 949 950 952 i1Pz3to5hGk8fuXl+PbwCw== 953 i1Pz3to5hGk8fuXl+PbwCw== 954 955 957 958 959 961 3.3.3. Example 3: Metadata snapshot of joining/dropping of a 962 participant to a session 964 In a conference model, participants can join and drop a session any 965 time during the session. The below shows a snapshot sent from SRC to 966 SRC in these case. Note the SRC here can be a focus or a participant 967 in the conference. In case where the SRC is a participant it may 968 learn the information required for metadata by subscribing to 969 conference event package [RFC4575]. Assume Alice and Bob were in the 970 conference and a third participant Carol joins, then SRC sends the 971 below snapshot with the indication of new participant. 973 mid call resume RE-INVITE SRC --------------> SRS 975 INVITE sip:recorder@example.com SIP/2.0 976 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 977 From: ;tag=35e195d2-947d-4585-946f-09839247 978 To: 979 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 980 CSeq: 101 INVITE 981 Max-Forwards: 70 982 Require: siprec 983 Accept: application/sdp, application/rs-metadata, 984 application/rs-metadata-request 985 Contact: ;+sip.src 986 Content-Type: multipart/mixed;boundary=foobar 987 Content-Length: [length] 989 --foobar 990 Content-Type: application/SDP 991 ... 992 m=audio 49170 RTP/AVP 0 993 a=rtpmap:0 PCMU/8000 994 a=label:96 995 a=sendonly 997 .... 998 --foobar 999 Content-Type: application/rs-metadata 1000 Content-Disposition: recording-session 1001 1002 1003 partial 1004 1006 1007 Carol 1008 1009 1010 1013 2013-12-16T23:41:07Z 1014 1015 1017 i1Pz3to5hGk8fuXl+PbwCw== 1018 i1Pz3to5hGk8fuXl+PbwCw== 1019 1020 1022 Assume Alice drops after some time from the conference. SRC 1023 generates a new snapshot showing Alice disassociating from the 1024 session 1026 mid call resume RE-INVITE SRC --------------> SRS 1028 INVITE sip:recorder@example.com SIP/2.0 1029 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 1030 From: ;tag=35e195d2-947d-4585-946f-09839247 1031 To: 1032 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1033 CSeq: 101 INVITE 1034 Max-Forwards: 70 1035 Require: siprec 1036 Accept: application/sdp, application/rs-metadata, 1037 application/rs-metadata-request 1038 Contact: ;+sip.src 1039 Content-Type: multipart/mixed;boundary=foobar 1040 Content-Length: [length] 1042 --foobar 1043 Content-Type: application/SDP 1044 ... 1045 m=audio 49170 RTP/AVP 0 1046 a=rtpmap:0 PCMU/8000 1047 a=label:96 1048 a=sendonly 1050 .... 1051 --foobar 1052 Content-Type: application/rs-metadata 1053 Content-Disposition: recording-session 1054 1055 1056 partial 1057 1060 2010-12-16T23:41:07Z 1061 1062 1064 3.3.4. Example 4: Call disconnect 1066 When a CS is disconnected, SRC sends BYE with a snapshot of metadata 1067 having session stop-time and participant dis-associate times. The 1068 snapshot looks same as listed in section 3.2.4 1070 3.4. Call scenarios with persistent RS between SRC and SRS 1072 The section shows the snapshots of metadata for the cases there a 1073 persistent RS exists between SRC and SRS. An SRC here may be SIP UA 1074 or a B2BUA or may be part of Conference model either as Focus or a 1075 participant in Conference. The SRS here could be a SIP UA or an 1076 entity part of MEDIACTRL architecture. Except disconnect case, the 1077 snapshot remains same as one of the examples mentioned in previous 1078 sections. 1080 3.4.1. Example 1: Metadata snapshot during CS disconnect with 1081 persistent RS between SRC and SRS 1083 RE-INVITE sent from SRC -----------> SRS 1085 INVITE sip:2001@8.3.2.12:5060 SIP/2.0 1086 Via: SIP/2.0/UDP 8.3.2.34:5060;branch=z9hG4bK47c8eb30 1087 From: ;tag=35e195d2-947d-4585-946f-09839247 1088 To: 1089 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1090 CSeq: 101 INVITE 1091 Max-Forwards: 70 1092 Require: siprec 1093 Accept: application/rs-metadata, 1094 application/rs-metadata-request 1095 Contact: ;+sip.src 1096 Content-Type: multipart/mixed;boundary=foobar 1097 Content-Length: [length] 1099 --foobar 1100 Content-Type: application/rs-metadata 1102 1103 1104 Partial 1105 1106 2010-12-16T23:41:07Z 1107 1108 1111 2010-12-16T23:41:07Z 1112 1114 1117 2010-12-16T23:41:07Z 1118 1119 1121 3.5. Turrent-Case: Multiple CS into single RS with mixed stream 1123 In trading turret, audio mixing is done locally before forwarding to 1124 the recording server. Sender and receiver audio is mixed for each 1125 communication session. The audio from multiple communication 1126 sessions is also mixed, or multiplexed, in a single RTP session to 1127 the recording server. 1129 snapshot of metadata INVITE SRC --------------> SRS 1131 Content-Type: application/SDP 1132 ... 1133 m=audio 49170 RTP/AVP 0 1134 a=rtpmap:0 PCMU/8000 1135 a=label:96 1136 a=sendonly 1137 ... 1138 1139 1140 complete 1141 1142 2010-12-16T23:41:07Z 1143 1144 1145 7+OTCyoxTmqmqyA/1weDAg== 1146 2010-12-16T23:41:07Z 1147 1148 1149 7+OTCyoxTmqmqyA/1weDAg== 1150 2010-12-16T23:43:07Z 1151 1152 1154 1155 RamMohan R 1156 1157 1158 1161 2010-12-16T23:41:07Z 1162 1163 1165 UAAMm5GRQKSCMVvLyl4rFw== 1166 UAAMm5GRQKSCMVvLyl4rFw== 1167 1168 1170 1171 Parthasarathi R 1172 1173 1174 1178 2010-12-16T23:41:07Z 1179 1180 1183 2010-12-16T23:43:07Z 1184 1185 1187 UAAMm5GRQKSCMVvLyl4rFw== 1188 UAAMm5GRQKSCMVvLyl4rFw== 1189 1190 1192 1193 Paul 1194 1195 1196 1199 2010-12-16T23:43:07Z 1200 1201 1203 UAAMm5GRQKSCMVvLyl4rFw== 1204 UAAMm5GRQKSCMVvLyl4rFw== 1205 1207 1209 1210 1211 1213 4. Security Considerations 1215 There is no security consideration as it is informatioal callflow 1216 document. 1218 5. IANA Considerations 1220 This document has no IANA considerations 1222 6. Acknowledgement 1224 Thanks to Ofir Rath, Charles Eckel for their review comments. 1226 7. References 1228 7.1. Normative References 1230 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1231 A., Peterson, J., Sparks, R., Handley, M., and E. 1232 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1233 June 2002. 1235 7.2. Informative References 1237 [I-D.ietf-siprec-metadata] 1238 R, R., Ravindran, P., and P. Kyzivat, "Session Initiation 1239 Protocol (SIP) Recording Metadata", 1240 draft-ietf-siprec-metadata-13 (work in progress), 1241 November 2013. 1243 [I-D.ietf-siprec-architecture] 1244 Hutton, A., Portman, L., Jain, R., and K. Rehor, "An 1245 Architecture for Media Recording using the Session 1246 Initiation Protocol", draft-ietf-siprec-architecture-11 1247 (work in progress), December 2013. 1249 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 1250 Initiation Protocol (SIP) Event Package for Conference 1251 State", RFC 4575, August 2006. 1253 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1254 Session Initiation Protocol (SIP)", RFC 4353, 1255 February 2006. 1257 [RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media 1258 Control Channel Framework", RFC 6230, May 2011. 1260 Authors' Addresses 1262 Ram Mohan Ravindranath 1263 Cisco Systems, Inc. 1264 Cessna Business Park, 1265 Kadabeesanahalli Village, Varthur Hobli, 1266 Sarjapur-Marathahalli Outer Ring Road 1267 Bangalore, Karnataka 560103 1268 India 1270 Email: rmohanr@cisco.com 1272 Parthasarathi Ravindran 1273 Nokia Solutions and Networks 1274 Bangalore, Karnataka 1275 India 1277 Email: partha@parthasarathi.co.in 1279 Paul Kyzivat 1280 Huawei 1281 Hudson, MA 1282 USA 1284 Email: pkyzivat@alum.mit.edu