idnits 2.17.1 draft-ietf-siprec-callflows-06.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 (January 30, 2016) is 2999 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-siprec-metadata-18 -- 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: August 2, 2016 Nokia Networks 6 Paul. Kyzivat 7 Huawei 8 January 30, 2016 10 Session Initiation Protocol (SIP) Recording Call Flows 11 draft-ietf-siprec-callflows-06 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 a Session Recording Client to Session Recording 22 Server. This is purely an informational document that is written to 23 support the model defined in the metadata draft. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 2, 2016. 42 Copyright Notice 44 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Metadata XML Instances . . . . . . . . . . . . . . . . . . . 3 62 3.1. Sample Call flow . . . . . . . . . . . . . . . . . . . . 3 63 3.2. Call Scenarios with SRC recording streams with out mixing 4 64 3.2.1. Example 1: Basic Call . . . . . . . . . . . . . . . . 4 65 3.2.2. Example 2: Hold/resume . . . . . . . . . . . . . . . 7 66 3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) . 11 67 3.2.4. Example 4: Call disconnect . . . . . . . . . . . . . 17 68 3.3. Call Scenarios with SRC recording streams by mixing . . . 18 69 3.3.1. Example 1: Basic call with SRC mixing streams . . . . 18 70 3.3.2. Example 2: Hold/resume with SRC recording by mixing 71 streams . . . . . . . . . . . . . . . . . . . . . . . 21 72 3.3.3. Example 3: Metadata snapshot of joining/dropping of a 73 participant to a session . . . . . . . . . . . . . . 24 74 3.3.4. Example 4: Call disconnect . . . . . . . . . . . . . 27 75 3.4. Call scenarios with persistent RS between SRC and SRS . . 27 76 3.4.1. Example 1: Metadata snapshot during CS disconnect 77 with persistent RS between SRC and SRS . . . . . . . 27 78 3.5. Turrent-Case: Multiple CS into single RS with mixed 79 stream . . . . . . . . . . . . . . . . . . . . . . . . . 28 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 31 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 82 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 31 83 7. Informative References . . . . . . . . . . . . . . . . . . . 32 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 86 1. Overview 88 [I-D.ietf-siprec-metadata] document focuses on the recording metadata 89 which describes the communication session(CS). This document lists 90 few examples and shows the snapshots of metadata sent from a Session 91 Recording Client (SRC) to Session Recording Server (SRS). For the 92 sake of simplicity the entire Session Initiation Protocol (SIP) 93 [RFC3261] messages are not shown at various points, instead only 94 snippets of the SIP and Session Description Protocol (SDP)[RFC4566] 95 messages and the XML snapshot of metadata is shown. 97 2. Terminology 99 The terms using in this document are defined in 100 [I-D.ietf-siprec-metadata] and [RFC6341]. No new definitions are 101 introduced in this document. 103 3. Metadata XML Instances 105 The following sub-sections has examples showing the metadata snapshot 106 sent from SRC to SRS. In all these use-cases, the SRC is a B2BUA. 108 3.1. Sample Call flow 110 The following is a sample call flow that shows the SRC establishing a 111 Recording Session(RS) towards the SRS. The SRC in this example could 112 be part of any one of the architectures described in section 3 of 113 [RFC7245]. 115 SRC SRS 116 | | 117 |(1) INVITE (metadata snapshot) F1 | 118 |---------------------------------------------------->| 119 | 200 OK | 120 |<----------------------------------------------------| 121 |(3) ACK | 122 |---------------------------------------------------->| 123 |(4) RTP | 124 |====================================================>| 125 |====================================================>| 126 |====================================================>| 127 |====================================================>| 128 |(5) UPDATE/RE-INVITE (metadata update 1) F2 | 129 |---------------------------------------------------->| 130 | 200 OK | 131 |<----------------------------------------------------| 132 | ................................................... | 133 | ................................................... | 134 | | 135 |====================================================>| 136 |====================================================>| 137 |(7) UPDATE/RE-INVITE (metadata update n-1) Fn-1 | 138 |---------------------------------------------------->| 139 | 200 OK | 140 |<----------------------------------------------------| 142 For the sake of simplicity, ACKs to RE-INVITES and BYEs are not 143 shown. The subsequent sections describes the snapshot of metadata 144 sent from SRC to SRS for each of the above transactions (F1 ... Fn- 145 1). There may be multiple UPDATES/RE-INVITES mid call to indicates 146 snapshots of different CS changes. Depending on the architecture 147 described in section 3 of [RFC7245] an SRC may be a endpoint or B2BUA 148 or as part of MEDIACTRL or Conference Focus. The subsequent sections 149 in this document tries to list some example metadata snapshots for 150 three major categories. 152 o SRC recording streams unmixed to SRS. This includes cases where 153 SRC is SIP UA or B2BUA. 155 o SRC recording mixed streams to SRS. This includes cases where SRC 156 is part of SIP conference model explained in [RFC4353]. 158 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 This section describes few example flows where SRC can be a SIP-UA or 170 B2BUA as described in section 3 of [RFC7245]. The SRS here can be a 171 SIP-UA or an entity part of MEDIACTRL architecture described in 172 [RFC6230]. 174 3.2.1. Example 1: Basic Call 176 Basic call between two participants Alice and Bob who are part of the 177 same CS. In this use case each participant sends two media 178 streams(audio and video). Media streams sent by each participant are 179 received by the other participant in this use-case. In this example 180 the SRC is a B2BUA in the path between Alice and Bob as described in 181 section 3.1.1 of [RFC7245]. Below is the initial snapshot sent by 182 SRC in the INVITE to SRS. This snapshot has the complete metadata. 183 For the sake of simplicity only snippets of SIP/SDP are shown. The 184 SRCs records the streams of each participant to SRS with out mixing 185 in this example. 187 F1 INVITE SRC --------------> SRS 188 INVITE sip:recorder@example.com SIP/2.0 189 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 190 From: ;tag=35e195d2-947d-4585-946f-09839247 191 To: 192 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 193 Session-ID: ab30317f1a784dc48ff824d0d3715d86 194 ;remote=00000000000000000000000000000000 195 CSeq: 101 INVITE 196 Max-Forwards: 70 197 Require: siprec 198 Accept: application/sdp, application/rs-metadata, 199 application/rs-metadata-request 200 Contact: ;+sip.src 201 Content-Type: multipart/mixed;boundary=foobar 202 Content-Length: [length] 204 --foobar 205 Content-Type: application/SDP 206 ... 207 m=audio 49170 RTP/AVP 0 208 a=rtpmap:0 PCMU/8000 209 a=label:96 210 a=sendonly 211 ... 212 m=video 49174 RTP/AVPF 96 213 a=rtpmap:96 H.264/90000 214 a=label:97 215 a=sendonly 216 ... 217 m=audio 51372 RTP/AVP 0 218 a=rtpmap:0 PCMU/8000 219 a=label:98 220 a=sendonly 221 ... 222 m=video 49176 RTP/AVPF 96 223 a=rtpmap:96 H.264/90000 224 a=label:99 225 a=sendonly 226 .... 227 --foobar 228 Content-Type: application/rs-metadata 229 Content-Disposition: recording-session 230 231 232 complete 233 234 2010-12-16T23:41:07Z 235 236 237 sip:alice@atlanta.com 238 239 240 FOO! 241 bar 242 243 244 245 ab30317f1a784dc48ff824d0d3715d86; 246 remote=47755a9de7794ba387653f2099600ef2 247 7+OTCyoxTmqmqyA/1weDAg== 248 249 250 251 FOO! 252 bar 253 254 255 257 258 Alice 259 260 261 262 FOO! 263 bar 264 265 266 268 269 Bob 270 271 272 273 FOO! 274 bar 275 276 277 279 280 281 283 285 286 288 289 290 292 293 294 295 2010-12-16T23:41:07Z 296 297 300 2010-12-16T23:41:07Z 301 302 305 2010-12-16T23:41:07Z 306 307 309 i1Pz3to5hGk8fuXl+PbwCw== 310 UAAMm5GRQKSCMVvLyl4rFw== 311 8zc6e0lYTlWIINA6GR+3ag== 312 EiXGlc+4TruqqoDaNE76ag== 313 314 316 8zc6e0lYTlWIINA6GR+3ag== 317 EiXGlc+4TruqqoDaNE76ag== 318 UAAMm5GRQKSCMVvLyl4rFw== 319 i1Pz3to5hGk8fuXl+PbwCw== 320 321 323 3.2.2. Example 2: Hold/resume 325 A call between two participants Alice and Bob is established and a RS 326 is created for recording as in example1. One of the participants Bob 327 puts Alice hold and then resumes as part of the same CS. The send 328 and recv XML elements of a participantstreamassoc XML element is used 329 to indicate whether a participant is contributing to a media stream 330 or not. SRC sends a snapshot with only the changed XML elements. 332 During hold 334 F2 mid call RE-INVITE SRC-------------------->SRS 336 INVITE sip:recorder@example.com SIP/2.0 337 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 338 From: ;tag=35e195d2-947d-4585-946f-09839247 339 To: 340 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 341 Session-ID: ab30317f1a784dc48ff824d0d3715d86 342 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 343 CSeq: 101 INVITE 344 Max-Forwards: 70 345 Require: siprec 346 Accept: application/sdp, application/rs-metadata, 347 application/rs-metadata-request 348 Contact: ;+sip.src 349 Content-Type: multipart/mixed;boundary=foobar 350 Content-Length: [length] 352 --foobar 353 Content-Type: application/SDP 354 ... 355 m=audio 49170 RTP/AVP 0 356 a=rtpmap:0 PCMU/8000 357 a=label:96 358 a=sendonly 359 ... 360 m=video 49174 RTP/AVPF 96 361 a=rtpmap:96 H.264/90000 362 a=label:97 363 a=sendonly 364 ... 365 m=audio 51372 RTP/AVP 0 366 a=rtpmap:0 PCMU/8000 367 a=label:98 368 a=sendonly 369 ... 370 m=video 49176 RTP/AVPF 96 371 a=rtpmap:96 H.264/90000 372 a=label:99 373 a=sendonly 374 .... 376 --foobar 377 Content-Type: application/rs-metadata 378 Content-Disposition: recording-session 380 381 382 partial 383 385 8zc6e0lYTlWIINA6GR+3ag== 386 EiXGlc+4TruqqoDaNE76ag== 387 388 390 8zc6e0lYTlWIINA6GR+3ag== 391 EiXGlc+4TruqqoDaNE76ag== 392 393 395 In the above snippet, Alice with participant_id 396 srfBElmCRp2QB23b7Mpk0w== only receives media streams and does not 397 send any media. The same is indicated by the absence of send XML 398 element. Bob(participant_id zSfPoSvdSDCmU3A3TRDxAw==) on the other 399 hand would be sending media but does not receive any media from Alice 400 and so recv XML element is absent in this instance. 402 During resume 404 The snapshot now has send and recv XML elements for both Alice and 405 Bob indicating that both are receiving and sending media. 407 F3 mid call RE-INVITE SRC-------------------->SRS 409 INVITE sip:recorder@example.com SIP/2.0 410 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 411 From: ;tag=35e195d2-947d-4585-946f-09839247 412 To: 413 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 414 Session-ID: ab30317f1a784dc48ff824d0d3715d86 415 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 416 CSeq: 101 INVITE 417 Max-Forwards: 70 418 Require: siprec 419 Accept: application/sdp, application/rs-metadata, 420 application/rs-metadata-request 421 Contact: ;+sip.src 422 Content-Type: multipart/mixed;boundary=foobar 423 Content-Length: [length] 425 --foobar 426 Content-Type: application/SDP 427 ... 428 m=audio 49170 RTP/AVP 0 429 a=rtpmap:0 PCMU/8000 430 a=label:96 431 a=sendonly 432 ... 433 m=video 49174 RTP/AVPF 96 434 a=rtpmap:96 H.264/90000 435 a=label:97 436 a=sendonly 437 ... 438 m=audio 51372 RTP/AVP 0 439 a=rtpmap:0 PCMU/8000 440 a=label:98 441 a=sendonly 442 ... 443 m=video 49176 RTP/AVPF 96 444 a=rtpmap:96 H.264/90000 445 a=label:99 446 a=sendonly 447 .... 448 --foobar 449 Content-Type: application/rs-metadata 450 Content-Disposition: recording-session 452 453 454 partial 455 457 8zc6e0lYTlWIINA6GR+3ag== 458 EiXGlc+4TruqqoDaNE76ag== 459 i1Pz3to5hGk8fuXl+PbwCw== 460 UAAMm5GRQKSCMVvLyl4rFw== 461 462 464 8zc6e0lYTlWIINA6GR+3ag== 465 EiXGlc+4TruqqoDaNE76ag== 466 i1Pz3to5hGk8fuXl+PbwCw== 467 UAAMm5GRQKSCMVvLyl4rFw== 468 469 471 3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) 473 Basic call between two Participants Alice and Bob is connected and 474 SRC(B2BUA acting as SRC as per section 3.1.1 of [RFC7245]) has sent a 475 snapshot as described in example 1. Transfer is initiated by one of 476 the participants(Alice). After the transfer is completed, SRC sends 477 a snapshot of the participant changes to SRS. In this transfer 478 scenario, Alice drops out after transfer is completed and Bob and 479 Carol gets connected and recording of media between Bob and Carol is 480 done by SRC. There are two flows that can happen here as described 481 below. 483 Transfer with in the same session - (.e.g. RE-INVITE based 484 transfer). Participant Alice drops out and Carol is added to the 485 same session. No change to session/group element. A 486 participantsessassoc element indicating that Alice has disassociated 487 from the CS will be present in the snapshot. A new participant XML 488 element representing Carol with mapping to the same RS SDP stream 489 used for mapping earlier Alice's stream is sent in the snapshot. A 490 new sipSessionID XML element that has UUID tuples which corresponds 491 to Bob and Carol is sent in the snapshot from SRC to SRS. Note that 492 one half of the session ID that corresponds to Bob remains same. 494 mid call RE-INVITE SRC-------------------->SRS 496 INVITE sip:recorder@example.com SIP/2.0 497 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 498 From: ;tag=35e195d2-947d-4585-946f-09839247 499 To: 500 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 501 Session-ID: ab30317f1a784dc48ff824d0d3715d86 502 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 503 CSeq: 101 INVITE 504 Max-Forwards: 70 505 Require: siprec 506 Accept: application/sdp, application/rs-metadata, 507 application/rs-metadata-request 508 Contact: ;+sip.src 509 Content-Type: multipart/mixed;boundary=foobar 510 Content-Length: [length] 512 --foobar 513 Content-Type: application/SDP 514 ... 515 m=audio 49180 RTP/AVP 0 516 a=rtpmap:0 PCMU/8000 517 a=label:96 518 a=sendonly 519 ... 520 m=video 49182 RTP/AVPF 96 521 a=rtpmap:96 H.264/90000 522 a=label:97 523 a=sendonly 524 ... 525 m=audio 51374 RTP/AVP 0 526 a=rtpmap:0 PCMU/8000 527 a=label:98 528 a=sendonly 529 ... 530 m=video 49178 RTP/AVPF 96 531 a=rtpmap:96 H.264/90000 532 a=label:99 533 a=sendonly 534 .... 535 --foobar 536 Content-Type: application/rs-metadata 537 Content-Disposition: recording-session 539 540 541 partial 542 543 3363127f0d084c10876dddd4f8e5eeb9 544 ;remote=2272bb7e70fe41dba0025ae9a26d54cf 545 546 548 549 Carol 550 551 552 555 2013-12-16T23:41:07Z 556 557 560 2013-12-16T23:41:07Z 561 562 564 8zc6e0lYTlWIINA6GR+3ag== 565 EiXGlc+4TruqqoDaNE76ag== 566 60JAJm9UTvik0Ltlih/Gzw== 567 AcR5FUd3Edi8cACQJy/3JQ== 568 569 571 60JAJm9UTvik0Ltlih/Gzw== 572 AcR5FUd3Edi8cACQJy/3JQ== 573 8zc6e0lYTlWIINA6GR+3ag== 574 EiXGlc+4TruqqoDaNE76ag== 575 2013-12-16T23:42:07Z 576 577 579 Transfer with new session - (.e.g. REFER based transfer). In this 580 case a new session (CS) is created and shall be part of same CS-group 581 (done by SRC). 583 SRC first sends an optional snapshot indicating disassociation of 584 participant from the old CS. Please note this is a optional message. 585 An SRC may choose to just send a INVITE with a new session element to 586 implicitly indicate that the participants are now part of a different 587 CS with out sending disassociation from the old CS. The SRC in this 588 example uses the same RS. In case the SRC wishes to use a new RS, it 589 will tear down the current RS using normal SIP procedures (BYE) with 590 metadata as in example 4. 592 mid call RE-INVITE SRC-------------------->SRS 594 INVITE sip:recorder@example.com SIP/2.0 595 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 596 From: ;tag=35e195d2-947d-4585-946f-09839247 597 To: 598 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 599 Session-ID: ab30317f1a784dc48ff824d0d3715d86 600 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 601 CSeq: 101 INVITE 602 Max-Forwards: 70 603 Require: siprec 604 Accept: application/sdp, application/rs-metadata, 605 application/rs-metadata-request 606 Contact: ;+sip.src 607 Content-Type: multipart/mixed;boundary=foobar 608 Content-Length: [length] 609 --foobar 610 Content-Type: application/SDP 611 ... 612 m=audio 49180 RTP/AVP 0 613 a=rtpmap:0 PCMU/8000 614 a=label:96 615 a=sendonly 616 ... 617 m=video 49182 RTP/AVPF 96 618 a=rtpmap:96 H.264/90000 619 a=label:97 620 a=sendonly 621 ... 622 m=audio 51374 RTP/AVP 0 623 a=rtpmap:0 PCMU/8000 624 a=label:98 625 a=sendonly 626 ... 627 m=video 49178 RTP/AVPF 96 628 a=rtpmap:96 H.264/90000 629 a=label:99 630 a=sendonly 631 .... 633 --foobar 634 Content-Type: application/rs-metadata 635 Content-Disposition: recording-session 637 638 639 Partial 640 641 2010-12-16T23:41:07Z 642 643 646 2010-12-16T23:41:07Z 647 648 651 2010-12-16T23:41:07Z 652 653 655 In the above snapshot, the participantsessionassoc element is 656 optional as indicating session XML element with a stop-time 657 implicitly means that all the participants associated with that 658 session have been disassociated. 660 SRC sends another snapshot to indicate the participant change (due to 661 REFER) and new session information after transfer. In this example 662 it is assumed SRC uses the same RS to continue recording the call. 663 The sipSessionID XML element in metadata snapshot now indicates Alice 664 and Carol in the (local, remote) uuid pair. 666 mid call RE-INVITE SRC-------------------->SRS 668 INVITE sip:recorder@example.com SIP/2.0 669 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 670 From: ;tag=35e195d2-947d-4585-946f-09839247 671 To: 672 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 673 Session-ID: ab30317f1a784dc48ff824d0d3715d86 674 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 675 CSeq: 101 INVITE 676 Max-Forwards: 70 677 Require: siprec 678 Accept: application/sdp, application/rs-metadata, 679 application/rs-metadata-request 680 Contact: ;+sip.src 681 Content-Type: multipart/mixed;boundary=foobar 682 Content-Length: [length] 684 --foobar 685 Content-Type: application/SDP 686 ... 687 m=audio 49180 RTP/AVP 0 688 a=rtpmap:0 PCMU/8000 689 a=label:96 690 a=sendonly 691 ... 692 m=video 49182 RTP/AVPF 96 693 a=rtpmap:96 H.264/90000 694 a=label:97 695 a=sendonly 696 ... 697 m=audio 51374 RTP/AVP 0 698 a=rtpmap:0 PCMU/8000 699 a=label:98 700 a=sendonly 701 ... 702 m=video 49178 RTP/AVPF 96 703 a=rtpmap:96 H.264/90000 704 a=label:99 705 a=sendonly 706 .... 708 --foobar 709 Content-Type: application/rs-metadata 711 712 713 complete 714 715 2010-12-16T23:41:07Z 716 3363127f0d084c10876dddd4f8e5eeb9 717 ;remote=2272bb7e70fe41dba0025ae9a26d54cf 718 719 721 722 723 725 726 727 729 730 731 733 734 735 737 738 739 741 742 743 746 2010-12-16T23:32:03Z 747 749 752 2010-12-16T23:41:07Z 753 754 756 8zc6e0lYTlWIINA6GR+3ag== 757 EiXGlc+4TruqqoDaNE76ag== 758 60JAJm9UTvik0Ltlih/Gzw== 759 AcR5FUd3Edi8cACQJy/3JQ== 760 761 763 60JAJm9UTvik0Ltlih/Gzw== 764 AcR5FUd3Edi8cACQJy/3JQ== 765 8zc6e0lYTlWIINA6GR+3ag== 766 EiXGlc+4TruqqoDaNE76ag== 767 768 770 3.2.4. Example 4: Call disconnect 772 This example shows a snapshot of metadata sent by the SRC to SRS when 773 a CS with Alice and Bob as participants is disconnected. 775 SRC SRS 776 | | 777 |(1) BYE (metadata snapshot) F1 | 778 |---------------------------------------------------->| 779 | 200 OK F2 | 780 |<----------------------------------------------------| 782 F1 BYE SRC -----------> SRS 784 BYE sip:2001@example.com SIP/2.0 785 Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30 786 From: ;tag=35e195d2-947d-4585-946f-09839247 787 To: 788 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 789 Session-ID: ab30317f1a784dc48ff824d0d3715d86 790 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 791 CSeq: 102 BYE 792 Max-Forwards: 70 793 Require: siprec 794 Accept: application/rs-metadata, 795 application/rs-metadata-request 796 Contact: ;+sip.src 797 Content-Type: multipart/mixed;boundary=foobar 798 Content-Length: [length] 800 --foobar 801 Content-Type: application/rs-metadata 803 804 805 Partial 806 807 2010-12-16T23:41:07Z 808 809 812 2010-12-16T23:41:07Z 813 815 818 2010-12-16T23:41:07Z 819 820 822 3.3. Call Scenarios with SRC recording streams by mixing 824 The section describes a few example call flows where SRC may be part 825 of conference model either as Focus or a participant in conference as 826 explained in section 3.1.5 of [RFC7245]. The SRS here can be a SIP 827 UA or an entity part of MEDIACTRL architecture. Note that the 828 disconnect case is not shown since the metadata snapshot will be same 829 as for a non-mixing case. 831 3.3.1. Example 1: Basic call with SRC mixing streams 833 Basic call between two participants Alice and Bob who are part of one 834 CS. In this use case each participant call into a conference server 835 (say, an MCU) to attend one of many conferences hosted on or managed 836 by that servers. Media streams sent by each participant is received 837 by all the other participants in the conference. Below is the 838 initial snapshot sent by SRC in the INVITE to SRS that has the 839 complete metadata. For the sake of simplicity only snippets of SIP/ 840 SDP are shown. The SRC records the streams of each participant to 841 SRS by mixing in this example. The SRC here is part of conference 842 model described in section 3 of [RFC7245] as a Focus and does mixing. 843 The SRC here is not a participant by itself and hence it does not 844 contribute to media. 846 F1 INVITE SRC --------------> SRS 848 INVITE sip:recorder@example.com SIP/2.0 849 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 850 From: ;tag=35e195d2-947d-4585-946f-09839247 851 To: 852 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 853 Session-ID: a358d2b81a444a8c8fb05950cef331e7 854 ;remote=00000000000000000000000000000000 855 CSeq: 101 INVITE 856 Max-Forwards: 70 857 Require: siprec 858 Accept: application/sdp, application/rs-metadata, 859 application/rs-metadata-request 860 Contact: ;+sip.src 861 Content-Type: multipart/mixed;boundary=foobar 862 Content-Length: [length] 864 --foobar 865 Content-Type: application/SDP 866 ... 867 m=audio 49170 RTP/AVP 0 868 a=rtpmap:0 PCMU/8000 869 a=label:96 870 a=sendonly 872 .... 873 --foobar 874 Content-Type: application/rs-metadata 875 Content-Disposition: recording-session 876 877 878 complete 879 880 2010-12-16T23:41:07Z 881 fa3b60f27e91441e84c55a9a0095f075 882 ;remote=a358d2b81a444a8c8fb05950cef331e7 883 ca718e1430474b5485a53aa5d0bea45e 884 ;remote=68caf509b9284b7ea45f84a049febf0a 886 887 889 890 Alice 891 892 893 895 896 Bob 897 898 899 901 902 903 906 2010-12-16T23:41:07Z 907 908 910 i1Pz3to5hGk8fuXl+PbwCw== 911 i1Pz3to5hGk8fuXl+PbwCw== 912 914 917 2010-12-16T23:41:07Z 918 919 921 i1Pz3to5hGk8fuXl+PbwCw== 922 i1Pz3to5hGk8fuXl+PbwCw== 923 925 927 In the above example there are two participants Alice and Bob in the 928 conference. Among other things, SRC sends Session-ID in the metadata 929 snapshot. There are two Session-ID's here, one that corresponds to 930 the SIP session between Alice and conference focus and the other for 931 the SIP session between Bob and conference focus. In this use-case, 932 since Alice and Bob calls into the conference these Session-ID's are 933 different. 935 3.3.2. Example 2: Hold/resume with SRC recording by mixing streams 937 Assume a call between two participants Alice and Bob is established 938 and a RS is created for recording as in example 5. This is the 939 continuation of above use-case. One of the participants Bob puts 940 Alice hold and then resumes as part of the same CS. The send and 941 recv XML elements of a participant is used to indicate whether a 942 participant is contributing or not to a media stream. The metadata 943 snapshot looks as below: 945 During hold 946 mid call hold RE-INVITE SRC --------------> SRS 948 INVITE sip:recorder@example.com SIP/2.0 949 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 950 From: ;tag=35e195d2-947d-4585-946f-09839247 951 To: 952 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 953 Session-ID: a358d2b81a444a8c8fb05950cef331e7 954 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 955 CSeq: 101 INVITE 956 Max-Forwards: 70 957 Require: siprec 958 Accept: application/sdp, application/rs-metadata, 959 application/rs-metadata-request 960 Contact: ;+sip.src 961 Content-Type: multipart/mixed;boundary=foobar 962 Content-Length: [length] 964 --foobar 965 Content-Type: application/SDP 966 ... 967 m=audio 49170 RTP/AVP 0 968 a=rtpmap:0 PCMU/8000 969 a=label:96 970 a=sendonly 972 .... 973 --foobar 974 Content-Type: application/rs-metadata 975 Content-Disposition: recording-session 976 977 978 partial 979 981 982 983 985 i1Pz3to5hGk8fuXl+PbwCw== 986 987 989 i1Pz3to5hGk8fuXl+PbwCw== 990 991 993 During resume a snapshot shown below will be sent from SRC to SRS. 995 mid call resume RE-INVITE SRC --------------> SRS 997 INVITE sip:recorder@example.com SIP/2.0 998 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 999 From: ;tag=35e195d2-947d-4585-946f-09839247 1000 To: 1001 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1002 Session-ID: a358d2b81a444a8c8fb05950cef331e7 1003 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 1004 CSeq: 101 INVITE 1005 Max-Forwards: 70 1006 Require: siprec 1007 Accept: application/sdp, application/rs-metadata, 1008 application/rs-metadata-request 1009 Contact: ;+sip.src 1010 Content-Type: multipart/mixed;boundary=foobar 1011 Content-Length: [length] 1013 --foobar 1014 Content-Type: application/SDP 1015 ... 1016 m=audio 49170 RTP/AVP 0 1017 a=rtpmap:0 PCMU/8000 1018 a=label:96 1019 a=sendonly 1021 .... 1022 --foobar 1023 Content-Type: application/rs-metadata 1024 Content-Disposition: recording-session 1025 1026 1027 partial 1028 1030 1031 1032 1034 i1Pz3to5hGk8fuXl+PbwCw== 1035 i1Pz3to5hGk8fuXl+PbwCw== 1036 1037 1039 i1Pz3to5hGk8fuXl+PbwCw== 1041 i1Pz3to5hGk8fuXl+PbwCw== 1042 1043 1045 3.3.3. Example 3: Metadata snapshot of joining/dropping of a 1046 participant to a session 1048 In a conference model, participants can join and drop a session any 1049 time during the session. The below shows a snapshot sent from SRC to 1050 SRC in these case. Note the SRC here can be a focus or a participant 1051 in the conference. In case where the SRC is a participant it may 1052 learn the information required for metadata by subscribing to 1053 conference event package [RFC4575]. Assume Alice and Bob were in the 1054 conference and a third participant Carol joins, then SRC sends the 1055 below snapshot with the indication of new participant. 1057 mid call resume RE-INVITE SRC --------------> SRS 1059 INVITE sip:recorder@example.com SIP/2.0 1060 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 1061 From: ;tag=35e195d2-947d-4585-946f-09839247 1062 To: 1063 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1064 Session-ID: a358d2b81a444a8c8fb05950cef331e7 1065 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 1066 CSeq: 101 INVITE 1067 Max-Forwards: 70 1068 Require: siprec 1069 Accept: application/sdp, application/rs-metadata, 1070 application/rs-metadata-request 1071 Contact: ;+sip.src 1072 Content-Type: multipart/mixed;boundary=foobar 1073 Content-Length: [length] 1075 --foobar 1076 Content-Type: application/SDP 1077 ... 1078 m=audio 49170 RTP/AVP 0 1079 a=rtpmap:0 PCMU/8000 1080 a=label:96 1081 a=sendonly 1083 .... 1084 --foobar 1085 Content-Type: application/rs-metadata 1086 Content-Disposition: recording-session 1087 1088 1089 partial 1090 1091 fa3b60f27e91441e84c55a9a0095f075 1092 ;remote=a358d2b81a444a8c8fb05950cef331e7 1093 ca718e1430474b5485a53aa5d0bea45e 1094 ;remote=68caf509b9284b7ea45f84a049febf0a 1095 497c0f13929643b4a16858e2a3885edc 1096 ;remote=0e8a82bedda74f57be4a4a4da54167c4 1097 1098 1100 1101 Carol 1102 1103 1104 1107 2013-12-16T23:41:07Z 1108 1109 1111 i1Pz3to5hGk8fuXl+PbwCw== 1112 i1Pz3to5hGk8fuXl+PbwCw== 1113 1114 1116 Assume Alice drops after some time from the conference. SRC 1117 generates a new snapshot showing Alice disassociating from the 1118 session 1119 mid call resume RE-INVITE SRC --------------> SRS 1121 INVITE sip:recorder@example.com SIP/2.0 1122 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 1123 From: ;tag=35e195d2-947d-4585-946f-09839247 1124 To: 1125 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1126 Session-ID: a358d2b81a444a8c8fb05950cef331e7 1127 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 1128 CSeq: 101 INVITE 1129 Max-Forwards: 70 1130 Require: siprec 1131 Accept: application/sdp, application/rs-metadata, 1132 application/rs-metadata-request 1133 Contact: ;+sip.src 1134 Content-Type: multipart/mixed;boundary=foobar 1135 Content-Length: [length] 1137 --foobar 1138 Content-Type: application/SDP 1139 ... 1140 m=audio 49170 RTP/AVP 0 1141 a=rtpmap:0 PCMU/8000 1142 a=label:96 1143 a=sendonly 1145 .... 1146 --foobar 1147 Content-Type: application/rs-metadata 1148 Content-Disposition: recording-session 1149 1150 1151 partial 1152 1153 ca718e1430474b5485a53aa5d0bea45e 1154 ;remote=68caf509b9284b7ea45f84a049febf0a 1155 497c0f13929643b4a16858e2a3885edc 1156 ;remote=0e8a82bedda74f57be4a4a4da54167c4 1157 1158 1161 2010-12-16T23:41:07Z 1162 1163 1165 3.3.4. Example 4: Call disconnect 1167 When a CS is disconnected, SRC sends BYE with a snapshot of metadata 1168 having session stop-time and participant dis-associate times. The 1169 snapshot looks same as listed in section 3.2.4 1171 3.4. Call scenarios with persistent RS between SRC and SRS 1173 The section shows the snapshots of metadata for the cases there a 1174 persistent RS exists between SRC and SRS. An SRC here may be SIP UA 1175 or a B2BUA or may be part of Conference model either as Focus or a 1176 participant in a conference. The SRS here could be a SIP UA or an 1177 entity part of MEDIACTRL architecture. Except disconnect case, the 1178 snapshot remains same as mentioned in previous sections. 1180 3.4.1. Example 1: Metadata snapshot during CS disconnect with 1181 persistent RS between SRC and SRS 1183 RE-INVITE sent from SRC -----------> SRS 1185 INVITE sip:2001@example.com SIP/2.0 1186 Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30 1187 From: ;tag=35e195d2-947d-4585-946f-09839247 1188 To: 1189 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1190 Session-ID: ab30317f1a784dc48ff824d0d3715d86 1191 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 1192 CSeq: 101 INVITE 1193 Max-Forwards: 70 1194 Require: siprec 1195 Accept: application/rs-metadata, 1196 application/rs-metadata-request 1197 Contact: ;+sip.src 1198 Content-Type: multipart/mixed;boundary=foobar 1199 Content-Length: [length] 1201 --foobar 1202 Content-Type: application/rs-metadata 1204 1205 1206 Partial 1207 1208 2010-12-16T23:41:07Z 1209 1210 1213 2010-12-16T23:41:07Z 1214 1216 1219 2010-12-16T23:41:07Z 1220 1221 1223 3.5. Turrent-Case: Multiple CS into single RS with mixed stream 1225 In trading floor environments, in order to minimize storage and 1226 recording system resources, it may be preferable to mix multiple 1227 concurrent calls (each call is one CS) on different handsets/ 1228 speakers on the same turret into a single RS. This would means media 1229 in each CS is mixed and recorded as part of single media stream and 1230 multiple such CSs are recording in one RSfrom a SRC to SRS. 1232 Lets take a example where there are two CS[CS1 and CS2]. Assume 1233 mixing is done in each of these CS and both these CS are recorded as 1234 part of single RS from a single SRC which is part of both the CS. 1235 There are three possibilities here: 1237 o CS1 and CS2 uses the same Focus for fixing and that Focus is also 1238 acting as SRC in each of the CS. 1240 o In of the CS(say CS1), SRC is Focus and in the other CS(say CS2), 1241 SRC is just one of the participant of the conference. 1243 o In both CS1 and CS2, SRC is just a participant of conference. 1245 The following example shows the first possibility where CS1 and CS2 1246 uses the same Focus for fixing and that Focus is also acting as SRC 1247 in each of the CS. 1249 snapshot of metadata INVITE SRC --------------> SRS 1251 INVITE sip:recorder@example.com SIP/2.0 1252 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 1253 From: ;tag=35e195d2-947d-4585-946f-09839247 1254 To: 1255 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1256 Session-ID: a358d2b81a444a8c8fb05950cef331e7 1257 ;remote=00000000000000000000000000000000 1258 Content-Type: application/SDP 1259 ... 1260 m=audio 49170 RTP/AVP 0 1261 a=rtpmap:0 PCMU/8000 1262 a=label:96 1263 a=sendonly 1264 ... 1265 1266 1267 complete 1268 1269 2010-12-16T23:41:07Z 1270 1271 1272 7+OTCyoxTmqmqyA/1weDAg== 1273 2010-12-16T23:41:07Z 1274 fa3b60f27e91441e84c55a9a0095f075 1275 ;remote=a358d2b81a444a8c8fb05950cef331e7 1276 ca718e1430474b5485a53aa5d0bea45e 1277 ;remote=a358d2b81a444a8c8fb05950cef331e7 1278 497c0f13929643b4a16858e2a3885edc 1279 ;remote=a358d2b81a444a8c8fb05950cef331e7 1280 1281 1282 7+OTCyoxTmqmqyA/1weDAg== 1283 2010-12-16T23:43:07Z 1284 ae10731ca50343a5aaae2dd0904a65de 1285 ;remote=a358d2b81a444a8c8fb05950cef331e7 1286 33c77aac7deb414cbc8c10f363fccb71 1287 ;remote=a358d2b81a444a8c8fb05950cef331e7 1288 fd6932e9e5fc489fae2d5b3779723b7e 1289 ;remote=a358d2b81a444a8c8fb05950cef331e7 1290 1291 1293 1294 Alice 1295 1296 1297 1299 1300 Bob 1301 1302 1303 1305 1306 Carol 1307 1308 1309 1311 1312 1313 1316 2010-12-16T23:41:07Z 1317 1318 1321 2010-12-16T23:41:07Z 1322 1323 1326 2010-12-16T23:43:07Z 1327 1328 1331 2010-12-16T23:43:07Z 1332 1334 1336 UAAMm5GRQKSCMVvLyl4rFw== 1337 UAAMm5GRQKSCMVvLyl4rFw== 1338 1339 1341 UAAMm5GRQKSCMVvLyl4rFw== 1342 UAAMm5GRQKSCMVvLyl4rFw== 1343 1344 1346 UAAMm5GRQKSCMVvLyl4rFw== 1347 UAAMm5GRQKSCMVvLyl4rFw== 1348 1349 1351 4. Security Considerations 1353 Security considerations mentioned in [I-D.ietf-siprec-metadata] and 1354 [I-D.ietf-siprec-protocol] has to be followed by SRC and SRS for 1355 setting up RS SIP dialog and sending metadata. 1357 5. IANA Considerations 1359 This document has no IANA considerations 1361 6. Acknowledgement 1363 Thanks to Ofir Rath, Charles Eckel and Yaron Pdut for their review 1364 comments. 1366 7. Informative References 1368 [I-D.ietf-siprec-metadata] 1369 R, R., Ravindran, P., and P. Kyzivat, "Session Initiation 1370 Protocol (SIP) Recording Metadata", draft-ietf-siprec- 1371 metadata-18 (work in progress), August 2015. 1373 [RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor, 1374 "An Architecture for Media Recording Using the Session 1375 Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May 1376 2014, . 1378 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A 1379 Session Initiation Protocol (SIP) Event Package for 1380 Conference State", RFC 4575, DOI 10.17487/RFC4575, August 1381 2006, . 1383 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1384 Session Initiation Protocol (SIP)", RFC 4353, 1385 DOI 10.17487/RFC4353, February 2006, 1386 . 1388 [RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media 1389 Control Channel Framework", RFC 6230, 1390 DOI 10.17487/RFC6230, May 2011, 1391 . 1393 [RFC6341] Rehor, K., Ed., Portman, L., Ed., Hutton, A., and R. Jain, 1394 "Use Cases and Requirements for SIP-Based Media Recording 1395 (SIPREC)", RFC 6341, DOI 10.17487/RFC6341, August 2011, 1396 . 1398 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1399 A., Peterson, J., Sparks, R., Handley, M., and E. 1400 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1401 DOI 10.17487/RFC3261, June 2002, 1402 . 1404 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1405 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1406 July 2006, . 1408 [I-D.ietf-siprec-protocol] 1409 Portman, L., Lum, H., Eckel, C., Johnston, A., and A. 1410 Hutton, "Session Recording Protocol", draft-ietf-siprec- 1411 protocol-18 (work in progress), September 2015. 1413 Authors' Addresses 1415 Ram Mohan Ravindranath 1416 Cisco Systems, Inc. 1417 Cessna Business Park, 1418 Kadabeesanahalli Village, Varthur Hobli, 1419 Sarjapur-Marathahalli Outer Ring Road 1420 Bangalore, Karnataka 560103 1421 India 1423 Email: rmohanr@cisco.com 1425 Parthasarathi Ravindran 1426 Nokia Networks 1427 Bangalore, Karnataka 1428 India 1430 Email: partha@parthasarathi.co.in 1432 Paul Kyzivat 1433 Huawei 1434 Hudson, MA 1435 USA 1437 Email: pkyzivat@alum.mit.edu