idnits 2.17.1 draft-ietf-siprec-callflows-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 : ---------------------------------------------------------------------------- ** 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 139 has weird spacing: '... update n-1) ...' -- The document date (July 13, 2013) is 3932 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-12 == Outdated reference: A later version (-12) exists of draft-ietf-siprec-architecture-08 Summary: 2 errors (**), 0 flaws (~~), 5 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: January 14, 2014 Nokia Siemens Networks 5 Paul. Kyzivat 6 Huawei 7 July 13, 2013 9 Session Initiation Protocol (SIP) Recording Call Flows 10 draft-ietf-siprec-callflows-01 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 January 14, 2014. 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. Call Scenarios with SRC recording streams with out 64 mixing . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.2.1. Example 1: Basic Call . . . . . . . . . . . . . . . . 5 66 3.2.2. Example 2: Hold/resume . . . . . . . . . . . . . . . . 7 67 3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) . 10 68 3.2.4. Example 4: Call disconnect . . . . . . . . . . . . . . 16 69 3.3. Call Scenarios with SRC recording streams by mixing . . . 18 70 3.3.1. Example 1: Basic call with SRC mixing streams . . . . 18 71 3.3.2. Example 2: Hold/resume with SRC recording by 72 mixing streams . . . . . . . . . . . . . . . . . . . . 20 73 3.3.3. Example 3: Metadata snapshot of joining/dropping 74 of a participant to a session . . . . . . . . . . . . 23 75 3.3.4. Example 4: Call disconnect . . . . . . . . . . . . . . 26 76 3.4. Call scenarios with persistent RS between SRC and SRS . . 26 77 3.4.1. Example 1: Metadata snapshot during CS disconnect 78 with persistent RS between SRC and SRS . . . . . . . . 26 79 3.5. Turrent-Case: Multiple CS into single RS with mixed 80 stream . . . . . . . . . . . . . . . . . . . . . . . . . . 27 81 4. Security Considerations . . . . . . . . . . . . . . . . . . . 29 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 83 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 30 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 85 7.1. Normative References . . . . . . . . . . . . . . . . . . . 30 86 7.2. Informative References . . . . . . . . . . . . . . . . . . 30 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 89 1. Overview 91 [I-D.ietf-siprec-metadata] document focuses on the Recording metadata 92 which describes the communication session. The document lists a few 93 examples and shows the snapshots of metadata sent from SRC to SRS. 94 For the sake of simplicity the entire SIP [RFC3261] messages are not 95 shown at various points, instead only a snippets of the SIP/SDP 96 messages and the XML snapshot of metadata is shown. 98 2. Terminology 100 The terms using in this defined are defined in 101 [I-D.ietf-siprec-metadata]. No new terms/definitions are introduced 102 in this document. 104 3. Metadata XML schema Instances 106 This section describes the metadata model XML instances for different 107 use cases of SIPREC. For the sake of simplicity the complete SIP/SDP 108 snippets are NOT shown here. 110 3.1. Sample Call flow 112 The following is a sample call flow that shows the SRC establishing a 113 recording session towards the SRS. The SRC in this example could be 114 part of any one of the architectures described in section 3 of 115 [I-D.ietf-siprec-architecture]. 117 SRC SRS 118 | | 119 |(1) INVITE (metadata snapshot) F1 | 120 |---------------------------------------------------->| 121 | 200 OK | 122 |<----------------------------------------------------| 123 |(3) ACK | 124 |---------------------------------------------------->| 125 |(4) RTP | 126 |====================================================>| 127 |====================================================>| 128 |====================================================>| 129 |====================================================>| 130 |(5) UPDATE/RE-INVITE (metadata update 1) F2 | 131 |---------------------------------------------------->| 132 | 200 OK | 133 |<----------------------------------------------------| 134 | ................................................... | 135 | ................................................... | 136 | | 137 |====================================================>| 138 |====================================================>| 139 |(7) UPDATE/RE-INVITE (metadata update n-1) Fn-1 | 140 |---------------------------------------------------->| 141 | 200 OK | 142 |<----------------------------------------------------| 144 For the sake of simplicity, ACKs to RE-INVITES and BYEs are not 145 shown. The subsequent sections describes the snapshot of metadata 146 sent from SRC to SRS for each of the above transactions (F1 ... 147 Fn-1). There may be multiple UPDATES/RE-INVITES mid call to 148 indicates snapshots of different CS changes. Depending on the 149 architecture described in section 3 of [I-D.ietf-siprec-architecture] 150 an SRC may be a endpoint or B2BUA or as part of MEDIACTRL or 151 Conference Focus. The subsequent sections in this document tries to 152 list some example metadata snapshots for three major categories. 154 o SRC recording streams unmixed to SRS. This includes cases where 155 SRC is SIP UA or B2BUA. 156 o SRC recording mixed streams to SRS. This includes cases where SRC 157 is part of SIP conference model explained in [RFC4353] 158 o SRC having a persistent RS with SRS 159 o Special flows like Turrent flows 161 Note that only those examples for which metadata changes are listed 162 in each category. For some of the call flows the snapshots may be 163 same (like in case of endpoint or B2BUA acting as SRC) and the same 164 is mentioned in the text preceding the example. 166 3.2. Call Scenarios with SRC recording streams with out mixing 168 The section covers the models mentioned in the architecture document 169 in section 3 of [I-D.ietf-siprec-architecture] where an SRC may be a 170 SIP-UA or B2BUA. The SRS here could be a SIP-UA or an entity part of 171 MEDIACTRL architecture described in [RFC6230]. 173 3.2.1. Example 1: Basic Call 175 Basic call between two Participants Alice and Bob who are part of one 176 CS. In this use case each participant sends two Media Streams. 177 Media Streams sent by each participant are received all other 178 participants in this use-case. Below is the initial snapshot sent by 179 SRC in the INVITE to SRS that has complete metadata. For the sake of 180 simplicity only snippets of SIP/SDP are shown. The SRCs records the 181 streams of each participant to SRS with out mixing in this example. 183 F1 INVITE SRC --------------> SRS 185 INVITE sip:recorder@example.com SIP/2.0 186 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 187 From: ;tag=35e195d2-947d-4585-946f-09839247 188 To: 189 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 190 CSeq: 101 INVITE 191 Max-Forwards: 70 192 Require: siprec 193 Accept: application/sdp, application/rs-metadata, 194 application/rs-metadata-request 195 Contact: ;+sip.src 196 Content-Type: multipart/mixed;boundary=foobar 197 Content-Length: [length] 199 --foobar 200 Content-Type: application/SDP 201 ... 202 m=audio 49170 RTP/AVP 0 203 a=rtpmap:0 PCMU/8000 204 a=label:96 205 a=sendonly 206 ... 207 m=video 49174 RTP/AVPF 96 208 a=rtpmap:96 H.264/90000 209 a=label:97 210 a=sendonly 211 ... 212 m=audio 51372 RTP/AVP 0 213 a=rtpmap:0 PCMU/8000 214 a=label:98 215 a=sendonly 216 ... 217 m=video 49176 RTP/AVPF 96 218 a=rtpmap:96 H.264/90000 219 a=label:99 220 a=sendonly 221 .... 222 --foobar 223 Content-Type: application/rs-metadata 224 Content-Disposition: recording-session 225 226 227 complete 228 229 2010-12-16T23:41:07Z 230 231 233 234 Alice 235 236 237 240 2010-12-16T23:41:07Z 241 242 244 i1Pz3to5hGk8fuXl+PbwCw== 245 UAAMm5GRQKSCMVvLyl4rFw== 246 8zc6e0lYTlWIINA6GR+3ag== 247 EiXGlc+4TruqqoDaNE76ag== 248 249 251 252 Bob 253 254 255 258 2010-12-16T23:41:07Z 259 260 262 8zc6e0lYTlWIINA6GR+3ag== 263 EiXGlc+4TruqqoDaNE76ag== 264 UAAMm5GRQKSCMVvLyl4rFw== 265 i1Pz3to5hGk8fuXl+PbwCw== 266 267 269 270 271 273 274 275 277 278 279 281 282 283 285 3.2.2. Example 2: Hold/resume 287 Assume a call between two Participants Alice and Bob is established 288 and a RS is created for recording as in example1. This is the 289 continuation of above use-case. One of the participants Bob puts 290 Alice hold and then resumes as part of the same session. The send 291 and recv XML elements of a participant is used to indicate whether a 292 participant is sending not sending a particular media stream whose 293 properties are represented by stream element. The metadata snapshot 294 looks as below 296 During hold 298 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 665 666 669 2010-12-16T23:32:03Z 670 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 .... 808 --foobar 809 Content-Type: application/rs-metadata 810 Content-Disposition: recording-session 811 812 813 complete 814 815 2010-12-16T23:41:07Z 816 817 819 820 Alice 821 822 823 826 2010-12-16T23:41:07Z 827 828 830 i1Pz3to5hGk8fuXl+PbwCw== 831 i1Pz3to5hGk8fuXl+PbwCw== 832 833 835 836 Bob 837 838 839 842 2010-12-16T23:41:07Z 843 844 846 i1Pz3to5hGk8fuXl+PbwCw== 847 i1Pz3to5hGk8fuXl+PbwCw== 848 849 851 852 853 855 3.3.2. Example 2: Hold/resume with SRC recording by mixing streams 857 Assume a call between two Participants Alice and Bob is established 858 and a RS is created for recording as in example 5. This is the 859 continuation of above use-case. One of the participants Bob puts 860 Alice hold and then resumes as part of the same session. The send 861 and recv XML elements of a participant is used to indicate whether a 862 participant is sending not sending a particular media stream whose 863 properties are represented by stream element. The metadata snapshot 864 looks as below: 866 During hold 867 mid call hold RE-INVITE SRC --------------> SRS 869 INVITE sip:recorder@example.com SIP/2.0 870 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 871 From: ;tag=35e195d2-947d-4585-946f-09839247 872 To: 873 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 874 CSeq: 101 INVITE 875 Max-Forwards: 70 876 Require: siprec 877 Accept: application/sdp, application/rs-metadata, 878 application/rs-metadata-request 879 Contact: ;+sip.src 880 Content-Type: multipart/mixed;boundary=foobar 881 Content-Length: [length] 883 --foobar 884 Content-Type: application/SDP 885 ... 886 m=audio 49170 RTP/AVP 0 887 a=rtpmap:0 PCMU/8000 888 a=label:96 889 a=sendonly 891 .... 892 --foobar 893 Content-Type: application/rs-metadata 894 Content-Disposition: recording-session 895 896 897 partial 898 900 i1Pz3to5hGk8fuXl+PbwCw== 901 902 904 i1Pz3to5hGk8fuXl+PbwCw== 905 906 908 909 910 912 During resume a snapshot shown below will be sent from SRC to SRS 913 mid call resume RE-INVITE SRC --------------> SRS 915 INVITE sip:recorder@example.com SIP/2.0 916 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 917 From: ;tag=35e195d2-947d-4585-946f-09839247 918 To: 919 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 920 CSeq: 101 INVITE 921 Max-Forwards: 70 922 Require: siprec 923 Accept: application/sdp, application/rs-metadata, 924 application/rs-metadata-request 925 Contact: ;+sip.src 926 Content-Type: multipart/mixed;boundary=foobar 927 Content-Length: [length] 929 --foobar 930 Content-Type: application/SDP 931 ... 932 m=audio 49170 RTP/AVP 0 933 a=rtpmap:0 PCMU/8000 934 a=label:96 935 a=sendonly 937 .... 938 --foobar 939 Content-Type: application/rs-metadata 940 Content-Disposition: recording-session 941 942 943 partial 944 946 i1Pz3to5hGk8fuXl+PbwCw== 947 i1Pz3to5hGk8fuXl+PbwCw== 948 949 951 i1Pz3to5hGk8fuXl+PbwCw== 952 i1Pz3to5hGk8fuXl+PbwCw== 953 954 956 957 958 960 3.3.3. Example 3: Metadata snapshot of joining/dropping of a 961 participant to a session 963 In a conference model, participants can join and drop a session any 964 time during the session. The below shows a snapshot sent from SRC to 965 SRC in these case. Note the SRC here can be a focus or a participant 966 in the conference. In case where the SRC is a participant it may 967 learn the information required for metadata by subscribing to 968 conference event package [RFC4575]. Assume Alice and Bob were in the 969 conference and a third participant Carol joins, then SRC sends the 970 below snapshot with the indication of new participant. 972 mid call resume RE-INVITE SRC --------------> SRS 974 INVITE sip:recorder@example.com SIP/2.0 975 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 976 From: ;tag=35e195d2-947d-4585-946f-09839247 977 To: 978 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 979 CSeq: 101 INVITE 980 Max-Forwards: 70 981 Require: siprec 982 Accept: application/sdp, application/rs-metadata, 983 application/rs-metadata-request 984 Contact: ;+sip.src 985 Content-Type: multipart/mixed;boundary=foobar 986 Content-Length: [length] 988 --foobar 989 Content-Type: application/SDP 990 ... 991 m=audio 49170 RTP/AVP 0 992 a=rtpmap:0 PCMU/8000 993 a=label:96 994 a=sendonly 996 .... 997 --foobar 998 Content-Type: application/rs-metadata 999 Content-Disposition: recording-session 1000 1001 1002 partial 1003 1005 1006 Carol 1007 1008 1009 1012 2013-12-16T23:41:07Z 1013 1014 1016 i1Pz3to5hGk8fuXl+PbwCw== 1017 i1Pz3to5hGk8fuXl+PbwCw== 1018 1019 1021 Assume Alice drops after some time from the conference. SRC 1022 generates a new snapshot showing Alice disassociating from the 1023 session 1025 mid call resume RE-INVITE SRC --------------> SRS 1027 INVITE sip:recorder@example.com SIP/2.0 1028 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 1029 From: ;tag=35e195d2-947d-4585-946f-09839247 1030 To: 1031 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1032 CSeq: 101 INVITE 1033 Max-Forwards: 70 1034 Require: siprec 1035 Accept: application/sdp, application/rs-metadata, 1036 application/rs-metadata-request 1037 Contact: ;+sip.src 1038 Content-Type: multipart/mixed;boundary=foobar 1039 Content-Length: [length] 1041 --foobar 1042 Content-Type: application/SDP 1043 ... 1044 m=audio 49170 RTP/AVP 0 1045 a=rtpmap:0 PCMU/8000 1046 a=label:96 1047 a=sendonly 1049 .... 1050 --foobar 1051 Content-Type: application/rs-metadata 1052 Content-Disposition: recording-session 1053 1054 1055 partial 1056 1059 2010-12-16T23:41:07Z 1060 1061 1063 3.3.4. Example 4: Call disconnect 1065 When a CS is disconnected, SRC sends BYE with a snapshot of metadata 1066 having session stop-time and participant dis-associate times. The 1067 snapshot looks same as listed in section 3.2.4 1069 3.4. Call scenarios with persistent RS between SRC and SRS 1071 The section shows the snapshots of metadata for the cases there a 1072 persistent RS exists between SRC and SRS. An SRC here may be SIP UA 1073 or a B2BUA or may be part of Conference model either as Focus or a 1074 participant in Conference. The SRS here could be a SIP UA or an 1075 entity part of MEDIACTRL architecture. Except disconnect case, the 1076 snapshot remains same as one of the examples mentioned in previous 1077 sections. 1079 3.4.1. Example 1: Metadata snapshot during CS disconnect with 1080 persistent RS between SRC and SRS 1082 RE-INVITE sent from SRC -----------> SRS 1084 INVITE sip:2001@8.3.2.12:5060 SIP/2.0 1085 Via: SIP/2.0/UDP 8.3.2.34:5060;branch=z9hG4bK47c8eb30 1086 From: ;tag=35e195d2-947d-4585-946f-09839247 1087 To: 1088 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1089 CSeq: 101 INVITE 1090 Max-Forwards: 70 1091 Require: siprec 1092 Accept: application/rs-metadata, 1093 application/rs-metadata-request 1094 Contact: ;+sip.src 1095 Content-Type: multipart/mixed;boundary=foobar 1096 Content-Length: [length] 1098 --foobar 1099 Content-Type: application/rs-metadata 1101 1102 1103 Partial 1104 1105 2010-12-16T23:41:07Z 1106 1107 1110 2010-12-16T23:41:07Z 1111 1113 1116 2010-12-16T23:41:07Z 1117 1118 1120 3.5. Turrent-Case: Multiple CS into single RS with mixed stream 1122 In trading turret, audio mixing is done locally before forwarding to 1123 the recording server. Sender and receiver audio is mixed for each 1124 communication session. The audio from multiple communication 1125 sessions is also mixed, or multiplexed, in a single RTP session to 1126 the recording server. 1128 snapshot of metadata INVITE SRC --------------> SRS 1130 Content-Type: application/SDP 1131 ... 1132 m=audio 49170 RTP/AVP 0 1133 a=rtpmap:0 PCMU/8000 1134 a=label:96 1135 a=sendonly 1136 ... 1137 1138 1139 complete 1140 1141 2010-12-16T23:41:07Z 1142 1143 1144 7+OTCyoxTmqmqyA/1weDAg== 1145 2010-12-16T23:41:07Z 1146 1147 1148 7+OTCyoxTmqmqyA/1weDAg== 1149 2010-12-16T23:43:07Z 1150 1151 1153 1154 RamMohan R 1155 1156 1157 1160 2010-12-16T23:41:07Z 1161 1162 1164 UAAMm5GRQKSCMVvLyl4rFw== 1165 UAAMm5GRQKSCMVvLyl4rFw== 1166 1167 1169 1170 Parthasarathi R 1171 1172 1173 1177 2010-12-16T23:41:07Z 1178 1179 1182 2010-12-16T23:43:07Z 1183 1184 1186 UAAMm5GRQKSCMVvLyl4rFw== 1187 UAAMm5GRQKSCMVvLyl4rFw== 1188 1189 1191 1192 Paul 1193 1194 1195 1198 2010-12-16T23:43:07Z 1199 1200 1202 UAAMm5GRQKSCMVvLyl4rFw== 1203 UAAMm5GRQKSCMVvLyl4rFw== 1204 1206 1208 1209 1210 1212 4. Security Considerations 1214 There is no security consideration as it is informatioal callflow 1215 document. 1217 5. IANA Considerations 1219 This document has no IANA considerations 1221 6. Acknowledgement 1223 Thanks to Ofir Rath, Charles Eckel for their review comments. 1225 7. References 1227 7.1. Normative References 1229 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1230 A., Peterson, J., Sparks, R., Handley, M., and E. 1231 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1232 June 2002. 1234 7.2. Informative References 1236 [I-D.ietf-siprec-metadata] 1237 R, R., Ravindran, P., and P. Kyzivat, "Session Initiation 1238 Protocol (SIP) Recording Metadata", 1239 draft-ietf-siprec-metadata-12 (work in progress), 1240 May 2013. 1242 [I-D.ietf-siprec-architecture] 1243 Hutton, A., Portman, L., Jain, R., and K. Rehor, "An 1244 Architecture for Media Recording using the Session 1245 Initiation Protocol", draft-ietf-siprec-architecture-08 1246 (work in progress), May 2013. 1248 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 1249 Initiation Protocol (SIP) Event Package for Conference 1250 State", RFC 4575, August 2006. 1252 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1253 Session Initiation Protocol (SIP)", RFC 4353, 1254 February 2006. 1256 [RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media 1257 Control Channel Framework", RFC 6230, May 2011. 1259 Authors' Addresses 1261 Ram Mohan Ravindranath 1262 Cisco Systems, Inc. 1263 Cessna Business Park, 1264 Kadabeesanahalli Village, Varthur Hobli, 1265 Sarjapur-Marathahalli Outer Ring Road 1266 Bangalore, Karnataka 560103 1267 India 1269 Email: rmohanr@cisco.com 1271 Parthasarathi Ravindran 1272 Nokia Siemens Networks 1273 Manyata Embassy business Park 1274 Bangalore, Karnataka 560045 1275 India 1277 Email: partha@parthasarathi.co.in 1279 Paul Kyzivat 1280 Huawei 1281 Hudson, MA 1282 USA 1284 Email: pkyzivat@alum.mit.edu