Transport Area X. Wu Internet-Draft V. Krishnaswamy Expires: December 9, 2006 Avaya Labs Research June 7, 2006 Using SIP Event Package and CONSENT Request for Media Recording draft-wu-sipping-media-recording-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 9, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Media recording enables the parties of a conversation to record all or part of the conversation. Automatic recording may bring great convenience to users. However, federal law requires the parties of a conversation to have a consent for media recording. In addition, FCC requires the recorded parties must be notified before the recording. These requirements make automatic recording impossible without defining a mechanism to negotiate the consent and send recording notifications. This document defines a SIP event package for Wu & Krishnaswamy Expires December 9, 2006 [Page 1] Internet-Draft media-recording June 2006 recording event notifications and use the SIP CONSENT method to negotiate a consent among multiple parties for media recording. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Acquiring conversation parties' location information . . . . . 4 5. Using CONSENT request to negotiate recording consent . . . . . 5 5.1. Negotiating consent before the conversation . . . . . . . 7 6. Using recording event package for recording notifications . . 7 7. Recording a conference . . . . . . . . . . . . . . . . . . . . 8 8. Integrating with PSTN . . . . . . . . . . . . . . . . . . . . 9 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. XML Schema Definitions . . . . . . . . . . . . . . . . . . . . 11 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 13 11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 14 12. Security Considerations . . . . . . . . . . . . . . . . . . . 14 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 13.1. Normative References . . . . . . . . . . . . . . . . . . . 14 13.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Wu & Krishnaswamy Expires December 9, 2006 [Page 2] Internet-Draft media-recording June 2006 1. Introduction Media recording is important for communications. With media recording, people can get reminded of their previous conversations, or play back some special moments. Many times, it is too late when people want to start recording. Some events are just unrepeatable, e.g., children's first laugh over the phone. Given that most Internet telephony endpoints have CPU and memory, it should be straightforward to automatically start recording on an Internet telephony endpoint when a conversation starts. When the conversation ends, the endpoint can ask the user to upload the saved audio clips to a permanent storage, e.g., uploading to a web server. However, media recording may require consent from all parties of the conversation, otherwise will be considered unlawful. The federal law [6] makes it unlawful to record telephone conversations except in one party consent cases which permit one party consent recording by state law. What one party consent means is a person can record their own telephone conversations without the knowledge or consent of the other party in those states that allow one party consent. In addition, the Federal Communications Commission (FCC) goes further into details on recording telephone conversations and states that the party recording must give verbal notification before the recording and that there must be a beep tone on the line to indicate that the line is being recorded. To fulfull the federal law and FCC's requirements, we need to define a mechanism to automatically negotiate recording consent based on the location of the conversation parties, and send a recording notification to all parties of the conversation. When an endpoint starts to record, it first checks every party's physical location. If all parties are in a place that requires one party consent for recording, the endpoint can start recording immediately without negotiating recording consent. Otherwise, the endpoint must send a SIP [2] CONSENT [8] [3] request to all the parties that at the place that requires all party consent. The endpoint must not start recording until receiving positive responses of all the CONSENT requests. Before starting to record, the endpoint should send a recording start event to all the conversation parties. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Wu & Krishnaswamy Expires December 9, 2006 [Page 3] Internet-Draft media-recording June 2006 3. Terminology Recording: The operation that is performed by a recording party to save part or all of the media streams of a conversation to a permanent storage device. Recording party: A recording party is the entity who will record media streams of a conversation. The recording party may not be in the conversation. If the recording party is in the conversation, the recording party may record his/her own media streams. Recorded party: A recorded party is the entity whose media streams will be recorded by a recording party. One party consent: One party consent means that one party to the conversation must have knowledge and give consent to the recording. In the United States, there are thirty eight states that permit one party consent. They are Alaska, Arkansas, Colorado District of Columbia, Georgia, Hawaii, Idaho, Indiana, Iowa Kansas, Kentucky, Louisiana, Maine, Minnesota, Mississippi Missouri, Nebraska, Nevada, New Jersey, New Mexico, New York North Carolina, North Dakota, Ohio, Oklahoma, Oregon, Rhode Island South Carolina, South Dakota, Tennessee, Texas, Utah, Vermont Virginia, West Virginia, Wisconsin, and Wyoming. [9] Two party or all party consent: Two party or all party consent means that every party to the conversation must have knowledge and give consent to the recording. In the United States, there are twelve states require, under most circumstances, the consent of all parties to a conversation. Those jurisdictions are California, Connecticut, Florida, Illinois, Maryland, Massachusetts, Michigan, Montana, Nevada, New Hampshire, Pennsylvania and Washington. [9] 4. Acquiring conversation parties' location information When an endpoint wants to start recording, the endpoint should check all the conversation parties' location information. It can use SIP SUBSCRIBE requests [5] to acquire remote parties' location information. The location information can be presented in Presence- based GEOPRIV Location Object Format (pidf-lo) [10] and sent in SIP NOTIFY requests [5]. For the remote parties that have unknown location or at a location requiring all party consent, the endpoint MUST use SIP CONSENT requests to acquire the consents from these parties. The endpoint MUST NOT start recording until receiving positive consent response from all the parties that have unknown location or requiring all party consent. Wu & Krishnaswamy Expires December 9, 2006 [Page 4] Internet-Draft media-recording June 2006 5. Using CONSENT request to negotiate recording consent The Framework for Consent-Based Communications in the Session Initiation Protocol [8] uses an asynchoronous way to acquire consents. The party who sends a CONSENT request should first send a SUBSCRIBE request for the "grant-permission" events. The reason is that users are not on-line all the time, so, sometimes are not able to receive CONSENT requests. But for negotiating recording consent, we expect all parties are online and be able to give or deny the permission needed for doing the recording. So, the recording consent negotiation should be in a synchronous way. The recipients of CONSENT requests should use "200 Ok" response to grant a permission, and "403 Forbidden" or "603 Decline" response to deny a recording permission. [[Comment.1: The current proposal of SIP CONSENT methodis designed specifically for SIP relays to handle permissions to perform translations. It may be desirable to define a more general SIP CONSENT method to handle different consent negotiations, including but not limited to recording consent negotiation, among multiple parties.]][3] The CONSENT requests sent by the recording party should indicate that the purpose of the consent is for recording. The request should also provide the information about what type of media streams will be recorded and in what mode. The mode information indicates whether the recording will be done in an "all-or-none" mode or in "partial" mode. If the recording is done in "all-or-none" mode, media streams from all parties will be recorded and saved in one media clip. If the recording is done in "partial" mode, only part of the conversation parties' media streams will be recorded. These information can be conveyed by using one or more "Consent-Needed" header field. For example, the "Consent-Needed" header below asks for consent from sip:tom@example.com for recording permission on both audio and video. The recording mode is "partial" for both audio and video. Consent-Needed: sip:tom@example.com; purpose=recording;audio;video;mode=partial The "Consent-Needed" headers below also ask for consent from sip:tom@example.com for recording permission on both audio and video. But the recording mode is "all-or-none" for audio, and "partial" for video. Consent-Needed: sip:tom@example.com; purpose=recording;audio;mode=all-or-none Consent-Needed: sip:tom@example.com; purpose=recording;video;mode=partial Wu & Krishnaswamy Expires December 9, 2006 [Page 5] Internet-Draft media-recording June 2006 [[Comment.2: Note that we may also use an XML document to describe the consent. Using XML document seems more flexible than using a SIP header. We can easily specify the starting time, the ending time, and the duration of a recording. For example, we can set the Content-Type as "application/consent+xml" and have an XML document like]] CONSENT requests for recording a session should be sent inside the session and have the same Call-ID as the INVITE request for the session. A CONSENT request should use the 'Expires' header to indicate how long the recording party wants to record the conversation. If the header is not presented, by default, it means the recording will continue until the end of the session. The recorded parties should use the 'Expires' header in its '200 Ok' response to indicate how long they would like to be recorded. The recording party MUST use the shortest expiration time from all recorded parties to handle the recording if the recording is done in the "all-or-none" mode. [[Comment.3: Note that an endpoint may cache media streams so the starting time of a recording may before the time of sending the CONSENT request. That's another reason that using a consent XML document is a better way.]] Wu & Krishnaswamy Expires December 9, 2006 [Page 6] Internet-Draft media-recording June 2006 5.1. Negotiating consent before the conversation With the CONSENT request, it is possible for people to negotiate a recording consent before the conversation so people can record the whole conversation once it starts. There are several ways to handle this. We can put the consent XML document as a MIME content in the SIP INVITE request. We can also send a CONSENT request before the initial INVITE has been completed, like the way used by SIP UPDATE requests [11], as shown in Figure 4. Recording Recorded | | |---(1) INVITE ---->| | | |<--(2) 180 --------| | | |---(3) CONSENT---->| | | |<--(4) 200 OK------| | (for CONSENT) | | | |<--(5) 200 OK------| | (for INVITE) | | | |---(6) ACK ------->| | (start recording) | | | Figure 4: CONSENT before the conversation 6. Using recording event package for recording notifications Before starting a recording, the recording party SHOULD send notifications to all recorded parties about the recording. The event information is carried as XML, and with the content type as application/session-recording+xml. The document MUST indicate when the recording started, what's the duration of the recording, and the information of the recorded parties, medias, and modes. [[Comment.4: Note that even the recorded parties did not subscribe for this event, the recording party SHOULD still send this notification to fulfill the requirement of FCC. Since the recording operation is part of a session and very closely related to the dialog of a session, the session-recording notification may need to be considered as an INVITE initiated event package. Maybe there should be an embeded FSM to handle recording in the "Confirmed" state in SIP dialog state machine.]][7] [[Comment.5: The other way to initiate the session recording notification is to treat the notification as a CONSENT Wu & Krishnaswamy Expires December 9, 2006 [Page 7] Internet-Draft media-recording June 2006 triggered notification, like the way used by SIP REFER requests.]][12] The XML document below shows an example of session- recording notification. .... Content-Type: application/session-recording+xml .... 7. Recording a conference When a conference participant wants to record a conference, the participant MUST acquire consents from all other conference participants. Since usually a conference participant does not know other conference participants' session information, the recording party has to send a CONSENT request to the conference server and the conference server will then ask for consents from other conference participants on behalf of the recording party. The conference server can use a "Consent-RequestedBy" header to carry the information of the recording party. For example, the "Consent-RequestedBy" header below indicates the CONSENT request is sent on behalf of "sip:tom@example.com". Consent-RequestedBy: sip:tom@example.com [[Comment.6: Note that a consent XML document seems a better solution. A consent XML document can clearly indicate who is requiring a consent. The recording party does not have to be the Wu & Krishnaswamy Expires December 9, 2006 [Page 8] Internet-Draft media-recording June 2006 sender of the CONSENT request.]] 8. Integrating with PSTN When a SIP phone user is talking with a PSTN phone user, the SIP phone user cannot directly use the CONSENT method to negotiate a recording consent with the PSTN phone user. There must be an application server, or a gateway in between, and have an Interactive Voice Response (IVR) system to handle text to speech (TTS) and speech to text (STT). +-------+ +-----------+ +--------+ | IP | CONSENT |Application| IVR | Voice | | phone +----------+ server +-----+ portal | +-------+ +-----+-----+ +--------+ | | +----+----+ +-------+ | PSTN | | POTS | + gateway +-------+ phone | +---------+ +-------+ Figure 7: Makeing consent through an application server Figure 7 shows how to negotiate a recording consent between an IP phone and a POTS phone. The IP phone sends a CONSENT request to the application server. The application server brings the voice portal in the conversation by asking recording consent verbally. The POTS phone user can respond by saying "yes" or "no" for the recording consent, and may be prompted for more recording parameters, such as how long the recording should be. Through the voice portal, the application server can get all the required information for generating a response for the CONSENT request, and send back to the IP phone. Wu & Krishnaswamy Expires December 9, 2006 [Page 9] Internet-Draft media-recording June 2006 +--------+ IVR | Voice | +--------+ portal | | +--------+ | | +-------+ +------+--+ +-------+ | IP | CONSENT | PSTN | | POTS | | phone +-----------+ gateway +------+ phone | +-------+ +---------+ +-------+ Figure 8: Makeing consent through a PSTN gateway Figure 8 shows the way of using a PSTN gateway directly talk to the voice portal for TTS and STT. 9. Examples Recording Recorded | | |--(1) SUBSCRIBE--->| | location info-->| | | |<-(2) NOTIFY-------| | ...A1="CA"...----| | | |---(3) CONSENT---->| | | |<--(4) 200 OK------| |---(5) NOTIFY----->| |<--(6) 200 OK------| |(start recording) | | | Figure 9: Two party recording Figure 9 shows a two party recording consent negotiation process. The recording party first sends a SUBSCRIBE for the recorded party's location information. The recorded party is in California, which requires two party consent. The recording party then sends a CONSENT request asking for recording consent from the recorded party. Once the recording party gets the 200 OK response, it will send a NOTIFY for the recording and then start to record. Wu & Krishnaswamy Expires December 9, 2006 [Page 10] Internet-Draft media-recording June 2006 Recording Conference Recorded Recorded Server | | | | |---(1) CONSENT---->| | | |<--(2) 100 Trying--| | | | |---(3) CONSENT---->| | | |---(4) CONSENT---------------------->| | |<--(5) 200 OK------| | | |<--(6) 200 OK------------------------| |<--(7) 200 OK------| | | |---(8) NOTIFY----->| | | | |---(9) NOTIFY----->| | | |---(10) NOTIFY---------------------->| |<--(11) 200 OK-----| | | |(start recording) | | | | | | | Figure 10: Recording a conference Figure 10 shows how to acquire recording consent in a conference. The recording party sends a CONSENT request to the conference server. The conference server then sends CONSENT requests to all the conference participants. Upon receiving all consents, the conference server sends a "200 Ok" response to the recording party. The recording party starts recording and sends a NOTIFY for recording started event. The conference server relay the NOTIFY to all the recorded parties. 10. XML Schema Definitions The session-recording schema is shown below. We expect a separate document defining the XML schema for consent negotiation. Wu & Krishnaswamy Expires December 9, 2006 [Page 11] Internet-Draft media-recording June 2006 If no media provided, all the media streams from the call will be recorded. If no mid provided, all streams with the same media type will be recorded. If no "from" provided, recording starts immediately after the session-recording notification. Note that the value of "from" may before the current time. Wu & Krishnaswamy Expires December 9, 2006 [Page 12] Internet-Draft media-recording June 2006 If no until provided, recording lasts until the end of the session. Figure 11: XML schema for session-recording 11. IANA Considerations 11.1. URN Sub-Namespace Registration This section registers a new XML namespace, per the guidelines in [4] URI: The URI for this namespace is urn:ietf:params:xml:ns:session-recording. Registrant Contact: Xiaotao Wu (xwu@avaya.com), Venkatesh Krishnaswamy (venky@avaya.com). XML: BEGIN Session Recording Notification Namespace

Namespace for Session Recording Notification

urn:ietf:params:xml:ns:session-recording

See RFCXXXX.

END Wu & Krishnaswamy Expires December 9, 2006 [Page 13] Internet-Draft media-recording June 2006 11.2. XML Schema Registration This section registers one XML schemas per the procedures in [4]. URI: urn:ietf:params:xml:ns:session-recording. Registrant Contact: Xiaotao Wu (xwu@avaya.com), Venkatesh Krishnaswamy (venky@avaya.com). The XML for this schema can be found in Section 10. 12. Security Considerations TBD [[Comment.7: The same security considerations of the framework for Consent-Based Communications in SIP applied here. The parties who grant permissions for recording should have the consent documents signatured.]] 13. References 13.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCD 14, March 1997. [2] Rosenberg et al., J., "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Camarillo, G., "The Session Initiation Protocol (SIP) CONSENT Method", draft-camarillo-sip-consent-method-00.txt (work in progress), February 2006. [4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [6] PUBLIC LAW 99-508, "Electronic Communications Privacy Act of 1986", October 1986. [7] Rosenberg, J., "An INVITE Inititiated Dialog Event Package for the Session Initiation Protocol (SIP)", draft-ietf-sipping-dialog-package-06 (work in progress), April 2005. Wu & Krishnaswamy Expires December 9, 2006 [Page 14] Internet-Draft media-recording June 2006 13.2. Informative References [8] Rosenberg, J., "A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)", draft-ietf-sipping-consent-framework-04 (work in progress), February 2006. [9] The Reporters Committee for Freedom of the Press, "A Practical Guide to Taping Phone Calls and In-Person Conversations in the 50 States and D.C.", December 2003. [10] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [11] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [12] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. Wu & Krishnaswamy Expires December 9, 2006 [Page 15] Internet-Draft media-recording June 2006 Authors' Addresses Xiaotao Wu Avaya Labs Research 307 Middletown Lincroft Road Lincroft 07738 USA Email: xwu@avaya.com Venkatesh Krishnaswamy Avaya Labs Research 307 Middletown Lincroft Road Lincroft 07738 USA Email: venky@avaya.com Wu & Krishnaswamy Expires December 9, 2006 [Page 16] Internet-Draft media-recording June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Wu & Krishnaswamy Expires December 9, 2006 [Page 17]