idnits 2.17.1
draft-ram-siprec-callflows-03.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 :
----------------------------------------------------------------------------
** The abstract seems to contain references ([I-D.ietf-siprec-metadata]),
which it shouldn't. Please replace those with straight textual mentions
of the documents in question.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (February 25, 2013) is 4077 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-11
Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 SIPREC Ram Mohan. Ravindranath
2 Internet-Draft Cisco Systems, Inc.
3 Intended status: Standards Track Parthasarathi. Ravindran
4 Expires: August 29, 2013 Nokia Siemens Networks
5 Paul. Kyzivat
6 Huawei
7 February 25, 2013
9 Session Initiation Protocol (SIP) Recording Call Flows
10 draft-ram-siprec-callflows-03
12 Abstract
14 Session recording is a critical requirement in many communications
15 environments such as call centers and financial trading. In some of
16 these environments, all calls must be recorded for regulatory,
17 compliance, and consumer protection reasons. Recording of a session
18 is typically performed by sending a copy of a media stream to a
19 recording device. This document lists call flows that has snapshot
20 of metadata sent from SRC to SRS, the metadata format for which is
21 described in [I-D.ietf-siprec-metadata] . This is purely an
22 informational document that is written to support the model defined
23 in the metadata draft.
25 Status of this Memo
27 This Internet-Draft is submitted in full conformance with the
28 provisions of BCP 78 and BCP 79.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF). Note that other groups may also distribute
32 working documents as Internet-Drafts. The list of current Internet-
33 Drafts is at http://datatracker.ietf.org/drafts/current/.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as "work in progress."
40 This Internet-Draft will expire on August 29, 2013.
42 Copyright Notice
44 Copyright (c) 2013 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (http://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with respect
52 to this document. Code Components extracted from this document must
53 include Simplified BSD License text as described in Section 4.e of
54 the Trust Legal Provisions and are provided without warranty as
55 described in the Simplified BSD License.
57 Table of Contents
59 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
61 3. Metadata XML schema Instances . . . . . . . . . . . . . . . . 3
62 3.1. Sample Call flow . . . . . . . . . . . . . . . . . . . . . 3
63 3.2. Example 1: Basic Call . . . . . . . . . . . . . . . . . . 5
64 3.3. Example 2: Hold/resume . . . . . . . . . . . . . . . . . . 7
65 3.4. Example 3: Basic Call with transfer . . . . . . . . . . . 10
66 3.5. Example 4: Call disconnect . . . . . . . . . . . . . . . . 14
67 3.6. Example 5: Multiple CS into single RS with mixed stream . 15
68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
70 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17
71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
72 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18
73 7.2. Informative References . . . . . . . . . . . . . . . . . . 18
74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
76 1. Overview
78 [I-D.ietf-siprec-metadata] document focuses on the Recording metadata
79 which describes the communication session. The document lists a few
80 examples and shows the snapshots of metadata sent from SRC to SRS.
81 For the sake of simplicity the entire SIP [RFC3261] messages are not
82 shown at various points, instead only a snip of the SIP/SDP message
83 and the XML snapshot of metadata is shown. This document is
84 informational and is not normative on any aspect of SIPREC.
86 2. Terminology
88 The terms using in this defined are defined in
89 [I-D.ietf-siprec-metadata]. No new terms/definitions are introduced
90 in this document.
92 3. Metadata XML schema Instances
94 This section describes the metadata model XML instances for different
95 use cases of SIPREC. For the sake of simplicity the complete SIP
96 messages are NOT shown here.
98 3.1. Sample Call flow
100 The following is a sample call flow that shows the SRC establishing a
101 recording session towards the SRS. The call flow is essentially
102 identical when the SRC is a B2BUA or as the endpoint itself. Note
103 that the SRC can choose when to establish the Recording Session
104 independent of the Communication Session, even though the following
105 call flow suggests that the SRC is establishing the Recording Session
106 (message #5) after the Communication Session is established.
108 UA A SRC UA B SRS
109 |(1)CS INVITE | | |
110 |------------->| | |
111 | |(2)CS INVITE | |
112 | |---------------------->| |
113 | | (3) 200 OK | |
114 | |<----------------------| |
115 | (4) 200 OK | | |
116 |<-------------| | |
117 | |(5)RS INVITE with SDP | |
118 | |--------------------------------------------->|
119 | | | (6) 200 OK with SDP |
120 | |<---------------------------------------------|
121 |(7)CS RTP | | |
122 |=============>|======================>| |
123 |<=============|<======================| |
124 | |(8)RS RTP | |
125 | |=============================================>|
126 | |=============================================>|
127 | | | |
128 | Mid call updates(hold/resume/re-invite(new offer) |
129 | | | |
130 |(9)CS BYE | | |
131 |------------->| | |
132 | |(10)CS BYE | |
133 | |---------------------->| |
134 | |(11)RS BYE | |
135 | |--------------------------------------------->|
136 | | | |
138 The above call flow can also apply to the case of a centralized
139 conference with a mixer. For clarity, ACKs to INVITEs and 200 OKs to
140 BYEs are not shown. The conference focus can provide the SRC
141 functionality since the conference focus has access to all the media
142 from each conference participant. When a recording is requested, the
143 SRC delivers the metadata and the media streams to the SRS. Since
144 the conference focus has access to a mixer, the SRC may choose to mix
145 the media streams from all participants as a single mixed media
146 stream towards the SRS.
148 An SRC can use a single recording session to record multiple
149 communication sessions. Every time the SRC wants to record a new
150 call, the SRC updates the recording session with a new SDP offer to
151 add new recorded streams to the recording session, and
152 correspondingly also update the metadata for the new call.
154 3.2. Example 1: Basic Call
156 SRC SRS
157 | |
158 |(1) INVITE (metadata snapshot) F1 |
159 |---------------------------------------------------->|
160 | 200 OK F2 |
161 |<----------------------------------------------------|
162 |(3) ACK F3 |
163 |---------------------------------------------------->|
164 |(4) RTP |
165 |====================================================>|
166 |====================================================>|
167 |====================================================>|
168 |====================================================>|
169 |(5) UPDATE/RE-INVITE (metadata update 1) F4 |
170 |---------------------------------------------------->|
171 | 200 OK F5 |
172 |<----------------------------------------------------|
173 |====================================================>|
174 |====================================================>|
175 |(7) UPDATE/RE-INVITE (metadata update 2) F6 |
176 |---------------------------------------------------->|
177 | 200 OK F7 |
178 |<----------------------------------------------------|
180 Basic call between two Participants Ram and Partha who are part of
181 one session. In this use case each participant sends two Media
182 Streams. Media Streams sent by each participant are received all
183 other participants of that CS in this use-case. Below is the initial
184 snapshot sent by SRC in the INVITE to SRS that has complete metadata.
185 For the sake of simplicity snippets of SDP are shown. Here the RS
186 stream is unmixed.
188 F1 INVITE SRC --------------> SRS
190 Content-Type: application/SDP
191 ...
192 m=audio 49170 RTP/AVP 0
193 a=rtpmap:0 PCMU/8000
194 a=label:96
195 a=sendonly
196 ...
198 m=video 49174 RTP/AVPF 96
199 a=rtpmap:96 H.264/90000
200 a=label:97
201 a=sendonly
202 ...
203 m=audio 51372 RTP/AVP 0
204 a=rtpmap:0 PCMU/8000
205 a=label:98
206 a=sendonly
207 ...
208 m=video 49176 RTP/AVPF 96
209 a=rtpmap:96 H.264/90000
210 a=label:99
211 a=sendonly
212 ....
213
214
215 complete
216
217 2010-12-16T23:41:07Z
218
219
221
222 RamMohan R
223
224
225
228 2010-12-16T23:41:07Z
229
230
232 i1Pz3to5hGk8fuXl+PbwCw==
233 UAAMm5GRQKSCMVvLyl4rFw==
234 8zc6e0lYTlWIINA6GR+3ag==
235 EiXGlc+4TruqqoDaNE76ag==
236
237
239
240 Parthasarathi R
241
242
243
247 2010-12-16T23:41:07Z
248
249
251 8zc6e0lYTlWIINA6GR+3ag==
252 EiXGlc+4TruqqoDaNE76ag==
253 UAAMm5GRQKSCMVvLyl4rFw==
254 i1Pz3to5hGk8fuXl+PbwCw==
255
256
258
259
260
262
263
264
266
267
268
270
271
272
274 3.3. Example 2: Hold/resume
276 Basic call between two Participants Ram and Partha. This is the
277 continuation of above use-case. One of the participants(say Ram)
278 goes on hold and then resumes as part of the same session. The
279 metadata snapshot looks as below
281 During hold
283 F4 RE-INVITE SRC-------------------->SRS
285 Content-Type: application/SDP
286 ...
287 m=audio 49170 RTP/AVP 0
288 a=rtpmap:0 PCMU/8000
289 a=label:96
290 a=inactive
291 ...
292 m=video 49174 RTP/AVPF 96
293 a=rtpmap:96 H.264/90000
294 a=label:97
295 a=inactive
296 ...
297 m=audio 51372 RTP/AVP 0
298 a=rtpmap:0 PCMU/8000
299 a=label:98
300 a=sendonly
301 ...
302 m=video 49176 RTP/AVPF 96
303 a=rtpmap:96 H.264/90000
304 a=label:99
305 a=sendonly
306 ....
308
309
310 partial
311
313 8zc6e0lYTlWIINA6GR+3ag==
314 EiXGlc+4TruqqoDaNE76ag==
315
316
318 8zc6e0lYTlWIINA6GR+3ag==
319 EiXGlc+4TruqqoDaNE76ag==
320
321
323
324
325
327
328
329
331
332
333
335
336
338
340 During resume
342 The snapshot will look pretty much same as above with just the SDP
343 dir change.
345 F5 RE-INVITE SRC-------------------->SRS
347 Content-Type: application/SDP
348 ...
349 m=audio 49170 RTP/AVP 0
350 a=rtpmap:0 PCMU/8000
351 a=label:96
352 a=sendonly
353 ...
354 m=video 49174 RTP/AVPF 96
355 a=rtpmap:96 H.264/90000
356 a=label:97
357 a=sendonly
358 ...
359 m=audio 51372 RTP/AVP 0
360 a=rtpmap:0 PCMU/8000
361 a=label:98
362 a=sendonly
363 ...
364 m=video 49176 RTP/AVPF 96
365 a=rtpmap:96 H.264/90000
366 a=label:99
367 a=sendonly
368 ....
370
371
372 partial
373
375 i1Pz3to5hGk8fuXl+PbwCw==
376 UAAMm5GRQKSCMVvLyl4rFw==
377 8zc6e0lYTlWIINA6GR+3ag==
378 EiXGlc+4TruqqoDaNE76ag==
379
380
382 8zc6e0lYTlWIINA6GR+3ag==
383 EiXGlc+4TruqqoDaNE76ag==
384 UAAMm5GRQKSCMVvLyl4rFw==
385 i1Pz3to5hGk8fuXl+PbwCw==
386
388
390
391
392
394
395
396
398
399
400
402
403
405
407 3.4. Example 3: Basic Call with transfer
409 Basic call between two Participants Ram and Partha is connected as in
410 Use-case 1. Transfer is initiated by one of the participants or by
411 other entity(3PCC case). SRC sends a snapshot of the participant
412 changes to SRS. In this instance participant Ram drops out during
413 the transfer and Participant Paul joins the session. There can be
414 two cases here, same session continues after transfer or a new
415 session (e.g. REFER based transfer) is created
417 Transfer with same session retained - (.e.g. RE-INVITE based
418 transfer). Participant Ram drops out and Paul is added to the same
419 session. No change to session/group element. Paul will have new
420 stream element which maps to RS SDP using the same labels in this
421 instance.
423 Content-Type: application/SDP
424 ...
425 m=audio 49170 RTP/AVP 0
426 a=rtpmap:0 PCMU/8000
427 a=label:96
428 a=sendonly
429 ...
430 m=video 49174 RTP/AVPF 96
431 a=rtpmap:96 H.264/90000
432 a=label:97
433 a=sendonly
434 ...
435 m=audio 51372 RTP/AVP 0
436 a=rtpmap:0 PCMU/8000
437 a=label:98
438 a=sendonly
439 ...
440 m=video 49176 RTP/AVPF 96
441 a=rtpmap:96 H.264/90000
442 a=label:99
443 a=sendonly
444 ....
445
446
447 partial
448
450 8zc6e0lYTlWIINA6GR+3ag==
451 EiXGlc+4TruqqoDaNE76ag==
452 60JAJm9UTvik0Ltlih/Gzw==
453 AcR5FUd3Edi8cACQJy/3JQ==
454
455
457
458 Paul Kyzivat
459
460
461
464 2010-12-16T23:41:07Z
465
466
468 60JAJm9UTvik0Ltlih/Gzw==
469 AcR5FUd3Edi8cACQJy/3JQ==
470 8zc6e0lYTlWIINA6GR+3ag==
471 EiXGlc+4TruqqoDaNE76ag==
472 2010-12-16T23:41:07Z
473
474
476
477
478
480
481
482
484
485
486
488
489
490
492 Transfer with new session - (.e.g. REFER based transfer). In this
493 case new session is part of same grouping (done by SRC).
495 SRC may send an optional snapshot indicating stop for the old
496 session.
498
499
500 Partial
501
502 2010-12-16T23:41:07Z
503
504
507 2010-12-16T23:41:07Z
508
509
512 2010-12-16T23:41:07Z
513
514
516 SRC sends a snapshot to indicate the participant change and new
517 session information after transfer. In this example the same RS is
518 used.
520 Content-Type: application/SDP
521 ...
522 m=audio 49170 RTP/AVP 0
523 a=rtpmap:0 PCMU/8000
524 a=label:96
525 a=sendonly
526 ...
527 m=video 49174 RTP/AVPF 96
528 a=rtpmap:96 H.264/90000
529 a=label:97
530 a=sendonly
531 ...
532 m=audio 51372 RTP/AVP 0
533 a=rtpmap:0 PCMU/8000
534 a=label:98
535 a=sendonly
536 ...
537 m=video 49176 RTP/AVPF 96
538 a=rtpmap:96 H.264/90000
539 a=label:99
540 a=sendonly
541 ....
542
543
544 partial
545
546 2010-12-16T23:41:07Z
547
548
550
551
552
555 2010-12-16T23:32:03Z
556
557
559 8zc6e0lYTlWIINA6GR+3ag==
560 EiXGlc+4TruqqoDaNE76ag==
561 60JAJm9UTvik0Ltlih/Gzw==
562 AcR5FUd3Edi8cACQJy/3JQ==
563
564
566
567
568
572 2010-12-16T23:41:07Z
573
574
576 60JAJm9UTvik0Ltlih/Gzw==
577 AcR5FUd3Edi8cACQJy/3JQ==
578 8zc6e0lYTlWIINA6GR+3ag==
579 EiXGlc+4TruqqoDaNE76ag==
580
581
583
584
585
587
588
589
591
592
593
595
596
597
599 3.5. Example 4: Call disconnect
601 This example shows a snapshot of metadata sent by an SRC at CS
602 disconnect where the participants of CS are Ram and Partha
603 SRC SRS
604 | |
605 |(1) BYE (metadata snapshot) F1 |
606 |---------------------------------------------------->|
607 | 200 OK F2 |
608 |<----------------------------------------------------|
610 F1 BYE SRC -----------> SRS
612
613
614 Partial
615
616 2010-12-16T23:41:07Z
617
618
621 2010-12-16T23:41:07Z
622
624
627 2010-12-16T23:41:07Z
628
629
631 3.6. Example 5: Multiple CS into single RS with mixed stream
633 In trading turret, audio mixing is done locally before forwarding to
634 the recording server. Sender and receiver audio is mixed for each
635 communication session. The audio from multiple communication
636 sessions is also mixed, or multiplexed, in a single RTP session to
637 the recording server.
639 F1 INVITE SRC --------------> SRS
641 Content-Type: application/SDP
642 ...
643 m=audio 49170 RTP/AVP 0
644 a=rtpmap:0 PCMU/8000
645 a=label:96
646 a=sendonly
647 ...
648
649
650 complete
651
652 2010-12-16T23:41:07Z
653
654
655 7+OTCyoxTmqmqyA/1weDAg==
656 2010-12-16T23:41:07Z
657
658
659 7+OTCyoxTmqmqyA/1weDAg==
660 2010-12-16T23:43:07Z
661
662
664
665 RamMohan R
666
667
668
671 2010-12-16T23:41:07Z
672
673
675 UAAMm5GRQKSCMVvLyl4rFw==
676 UAAMm5GRQKSCMVvLyl4rFw==
677
678
680
681 Parthasarathi R
682
683
684
687 2010-12-16T23:41:07Z
688
689
692 2010-12-16T23:43:07Z
693
694
696 UAAMm5GRQKSCMVvLyl4rFw==
697 UAAMm5GRQKSCMVvLyl4rFw==
698
699
701
702 Paul
703
704
705
708 2010-12-16T23:43:07Z
709
710
712 UAAMm5GRQKSCMVvLyl4rFw==
713 UAAMm5GRQKSCMVvLyl4rFw==
714
716
718
719
720
722 4. Security Considerations
724 There is no security consideration as it is informatioal callflow
725 document.
727 5. IANA Considerations
729 This document has no IANA considerations
731 6. Acknowledgement
733 Thanks to Ofir Rath, Charles Eckel for their review comments.
735 7. References
736 7.1. Normative References
738 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
739 A., Peterson, J., Sparks, R., Handley, M., and E.
740 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
741 June 2002.
743 7.2. Informative References
745 [I-D.ietf-siprec-metadata]
746 R, R., Ravindran, P., and P. Kyzivat, "Session Initiation
747 Protocol (SIP) Recording Metadata",
748 draft-ietf-siprec-metadata-11 (work in progress),
749 January 2013.
751 Authors' Addresses
753 Ram Mohan Ravindranath
754 Cisco Systems, Inc.
755 Cessna Business Park,
756 Kadabeesanahalli Village, Varthur Hobli,
757 Sarjapur-Marathahalli Outer Ring Road
758 Bangalore, Karnataka 560103
759 India
761 Email: rmohanr@cisco.com
763 Parthasarathi Ravindran
764 Nokia Siemens Networks
765 Bangalore, Karnataka
766 India
768 Email: partha@parthasarathi.co.in
770 Paul Kyzivat
771 Huawei
772 Hudson, MA
773 USA
775 Email: pkyzivat@alum.mit.edu