idnits 2.17.1 draft-ietf-siprec-callflows-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 15, 2016) is 2869 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6230' is defined on line 1405, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPREC Ram. Ravindranath 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Informational Parthasarathi. Ravindran 5 Expires: December 17, 2016 Nokia Networks 6 Paul. Kyzivat 7 Huawei 8 June 15, 2016 10 Session Initiation Protocol (SIP) Recording Call Flows 11 draft-ietf-siprec-callflows-07 13 Abstract 15 Session recording is a critical requirement in many communications 16 environments, such as call centers and financial trading 17 organizations. In some of these environments, all calls must be 18 recorded for regulatory, compliance, and consumer protection reasons. 19 The recording of a session is typically performed by sending a copy 20 of a media stream to a recording device. This document lists call 21 flows with metadata snapshots sent from a Session Recording 22 Client(SRC) to a Session Recording Server(SRS). 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 17, 2016. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Metadata XML Instances . . . . . . . . . . . . . . . . . . . 3 61 3.1. Sample Call flow . . . . . . . . . . . . . . . . . . . . 3 62 3.2. Call Scenarios with SRC recording streams without mixing 5 63 3.2.1. Example 1: Basic Call . . . . . . . . . . . . . . . . 5 64 3.2.2. Example 2: Hold/resume . . . . . . . . . . . . . . . 8 65 3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) . 11 66 3.2.4. Example 4: Call disconnect . . . . . . . . . . . . . 18 67 3.3. Call Scenarios with SRC recording streams by mixing . . . 19 68 3.3.1. Example 1: Basic call with SRC mixing streams . . . . 19 69 3.3.2. Example 2: Hold/resume with SRC recording by mixing 70 streams . . . . . . . . . . . . . . . . . . . . . . . 21 71 3.3.3. Example 3: Metadata snapshot of joining/dropping of a 72 participant to a session . . . . . . . . . . . . . . 24 73 3.3.4. Example 4: Call disconnect . . . . . . . . . . . . . 27 74 3.4. Call scenarios with persistent RS between SRC and SRS . . 27 75 3.4.1. Example 1: Metadata snapshot during CS disconnect 76 with persistent RS between SRC and SRS . . . . . . . 27 77 3.5. Turret-Case: Multiple CS into single RS with mixed stream 28 78 4. Security Considerations . . . . . . . . . . . . . . . . . . . 31 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 80 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 31 81 7. Informative References . . . . . . . . . . . . . . . . . . . 32 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 84 1. Overview 86 Session recording is a critical requirement in many communications 87 environments, such as call centers and financial trading 88 organizations. In some of these environments, all calls must be 89 recorded for regulatory, compliance, and consumer protection reasons. 90 The recording of a session is typically performed by sending a copy 91 of a media stream to a recording device. [RFC7865] focuses on the 92 recording metadata which describes the Communication Session(CS). 93 This document lists few examples and shows the snapshots of metadata 94 sent from a Session Recording Client(SRC) to Session Recording Server 95 (SRS). For the sake of simplicity the entire Session Initiation 96 Protocol (SIP) [RFC3261] messages are not shown, instead only 97 snippets of the SIP and Session Description Protocol (SDP)[RFC4566] 98 messages and the XML snapshot of metadata is shown. 100 2. Terminology 102 The terms using in this document are defined in [RFC7865] and 103 [RFC6341]. No new definitions are introduced in this document. 105 3. Metadata XML Instances 107 The following sub-sections has examples showing the metadata snapshot 108 sent from SRC to SRS. In all these use-cases, the SRC is a B2BUA. 110 3.1. Sample Call flow 112 The following is a sample call flow that shows the SRC establishing a 113 Recording Session(RS) towards the SRS. The SRC in this example could 114 be part of any one of the architectures described in section 3 of 115 [RFC7245]. 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 describe the snapshot of metadata 146 sent from SRC to SRS for each of the above transactions (F1 ... Fn- 147 1). There may be multiple UPDATES/RE-INVITES mid call to indicate 148 snapshots of different CS changes. Depending on the architecture 149 described in section 3 of [RFC7245] an SRC may be a endpoint or B2BUA 150 or as part of MEDIACTRL or Conference focus. The subsequent sections 151 in this document try to list some example metadata snapshots for 152 three major categories. 154 o SRC recording streams unmixed to SRS. This includes cases where 155 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]. 160 o SRC having a persistent RS with SRS. 162 o Special flows like Turret flows. 164 Note that only those examples for which metadata changes are listed 165 in each category. For some of the call flows the snapshots may be 166 same (like in case of endpoint or B2BUA acting as SRC) and the same 167 is mentioned in the text preceding the example. 169 3.2. Call Scenarios with SRC recording streams without mixing 171 This section describes example flows where SRC can be a SIP-UA or 172 B2BUA as described in section 3 of [RFC7245]. The SRS here can be a 173 SIP-UA or an entity part of MEDIACTRL architecture described in 174 section 3 of [RFC7245]. 176 3.2.1. Example 1: Basic Call 178 Basic call between two participants Alice and Bob who are part of the 179 same CS. In this use case each participant sends two media 180 streams(audio and video). Media streams sent by each participant are 181 received by the other participant in this use-case. In this example 182 the SRC is a B2BUA in the path between Alice and Bob as described in 183 section 3.1.1 of [RFC7245]. Below is the initial snapshot sent by 184 SRC in the INVITE to SRS. This snapshot has the complete metadata. 185 For the sake of simplicity only snippets of SIP/SDP are shown. In 186 this example the SRCs records the streams of each participant to SRS 187 without mixing. 189 F1 INVITE SRC --------------> SRS 191 INVITE sip:recorder@example.com SIP/2.0 192 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 193 From: ;tag=35e195d2-947d-4585-946f-09839247 194 To: 195 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 196 Session-ID: ab30317f1a784dc48ff824d0d3715d86 197 ;remote=00000000000000000000000000000000 198 CSeq: 101 INVITE 199 Max-Forwards: 70 200 Require: siprec 201 Accept: application/sdp, application/rs-metadata, 202 application/rs-metadata-request 203 Contact: ;+sip.src 204 Content-Type: multipart/mixed;boundary=foobar 205 Content-Length: [length] 207 --foobar 208 Content-Type: application/SDP 209 ... 211 m=audio 49170 RTP/AVP 0 212 a=rtpmap:0 PCMU/8000 213 a=label:96 214 a=sendonly 215 ... 216 m=video 49174 RTP/AVPF 96 217 a=rtpmap:96 H.264/90000 218 a=label:97 219 a=sendonly 220 ... 221 m=audio 51372 RTP/AVP 0 222 a=rtpmap:0 PCMU/8000 223 a=label:98 224 a=sendonly 225 ... 226 m=video 49176 RTP/AVPF 96 227 a=rtpmap:96 H.264/90000 228 a=label:99 229 a=sendonly 230 .... 231 --foobar 232 Content-Type: application/rs-metadata 233 Content-Disposition: recording-session 235 236 237 complete 238 239 2010-12-16T23:41:07Z 240 241 242 sip:alice@atlanta.com 243 244 245 FOO! 246 bar 247 248 249 250 ab30317f1a784dc48ff824d0d3715d86; 251 remote=47755a9de7794ba387653f2099600ef2 252 7+OTCyoxTmqmqyA/1weDAg== 253 254 255 256 FOO! 257 bar 258 260 261 263 264 Alice 265 266 267 268 FOO! 269 bar 270 271 272 274 275 Bob 276 277 278 279 FOO! 280 bar 281 282 283 285 286 287 289 290 291 293 294 295 297 298 299 300 2010-12-16T23:41:07Z 301 302 305 2010-12-16T23:41:07Z 306 307 310 2010-12-16T23:41:07Z 311 312 314 i1Pz3to5hGk8fuXl+PbwCw== 315 UAAMm5GRQKSCMVvLyl4rFw== 316 8zc6e0lYTlWIINA6GR+3ag== 317 EiXGlc+4TruqqoDaNE76ag== 318 319 321 8zc6e0lYTlWIINA6GR+3ag== 322 EiXGlc+4TruqqoDaNE76ag== 323 UAAMm5GRQKSCMVvLyl4rFw== 324 i1Pz3to5hGk8fuXl+PbwCw== 325 326 328 3.2.2. Example 2: Hold/resume 330 A call between two participants Alice and Bob is established and a RS 331 is created for recording as in example 1. One of the participants 332 Bob puts Alice hold and then resumes as part of the same CS. The 333 'send' and 'recv' XML elements of a 'participantstreamassoc' XML 334 element is used to indicate whether a participant is contributing to 335 a media stream or not. SRC sends a snapshot with only the changed 336 XML elements. 338 During hold 340 F2 mid call RE-INVITE SRC-------------------->SRS 342 INVITE sip:recorder@example.com SIP/2.0 343 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 344 From: ;tag=35e195d2-947d-4585-946f-09839247 345 To: 346 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 347 Session-ID: ab30317f1a784dc48ff824d0d3715d86 348 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 349 CSeq: 101 INVITE 350 Max-Forwards: 70 351 Require: siprec 352 Accept: application/sdp, application/rs-metadata, 353 application/rs-metadata-request 354 Contact: ;+sip.src 355 Content-Type: multipart/mixed;boundary=foobar 356 Content-Length: [length] 358 --foobar 359 Content-Type: application/SDP 360 ... 361 m=audio 49170 RTP/AVP 0 362 a=rtpmap:0 PCMU/8000 363 a=label:96 364 a=sendonly 365 ... 366 m=video 49174 RTP/AVPF 96 367 a=rtpmap:96 H.264/90000 368 a=label:97 369 a=sendonly 370 ... 371 m=audio 51372 RTP/AVP 0 372 a=rtpmap:0 PCMU/8000 373 a=label:98 374 a=sendonly 375 ... 376 m=video 49176 RTP/AVPF 96 377 a=rtpmap:96 H.264/90000 378 a=label:99 379 a=sendonly 380 .... 382 --foobar 383 Content-Type: application/rs-metadata 384 Content-Disposition: recording-session 386 387 388 partial 389 391 8zc6e0lYTlWIINA6GR+3ag== 392 EiXGlc+4TruqqoDaNE76ag== 393 394 396 8zc6e0lYTlWIINA6GR+3ag== 397 EiXGlc+4TruqqoDaNE76ag== 398 399 401 In the above snippet, Alice with participant_id 402 srfBElmCRp2QB23b7Mpk0w== only receives media streams and does not 403 send any media. The same is indicated by the absence of 'send' XML 404 element. Bob(participant_id zSfPoSvdSDCmU3A3TRDxAw==) on the other 405 hand would be sending media but does not receive any media from Alice 406 and so 'recv' XML element is absent in this instance. 408 During resume 410 The snapshot now has 'send' and 'recv' XML elements for both Alice 411 and Bob indicating that both are receiving and sending media. 413 F3 mid call RE-INVITE SRC-------------------->SRS 415 INVITE sip:recorder@example.com SIP/2.0 416 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 417 From: ;tag=35e195d2-947d-4585-946f-09839247 418 To: 419 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 420 Session-ID: ab30317f1a784dc48ff824d0d3715d86 421 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 422 CSeq: 101 INVITE 423 Max-Forwards: 70 424 Require: siprec 425 Accept: application/sdp, application/rs-metadata, 426 application/rs-metadata-request 427 Contact: ;+sip.src 428 Content-Type: multipart/mixed;boundary=foobar 429 Content-Length: [length] 431 --foobar 432 Content-Type: application/SDP 433 ... 434 m=audio 49170 RTP/AVP 0 435 a=rtpmap:0 PCMU/8000 436 a=label:96 437 a=sendonly 438 ... 439 m=video 49174 RTP/AVPF 96 440 a=rtpmap:96 H.264/90000 441 a=label:97 442 a=sendonly 443 ... 444 m=audio 51372 RTP/AVP 0 445 a=rtpmap:0 PCMU/8000 446 a=label:98 447 a=sendonly 448 ... 449 m=video 49176 RTP/AVPF 96 450 a=rtpmap:96 H.264/90000 451 a=label:99 452 a=sendonly 453 .... 454 --foobar 455 Content-Type: application/rs-metadata 456 Content-Disposition: recording-session 458 459 460 partial 461 463 i1Pz3to5hGk8fuXl+PbwCw== 464 UAAMm5GRQKSCMVvLyl4rFw== 465 8zc6e0lYTlWIINA6GR+3ag== 466 EiXGlc+4TruqqoDaNE76ag== 467 468 470 8zc6e0lYTlWIINA6GR+3ag== 471 EiXGlc+4TruqqoDaNE76ag== 472 i1Pz3to5hGk8fuXl+PbwCw== 473 UAAMm5GRQKSCMVvLyl4rFw== 474 475 477 3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) 479 Basic call between two Participants Alice and Bob is connected and 480 SRC(B2BUA acting as SRC as per section 3.1.1 of [RFC7245]) has sent a 481 snapshot as described in example 1. Transfer is initiated by one of 482 the participants(Alice). After the transfer is completed, SRC sends 483 a snapshot of the participant changes to SRS. In this transfer 484 scenario, Alice drops out after transfer is completed and Bob and 485 Carol gets connected and recording of media between Bob and Carol is 486 done by SRC. There are two flows that can happen here as described 487 below. 489 Transfer with in the same session - (.e.g. RE-INVITE based 490 transfer). Participant Alice drops out and Carol is added to the 491 same session. No change to session/group element. A 492 'participantsessassoc' XML element indicating that Alice has 493 disassociated from the CS will be present in the snapshot. A new 494 'participant' XML element representing Carol with mapping to the same 495 RS SDP stream used for mapping earlier Alice's stream is sent in the 496 snapshot. A new 'sipSessionID' XML element that has UUID tuples 497 which corresponds to Bob and Carol is sent in the snapshot from SRC 498 to SRS. Note that one half of the session ID that corresponds to Bob 499 remains same. 501 mid call RE-INVITE SRC-------------------->SRS 503 INVITE sip:recorder@example.com SIP/2.0 504 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 505 From: ;tag=35e195d2-947d-4585-946f-09839247 506 To: 507 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 508 Session-ID: ab30317f1a784dc48ff824d0d3715d86 509 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 510 CSeq: 101 INVITE 511 Max-Forwards: 70 512 Require: siprec 513 Accept: application/sdp, application/rs-metadata, 514 application/rs-metadata-request 515 Contact: ;+sip.src 516 Content-Type: multipart/mixed;boundary=foobar 517 Content-Length: [length] 519 --foobar 520 Content-Type: application/SDP 521 ... 522 m=audio 49180 RTP/AVP 0 523 a=rtpmap:0 PCMU/8000 524 a=label:96 525 a=sendonly 526 ... 527 m=video 49182 RTP/AVPF 96 528 a=rtpmap:96 H.264/90000 529 a=label:97 530 a=sendonly 531 ... 532 m=audio 51374 RTP/AVP 0 533 a=rtpmap:0 PCMU/8000 534 a=label:98 535 a=sendonly 536 ... 537 m=video 49178 RTP/AVPF 96 538 a=rtpmap:96 H.264/90000 539 a=label:99 540 a=sendonly 541 .... 542 --foobar 543 Content-Type: application/rs-metadata 544 Content-Disposition: recording-session 546 547 548 partial 549 550 3363127f0d084c10876dddd4f8e5eeb9 551 ;remote=2272bb7e70fe41dba0025ae9a26d54cf 552 553 555 556 Carol 557 558 559 562 2013-12-16T23:41:07Z 563 564 567 2013-12-16T23:41:07Z 568 569 571 8zc6e0lYTlWIINA6GR+3ag== 572 EiXGlc+4TruqqoDaNE76ag== 573 60JAJm9UTvik0Ltlih/Gzw== 574 AcR5FUd3Edi8cACQJy/3JQ== 575 576 578 60JAJm9UTvik0Ltlih/Gzw== 579 AcR5FUd3Edi8cACQJy/3JQ== 580 8zc6e0lYTlWIINA6GR+3ag== 581 EiXGlc+4TruqqoDaNE76ag== 582 2013-12-16T23:42:07Z 583 584 586 Transfer with new session - (.e.g. REFER based transfer). In this 587 case a new session (CS) is created and shall be part of same CS-group 588 (done by SRC). 590 SRC first sends an optional snapshot indicating disassociation of 591 participant from the old CS. Please note this is an optional 592 message. An SRC may choose to just send an INVITE with a new 593 'session' XML element to implicitly indicate that the participants 594 are now part of a different CS without sending disassociation from 595 the old CS. The SRC in this example uses the same RS. In case the 596 SRC wishes to use a new RS, it will tear down the current RS using 597 normal SIP procedures (BYE) with metadata as in example 4. 599 mid call RE-INVITE SRC-------------------->SRS 601 INVITE sip:recorder@example.com SIP/2.0 602 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 603 From: ;tag=35e195d2-947d-4585-946f-09839247 604 To: 605 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 606 Session-ID: ab30317f1a784dc48ff824d0d3715d86 607 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 608 CSeq: 101 INVITE 609 Max-Forwards: 70 610 Require: siprec 611 Accept: application/sdp, application/rs-metadata, 612 application/rs-metadata-request 613 Contact: ;+sip.src 614 Content-Type: multipart/mixed;boundary=foobar 615 Content-Length: [length] 617 --foobar 618 Content-Type: application/SDP 619 ... 620 m=audio 49180 RTP/AVP 0 621 a=rtpmap:0 PCMU/8000 622 a=label:96 623 a=sendonly 624 ... 625 m=video 49182 RTP/AVPF 96 626 a=rtpmap:96 H.264/90000 627 a=label:97 628 a=sendonly 629 ... 630 m=audio 51374 RTP/AVP 0 631 a=rtpmap:0 PCMU/8000 632 a=label:98 633 a=sendonly 634 ... 635 m=video 49178 RTP/AVPF 96 636 a=rtpmap:96 H.264/90000 637 a=label:99 638 a=sendonly 639 .... 641 --foobar 642 Content-Type: application/rs-metadata 643 Content-Disposition: recording-session 645 646 647 partial 648 649 2010-12-16T23:41:07Z 650 651 654 2010-12-16T23:41:07Z 655 656 659 2010-12-16T23:41:07Z 660 661 663 In the above snapshot, the 'participantsessionassoc' XML element is 664 optional as indicating 'session' XML element with a 'stop-time' 665 implicitly means that all the participants associated with that 666 session have been disassociated. 668 SRC sends another snapshot to indicate the participant change (due to 669 REFER) and new session information after transfer. In this example 670 it is assumed SRC uses the same RS to continue recording the call. 671 The 'sipSessionID' XML element in metadata snapshot now indicates Bob 672 and Carol in the (local, remote) uuid pair. 674 mid call RE-INVITE SRC-------------------->SRS 675 INVITE sip:recorder@example.com SIP/2.0 676 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 677 From: ;tag=35e195d2-947d-4585-946f-09839247 678 To: 679 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 680 Session-ID: ab30317f1a784dc48ff824d0d3715d86 681 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 682 CSeq: 101 INVITE 683 Max-Forwards: 70 684 Require: siprec 685 Accept: application/sdp, application/rs-metadata, 686 application/rs-metadata-request 687 Contact: ;+sip.src 688 Content-Type: multipart/mixed;boundary=foobar 689 Content-Length: [length] 691 --foobar 692 Content-Type: application/SDP 693 ... 694 m=audio 49180 RTP/AVP 0 695 a=rtpmap:0 PCMU/8000 696 a=label:96 697 a=sendonly 698 ... 699 m=video 49182 RTP/AVPF 96 700 a=rtpmap:96 H.264/90000 701 a=label:97 702 a=sendonly 703 ... 704 m=audio 51374 RTP/AVP 0 705 a=rtpmap:0 PCMU/8000 706 a=label:98 707 a=sendonly 708 ... 709 m=video 49178 RTP/AVPF 96 710 a=rtpmap:96 H.264/90000 711 a=label:99 712 a=sendonly 713 .... 715 --foobar 716 Content-Type: application/rs-metadata 718 719 720 complete 721 722 3363127f0d084c10876dddd4f8e5eeb9 723 ;remote=2272bb7e70fe41dba0025ae9a26d54cf 724 2010-12-16T23:41:07Z 725 726 728 729 730 732 733 734 736 737 738 740 741 742 744 745 746 748 749 750 753 2010-12-16T23:32:03Z 754 755 758 2010-12-16T23:41:07Z 759 760 762 8zc6e0lYTlWIINA6GR+3ag== 763 EiXGlc+4TruqqoDaNE76ag== 764 60JAJm9UTvik0Ltlih/Gzw== 765 AcR5FUd3Edi8cACQJy/3JQ== 766 767 769 60JAJm9UTvik0Ltlih/Gzw== 770 AcR5FUd3Edi8cACQJy/3JQ== 771 8zc6e0lYTlWIINA6GR+3ag== 772 EiXGlc+4TruqqoDaNE76ag== 773 774 776 3.2.4. Example 4: Call disconnect 778 This example shows a snapshot of metadata sent by the SRC to SRS when 779 a CS with Alice and Bob as participants is disconnected. 781 SRC SRS 782 | | 783 |(1) BYE (metadata snapshot) F1 | 784 |---------------------------------------------------->| 785 | 200 OK F2 | 786 |<----------------------------------------------------| 788 F1 BYE SRC -----------> SRS 790 BYE sip:2001@example.com SIP/2.0 791 Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30 792 From: ;tag=35e195d2-947d-4585-946f-09839247 793 To: 794 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 795 Session-ID: ab30317f1a784dc48ff824d0d3715d86 796 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 797 CSeq: 102 BYE 798 Max-Forwards: 70 799 Require: siprec 800 Accept: application/rs-metadata, 801 application/rs-metadata-request 802 Contact: ;+sip.src 803 Content-Type: multipart/mixed;boundary=foobar 804 Content-Length: [length] 806 --foobar 807 Content-Type: application/rs-metadata 809 810 811 partial 812 813 2010-12-16T23:41:07Z 815 816 819 2010-12-16T23:41:07Z 820 822 825 2010-12-16T23:41:07Z 826 827 829 3.3. Call Scenarios with SRC recording streams by mixing 831 The section describes a few example call flows where SRC may be part 832 of conference model either as focus or a participant in conference as 833 explained in section 3.1.5 of [RFC7245]. The SRS here can be a SIP 834 UA or an entity part of MEDIACTRL architecture. Note that the 835 disconnect case is not shown since the metadata snapshot will be same 836 as for a non-mixing case. 838 3.3.1. Example 1: Basic call with SRC mixing streams 840 Basic call between two participants Alice and Bob who are part of one 841 CS. In this use case each participant calls into a conference server 842 (say, an MCU) to attend one of many conferences hosted on or managed 843 by that server. Media streams sent by each participant are received 844 by all the other participants in the conference. Below is the 845 initial snapshot sent by SRC in the INVITE to SRS that has the 846 complete metadata. For the sake of simplicity only snippets of SIP/ 847 SDP are shown. The SRC records the streams of each participant to 848 SRS by mixing in this example. The SRC here is part of conference 849 model described in section 3 of [RFC7245] as a focus and does mixing. 850 The SRC here is not a participant by itself and hence it does not 851 contribute to media. 853 F1 INVITE SRC --------------> SRS 855 INVITE sip:recorder@example.com SIP/2.0 856 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 857 From: ;tag=35e195d2-947d-4585-946f-09839247 858 To: 859 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 860 Session-ID: a358d2b81a444a8c8fb05950cef331e7 861 ;remote=00000000000000000000000000000000 862 CSeq: 101 INVITE 863 Max-Forwards: 70 864 Require: siprec 865 Accept: application/sdp, application/rs-metadata, 866 application/rs-metadata-request 867 Contact: ;+sip.src 868 Content-Type: multipart/mixed;boundary=foobar 869 Content-Length: [length] 871 --foobar 872 Content-Type: application/SDP 873 ... 874 m=audio 49170 RTP/AVP 0 875 a=rtpmap:0 PCMU/8000 876 a=label:96 877 a=sendonly 879 .... 880 --foobar 881 Content-Type: application/rs-metadata 882 Content-Disposition: recording-session 884 885 886 complete 887 888 fa3b60f27e91441e84c55a9a0095f075 889 ;remote=a358d2b81a444a8c8fb05950cef331e7 890 ca718e1430474b5485a53aa5d0bea45e 891 ;remote=68caf509b9284b7ea45f84a049febf0a 892 2010-12-16T23:41:07Z 893 894 896 897 Alice 898 899 900 902 903 Bob 904 905 906 908 909 910 913 2010-12-16T23:41:07Z 914 915 918 2010-12-16T23:41:07Z 919 920 922 i1Pz3to5hGk8fuXl+PbwCw== 923 i1Pz3to5hGk8fuXl+PbwCw== 924 926 928 i1Pz3to5hGk8fuXl+PbwCw== 929 i1Pz3to5hGk8fuXl+PbwCw== 930 932 934 In the above example there are two participants Alice and Bob in the 935 conference. Among other things, SRC sends Session-ID in the metadata 936 snapshot. There are two Session-ID's here, one that corresponds to 937 the SIP session between Alice and conference focus and the other for 938 the SIP session between Bob and conference focus. In this use-case, 939 since Alice and Bob calls into the conference these Session-ID's are 940 different. 942 3.3.2. Example 2: Hold/resume with SRC recording by mixing streams 944 This is the continuation of Example 1: Basic call with SRC mixing 945 streams. Given a call between two participants Alice and Bob is 946 established and a RS is created for recording as in example 5. One 947 of the participants, Bob puts Alice hold and then resumes as part of 948 the same CS. The 'send' and 'recv' XML elements of a 'participant' 949 XML element are used to indicate whether a participant is 950 contributing or not to a media stream. The metadata snapshot looks 951 as below: 953 During hold 954 mid call hold RE-INVITE SRC --------------> SRS 956 INVITE sip:recorder@example.com SIP/2.0 957 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 958 From: ;tag=35e195d2-947d-4585-946f-09839247 959 To: 960 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 961 Session-ID: a358d2b81a444a8c8fb05950cef331e7 962 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 963 CSeq: 101 INVITE 964 Max-Forwards: 70 965 Require: siprec 966 Accept: application/sdp, application/rs-metadata, 967 application/rs-metadata-request 968 Contact: ;+sip.src 969 Content-Type: multipart/mixed;boundary=foobar 970 Content-Length: [length] 972 --foobar 973 Content-Type: application/SDP 974 ... 975 m=audio 49170 RTP/AVP 0 976 a=rtpmap:0 PCMU/8000 977 a=label:96 978 a=sendonly 980 .... 981 --foobar 982 Content-Type: application/rs-metadata 983 Content-Disposition: recording-session 985 986 987 partial 988 990 991 992 994 i1Pz3to5hGk8fuXl+PbwCw== 995 996 998 i1Pz3to5hGk8fuXl+PbwCw== 999 1000 1002 During resume a snapshot shown below will be sent from SRC to SRS. 1004 mid call resume RE-INVITE SRC --------------> SRS 1006 INVITE sip:recorder@example.com SIP/2.0 1007 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 1008 From: ;tag=35e195d2-947d-4585-946f-09839247 1009 To: 1010 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1011 Session-ID: a358d2b81a444a8c8fb05950cef331e7 1012 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 1013 CSeq: 101 INVITE 1014 Max-Forwards: 70 1015 Require: siprec 1016 Accept: application/sdp, application/rs-metadata, 1017 application/rs-metadata-request 1018 Contact: ;+sip.src 1019 Content-Type: multipart/mixed;boundary=foobar 1020 Content-Length: [length] 1022 --foobar 1023 Content-Type: application/SDP 1024 ... 1025 m=audio 49170 RTP/AVP 0 1026 a=rtpmap:0 PCMU/8000 1027 a=label:96 1028 a=sendonly 1030 .... 1031 --foobar 1032 Content-Type: application/rs-metadata 1033 Content-Disposition: recording-session 1035 1036 1037 partial 1038 1040 1041 1042 1044 i1Pz3to5hGk8fuXl+PbwCw== 1045 i1Pz3to5hGk8fuXl+PbwCw== 1046 1047 1050 i1Pz3to5hGk8fuXl+PbwCw== 1051 i1Pz3to5hGk8fuXl+PbwCw== 1052 1053 1055 3.3.3. Example 3: Metadata snapshot of joining/dropping of a 1056 participant to a session 1058 In a conference model, participants can join and drop a session any 1059 time during the session. Below is a snapshot sent from SRC to SRC in 1060 this case. Note the SRC here can be a focus or a participant in the 1061 conference. In the case where the SRC is a participant it may learn 1062 the information required for metadata by subscribing to conference 1063 event package [RFC4575]. Assume Alice and Bob were in the conference 1064 and a third participant Carol joins, then SRC sends the below 1065 snapshot with the indication of new participant. 1067 mid call resume RE-INVITE SRC --------------> SRS 1069 INVITE sip:recorder@example.com SIP/2.0 1070 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 1071 From: ;tag=35e195d2-947d-4585-946f-09839247 1072 To: 1073 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1074 Session-ID: a358d2b81a444a8c8fb05950cef331e7 1075 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 1076 CSeq: 101 INVITE 1077 Max-Forwards: 70 1078 Require: siprec 1079 Accept: application/sdp, application/rs-metadata, 1080 application/rs-metadata-request 1081 Contact: ;+sip.src 1082 Content-Type: multipart/mixed;boundary=foobar 1083 Content-Length: [length] 1085 --foobar 1086 Content-Type: application/SDP 1087 ... 1088 m=audio 49170 RTP/AVP 0 1089 a=rtpmap:0 PCMU/8000 1090 a=label:96 1091 a=sendonly 1093 .... 1094 --foobar 1095 Content-Type: application/rs-metadata 1096 Content-Disposition: recording-session 1098 1099 1100 partial 1101 1102 fa3b60f27e91441e84c55a9a0095f075 1103 ;remote=a358d2b81a444a8c8fb05950cef331e7 1104 ca718e1430474b5485a53aa5d0bea45e 1105 ;remote=68caf509b9284b7ea45f84a049febf0a 1106 497c0f13929643b4a16858e2a3885edc 1107 ;remote=0e8a82bedda74f57be4a4a4da54167c4 1108 1109 1111 1112 Carol 1113 1114 1115 1118 2013-12-16T23:41:07Z 1119 1120 1122 i1Pz3to5hGk8fuXl+PbwCw== 1123 i1Pz3to5hGk8fuXl+PbwCw== 1124 1125 1127 Given Alice drops after some time from the conference. SRC generates 1128 a new snapshot showing Alice disassociating from the session. 1130 mid call resume RE-INVITE SRC --------------> SRS 1132 INVITE sip:recorder@example.com SIP/2.0 1133 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 1134 From: ;tag=35e195d2-947d-4585-946f-09839247 1135 To: 1136 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1137 Session-ID: a358d2b81a444a8c8fb05950cef331e7 1138 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 1139 CSeq: 101 INVITE 1140 Max-Forwards: 70 1141 Require: siprec 1142 Accept: application/sdp, application/rs-metadata, 1143 application/rs-metadata-request 1144 Contact: ;+sip.src 1145 Content-Type: multipart/mixed;boundary=foobar 1146 Content-Length: [length] 1148 --foobar 1149 Content-Type: application/SDP 1150 ... 1151 m=audio 49170 RTP/AVP 0 1152 a=rtpmap:0 PCMU/8000 1153 a=label:96 1154 a=sendonly 1156 .... 1157 --foobar 1158 Content-Type: application/rs-metadata 1159 Content-Disposition: recording-session 1161 1162 1163 partial 1164 1165 ca718e1430474b5485a53aa5d0bea45e 1166 ;remote=68caf509b9284b7ea45f84a049febf0a 1167 497c0f13929643b4a16858e2a3885edc 1168 ;remote=0e8a82bedda74f57be4a4a4da54167c4 1169 1170 1173 2010-12-16T23:41:07Z 1174 1175 1177 3.3.4. Example 4: Call disconnect 1179 When a CS is disconnected, SRC sends BYE with a snapshot of metadata 1180 having session stop time and participant dis-associate times. The 1181 snapshot looks same as listed in section 3.2.4 1183 3.4. Call scenarios with persistent RS between SRC and SRS 1185 The section shows the snapshots of metadata for the cases where a 1186 persistent RS exists between SRC and SRS. An SRC here may be SIP UA 1187 or a B2BUA or may be part of Conference model either as focus or a 1188 participant in a conference. The SRS here could be a SIP UA or an 1189 entity part of MEDIACTRL architecture. Except in the disconnect 1190 case, the snapshot remains same as mentioned in previous sections. 1192 3.4.1. Example 1: Metadata snapshot during CS disconnect with 1193 persistent RS between SRC and SRS 1195 RE-INVITE sent from SRC -----------> SRS 1197 INVITE sip:2001@example.com SIP/2.0 1198 Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30 1199 From: ;tag=35e195d2-947d-4585-946f-09839247 1200 To: 1201 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1202 Session-ID: ab30317f1a784dc48ff824d0d3715d86 1203 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 1204 CSeq: 101 INVITE 1205 Max-Forwards: 70 1206 Require: siprec 1207 Accept: application/rs-metadata, 1208 application/rs-metadata-request 1209 Contact: ;+sip.src 1210 Content-Type: multipart/mixed;boundary=foobar 1211 Content-Length: [length] 1213 --foobar 1214 Content-Type: application/rs-metadata 1216 1217 1218 partial 1219 1220 2010-12-16T23:41:07Z 1221 1222 1225 2010-12-16T23:41:07Z 1226 1228 1231 2010-12-16T23:41:07Z 1232 1233 1235 3.5. Turret-Case: Multiple CS into single RS with mixed stream 1237 In trading floor environments, in order to minimize storage and 1238 recording system resources, it may be preferable to mix multiple 1239 concurrent calls (each call is one CS) on different handsets/ 1240 speakers on the same turret into a single RS. This would means media 1241 in each CS is mixed and recorded as part of single media stream and 1242 multiple such CSs are recording in one RSfrom a SRC to SRS. 1244 Taking an example where there are two CS [CS1 and CS2]. Assume 1245 mixing is done in each of these CS and both these CS are recorded as 1246 part of single RS from a single SRC which is part of both the CS. 1247 There are three possibilities here: 1249 o CS1 and CS2 uses the same focus for fixing and that focus is also 1250 acting as SRC in each of the CS. 1252 o One of the CS (e.g. CS1), SRC is Focus and the other CS (e.g. 1253 CS2), SRC is just one of the participant of the conference. 1255 o In both CS1 and CS2, SRC is just a participant of conference. 1257 The following example shows the first possibility where CS1 and CS2 1258 uses the same focus for fixing and that focus is also acting as SRC 1259 in each of the CS. 1261 snapshot of metadata INVITE SRC --------------> SRS 1263 INVITE sip:recorder@example.com SIP/2.0 1264 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 1265 From: ;tag=35e195d2-947d-4585-946f-09839247 1266 To: 1267 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1268 Session-ID: a358d2b81a444a8c8fb05950cef331e7 1269 ;remote=00000000000000000000000000000000 1270 Content-Type: application/SDP 1271 ... 1272 m=audio 49170 RTP/AVP 0 1273 a=rtpmap:0 PCMU/8000 1274 a=label:96 1275 a=sendonly 1276 ... 1277 1278 1279 complete 1280 1281 2010-12-16T23:41:07Z 1282 1283 1284 fa3b60f27e91441e84c55a9a0095f075 1285 ;remote=a358d2b81a444a8c8fb05950cef331e7 1286 ca718e1430474b5485a53aa5d0bea45e 1287 ;remote=a358d2b81a444a8c8fb05950cef331e7 1288 497c0f13929643b4a16858e2a3885edc 1289 ;remote=a358d2b81a444a8c8fb05950cef331e7 1290 7+OTCyoxTmqmqyA/1weDAg== 1291 2010-12-16T23:41:07Z 1292 1293 1294 ae10731ca50343a5aaae2dd0904a65de 1295 ;remote=a358d2b81a444a8c8fb05950cef331e7 1296 33c77aac7deb414cbc8c10f363fccb71 1297 ;remote=a358d2b81a444a8c8fb05950cef331e7 1298 fd6932e9e5fc489fae2d5b3779723b7e 1299 ;remote=a358d2b81a444a8c8fb05950cef331e7 1300 7+OTCyoxTmqmqyA/1weDAg== 1301 2010-12-16T23:43:07Z 1302 1303 1305 1306 Alice 1307 1308 1309 1311 1312 Bob 1313 1314 1315 1317 1318 Carol 1319 1320 1321 1323 1324 1325 1328 2010-12-16T23:41:07Z 1329 1330 1333 2010-12-16T23:41:07Z 1334 1335 1338 2010-12-16T23:43:07Z 1339 1340 1343 2010-12-16T23:43:07Z 1344 1346 1348 UAAMm5GRQKSCMVvLyl4rFw== 1349 UAAMm5GRQKSCMVvLyl4rFw== 1350 1351 1353 UAAMm5GRQKSCMVvLyl4rFw== 1354 UAAMm5GRQKSCMVvLyl4rFw== 1355 1356 1358 UAAMm5GRQKSCMVvLyl4rFw== 1359 UAAMm5GRQKSCMVvLyl4rFw== 1360 1361 1363 4. Security Considerations 1365 Security considerations mentioned in [RFC7865] and [RFC7866] has to 1366 be followed by SRC and SRS for setting up RS SIP dialog and sending 1367 metadata. 1369 5. IANA Considerations 1371 This document has no IANA considerations 1373 6. Acknowledgement 1375 Thanks to Ofir Rath, Charles Eckel, Yaron Pdut, Dmitry Andreyev and 1376 Charles Armitage for their review comments. 1378 7. Informative References 1380 [RFC7865] Ravindranath, R., Ravindran, P., and P. Kyzivat, "Session 1381 Initiation Protocol (SIP) Recording Metadata", RFC 7865, 1382 DOI 10.17487/RFC7865, May 2016, 1383 . 1385 [RFC7866] Portman, L., Lum, H., Ed., Eckel, C., Johnston, A., and A. 1386 Hutton, "Session Recording Protocol", RFC 7866, 1387 DOI 10.17487/RFC7866, May 2016, 1388 . 1390 [RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor, 1391 "An Architecture for Media Recording Using the Session 1392 Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May 1393 2014, . 1395 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A 1396 Session Initiation Protocol (SIP) Event Package for 1397 Conference State", RFC 4575, DOI 10.17487/RFC4575, August 1398 2006, . 1400 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1401 Session Initiation Protocol (SIP)", RFC 4353, 1402 DOI 10.17487/RFC4353, February 2006, 1403 . 1405 [RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media 1406 Control Channel Framework", RFC 6230, 1407 DOI 10.17487/RFC6230, May 2011, 1408 . 1410 [RFC6341] Rehor, K., Ed., Portman, L., Ed., Hutton, A., and R. Jain, 1411 "Use Cases and Requirements for SIP-Based Media Recording 1412 (SIPREC)", RFC 6341, DOI 10.17487/RFC6341, August 2011, 1413 . 1415 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1416 A., Peterson, J., Sparks, R., Handley, M., and E. 1417 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1418 DOI 10.17487/RFC3261, June 2002, 1419 . 1421 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1422 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1423 July 2006, . 1425 Authors' Addresses 1427 Ram Mohan Ravindranath 1428 Cisco Systems, Inc. 1429 Cessna Business Park, 1430 Kadabeesanahalli Village, Varthur Hobli, 1431 Sarjapur-Marathahalli Outer Ring Road 1432 Bangalore, Karnataka 560103 1433 India 1435 Email: rmohanr@cisco.com 1437 Parthasarathi Ravindran 1438 Nokia Networks 1439 Bangalore, Karnataka 1440 India 1442 Email: partha@parthasarathi.co.in 1444 Paul Kyzivat 1445 Huawei 1446 Hudson, MA 1447 USA 1449 Email: pkyzivat@alum.mit.edu