idnits 2.17.1
draft-ram-siprec-metadata-format-02.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 document has examples using IPv4 documentation addresses according
to RFC6890, but does not use any IPv6 documentation addresses. Maybe
there should be IPv6 examples, too?
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (June 17, 2011) is 4690 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)
** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141)
** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866)
== Outdated reference: A later version (-12) exists of
draft-ietf-siprec-architecture-02
== Outdated reference: A later version (-22) exists of
draft-ietf-siprec-metadata-00
== Outdated reference: A later version (-05) exists of
draft-portman-siprec-protocol-04
Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 siprec Ram Mohan. Ravindranath
2 Internet-Draft Parthasarathi. Ravindran
3 Intended status: Standards Track Paul. Kyzivat
4 Expires: December 19, 2011 Cisco Systems, Inc.
5 June 17, 2011
7 Session Initiation Protocol (SIP) Recording Metadata Format
8 draft-ram-siprec-metadata-format-02
10 Abstract
12 Session recording is a critical requirement in many communications
13 environments such as call centers and financial trading. In some of
14 these environments, all calls must be recorded for regulatory,
15 compliance and consumer protection reasons. Recording of a session
16 is typically performed by sending a copy of a media stream to a
17 recording device. This document focuses on the Recording metadata
18 format which describes the communication session.
20 Status of this Memo
22 This Internet-Draft is submitted to IETF in full conformance with the
23 provisions of BCP 78 and BCP 79.
25 Internet-Drafts are working documents of the Internet Engineering
26 Task Force (IETF). Note that other groups may also distribute
27 working documents as Internet-Drafts. The list of current Internet-
28 Drafts is at http://datatracker.ietf.org/drafts/current/.
30 Internet-Drafts are draft documents valid for a maximum of six months
31 and may be updated, replaced, or obsoleted by other documents at any
32 time. It is inappropriate to use Internet-Drafts as reference
33 material or to cite them other than as "work in progress."
35 This Internet-Draft will expire on December 19, 2011.
37 Copyright Notice
39 Copyright (c) 2011 IETF Trust and the persons identified as the
40 document authors. All rights reserved.
42 This document is subject to BCP 78 and the IETF Trust's Legal
43 Provisions Relating to IETF Documents
44 (http://trustee.ietf.org/license-info) in effect on the date of
45 publication of this document. Please review these documents
46 carefully, as they describe your rights and restrictions with respect
47 to this document. Code Components extracted from this document must
48 include Simplified BSD License text as described in Section 4.e of
49 the Trust Legal Provisions and are provided without warranty as
50 described in the Simplified BSD License.
52 Table of Contents
54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
56 3. Recording Metadata Format . . . . . . . . . . . . . . . . . . 3
57 4. SIP Recording Metadata document format . . . . . . . . . . . . 4
58 4.1. Contents . . . . . . . . . . . . . . . . . . . . . . . . . 4
59 4.2. XML data format . . . . . . . . . . . . . . . . . . . . . 4
60 4.2.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 5
61 4.2.2. recording . . . . . . . . . . . . . . . . . . . . . . 5
62 4.2.3. group . . . . . . . . . . . . . . . . . . . . . . . . 5
63 4.2.4. session . . . . . . . . . . . . . . . . . . . . . . . 5
64 4.2.5. participant . . . . . . . . . . . . . . . . . . . . . 5
65 4.2.6. stream . . . . . . . . . . . . . . . . . . . . . . . . 6
66 4.2.7. extensiondata . . . . . . . . . . . . . . . . . . . . 6
67 4.2.8. start-time/stop-time . . . . . . . . . . . . . . . . . 6
68 5. SIP Recording Metadata Example . . . . . . . . . . . . . . . . 7
69 5.1. Complete SIP Recording Metadata Example . . . . . . . . . 7
70 5.2. Partial Update of Recording metadata XML body . . . . . . 8
71 6. XML Schema definition for Recording metadata . . . . . . . . . 9
72 7. Example with SIP and metadata XML+SDP . . . . . . . . . . . . 12
73 7.1. SRC Initiated Recording . . . . . . . . . . . . . . . . . 12
74 7.2. SRC updates about participant change . . . . . . . . . . . 14
75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
76 8.1. Connection Security . . . . . . . . . . . . . . . . . . . 16
77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
78 9.1. SIP recording metadata Schema Registration . . . . . . . . 17
79 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17
80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
81 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
82 11.2. Informative References . . . . . . . . . . . . . . . . . . 18
83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
85 1. Introduction
87 Session recording is a critical requirement in many communications
88 environments such as call centers and financial trading. In some of
89 these environments, all calls must be recorded for regulatory,
90 compliance and consumer protection reasons. Recording of a session
91 is typically performed by sending a copy of a media stream to a
92 recording device. The requirements for such recording is described
93 in [I-D.ietf-siprec-req], the related architecture is described in
94 [I-D.ietf-siprec-architecture], and the metadata model viewed by
95 Session Recording Server is described in [I-D.ietf-siprec-metadata].
96 This document focuses on the Recording metadata format which
97 describes the communication session. The delivery mechanism for
98 passing metadata is outside the scope of this document.
100 The Session Recording Client (SRC) initiates the Recording Session.
101 Here, Recording Session is a completely independent from the
102 Communication Session that is being recorded at both the SIP dialog
103 level and at the session level.
105 2. Terminology
107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
109 document are to be interpreted as described in [RFC2119]. This
110 document only uses these key words when referencing normative
111 statements in existing RFCs.
113 3. Recording Metadata Format
115 Recording Metadata is the data that describes the communication
116 session. Metadata has to be conveyed from SRC to SRS, further the
117 metadata MAY be conveyed in the Recording Session dialog. Few
118 metadata information SHALL be derived from RS dialog. Recording
119 dialog-id SHALL be used as recording specific unique id, Date header
120 SHALL be used as start and stop time of recording metadata block.
122 The media related details of metadata SHALL be passed across using
123 session description protocol (SDP) [RFC4566]. SDP attributes
124 describes about different media formats like audio, video. The other
125 metadata attributes like participant details MUST be passed across in
126 new Recording specific XML document namely application/
127 rs-metadata+xml. The linkage between application/rs-metadata+xml XML
128 schema and metadata SDP is done using the SDP label attribute
129 (a=label:xxx) referenced in [RFC4574].
131 Metadata is passed across in Recording Session(RS) incrementally
132 whenever there is a change in CS.
134 4. SIP Recording Metadata document format
136 4.1. Contents
138 Recording Metadata document is an XML document which will be embedded
139 as a message body. The document contains
141 o recording element MUST present in all recording metadata XML
142 document. recording acts as container for all other elements in
143 this XML document.
144 o Elements like session, participant, stream and group are under
145 recording element directly with appropriate parent id and have
146 separate URN UUID for passing the partial information of metadata.
147 In case of partial metadata, recording element and the relevant
148 updated elements will be passed by SRC and the elements are
149 identified in SRS using URN UUID and parent id.
150 o Group element is an optional element provides the information
151 about the communication session group
152 o Session element provides the information about the communication
153 session
154 o Participant element provides information regarding the specific
155 participant involved in the recording
156 o Stream element indicates SDP media lines associated with the
157 session and participants
158 o Extensiondata element provides the mechanism by which namespace/
159 element MAY be extended with standard or proprietary information.
161 4.2. XML data format
163 Recording object is a XML document. It MUST have the XML declaration
164 and it SHOULD contain an encoding declaration in the XML declaration,
165 e.g., "". If the charset
166 parameter of the MIME content type declaration is present and it is
167 different from the encoding declaration, the charset parameter takes
168 precedence.
170 Every application conforms to this specification MUST accept the
171 UTF-8 character encoding to ensure the minimal interoperability.
173 Syntax and semantics error in recording XML document has to be
174 informed to the originator using application specific mechanism.
176 4.2.1. Namespace
178 The namespace URI for elements defined by this specification is a
179 Uniform Resource Namespace (URN) [RFC2141], using the namespace
180 identifier 'ietf' defined by [RFC2648] and extended by [RFC3688].
182 The URN is as follows: urn:ietf:params:xml:ns:recording
184 4.2.2. recording
186 recording element MUST contain an xmlns namespace attribute with
187 value as urn:ietf:params:xml:ns:siprec. One recording element MUST
188 present in the all recording metadata XML document.
190 recording element has group, session, stream, participant elements.
192 dataMode element shows whether the XML document is complete document
193 or partial update. The default value is complete.
195 4.2.3. group
197 Each communication session group (CSG) is represented using one group
198 element. Each group element has unique URN UUID attribute which
199 helps to uniquely identify CSG.
201 4.2.4. session
203 Each communication session(CS) has one session element. Each session
204 element has unique URN UUID attribute which helps to uniquely
205 identify CS.
207 Reason element MAY be included to indicate the reason for
208 termination. group-ref element MAY exist to indicate the group where
209 the mentioned session belongs.
211 4.2.5. participant
213 Each communication session user is defined by one participant element
214 and there MUST be atleast 2 participant for any given session. "send"
215 or "receive" element in each participant is associating SDP m-lines
216 with the participant. send element indicates that participant is
217 sending the stream of media with the mentioned media description.
218 recv element indicates that participant is receiving the stream and
219 by default all participant will receive the stream. recv element has
220 relevance in case whisper call scenario wherein few of the
221 participant in the session receives the stream and not others.
223 Participant MUST have AOR element which contains SIP/SIPS URI to
224 identify the participant. AOR element is SIP/SIPS URI FQDN or IP
225 address which represents the user. name is an optional element to
226 represent display name.
228 Each participant element has unique URN UUID attribute which helps to
229 uniquely identify participant and session URN UUID to associate
230 participant with specific session element. URN UUID of participant
231 *MUST* used in the scope of CSG and no new URN UUID has to be created
232 for the same element (participant, stream) between different CS in
233 the same CSG. In case URN UUID has to be used permanent, careful
234 usage of URN UUID to original AoR has to be decided by the
235 implementers and it is implementer's choice.
237 4.2.6. stream
239 This element indicates the SDP m-line properties like label
240 attributes, media mode. Label attribute is used to link m-line SDP
241 body using label attribute in SDP m-line. The media mode helps in
242 understanding whether the media is mixed or not.
244 Each stream element has unique URN UUID attribute which helps to
245 uniquely identify stream and session URN UUID to associate stream
246 with specific session element. The open item here is whether to use
247 URN UUID (global id) or xml:id (local id).
249 4.2.7. extensiondata
251 extensiondata element SHALL include any other XML namespace.
252 Multiple namespace MAY exists under extensiondata. extensiondata
253 element exist in each level like recording, session, participant,
254 stream to provide extensiondata specific to each element.
255 extensiondata element has unique id based on URN UUID [RFC4122]
256 attribute and its parent id. The open item in extensiondata is
257 whether any need of separate metadata block or not.
259 4.2.8. start-time/stop-time
261 start-time/stop-time contains a string indicating the date and time
262 of the status change of this tuple. The value of this element MUST
263 follow the IMPP datetime format [RFC3339]. Timestamps that contain
264 'T' or 'Z' MUST use the capitalized forms. At a time, any of the
265 time tuple start-time or stop-time MAY exist in the element namely
266 group, session, participant, stream and not both timestamp at the
267 same time.
269 As a security measure, the timestamp element SHOULD be included in
270 all tuples unless the exact time of the status change cannot be
271 determined.
273 5. SIP Recording Metadata Example
275 5.1. Complete SIP Recording Metadata Example
277 The following example provides all the tuples involved in Recording
278 Metadata XML body.
280
281
282
283 2010-12-16T23:41:07Z
284
285
287
288
289 sip:alice@cisco.com
290
291
292 FOO!
293 bar
294
295
296
297 urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302
298
299 2010-12-16T23:41:07Z
300
301
303 FOO!
304 bar
305
306
309 sip:partha@blr.cisco.com
310 urn:uuid:8b53f3de-da39-4846-93c7-ee5e5f8f6f0b
311 urn:uuid:50000c9b-9191-40a4-8231-5bcbca5e2b17
312 2010-12-16T23:41:07Z
313
314
317 FOO!
318 bar
319
320
323 sip:paul@box.cisco.com
324 urn:uuid:50000c9b-9191-40a4-8231-5bcbca5e2b17
325 urn:uuid:8b53f3de-da39-4846-93c7-ee5e5f8f6f0b
326 2010-12-16T23:41:07Z
327
328
331 FOO!
332 bar
333
334
336 2010-12-16T23:41:07Z
337
338
339
341 2010-12-16T23:41:07Z
342
343
344
346 2010-12-16T23:41:07Z
347
348
349
351 2010-12-16T23:41:07Z
352
353
354
356 SIP Recording Metadata Example XML body
358 5.2. Partial Update of Recording metadata XML body
360 The following example provides partial update in Recording Metadata
361 XML body for the above example. The example illustrate the stop time
362 of the specific stream.
364
365
366 partial
367
369
370
371
373
374
375
377
378
379
381
382
383
385 Partial update of SIP Recording Example XML body
387 6. XML Schema definition for Recording metadata
389 This section defines XML schema for Recording metadata document
391
392
397
398
400
401
402
403
405
407
409
412
414
415
416
417
418
420
422
423
425
426
427
428
430
432
434
436
437
439
440
441
442
444
446
448
450
452
454
455
457
459
460
461
462
464
466
468
470
472
473
475
477
478
479
480
484
485
487
489
490
491
492
494
495
496
497
500
501
502
503
504
505
507
509
511 7. Example with SIP and metadata XML+SDP
513 This section describes the different use cases/messages for
514 delivering Metadata in a Recording Sessions. This section is written
515 in the draft for better readability and the example will be moved to
516 solution document or removed when this draft is adopted as WG item.
518 7.1. SRC Initiated Recording
520 An SRC initiates Recording Session(RS) for recording a communication
521 session with audio and video media. SRC initiates the dialog by
522 sending an INVITE request to the SRS. INVITE is formed as specified
523 in [RFC3261] , SRC inserts recording metadata as an XML document and
524 SDP in multipart MIME message body [RFC2046]. The content type of
525 SIP header is set to application/rs-metadata+xml
526 [I-D.portman-siprec-protocol]. SRC MUST form SDP offer using the
527 normal procedures defined in [RFC3261]and [RFC3264]. SRC SHALL
528 include one m-line for each stream of each participant. If the
529 recording has to be started immediately then SRC MUST include an SDP
530 attribute of "a=sendonly" for each media line or "a=inactive" if it
531 is not ready to transmit the media. SRC MAY also include only one
532 m-line for all streams of same type for all participants depending on
533 whether it has the capability to mix the streams. SRC indicates the
534 modes (mixed or single) for each stream using a mode attribute. An
535 example wherein INVITE sent by an SRC is shown below:
537 INVITE sip:1041@recordingserver.cisco.com:5060;transport=tcp SIP/2.0
538 Via: SIP/2.0/TCP 192.0.2.58;branch=z9hG4bK-19935-1-7
539 Max-Forwards: 70
540 To:
541 From: RecrdingClient ;tag=ds43d76263
542 Call-ID: 12548086970261@192.0.2.58
543 CSeq: 100 INVITE
544 Content-Length: xxx
545 Contact:
546 Date: Tue, 16 Dec 2010 23:41:07 GMT
547 Content-Type: multipart/mixed;boundary=unique-boundary-1
548 MIME-Version: 1.0
550 --unique-boundary-1
551 Content-Type: application/SDP
552 ...
553 m=audio 49170 RTP/AVP 0
554 a=rtpmap:0 PCMU/8000
555 a=label:96
556 a=sendonly
557 ...
558 m=video 49174 RTP/AVPF 96
559 a=rtpmap:96 H.264/90000
560 a=label:97
561 a=sendonly
562 ...
563 m=audio 51372 RTP/AVP 0
564 a=rtpmap:0 PCMU/8000
565 a=label:98
566 a=sendonly
567 ...
568 m=video 49176 RTP/AVPF 96
569 a=rtpmap:96 H.264/90000
570 a=label:99
571 a=sendonly
572 ....
574 --unique-boundary-1
575 Content-type:application/rs-metadata+xml
577
578
579
580
581
582 urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302
583
584 2010-12-16T23:41:07Z
585
586
589 sip:partha@blr.cisco.com
590 urn:uuid:8b53f3de-da39-4846-93c7-ee5e5f8f6f0b
591 urn:uuid:50000c9b-9191-40a4-8231-5bcbca5e2b17
592 2010-12-16T23:41:07Z
593
594
597 sip:paul@box.cisco.com
598 urn:uuid:50000c9b-9191-40a4-8231-5bcbca5e2b17
599 urn:uuid:8b53f3de-da39-4846-93c7-ee5e5f8f6f0b
600 2010-12-16T23:41:07Z
601
602
604 2010-12-16T23:41:07Z
605
606
607
609 2010-12-16T23:41:07Z
610
611
612
614 2010-12-16T23:41:07Z
615
616
617
619 2010-12-16T23:41:07Z
620
621
622
624 --unique-boundary-1--
626 7.2. SRC updates about participant change
628 An SRC updates about participant change without impact any change in
629 MS, CSG using RE-INVITE. An example wherein RE-INVITE sent by an SRC
630 for the participant update is shown below:
632 INVITE sip:1041@recordingserver.cisco.com:5060;transport=tcp SIP/2.0
633 Via: SIP/2.0/TCP 192.0.2.58;branch=z9hG4bK-19935-1-7
634 Max-Forwards: 70
635 To:
636 From: RecrdingClient ;tag=ds43d76263
637 Call-ID: 12548086970261@192.0.2.58
638 CSeq: 100 INVITE
639 Content-Length: xxx
640 Contact:
641 Date: Tue, 16 Dec 2010 23:41:07 GMT
642 Content-Type: multipart/mixed;boundary=unique-boundary-1
643 MIME-Version: 1.0
645 --unique-boundary-1
646 Content-Type: application/SDP
647 ...
649 m=audio 49170 RTP/AVP 0
650 a=rtpmap:0 PCMU/8000
651 a=label:96
652 a=sendonly
653 ...
654 m=video 49174 RTP/AVPF 96
655 a=rtpmap:96 H.264/90000
656 a=label:97
657 a=sendonly
658 ...
659 m=audio 51372 RTP/AVP 0
660 a=rtpmap:0 PCMU/8000
661 a=label:98
662 a=sendonly
663 ...
664 m=video 49176 RTP/AVPF 96
665 a=rtpmap:96 H.264/90000
666 a=label:99
667 a=sendonly
668 ....
670 --unique-boundary-1
671 Content-type:application/rs-metadata+xml
673
674
675 partial
676
677 urn:uuid:efe3930b-2a31-4e6a-a6ab-203fd7078302
678
679 2010-12-16T23:45:07Z
680
681
682 2010-12-16T23:45:07Z
683
684
687 sip:partha@blr.cisco.com
688 urn:uuid:8b53f3de-da39-4846-93c7-ee5e5f8f6f0b
689 urn:uuid:50000c9b-9191-40a4-8231-5bcbca5e2b17
690
691
694 2010-12-16T23:45:07Z
695
696
699 2010-12-16T23:45:07Z
700 sip:ram@blr.cisco.com
701 urn:uuid:50000c9b-9191-40a4-8231-5bcbca5e2b17
702 urn:uuid:8b53f3de-da39-4846-93c7-ee5e5f8f6f0b
703
704
706
707
708
710
711
712
714
715
716
718
719
720
722 --unique-boundary-1--
724 8. Security Considerations
726 The metadata information sent from SRC to SRS MAY reveal sensitive
727 information about different participants in a session. For this
728 reason, it is RECOMMENDED that a SRC use a strong means for
729 authentication and metadata information protection and that it apply
730 comprehensive authorization rules when using the metadata format
731 defined in this document. The following sections will discuss each
732 of these aspects in more detail.
734 8.1. Connection Security
736 It is RECOMMENDED that a SRC authenticate SRS using the normal SIP
737 authentication mechanisms, such as Digest as defined in Section 22 of
738 [RFC3261]. The mechanism used for conveying the metadata information
739 MUST ensure integrity and SHOULD ensure confidentially of the
740 information. In order to achieve these, an end-to-end SIP encryption
741 mechanism, such as S/MIME described in [RFC3261], SHOULD be used.
743 If a strong end-to-end security means (such as above) is not
744 available, it is RECOMMENDED that a SRC use mutual hop-by-hop
745 Transport Layer Security (TLS) authentication and encryption
746 mechanisms described in "SIPS URI Scheme" and "Interdomain Requests"
747 of [RFC3261].
749 TBD: Other detailed security aspects
751 9. IANA Considerations
753 This specification registers a new XML namespace, and a new XML
754 schema.
756 9.1. SIP recording metadata Schema Registration
758 URI: urn:ietf:params:xml:ns:recording
760 Registrant Contact: IETF SIPREC working group, Ram mohan
761 R(rmohanr@cisco.com)
763 XML: the XML schema to be registered is contained in Section 6.
765 Its first line is and its last
766 line is
768 10. Acknowledgement
770 We wish to thank Joe Hildebrand(Cisco), Peter Saint-Andre(Cisco) for
771 the valuable XML related guidance. Thanks to Michael
772 Benenson(Cisco), Leon Portman(Nice), Henry Lum(Alcatel-lucent), John
773 Elwell(Siemens-Enterprise), Hadriel Kaplan (ACME), Brian
774 Rosen(Neustar), Scott Orton(Broadsoft), Charles Eckel(Cisco) for
775 their inputs and comments.
777 11. References
779 11.1. Normative References
781 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
782 Extensions (MIME) Part Two: Media Types", RFC 2046,
783 November 1996.
785 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
786 Requirement Levels", BCP 14, RFC 2119, March 1997.
788 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
790 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
791 A., Peterson, J., Sparks, R., Handley, M., and E.
792 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
793 June 2002.
795 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
796 with Session Description Protocol (SDP)", RFC 3264,
797 June 2002.
799 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
800 January 2004.
802 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
803 Internet: Timestamps", RFC 3339, July 2002.
805 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
806 Unique IDentifier (UUID) URN Namespace", RFC 4122,
807 July 2005.
809 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
810 Description Protocol", RFC 4566, July 2006.
812 [RFC4574] Levin, O. and G. Camarillo, "The Session Description
813 Protocol (SDP) Label Attribute", RFC 4574, August 2006.
815 11.2. Informative References
817 [I-D.ietf-siprec-req]
818 Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use
819 Cases and Requirements for SIP-based Media Recording
820 (SIPREC)", draft-ietf-siprec-req-12 (work in progress),
821 June 2011.
823 [I-D.ietf-siprec-architecture]
824 Hutton, A., Portman, L., Jain, R., and K. Rehor, "An
825 Architecture for Media Recording using the Session
826 Initiation Protocol", draft-ietf-siprec-architecture-02
827 (work in progress), April 2011.
829 [I-D.ietf-siprec-metadata]
830 R, R., R, P., and P. Kyzivat, "Session Initiation Protocol
831 (SIP) Recording Metadata", draft-ietf-siprec-metadata-00
832 (work in progress), April 2011.
834 [I-D.portman-siprec-protocol]
835 Portman, L., Lum, H., Johnston, A., and A. Hutton,
836 "Session Recording Protocol",
837 draft-portman-siprec-protocol-04 (work in progress),
838 May 2011.
840 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
841 August 1999.
843 Authors' Addresses
845 Ram Mohan Ravindranath
846 Cisco Systems, Inc.
847 Cessna Business Park,
848 Kadabeesanahalli Village, Varthur Hobli,
849 Sarjapur-Marathahalli Outer Ring Road
850 Bangalore, Karnataka 560103
851 India
853 Email: rmohanr@cisco.com
855 Parthasarathi Ravindran
856 Cisco Systems, Inc.
857 Cessna Business Park,
858 Kadabeesanahalli Village, Varthur Hobli,
859 Sarjapur-Marathahalli Outer Ring Road
860 Bangalore, Karnataka 560103
861 India
863 Email: partr@cisco.com
865 P. Kyzivat
866 Cisco Systems, Inc.
867 1414 Massachusetts Avenue
868 Boxborough, MA 01719
869 USA
871 Email: pkyzivat@cisco.com