idnits 2.17.1 draft-ietf-siprec-callflows-04.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 (February 28, 2015) is 3338 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: September 1, 2015 Nokia Networks 6 Paul. Kyzivat 7 Huawei 8 February 28, 2015 10 Session Initiation Protocol (SIP) Recording Call Flows 11 draft-ietf-siprec-callflows-04 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 September 1, 2015. 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 . . . . . . . . . . . . . . . . 7 67 3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) . 11 68 3.2.4. Example 4: Call disconnect . . . . . . . . . . . . . . 17 69 3.3. Call Scenarios with SRC recording streams by mixing . . . 19 70 3.3.1. Example 1: Basic call with SRC mixing streams . . . . 19 71 3.3.2. Example 2: Hold/resume with SRC recording by 72 mixing streams . . . . . . . . . . . . . . . . . . . . 21 73 3.3.3. Example 3: Metadata snapshot of joining/dropping 74 of a participant to a session . . . . . . . . . . . . 25 75 3.3.4. Example 4: Call disconnect . . . . . . . . . . . . . . 28 76 3.4. Call scenarios with persistent RS between SRC and SRS . . 28 77 3.4.1. Example 1: Metadata snapshot during CS disconnect 78 with persistent RS between SRC and SRS . . . . . . . . 28 79 3.5. Turrent-Case: Multiple CS into single RS with mixed 80 stream . . . . . . . . . . . . . . . . . . . . . . . . . . 29 81 4. Security Considerations . . . . . . . . . . . . . . . . . . . 32 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 83 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 32 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 85 7.1. Normative References . . . . . . . . . . . . . . . . . . . 33 86 7.2. Informative References . . . . . . . . . . . . . . . . . . 33 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 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 47755a9de7794ba387653f2099600ef2 235 ;remote=3363127f0d084c10876dddd4f8e5eeb9 236 237 239 240 Alice 241 242 243 246 2010-12-16T23:41:07Z 247 248 250 i1Pz3to5hGk8fuXl+PbwCw== 251 UAAMm5GRQKSCMVvLyl4rFw== 252 8zc6e0lYTlWIINA6GR+3ag== 253 EiXGlc+4TruqqoDaNE76ag== 254 255 257 258 Bob 259 260 261 264 2010-12-16T23:41:07Z 265 266 268 8zc6e0lYTlWIINA6GR+3ag== 269 EiXGlc+4TruqqoDaNE76ag== 270 UAAMm5GRQKSCMVvLyl4rFw== 271 i1Pz3to5hGk8fuXl+PbwCw== 272 273 275 276 277 279 280 281 283 284 285 287 288 289 291 3.2.2. Example 2: Hold/resume 293 Assume a call between two Participants Alice and Bob is established 294 and a RS is created for recording as in example1. This is the 295 continuation of above use-case. One of the participants Bob puts 296 Alice hold and then resumes as part of the same session. The send 297 and recv XML elements of a participant is used to indicate whether a 298 participant is sending not sending a particular media stream whose 299 properties are represented by stream element. SRC sends a snapshot 300 with only the changed XML elements. 302 During hold 303 F2 mid call RE-INVITE SRC-------------------->SRS 305 INVITE sip:recorder@example.com SIP/2.0 306 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 307 From: ;tag=35e195d2-947d-4585-946f-09839247 308 To: 309 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 310 Session-ID: ab30317f1a784dc48ff824d0d3715d86 311 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 312 CSeq: 101 INVITE 313 Max-Forwards: 70 314 Require: siprec 315 Accept: application/sdp, application/rs-metadata, 316 application/rs-metadata-request 317 Contact: ;+sip.src 318 Content-Type: multipart/mixed;boundary=foobar 319 Content-Length: [length] 321 --foobar 322 Content-Type: application/SDP 323 ... 324 m=audio 49170 RTP/AVP 0 325 a=rtpmap:0 PCMU/8000 326 a=label:96 327 a=sendonly 328 ... 329 m=video 49174 RTP/AVPF 96 330 a=rtpmap:96 H.264/90000 331 a=label:97 332 a=sendonly 333 ... 334 m=audio 51372 RTP/AVP 0 335 a=rtpmap:0 PCMU/8000 336 a=label:98 337 a=sendonly 338 ... 339 m=video 49176 RTP/AVPF 96 340 a=rtpmap:96 H.264/90000 341 a=label:99 342 a=sendonly 343 .... 345 --foobar 346 Content-Type: application/rs-metadata 347 Content-Disposition: recording-session 349 350 351 partial 352 354 8zc6e0lYTlWIINA6GR+3ag== 355 EiXGlc+4TruqqoDaNE76ag== 356 357 359 8zc6e0lYTlWIINA6GR+3ag== 360 EiXGlc+4TruqqoDaNE76ag== 361 362 364 In the above snippet, Alice with participant_id 365 srfBElmCRp2QB23b7Mpk0w== only receives media streams and does not 366 send any media. The same is indicated by the absence of send XML 367 element. Bob(participant_id zSfPoSvdSDCmU3A3TRDxAw==) on the other 368 hand would be sending media but does not receive any media from Alice 369 and so recv XML element is absent in this instance. 371 During resume 373 The snapshot now has send and recv XML elements for both Alice and 374 Bob indicating that both are receiving and sending media. 376 F3 mid call RE-INVITE SRC-------------------->SRS 378 INVITE sip:recorder@example.com SIP/2.0 379 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 380 From: ;tag=35e195d2-947d-4585-946f-09839247 381 To: 382 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 383 Session-ID: ab30317f1a784dc48ff824d0d3715d86 384 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 385 CSeq: 101 INVITE 386 Max-Forwards: 70 387 Require: siprec 388 Accept: application/sdp, application/rs-metadata, 389 application/rs-metadata-request 390 Contact: ;+sip.src 391 Content-Type: multipart/mixed;boundary=foobar 392 Content-Length: [length] 394 --foobar 395 Content-Type: application/SDP 396 ... 397 m=audio 49170 RTP/AVP 0 398 a=rtpmap:0 PCMU/8000 399 a=label:96 400 a=sendonly 401 ... 402 m=video 49174 RTP/AVPF 96 403 a=rtpmap:96 H.264/90000 404 a=label:97 405 a=sendonly 406 ... 407 m=audio 51372 RTP/AVP 0 408 a=rtpmap:0 PCMU/8000 409 a=label:98 410 a=sendonly 411 ... 412 m=video 49176 RTP/AVPF 96 413 a=rtpmap:96 H.264/90000 414 a=label:99 415 a=sendonly 416 .... 417 --foobar 418 Content-Type: application/rs-metadata 419 Content-Disposition: recording-session 421 422 423 partial 424 426 8zc6e0lYTlWIINA6GR+3ag== 427 EiXGlc+4TruqqoDaNE76ag== 428 i1Pz3to5hGk8fuXl+PbwCw== 429 UAAMm5GRQKSCMVvLyl4rFw== 430 431 433 8zc6e0lYTlWIINA6GR+3ag== 434 EiXGlc+4TruqqoDaNE76ag== 435 i1Pz3to5hGk8fuXl+PbwCw== 436 UAAMm5GRQKSCMVvLyl4rFw== 437 438 440 3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) 442 Basic call between two Participants Alice and Bob is connected and 443 SRC(B2BUA as per section 3.1.1 of [RFC7245]) has sent a snapshot as 444 in example 1. Transfer is initiated by one of the 445 participants(Alice). After the transfer is completed, SRC sends a 446 snapshot of the participant changes to SRS. In this transfer 447 scenario, Alice drops out after transfer is completed and Bob and 448 Carol gets connected and recording of media between Bob and Carol is 449 done by SRC. There may be two cases here as described below. 451 Transfer with in the same session - (.e.g. RE-INVITE based 452 transfer). Participant Alice drops out and Carol is added to the 453 same session. No change to session/group element. A 454 participantsessassoc element indicating that Alice has disassociated 455 from the CS will be present in the snapshot. A new participant XML 456 element representing Carol with mapping to the same RS SDP stream 457 used for mapping earlier Alice's stream is sent in the snapshot. A 458 new sipSessionID XML element that has UUID tuples which corresponds 459 to Bob and Carol is sent in the snapshot from SRC to SRS. Note that 460 one half of the session ID that corresponds to Bob remains same. 462 mid call RE-INVITE SRC-------------------->SRS 464 INVITE sip:recorder@example.com SIP/2.0 465 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 466 From: ;tag=35e195d2-947d-4585-946f-09839247 467 To: 468 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 469 Session-ID: ab30317f1a784dc48ff824d0d3715d86 470 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 471 CSeq: 101 INVITE 472 Max-Forwards: 70 473 Require: siprec 474 Accept: application/sdp, application/rs-metadata, 475 application/rs-metadata-request 476 Contact: ;+sip.src 477 Content-Type: multipart/mixed;boundary=foobar 478 Content-Length: [length] 480 --foobar 481 Content-Type: application/SDP 482 ... 483 m=audio 49180 RTP/AVP 0 484 a=rtpmap:0 PCMU/8000 485 a=label:96 486 a=sendonly 487 ... 488 m=video 49182 RTP/AVPF 96 489 a=rtpmap:96 H.264/90000 490 a=label:97 491 a=sendonly 492 ... 493 m=audio 51374 RTP/AVP 0 494 a=rtpmap:0 PCMU/8000 495 a=label:98 496 a=sendonly 497 ... 498 m=video 49178 RTP/AVPF 96 499 a=rtpmap:96 H.264/90000 500 a=label:99 501 a=sendonly 502 .... 503 --foobar 504 Content-Type: application/rs-metadata 505 Content-Disposition: recording-session 507 508 509 partial 510 511 3363127f0d084c10876dddd4f8e5eeb9 512 ;remote=2272bb7e70fe41dba0025ae9a26d54cf 513 514 517 2013-12-16T23:41:07Z 518 519 521 8zc6e0lYTlWIINA6GR+3ag== 522 EiXGlc+4TruqqoDaNE76ag== 523 60JAJm9UTvik0Ltlih/Gzw== 524 AcR5FUd3Edi8cACQJy/3JQ== 525 526 528 529 Carol 530 531 532 535 2013-12-16T23:41:07Z 536 537 539 60JAJm9UTvik0Ltlih/Gzw== 540 AcR5FUd3Edi8cACQJy/3JQ== 541 8zc6e0lYTlWIINA6GR+3ag== 542 EiXGlc+4TruqqoDaNE76ag== 543 2013-12-16T23:42:07Z 544 545 547 Transfer with new session - (.e.g. REFER based transfer). In this 548 case a new session (CS) is created and shall be part of same CS-group 549 (done by SRC). 551 SRC first sends an optional snapshot indicating disassociation of 552 participant from the old CS. Please note this is a optional message. 553 An SRC may choose to just send a INVITE with a new session element to 554 implicitly indicate that the participants are now part of a different 555 CS with out sending disassociation from the old CS. Also note that 556 the SRC in this example uses the same RS. In case it decides to use 557 a new RS, it will tear down the current RS using normal SIP 558 procedures (BYE) with metadata as in example 4. 560 mid call RE-INVITE SRC-------------------->SRS 562 INVITE sip:recorder@example.com SIP/2.0 563 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 564 From: ;tag=35e195d2-947d-4585-946f-09839247 565 To: 566 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 567 Session-ID: ab30317f1a784dc48ff824d0d3715d86 568 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 569 CSeq: 101 INVITE 570 Max-Forwards: 70 571 Require: siprec 572 Accept: application/sdp, application/rs-metadata, 573 application/rs-metadata-request 574 Contact: ;+sip.src 575 Content-Type: multipart/mixed;boundary=foobar 576 Content-Length: [length] 577 --foobar 578 Content-Type: application/SDP 579 ... 580 m=audio 49180 RTP/AVP 0 581 a=rtpmap:0 PCMU/8000 582 a=label:96 583 a=sendonly 584 ... 585 m=video 49182 RTP/AVPF 96 586 a=rtpmap:96 H.264/90000 587 a=label:97 588 a=sendonly 589 ... 590 m=audio 51374 RTP/AVP 0 591 a=rtpmap:0 PCMU/8000 592 a=label:98 593 a=sendonly 594 ... 595 m=video 49178 RTP/AVPF 96 596 a=rtpmap:96 H.264/90000 597 a=label:99 598 a=sendonly 599 .... 601 --foobar 602 Content-Type: application/rs-metadata 603 Content-Disposition: recording-session 605 606 607 Partial 608 609 2010-12-16T23:41:07Z 610 611 614 2010-12-16T23:41:07Z 615 616 619 2010-12-16T23:41:07Z 620 621 623 Note in the above snapshot the participantsessionassoc element is 624 optional as indicating session XML element with a stop-time 625 implicitly means that all the participants associated with that 626 session have been disassociated. 628 SRC sends another snapshot to indicate the participant change (due to 629 REFER) and new session information after transfer. In this example 630 it is assumed SRC uses the same Recording Session to continue 631 recording the call. Also note that the sipSessionID XML element in 632 metadata snapshot now indicates Alice and Carol in the (local, 633 remote) uuid pair. 635 mid call RE-INVITE SRC-------------------->SRS 637 INVITE sip:recorder@example.com SIP/2.0 638 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 639 From: ;tag=35e195d2-947d-4585-946f-09839247 640 To: 641 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 642 Session-ID: ab30317f1a784dc48ff824d0d3715d86 643 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 644 CSeq: 101 INVITE 645 Max-Forwards: 70 646 Require: siprec 647 Accept: application/sdp, application/rs-metadata, 648 application/rs-metadata-request 649 Contact: ;+sip.src 650 Content-Type: multipart/mixed;boundary=foobar 651 Content-Length: [length] 653 --foobar 654 Content-Type: application/SDP 655 ... 656 m=audio 49180 RTP/AVP 0 657 a=rtpmap:0 PCMU/8000 658 a=label:96 659 a=sendonly 660 ... 661 m=video 49182 RTP/AVPF 96 662 a=rtpmap:96 H.264/90000 663 a=label:97 664 a=sendonly 665 ... 666 m=audio 51374 RTP/AVP 0 667 a=rtpmap:0 PCMU/8000 668 a=label:98 669 a=sendonly 670 ... 671 m=video 49178 RTP/AVPF 96 672 a=rtpmap:96 H.264/90000 673 a=label:99 674 a=sendonly 675 .... 677 --foobar 678 Content-Type: application/rs-metadata 680 681 682 complete 683 684 2010-12-16T23:41:07Z 685 3363127f0d084c10876dddd4f8e5eeb9 686 ;remote=2272bb7e70fe41dba0025ae9a26d54cf 687 688 690 691 692 695 2010-12-16T23:32:03Z 696 697 699 8zc6e0lYTlWIINA6GR+3ag== 700 EiXGlc+4TruqqoDaNE76ag== 701 60JAJm9UTvik0Ltlih/Gzw== 702 AcR5FUd3Edi8cACQJy/3JQ== 703 704 706 707 708 711 2010-12-16T23:41:07Z 712 713 715 60JAJm9UTvik0Ltlih/Gzw== 716 AcR5FUd3Edi8cACQJy/3JQ== 717 8zc6e0lYTlWIINA6GR+3ag== 718 EiXGlc+4TruqqoDaNE76ag== 719 720 722 723 724 726 727 728 730 731 732 734 735 736 738 3.2.4. Example 4: Call disconnect 740 This example shows a snapshot of metadata sent by an SRC at CS 741 disconnect where the participants of CS are Alice and Bob 742 SRC SRS 743 | | 744 |(1) BYE (metadata snapshot) F1 | 745 |---------------------------------------------------->| 746 | 200 OK F2 | 747 |<----------------------------------------------------| 749 F1 BYE SRC -----------> SRS 751 BYE sip:2001@example.com SIP/2.0 752 Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30 753 From: ;tag=35e195d2-947d-4585-946f-09839247 754 To: 755 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 756 Session-ID: ab30317f1a784dc48ff824d0d3715d86 757 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 758 CSeq: 102 BYE 759 Max-Forwards: 70 760 Require: siprec 761 Accept: application/rs-metadata, 762 application/rs-metadata-request 763 Contact: ;+sip.src 764 Content-Type: multipart/mixed;boundary=foobar 765 Content-Length: [length] 767 --foobar 768 Content-Type: application/rs-metadata 770 771 772 Partial 773 774 2010-12-16T23:41:07Z 775 776 779 2010-12-16T23:41:07Z 780 782 785 2010-12-16T23:41:07Z 786 787 789 3.3. Call Scenarios with SRC recording streams by mixing 791 The section covers the models mentioned in the architecture document 792 in section 3 of [RFC7245] where an SRC may be part of Conference 793 model either as Focus or a participant in Conference. The SRS here 794 could be a SIP UA or an entity part of MEDIACTRL architecture. Note 795 that the disconnect case is not shown since the metadata snapshot 796 will be same as for a non-mixing case. 798 3.3.1. Example 1: Basic call with SRC mixing streams 800 Basic call between two Participants Alice and Bob who are part of one 801 CS. In this use case each participant sends one Media Streams. 802 Media Streams sent by each participant is received by the other 803 participant. Below is the initial snapshot sent by SRC in the INVITE 804 to SRS that has complete metadata. For the sake of simplicity only 805 snippets of SIP/SDP are shown. The SRCs records the streams of each 806 participant to SRS by mixing in this example. The SRC here is part 807 of conference model described in section 3 of [RFC7245] as a Focus 808 and does mixing. The SRC here is not a participant by itself and 809 hence it does not contribute to streams. 811 F1 INVITE SRC --------------> SRS 813 INVITE sip:recorder@example.com SIP/2.0 814 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 815 From: ;tag=35e195d2-947d-4585-946f-09839247 816 To: 817 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 818 Session-ID: a358d2b81a444a8c8fb05950cef331e7 819 ;remote=00000000000000000000000000000000 820 CSeq: 101 INVITE 821 Max-Forwards: 70 822 Require: siprec 823 Accept: application/sdp, application/rs-metadata, 824 application/rs-metadata-request 825 Contact: ;+sip.src 826 Content-Type: multipart/mixed;boundary=foobar 827 Content-Length: [length] 829 --foobar 830 Content-Type: application/SDP 831 ... 832 m=audio 49170 RTP/AVP 0 833 a=rtpmap:0 PCMU/8000 834 a=label:96 835 a=sendonly 837 .... 838 --foobar 839 Content-Type: application/rs-metadata 840 Content-Disposition: recording-session 841 842 843 complete 844 845 2010-12-16T23:41:07Z 846 fa3b60f27e91441e84c55a9a0095f075 847 ;remote=a358d2b81a444a8c8fb05950cef331e7 848 ca718e1430474b5485a53aa5d0bea45e 849 ;remote=a358d2b81a444a8c8fb05950cef331e7 850 851 853 854 Alice 855 856 857 860 2010-12-16T23:41:07Z 861 862 864 i1Pz3to5hGk8fuXl+PbwCw== 865 i1Pz3to5hGk8fuXl+PbwCw== 866 867 869 870 Bob 871 872 873 876 2010-12-16T23:41:07Z 877 878 880 i1Pz3to5hGk8fuXl+PbwCw== 881 i1Pz3to5hGk8fuXl+PbwCw== 882 883 885 886 887 889 In the above example there are two participants Alice and Bob in the 890 conference. Among other things, SRC sends Session-ID in the metadata 891 snapshot. There are two Session-ID's here, one that corresponds to 892 the SIP session between Alice and Conference Focus and the other for 893 the SIP session between Bob and Conference Focus. One half of both 894 these Session-ID's will have the same value (which is added by the 895 Focus). 897 3.3.2. Example 2: Hold/resume with SRC recording by mixing streams 899 Assume a call between two Participants Alice and Bob is established 900 and a RS is created for recording as in example 5. This is the 901 continuation of above use-case. One of the participants Bob puts 902 Alice hold and then resumes as part of the same session. The send 903 and recv XML elements of a participant is used to indicate whether a 904 participant is sending not sending a particular media stream whose 905 properties are represented by stream element. The metadata snapshot 906 looks as below: 908 During hold 909 mid call hold RE-INVITE SRC --------------> SRS 911 INVITE sip:recorder@example.com SIP/2.0 912 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 913 From: ;tag=35e195d2-947d-4585-946f-09839247 914 To: 915 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 916 Session-ID: a358d2b81a444a8c8fb05950cef331e7 917 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 918 CSeq: 101 INVITE 919 Max-Forwards: 70 920 Require: siprec 921 Accept: application/sdp, application/rs-metadata, 922 application/rs-metadata-request 923 Contact: ;+sip.src 924 Content-Type: multipart/mixed;boundary=foobar 925 Content-Length: [length] 927 --foobar 928 Content-Type: application/SDP 929 ... 930 m=audio 49170 RTP/AVP 0 931 a=rtpmap:0 PCMU/8000 932 a=label:96 933 a=sendonly 935 .... 936 --foobar 937 Content-Type: application/rs-metadata 938 Content-Disposition: recording-session 939 940 941 partial 942 944 i1Pz3to5hGk8fuXl+PbwCw== 945 946 948 i1Pz3to5hGk8fuXl+PbwCw== 949 950 952 953 954 956 During resume a snapshot shown below will be sent from SRC to SRS 957 mid call resume RE-INVITE SRC --------------> SRS 959 INVITE sip:recorder@example.com SIP/2.0 960 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 961 From: ;tag=35e195d2-947d-4585-946f-09839247 962 To: 963 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 964 Session-ID: a358d2b81a444a8c8fb05950cef331e7 965 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 966 CSeq: 101 INVITE 967 Max-Forwards: 70 968 Require: siprec 969 Accept: application/sdp, application/rs-metadata, 970 application/rs-metadata-request 971 Contact: ;+sip.src 972 Content-Type: multipart/mixed;boundary=foobar 973 Content-Length: [length] 975 --foobar 976 Content-Type: application/SDP 977 ... 978 m=audio 49170 RTP/AVP 0 979 a=rtpmap:0 PCMU/8000 980 a=label:96 981 a=sendonly 983 .... 984 --foobar 985 Content-Type: application/rs-metadata 986 Content-Disposition: recording-session 987 988 989 partial 990 992 i1Pz3to5hGk8fuXl+PbwCw== 993 i1Pz3to5hGk8fuXl+PbwCw== 994 995 997 i1Pz3to5hGk8fuXl+PbwCw== 998 i1Pz3to5hGk8fuXl+PbwCw== 999 1000 1002 1003 1004 1006 3.3.3. Example 3: Metadata snapshot of joining/dropping of a 1007 participant to a session 1009 In a conference model, participants can join and drop a session any 1010 time during the session. The below shows a snapshot sent from SRC to 1011 SRC in these case. Note the SRC here can be a focus or a participant 1012 in the conference. In case where the SRC is a participant it may 1013 learn the information required for metadata by subscribing to 1014 conference event package [RFC4575]. Assume Alice and Bob were in the 1015 conference and a third participant Carol joins, then SRC sends the 1016 below snapshot with the indication of new participant. 1018 mid call resume RE-INVITE SRC --------------> SRS 1020 INVITE sip:recorder@example.com SIP/2.0 1021 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 1022 From: ;tag=35e195d2-947d-4585-946f-09839247 1023 To: 1024 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1025 Session-ID: a358d2b81a444a8c8fb05950cef331e7 1026 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 1027 CSeq: 101 INVITE 1028 Max-Forwards: 70 1029 Require: siprec 1030 Accept: application/sdp, application/rs-metadata, 1031 application/rs-metadata-request 1032 Contact: ;+sip.src 1033 Content-Type: multipart/mixed;boundary=foobar 1034 Content-Length: [length] 1036 --foobar 1037 Content-Type: application/SDP 1038 ... 1039 m=audio 49170 RTP/AVP 0 1040 a=rtpmap:0 PCMU/8000 1041 a=label:96 1042 a=sendonly 1044 .... 1045 --foobar 1046 Content-Type: application/rs-metadata 1047 Content-Disposition: recording-session 1048 1049 1050 partial 1051 1053 fa3b60f27e91441e84c55a9a0095f075 1054 ;remote=a358d2b81a444a8c8fb05950cef331e7 1055 ca718e1430474b5485a53aa5d0bea45e 1056 ;remote=a358d2b81a444a8c8fb05950cef331e7 1057 497c0f13929643b4a16858e2a3885edc 1058 ;remote=a358d2b81a444a8c8fb05950cef331e7 1059 1060 1062 1063 Carol 1064 1065 1066 1069 2013-12-16T23:41:07Z 1070 1071 1073 i1Pz3to5hGk8fuXl+PbwCw== 1074 i1Pz3to5hGk8fuXl+PbwCw== 1075 1076 1078 Assume Alice drops after some time from the conference. SRC 1079 generates a new snapshot showing Alice disassociating from the 1080 session 1081 mid call resume RE-INVITE SRC --------------> SRS 1083 INVITE sip:recorder@example.com SIP/2.0 1084 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 1085 From: ;tag=35e195d2-947d-4585-946f-09839247 1086 To: 1087 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1088 Session-ID: a358d2b81a444a8c8fb05950cef331e7 1089 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 1090 CSeq: 101 INVITE 1091 Max-Forwards: 70 1092 Require: siprec 1093 Accept: application/sdp, application/rs-metadata, 1094 application/rs-metadata-request 1095 Contact: ;+sip.src 1096 Content-Type: multipart/mixed;boundary=foobar 1097 Content-Length: [length] 1099 --foobar 1100 Content-Type: application/SDP 1101 ... 1102 m=audio 49170 RTP/AVP 0 1103 a=rtpmap:0 PCMU/8000 1104 a=label:96 1105 a=sendonly 1107 .... 1108 --foobar 1109 Content-Type: application/rs-metadata 1110 Content-Disposition: recording-session 1111 1112 1113 partial 1114 1115 ca718e1430474b5485a53aa5d0bea45e 1116 ;remote=a358d2b81a444a8c8fb05950cef331e7 1117 497c0f13929643b4a16858e2a3885edc 1118 ;remote=a358d2b81a444a8c8fb05950cef331e7 1119 1120 1123 2010-12-16T23:41:07Z 1124 1125 1127 3.3.4. Example 4: Call disconnect 1129 When a CS is disconnected, SRC sends BYE with a snapshot of metadata 1130 having session stop-time and participant dis-associate times. The 1131 snapshot looks same as listed in section 3.2.4 1133 3.4. Call scenarios with persistent RS between SRC and SRS 1135 The section shows the snapshots of metadata for the cases there a 1136 persistent RS exists between SRC and SRS. An SRC here may be SIP UA 1137 or a B2BUA or may be part of Conference model either as Focus or a 1138 participant in Conference. The SRS here could be a SIP UA or an 1139 entity part of MEDIACTRL architecture. Except disconnect case, the 1140 snapshot remains same as one of the examples mentioned in previous 1141 sections. 1143 3.4.1. Example 1: Metadata snapshot during CS disconnect with 1144 persistent RS between SRC and SRS 1146 RE-INVITE sent from SRC -----------> SRS 1148 INVITE sip:2001@example.com SIP/2.0 1149 Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30 1150 From: ;tag=35e195d2-947d-4585-946f-09839247 1151 To: 1152 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1153 Session-ID: ab30317f1a784dc48ff824d0d3715d86 1154 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 1155 CSeq: 101 INVITE 1156 Max-Forwards: 70 1157 Require: siprec 1158 Accept: application/rs-metadata, 1159 application/rs-metadata-request 1160 Contact: ;+sip.src 1161 Content-Type: multipart/mixed;boundary=foobar 1162 Content-Length: [length] 1164 --foobar 1165 Content-Type: application/rs-metadata 1167 1168 1169 Partial 1170 1171 2010-12-16T23:41:07Z 1172 1173 1176 2010-12-16T23:41:07Z 1177 1179 1182 2010-12-16T23:41:07Z 1183 1184 1186 3.5. Turrent-Case: Multiple CS into single RS with mixed stream 1188 In trading floor environments, in order to minimize storage and 1189 recording system resources, it may be preferable to mix multiple 1190 concurrent calls (Communication Sessions) on different handsets/ 1191 speakers on the same turret into a single recording session. This 1192 would means media in each CS is mixed and recorded as part of single 1193 media stream and multiple such CSs are recording in one Recording 1194 Session from a SRC to SRS. 1196 Lets take a example where there are two CS[CS1 and CS2]. Assume 1197 mixing is done in each of these CS and both these CS are recorded as 1198 part of single RS from a single SRC which is part of both the CS. 1199 There are three possibilities here: 1201 o CS1 and CS2 uses the same Focus for fixing and that Focus is also 1202 acting as SRC in each of the CS. 1203 o In of the CS(say CS1), SRC is Focus and in the other CS(say CS2), 1204 SRC is just one of the participant of the conference. 1205 o In both CS1 and CS2, SRC is just a participant of Conference. 1207 The following example shows the first possibility where CS1 and CS2 1208 uses the same Focus for fixing and that Focus is also acting as SRC 1209 in each of the CS. 1211 snapshot of metadata INVITE SRC --------------> SRS 1213 INVITE sip:recorder@example.com SIP/2.0 1214 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 1215 From: ;tag=35e195d2-947d-4585-946f-09839247 1216 To: 1217 Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 1218 Session-ID: a358d2b81a444a8c8fb05950cef331e7 1219 ;remote=00000000000000000000000000000000 1220 Content-Type: application/SDP 1221 ... 1222 m=audio 49170 RTP/AVP 0 1223 a=rtpmap:0 PCMU/8000 1224 a=label:96 1225 a=sendonly 1226 ... 1227 1228 1229 complete 1230 1231 2010-12-16T23:41:07Z 1232 1233 1234 7+OTCyoxTmqmqyA/1weDAg== 1235 2010-12-16T23:41:07Z 1236 fa3b60f27e91441e84c55a9a0095f075 1237 ;remote=a358d2b81a444a8c8fb05950cef331e7 1238 ca718e1430474b5485a53aa5d0bea45e 1239 ;remote=a358d2b81a444a8c8fb05950cef331e7 1240 497c0f13929643b4a16858e2a3885edc 1241 ;remote=a358d2b81a444a8c8fb05950cef331e7 1242 1243 1244 7+OTCyoxTmqmqyA/1weDAg== 1245 2010-12-16T23:43:07Z 1246 ae10731ca50343a5aaae2dd0904a65de 1247 ;remote=a358d2b81a444a8c8fb05950cef331e7 1248 33c77aac7deb414cbc8c10f363fccb71 1249 ;remote=a358d2b81a444a8c8fb05950cef331e7 1250 fd6932e9e5fc489fae2d5b3779723b7e 1251 ;remote=a358d2b81a444a8c8fb05950cef331e7 1252 1253 1255 1256 Alice 1257 1258 1259 1262 2010-12-16T23:41:07Z 1263 1264 1266 UAAMm5GRQKSCMVvLyl4rFw== 1267 UAAMm5GRQKSCMVvLyl4rFw== 1268 1269 1271 1272 Bob 1273 1274 1275 1278 2010-12-16T23:41:07Z 1279 1280 1283 2010-12-16T23:43:07Z 1284 1285 1287 UAAMm5GRQKSCMVvLyl4rFw== 1288 UAAMm5GRQKSCMVvLyl4rFw== 1289 1290 1292 1293 Carol 1294 1295 1296 1299 2010-12-16T23:43:07Z 1300 1302 1304 UAAMm5GRQKSCMVvLyl4rFw== 1305 UAAMm5GRQKSCMVvLyl4rFw== 1306 1308 1310 1311 1312 1314 4. Security Considerations 1316 There is no security consideration as it is informational callflow 1317 document. 1319 5. IANA Considerations 1321 This document has no IANA considerations 1323 6. Acknowledgement 1325 Thanks to Ofir Rath, Charles Eckel for their review comments. 1327 7. References 1328 7.1. Normative References 1330 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1331 A., Peterson, J., Sparks, R., Handley, M., and E. 1332 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1333 June 2002. 1335 7.2. Informative References 1337 [I-D.ietf-siprec-metadata] 1338 R, R., Ravindran, P., and P. Kyzivat, "Session Initiation 1339 Protocol (SIP) Recording Metadata", 1340 draft-ietf-siprec-metadata-17 (work in progress), 1341 February 2015. 1343 [RFC7245] Hutton, A., Portman, L., Jain, R., and K. Rehor, "An 1344 Architecture for Media Recording Using the Session 1345 Initiation Protocol", RFC 7245, May 2014. 1347 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 1348 Initiation Protocol (SIP) Event Package for Conference 1349 State", RFC 4575, August 2006. 1351 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1352 Session Initiation Protocol (SIP)", RFC 4353, 1353 February 2006. 1355 [RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media 1356 Control Channel Framework", RFC 6230, May 2011. 1358 Authors' Addresses 1360 Ram Mohan Ravindranath 1361 Cisco Systems, Inc. 1362 Cessna Business Park, 1363 Kadabeesanahalli Village, Varthur Hobli, 1364 Sarjapur-Marathahalli Outer Ring Road 1365 Bangalore, Karnataka 560103 1366 India 1368 Email: rmohanr@cisco.com 1369 Parthasarathi Ravindran 1370 Nokia Networks 1371 Bangalore, Karnataka 1372 India 1374 Email: partha@parthasarathi.co.in 1376 Paul Kyzivat 1377 Huawei 1378 Hudson, MA 1379 USA 1381 Email: pkyzivat@alum.mit.edu