idnits 2.17.1 draft-ietf-siprec-callflows-05.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 (July 30, 2015) is 3193 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-17 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPREC Ram Mohan. Ravindranath 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track Parthasarathi. Ravindran 5 Expires: January 31, 2016 Nokia Networks 6 Paul. Kyzivat 7 Huawei 8 July 30, 2015 10 Session Initiation Protocol (SIP) Recording Call Flows 11 draft-ietf-siprec-callflows-05 13 Abstract 15 Session recording is a critical requirement in many communications 16 environments such as call centers and financial trading. In some of 17 these environments, all calls must be recorded for regulatory, 18 compliance, and consumer protection reasons. Recording of a session 19 is typically performed by sending a copy of a media stream to a 20 recording device. This document lists call flows that has snapshot 21 of metadata sent from SRC to SRS. This is purely an informational 22 document that is written to support the model defined in the metadata 23 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 31, 2016. 42 Copyright Notice 44 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . 8 67 3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) . 11 68 3.2.4. Example 4: Call disconnect . . . . . . . . . . . . . . 18 69 3.3. Call Scenarios with SRC recording streams by mixing . . . 20 70 3.3.1. Example 1: Basic call with SRC mixing streams . . . . 20 71 3.3.2. Example 2: Hold/resume with SRC recording by 72 mixing streams . . . . . . . . . . . . . . . . . . . . 22 73 3.3.3. Example 3: Metadata snapshot of joining/dropping 74 of a participant to a session . . . . . . . . . . . . 26 75 3.3.4. Example 4: Call disconnect . . . . . . . . . . . . . . 29 76 3.4. Call scenarios with persistent RS between SRC and SRS . . 29 77 3.4.1. Example 1: Metadata snapshot during CS disconnect 78 with persistent RS between SRC and SRS . . . . . . . . 29 79 3.5. Turrent-Case: Multiple CS into single RS with mixed 80 stream . . . . . . . . . . . . . . . . . . . . . . . . . . 30 81 4. Security Considerations . . . . . . . . . . . . . . . . . . . 33 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 83 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 33 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 85 7.1. Normative References . . . . . . . . . . . . . . . . . . . 34 86 7.2. Informative References . . . . . . . . . . . . . . . . . . 34 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 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 [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 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 [RFC7245] an SRC may be a 150 endpoint or B2BUA or as part of MEDIACTRL or Conference Focus. The 151 subsequent sections in this document tries to list some example 152 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 [RFC7245] where an SRC may be a SIP-UA or B2BUA. The 170 SRS here could be a SIP-UA or an entity part of MEDIACTRL 171 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. In this example the SRC is a B2BUA in 179 the path between Alice and Bob as described in section 3.1.1 of 180 [RFC7245]. Below is the initial snapshot sent by SRC in the INVITE 181 to SRS that has complete metadata. For the sake of simplicity only 182 snippets of SIP/SDP are shown. The SRCs records the streams of each 183 participant to SRS with out mixing in this example. 185 F1 INVITE SRC --------------> SRS 187 INVITE sip:recorder@example.com SIP/2.0 188 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 189 From: ;tag=35e195d2-947d-4585-946f-09839247 190 To: 191 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 192 Session-ID: ab30317f1a784dc48ff824d0d3715d86 193 ;remote=00000000000000000000000000000000 194 CSeq: 101 INVITE 195 Max-Forwards: 70 196 Require: siprec 197 Accept: application/sdp, application/rs-metadata, 198 application/rs-metadata-request 199 Contact: ;+sip.src 200 Content-Type: multipart/mixed;boundary=foobar 201 Content-Length: [length] 203 --foobar 204 Content-Type: application/SDP 205 ... 206 m=audio 49170 RTP/AVP 0 207 a=rtpmap:0 PCMU/8000 208 a=label:96 209 a=sendonly 210 ... 211 m=video 49174 RTP/AVPF 96 212 a=rtpmap:96 H.264/90000 213 a=label:97 214 a=sendonly 215 ... 216 m=audio 51372 RTP/AVP 0 217 a=rtpmap:0 PCMU/8000 218 a=label:98 219 a=sendonly 220 ... 221 m=video 49176 RTP/AVPF 96 222 a=rtpmap:96 H.264/90000 223 a=label:99 224 a=sendonly 225 .... 226 --foobar 227 Content-Type: application/rs-metadata 228 Content-Disposition: recording-session 229 230 231 complete 232 233 2010-12-16T23:41:07Z 234 235 236 sip:alice@atlanta.com 237 238 239 FOO! 240 bar 241 242 243 244 ab30317f1a784dc48ff824d0d3715d86; 245 remote=47755a9de7794ba387653f2099600ef2 246 7+OTCyoxTmqmqyA/1weDAg== 247 248 249 250 FOO! 251 bar 252 253 254 256 257 Alice 258 259 260 261 FOO! 262 bar 263 264 265 267 268 Bob 269 270 271 272 FOO! 273 bar 274 275 276 278 279 280 282 283 284 286 287 288 290 291 292 293 2010-12-16T23:41:07Z 294 295 298 2010-12-16T23:41:07Z 299 300 303 2010-12-16T23:41:07Z 305 306 308 i1Pz3to5hGk8fuXl+PbwCw== 309 UAAMm5GRQKSCMVvLyl4rFw== 310 8zc6e0lYTlWIINA6GR+3ag== 311 EiXGlc+4TruqqoDaNE76ag== 312 313 315 8zc6e0lYTlWIINA6GR+3ag== 316 EiXGlc+4TruqqoDaNE76ag== 317 UAAMm5GRQKSCMVvLyl4rFw== 318 i1Pz3to5hGk8fuXl+PbwCw== 319 320 322 3.2.2. Example 2: Hold/resume 324 Assume a call between two Participants Alice and Bob is established 325 and a RS is created for recording as in example1. This is the 326 continuation of above use-case. One of the participants Bob puts 327 Alice hold and then resumes as part of the same session. The send 328 and recv XML elements of a participant is used to indicate whether a 329 participant is sending not sending a particular media stream whose 330 properties are represented by stream element. SRC sends a snapshot 331 with only the changed XML elements. 333 During hold 335 F2 mid call RE-INVITE SRC-------------------->SRS 337 INVITE sip:recorder@example.com SIP/2.0 338 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 339 From: ;tag=35e195d2-947d-4585-946f-09839247 340 To: 341 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 342 Session-ID: ab30317f1a784dc48ff824d0d3715d86 343 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 344 CSeq: 101 INVITE 345 Max-Forwards: 70 346 Require: siprec 347 Accept: application/sdp, application/rs-metadata, 348 application/rs-metadata-request 349 Contact: ;+sip.src 350 Content-Type: multipart/mixed;boundary=foobar 351 Content-Length: [length] 353 --foobar 354 Content-Type: application/SDP 355 ... 356 m=audio 49170 RTP/AVP 0 357 a=rtpmap:0 PCMU/8000 358 a=label:96 359 a=sendonly 360 ... 361 m=video 49174 RTP/AVPF 96 362 a=rtpmap:96 H.264/90000 363 a=label:97 364 a=sendonly 365 ... 366 m=audio 51372 RTP/AVP 0 367 a=rtpmap:0 PCMU/8000 368 a=label:98 369 a=sendonly 370 ... 371 m=video 49176 RTP/AVPF 96 372 a=rtpmap:96 H.264/90000 373 a=label:99 374 a=sendonly 375 .... 377 --foobar 378 Content-Type: application/rs-metadata 379 Content-Disposition: recording-session 381 382 383 partial 384 386 8zc6e0lYTlWIINA6GR+3ag== 387 EiXGlc+4TruqqoDaNE76ag== 388 389 391 8zc6e0lYTlWIINA6GR+3ag== 392 EiXGlc+4TruqqoDaNE76ag== 393 394 396 In the above snippet, Alice with participant_id 397 srfBElmCRp2QB23b7Mpk0w== only receives media streams and does not 398 send any media. The same is indicated by the absence of send XML 399 element. Bob(participant_id zSfPoSvdSDCmU3A3TRDxAw==) on the other 400 hand would be sending media but does not receive any media from Alice 401 and so recv XML element is absent in this instance. 403 During resume 405 The snapshot now has send and recv XML elements for both Alice and 406 Bob indicating that both are receiving and sending media. 408 F3 mid call RE-INVITE SRC-------------------->SRS 410 INVITE sip:recorder@example.com SIP/2.0 411 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 412 From: ;tag=35e195d2-947d-4585-946f-09839247 413 To: 414 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 415 Session-ID: ab30317f1a784dc48ff824d0d3715d86 416 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 417 CSeq: 101 INVITE 418 Max-Forwards: 70 419 Require: siprec 420 Accept: application/sdp, application/rs-metadata, 421 application/rs-metadata-request 422 Contact: ;+sip.src 423 Content-Type: multipart/mixed;boundary=foobar 424 Content-Length: [length] 426 --foobar 427 Content-Type: application/SDP 428 ... 429 m=audio 49170 RTP/AVP 0 430 a=rtpmap:0 PCMU/8000 431 a=label:96 432 a=sendonly 433 ... 434 m=video 49174 RTP/AVPF 96 435 a=rtpmap:96 H.264/90000 436 a=label:97 437 a=sendonly 438 ... 439 m=audio 51372 RTP/AVP 0 440 a=rtpmap:0 PCMU/8000 441 a=label:98 442 a=sendonly 443 ... 444 m=video 49176 RTP/AVPF 96 445 a=rtpmap:96 H.264/90000 446 a=label:99 447 a=sendonly 448 .... 449 --foobar 450 Content-Type: application/rs-metadata 451 Content-Disposition: recording-session 453 454 455 partial 456 458 8zc6e0lYTlWIINA6GR+3ag== 459 EiXGlc+4TruqqoDaNE76ag== 460 i1Pz3to5hGk8fuXl+PbwCw== 461 UAAMm5GRQKSCMVvLyl4rFw== 462 463 465 8zc6e0lYTlWIINA6GR+3ag== 466 EiXGlc+4TruqqoDaNE76ag== 467 i1Pz3to5hGk8fuXl+PbwCw== 468 UAAMm5GRQKSCMVvLyl4rFw== 469 470 472 3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) 474 Basic call between two Participants Alice and Bob is connected and 475 SRC(B2BUA as per section 3.1.1 of [RFC7245]) has sent a snapshot as 476 in example 1. Transfer is initiated by one of the 477 participants(Alice). After the transfer is completed, SRC sends a 478 snapshot of the participant changes to SRS. In this transfer 479 scenario, Alice drops out after transfer is completed and Bob and 480 Carol gets connected and recording of media between Bob and Carol is 481 done by SRC. There may be two cases here as described 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. Also note that 588 the SRC in this example uses the same RS. In case it decides to use 589 a new RS, it will tear down the current RS using normal SIP 590 procedures (BYE) with 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] 610 --foobar 611 Content-Type: application/SDP 612 ... 613 m=audio 49180 RTP/AVP 0 614 a=rtpmap:0 PCMU/8000 615 a=label:96 616 a=sendonly 617 ... 618 m=video 49182 RTP/AVPF 96 619 a=rtpmap:96 H.264/90000 620 a=label:97 621 a=sendonly 622 ... 623 m=audio 51374 RTP/AVP 0 624 a=rtpmap:0 PCMU/8000 625 a=label:98 626 a=sendonly 627 ... 628 m=video 49178 RTP/AVPF 96 629 a=rtpmap:96 H.264/90000 630 a=label:99 631 a=sendonly 632 .... 634 --foobar 635 Content-Type: application/rs-metadata 636 Content-Disposition: recording-session 638 639 640 Partial 641 642 2010-12-16T23:41:07Z 643 644 647 2010-12-16T23:41:07Z 648 649 652 2010-12-16T23:41:07Z 653 654 656 Note in the above snapshot the participantsessionassoc element is 657 optional as indicating session XML element with a stop-time 658 implicitly means that all the participants associated with that 659 session have been disassociated. 661 SRC sends another snapshot to indicate the participant change (due to 662 REFER) and new session information after transfer. In this example 663 it is assumed SRC uses the same Recording Session to continue 664 recording the call. Also note that the sipSessionID XML element in 665 metadata snapshot now indicates Alice and Carol in the (local, 666 remote) uuid pair. 668 mid call RE-INVITE SRC-------------------->SRS 669 INVITE sip:recorder@example.com SIP/2.0 670 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 671 From: ;tag=35e195d2-947d-4585-946f-09839247 672 To: 673 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 674 Session-ID: ab30317f1a784dc48ff824d0d3715d86 675 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 676 CSeq: 101 INVITE 677 Max-Forwards: 70 678 Require: siprec 679 Accept: application/sdp, application/rs-metadata, 680 application/rs-metadata-request 681 Contact: ;+sip.src 682 Content-Type: multipart/mixed;boundary=foobar 683 Content-Length: [length] 685 --foobar 686 Content-Type: application/SDP 687 ... 688 m=audio 49180 RTP/AVP 0 689 a=rtpmap:0 PCMU/8000 690 a=label:96 691 a=sendonly 692 ... 693 m=video 49182 RTP/AVPF 96 694 a=rtpmap:96 H.264/90000 695 a=label:97 696 a=sendonly 697 ... 698 m=audio 51374 RTP/AVP 0 699 a=rtpmap:0 PCMU/8000 700 a=label:98 701 a=sendonly 702 ... 703 m=video 49178 RTP/AVPF 96 704 a=rtpmap:96 H.264/90000 705 a=label:99 706 a=sendonly 707 .... 709 --foobar 710 Content-Type: application/rs-metadata 712 713 714 complete 715 716 2010-12-16T23:41:07Z 717 3363127f0d084c10876dddd4f8e5eeb9 718 ;remote=2272bb7e70fe41dba0025ae9a26d54cf 719 720 722 723 724 726 727 728 730 731 732 734 735 736 738 739 740 742 743 744 747 2010-12-16T23:32:03Z 748 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 an SRC at CS 773 disconnect where the participants of CS are Alice and Bob 774 SRC SRS 775 | | 776 |(1) BYE (metadata snapshot) F1 | 777 |---------------------------------------------------->| 778 | 200 OK F2 | 779 |<----------------------------------------------------| 781 F1 BYE SRC -----------> SRS 783 BYE sip:2001@example.com SIP/2.0 784 Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30 785 From: ;tag=35e195d2-947d-4585-946f-09839247 786 To: 787 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 788 Session-ID: ab30317f1a784dc48ff824d0d3715d86 789 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 790 CSeq: 102 BYE 791 Max-Forwards: 70 792 Require: siprec 793 Accept: 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/rs-metadata 802 803 804 Partial 805 806 2010-12-16T23:41:07Z 807 808 811 2010-12-16T23:41:07Z 812 814 817 2010-12-16T23:41:07Z 818 819 821 3.3. Call Scenarios with SRC recording streams by mixing 823 The section covers the models mentioned in the architecture document 824 in section 3 of [RFC7245] where an SRC may be part of Conference 825 model either as Focus or a participant in Conference. The SRS here 826 could be a SIP UA or an entity part of MEDIACTRL architecture. Note 827 that the disconnect case is not shown since the metadata snapshot 828 will be same as for a non-mixing case. 830 3.3.1. Example 1: Basic call with SRC mixing streams 832 Basic call between two Participants Alice and Bob who are part of one 833 CS. In this use case each participant call into a conference server 834 (say, an MCU) to attend one of many conferences hosted on or managed 835 by that servers. Media Streams sent by each participant is received 836 by the other participant. Below is the initial snapshot sent by SRC 837 in the INVITE to SRS that has complete metadata. For the sake of 838 simplicity only snippets of SIP/SDP are shown. The SRCs records the 839 streams of each participant to SRS by mixing in this example. The 840 SRC here is part of conference model described in section 3 of 841 [RFC7245] as a Focus and does mixing. The SRC here is not a 842 participant by itself and hence it does not contribute to streams. 844 F1 INVITE SRC --------------> SRS 846 INVITE sip:recorder@example.com SIP/2.0 847 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 848 From: ;tag=35e195d2-947d-4585-946f-09839247 849 To: 850 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 851 Session-ID: a358d2b81a444a8c8fb05950cef331e7 852 ;remote=00000000000000000000000000000000 853 CSeq: 101 INVITE 854 Max-Forwards: 70 855 Require: siprec 856 Accept: application/sdp, application/rs-metadata, 857 application/rs-metadata-request 858 Contact: ;+sip.src 859 Content-Type: multipart/mixed;boundary=foobar 860 Content-Length: [length] 862 --foobar 863 Content-Type: application/SDP 864 ... 865 m=audio 49170 RTP/AVP 0 866 a=rtpmap:0 PCMU/8000 867 a=label:96 868 a=sendonly 870 .... 871 --foobar 872 Content-Type: application/rs-metadata 873 Content-Disposition: recording-session 874 875 876 complete 877 878 2010-12-16T23:41:07Z 879 fa3b60f27e91441e84c55a9a0095f075 880 ;remote=a358d2b81a444a8c8fb05950cef331e7 881 ca718e1430474b5485a53aa5d0bea45e 882 ;remote=68caf509b9284b7ea45f84a049febf0a 883 884 886 887 Alice 888 889 890 892 893 Bob 894 895 896 898 899 900 903 2010-12-16T23:41:07Z 904 905 907 i1Pz3to5hGk8fuXl+PbwCw== 908 i1Pz3to5hGk8fuXl+PbwCw== 909 911 914 2010-12-16T23:41:07Z 916 917 919 i1Pz3to5hGk8fuXl+PbwCw== 920 i1Pz3to5hGk8fuXl+PbwCw== 921 923 925 In the above example there are two participants Alice and Bob in the 926 conference. Among other things, SRC sends Session-ID in the metadata 927 snapshot. There are two Session-ID's here, one that corresponds to 928 the SIP session between Alice and Conference Focus and the other for 929 the SIP session between Bob and Conference Focus. In this use-case, 930 since Alice and Bob calls into the conference these Session-ID's are 931 different. 933 3.3.2. Example 2: Hold/resume with SRC recording by mixing streams 935 Assume a call between two Participants Alice and Bob is established 936 and a RS is created for recording as in example 5. This is the 937 continuation of above use-case. One of the participants Bob puts 938 Alice hold and then resumes as part of the same session. The send 939 and recv XML elements of a participant is used to indicate whether a 940 participant is sending not sending a particular media stream whose 941 properties are represented by stream element. The metadata snapshot 942 looks as below: 944 During hold 945 mid call hold RE-INVITE SRC --------------> SRS 947 INVITE sip:recorder@example.com SIP/2.0 948 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 949 From: ;tag=35e195d2-947d-4585-946f-09839247 950 To: 951 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 952 Session-ID: a358d2b81a444a8c8fb05950cef331e7 953 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 954 CSeq: 101 INVITE 955 Max-Forwards: 70 956 Require: siprec 957 Accept: application/sdp, application/rs-metadata, 958 application/rs-metadata-request 959 Contact: ;+sip.src 960 Content-Type: multipart/mixed;boundary=foobar 961 Content-Length: [length] 963 --foobar 964 Content-Type: application/SDP 965 ... 966 m=audio 49170 RTP/AVP 0 967 a=rtpmap:0 PCMU/8000 968 a=label:96 969 a=sendonly 971 .... 972 --foobar 973 Content-Type: application/rs-metadata 974 Content-Disposition: recording-session 975 976 977 partial 978 980 981 982 984 i1Pz3to5hGk8fuXl+PbwCw== 985 986 988 i1Pz3to5hGk8fuXl+PbwCw== 989 990 992 During resume a snapshot shown below will be sent from SRC to SRS 993 mid call resume RE-INVITE SRC --------------> SRS 995 INVITE sip:recorder@example.com SIP/2.0 996 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 997 From: ;tag=35e195d2-947d-4585-946f-09839247 998 To: 999 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1000 Session-ID: a358d2b81a444a8c8fb05950cef331e7 1001 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 1002 CSeq: 101 INVITE 1003 Max-Forwards: 70 1004 Require: siprec 1005 Accept: application/sdp, application/rs-metadata, 1006 application/rs-metadata-request 1007 Contact: ;+sip.src 1008 Content-Type: multipart/mixed;boundary=foobar 1009 Content-Length: [length] 1011 --foobar 1012 Content-Type: application/SDP 1013 ... 1014 m=audio 49170 RTP/AVP 0 1015 a=rtpmap:0 PCMU/8000 1016 a=label:96 1017 a=sendonly 1019 .... 1020 --foobar 1021 Content-Type: application/rs-metadata 1022 Content-Disposition: recording-session 1023 1024 1025 partial 1026 1028 1029 1030 1032 i1Pz3to5hGk8fuXl+PbwCw== 1033 i1Pz3to5hGk8fuXl+PbwCw== 1034 1035 1037 i1Pz3to5hGk8fuXl+PbwCw== 1038 i1Pz3to5hGk8fuXl+PbwCw== 1039 1040 1042 3.3.3. Example 3: Metadata snapshot of joining/dropping of a 1043 participant to a session 1045 In a conference model, participants can join and drop a session any 1046 time during the session. The below shows a snapshot sent from SRC to 1047 SRC in these case. Note the SRC here can be a focus or a participant 1048 in the conference. In case where the SRC is a participant it may 1049 learn the information required for metadata by subscribing to 1050 conference event package [RFC4575]. Assume Alice and Bob were in the 1051 conference and a third participant Carol joins, then SRC sends the 1052 below snapshot with the indication of new participant. 1054 mid call resume RE-INVITE SRC --------------> SRS 1056 INVITE sip:recorder@example.com SIP/2.0 1057 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 1058 From: ;tag=35e195d2-947d-4585-946f-09839247 1059 To: 1060 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1061 Session-ID: a358d2b81a444a8c8fb05950cef331e7 1062 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 1063 CSeq: 101 INVITE 1064 Max-Forwards: 70 1065 Require: siprec 1066 Accept: application/sdp, application/rs-metadata, 1067 application/rs-metadata-request 1068 Contact: ;+sip.src 1069 Content-Type: multipart/mixed;boundary=foobar 1070 Content-Length: [length] 1072 --foobar 1073 Content-Type: application/SDP 1074 ... 1075 m=audio 49170 RTP/AVP 0 1076 a=rtpmap:0 PCMU/8000 1077 a=label:96 1078 a=sendonly 1080 .... 1081 --foobar 1082 Content-Type: application/rs-metadata 1083 Content-Disposition: recording-session 1084 1085 1086 partial 1087 1089 fa3b60f27e91441e84c55a9a0095f075 1090 ;remote=a358d2b81a444a8c8fb05950cef331e7 1091 ca718e1430474b5485a53aa5d0bea45e 1092 ;remote=68caf509b9284b7ea45f84a049febf0a 1093 497c0f13929643b4a16858e2a3885edc 1094 ;remote=0e8a82bedda74f57be4a4a4da54167c4 1095 1096 1098 1099 Carol 1100 1101 1102 1105 2013-12-16T23:41:07Z 1106 1107 1109 i1Pz3to5hGk8fuXl+PbwCw== 1110 i1Pz3to5hGk8fuXl+PbwCw== 1111 1112 1114 Assume Alice drops after some time from the conference. SRC 1115 generates a new snapshot showing Alice disassociating from the 1116 session 1117 mid call resume RE-INVITE SRC --------------> SRS 1119 INVITE sip:recorder@example.com SIP/2.0 1120 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 1121 From: ;tag=35e195d2-947d-4585-946f-09839247 1122 To: 1123 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1124 Session-ID: a358d2b81a444a8c8fb05950cef331e7 1125 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 1126 CSeq: 101 INVITE 1127 Max-Forwards: 70 1128 Require: siprec 1129 Accept: application/sdp, application/rs-metadata, 1130 application/rs-metadata-request 1131 Contact: ;+sip.src 1132 Content-Type: multipart/mixed;boundary=foobar 1133 Content-Length: [length] 1135 --foobar 1136 Content-Type: application/SDP 1137 ... 1138 m=audio 49170 RTP/AVP 0 1139 a=rtpmap:0 PCMU/8000 1140 a=label:96 1141 a=sendonly 1143 .... 1144 --foobar 1145 Content-Type: application/rs-metadata 1146 Content-Disposition: recording-session 1147 1148 1149 partial 1150 1151 ca718e1430474b5485a53aa5d0bea45e 1152 ;remote=68caf509b9284b7ea45f84a049febf0a 1153 497c0f13929643b4a16858e2a3885edc 1154 ;remote=0e8a82bedda74f57be4a4a4da54167c4 1155 1156 1159 2010-12-16T23:41:07Z 1160 1161 1163 3.3.4. Example 4: Call disconnect 1165 When a CS is disconnected, SRC sends BYE with a snapshot of metadata 1166 having session stop-time and participant dis-associate times. The 1167 snapshot looks same as listed in section 3.2.4 1169 3.4. Call scenarios with persistent RS between SRC and SRS 1171 The section shows the snapshots of metadata for the cases there a 1172 persistent RS exists between SRC and SRS. An SRC here may be SIP UA 1173 or a B2BUA or may be part of Conference model either as Focus or a 1174 participant in Conference. The SRS here could be a SIP UA or an 1175 entity part of MEDIACTRL architecture. Except disconnect case, the 1176 snapshot remains same as one of the examples mentioned in previous 1177 sections. 1179 3.4.1. Example 1: Metadata snapshot during CS disconnect with 1180 persistent RS between SRC and SRS 1182 RE-INVITE sent from SRC -----------> SRS 1184 INVITE sip:2001@example.com SIP/2.0 1185 Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30 1186 From: ;tag=35e195d2-947d-4585-946f-09839247 1187 To: 1188 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1189 Session-ID: ab30317f1a784dc48ff824d0d3715d86 1190 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 1191 CSeq: 101 INVITE 1192 Max-Forwards: 70 1193 Require: siprec 1194 Accept: application/rs-metadata, 1195 application/rs-metadata-request 1196 Contact: ;+sip.src 1197 Content-Type: multipart/mixed;boundary=foobar 1198 Content-Length: [length] 1200 --foobar 1201 Content-Type: application/rs-metadata 1203 1204 1205 Partial 1206 1207 2010-12-16T23:41:07Z 1208 1209 1212 2010-12-16T23:41:07Z 1213 1215 1218 2010-12-16T23:41:07Z 1219 1220 1222 3.5. Turrent-Case: Multiple CS into single RS with mixed stream 1224 In trading floor environments, in order to minimize storage and 1225 recording system resources, it may be preferable to mix multiple 1226 concurrent calls (Communication Sessions) on different handsets/ 1227 speakers on the same turret into a single recording session. This 1228 would means media in each CS is mixed and recorded as part of single 1229 media stream and multiple such CSs are recording in one Recording 1230 Session from 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. 1239 o In of the CS(say CS1), SRC is Focus and in the other CS(say CS2), 1240 SRC is just one of the participant of the conference. 1241 o In both CS1 and CS2, SRC is just a participant of Conference. 1243 The following example shows the first possibility where CS1 and CS2 1244 uses the same Focus for fixing and that Focus is also acting as SRC 1245 in each of the CS. 1247 snapshot of metadata INVITE SRC --------------> SRS 1249 INVITE sip:recorder@example.com SIP/2.0 1250 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 1251 From: ;tag=35e195d2-947d-4585-946f-09839247 1252 To: 1253 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1254 Session-ID: a358d2b81a444a8c8fb05950cef331e7 1255 ;remote=00000000000000000000000000000000 1256 Content-Type: application/SDP 1257 ... 1258 m=audio 49170 RTP/AVP 0 1259 a=rtpmap:0 PCMU/8000 1260 a=label:96 1261 a=sendonly 1262 ... 1263 1264 1265 complete 1266 1267 2010-12-16T23:41:07Z 1268 1269 1270 7+OTCyoxTmqmqyA/1weDAg== 1271 2010-12-16T23:41:07Z 1272 fa3b60f27e91441e84c55a9a0095f075 1273 ;remote=a358d2b81a444a8c8fb05950cef331e7 1274 ca718e1430474b5485a53aa5d0bea45e 1275 ;remote=a358d2b81a444a8c8fb05950cef331e7 1276 497c0f13929643b4a16858e2a3885edc 1277 ;remote=a358d2b81a444a8c8fb05950cef331e7 1278 1279 1280 7+OTCyoxTmqmqyA/1weDAg== 1281 2010-12-16T23:43:07Z 1282 ae10731ca50343a5aaae2dd0904a65de 1283 ;remote=a358d2b81a444a8c8fb05950cef331e7 1284 33c77aac7deb414cbc8c10f363fccb71 1285 ;remote=a358d2b81a444a8c8fb05950cef331e7 1286 fd6932e9e5fc489fae2d5b3779723b7e 1287 ;remote=a358d2b81a444a8c8fb05950cef331e7 1288 1289 1291 1292 Alice 1293 1294 1295 1297 1298 Bob 1299 1300 1301 1303 1304 Carol 1305 1306 1307 1309 1310 1311 1314 2010-12-16T23:41:07Z 1315 1316 1319 2010-12-16T23:41:07Z 1320 1321 1324 2010-12-16T23:43:07Z 1325 1326 1329 2010-12-16T23:43:07Z 1330 1332 1334 UAAMm5GRQKSCMVvLyl4rFw== 1335 UAAMm5GRQKSCMVvLyl4rFw== 1336 1337 1339 UAAMm5GRQKSCMVvLyl4rFw== 1340 UAAMm5GRQKSCMVvLyl4rFw== 1341 1342 1344 UAAMm5GRQKSCMVvLyl4rFw== 1345 UAAMm5GRQKSCMVvLyl4rFw== 1346 1347 1349 4. Security Considerations 1351 There is no security consideration as it is informational callflow 1352 document. 1354 5. IANA Considerations 1356 This document has no IANA considerations 1358 6. Acknowledgement 1360 Thanks to Ofir Rath, Charles Eckel and Yaron Pdut for their review 1361 comments. 1363 7. References 1364 7.1. Normative References 1366 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1367 A., Peterson, J., Sparks, R., Handley, M., and E. 1368 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1369 DOI 10.17487/RFC3261, June 2002, 1370 . 1372 7.2. Informative References 1374 [I-D.ietf-siprec-metadata] 1375 R, R., Ravindran, P., and P. Kyzivat, "Session Initiation 1376 Protocol (SIP) Recording Metadata", 1377 draft-ietf-siprec-metadata-17 (work in progress), 1378 February 2015. 1380 [RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor, 1381 "An Architecture for Media Recording Using the Session 1382 Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, 1383 May 2014, . 1385 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A 1386 Session Initiation Protocol (SIP) Event Package for 1387 Conference State", RFC 4575, DOI 10.17487/RFC4575, 1388 August 2006, . 1390 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1391 Session Initiation Protocol (SIP)", RFC 4353, 1392 DOI 10.17487/RFC4353, February 2006, 1393 . 1395 [RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media 1396 Control Channel Framework", RFC 6230, DOI 10.17487/ 1397 RFC6230, May 2011, 1398 . 1400 Authors' Addresses 1402 Ram Mohan Ravindranath 1403 Cisco Systems, Inc. 1404 Cessna Business Park, 1405 Kadabeesanahalli Village, Varthur Hobli, 1406 Sarjapur-Marathahalli Outer Ring Road 1407 Bangalore, Karnataka 560103 1408 India 1410 Email: rmohanr@cisco.com 1412 Parthasarathi Ravindran 1413 Nokia Networks 1414 Bangalore, Karnataka 1415 India 1417 Email: partha@parthasarathi.co.in 1419 Paul Kyzivat 1420 Huawei 1421 Hudson, MA 1422 USA 1424 Email: pkyzivat@alum.mit.edu