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