Session Initiation Protocol R. Shacham Internet-Draft H. Schulzrinne Expires: May 23, 2006 Columbia University W. Kellerer S. Thakolsri DoCoMo Eurolabs November 19, 2005 Use of the SIP Preconditions Framework for Media Privacy draft-shacham-sip-media-privacy-01 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 May 23, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Recording of a conversation presents a possible breach of privacy. This document presents a use of the SIP Preconditions Framework to negotiate the recording guidelines for the session. One party may assert either their desire to record or their restriction of the other party's recording. In order to establish the session, the Shacham, et al. Expires May 23, 2006 [Page 1] Internet-Draft SIP Preconditions for Media Privacy November 2005 other party must respond that it agrees to the conditions. While this does not have the power to limit the physical recording by the user on the end system, it provides evidence of the expressed wishes of one party and the agreement of the other. 1. Overview Recording of a conversation presents a possible breach of privacy. As such, it is useful to provide a way in which participants in a Session Initiation Protocol (SIP)[1] session may negotiate during session establishment the recording guidelines for the session. Namely, one party may assert a rule about recording and make the session establishment conditional on its agreement by the other party. While the information transferred during session establishment does not necessarily have the power to actually limit the recording done by the user on the end device, it provides evidence of the expressed wishes of one party and the agreement of the other. Two different types of conditions may be made during session setup. A participant may assert an intention to record so that the other party must explicitly agree before the call is set up. He may have a legal or other obligation to ask permission before recording. Alternatively, a participant may impose a restriction on the other party's recording and require his explicit agreement before setting up the call. The assertion and its agreement may give the participant a legal right not to be recorded. Either the caller or callee may assert either of the above conditions, and the other participant may either accept them and continue with session establishment, or reject them. The Preconditions Framework in SIP [2] was found to be a good existing method for this negotiation. It allows session establishment to be suspended until specific conditions are met. These conditions may be expressed by either the caller or callee, and the other party may fulfill them and continue with session setup, or reject them and terminate the session setup. 2. Terminology 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 BCP 14, RFC 2119 [3]. Shacham, et al. Expires May 23, 2006 [Page 2] Internet-Draft SIP Preconditions for Media Privacy November 2005 3. Definition of "no-record" and "allow-record" precondition types Precondition type tag: no-record Status type: e2e Precondition strength: No optional precondition available Precondition type tag: allow-record Status type: e2e Precondition strength: optional precondition available We define two precondition types in accordance with [2] and [4]. Only the "recv" direction is relevant to a call participant, since it doesn't make sense to restrict what another person does with the media stream that he himself sends. Therefore, the "send" and "recv" directions are sufficient for defining all preconditions in a single media session, without the need of a "local" and "remote", so we use the e2e status type. The type "no-record" imposes a recording restriction on the other party. In order to set up the session, the recipient must respond that the current state of his received media stream is "no-record". The type "allow-record" asserts a party's desire to record. The recipient must respond that the current state of his sent media stream is "allow-record". The allowed precondition strengths differ for the two types defined. A call participant is unlikely to request that the other party not record their converation, but accept the session in any case. Therefore, a precondition strength of "optional" is unnecessary and not allowed for "no-record". On the other hand, a participant may ask for permission to record so that he will have evidence of the other party's agreement, but may still accept the session without recording. For this reason, a precondition strength of "optional" is allowed for "allow-record". A single direction of a media session, that is a stream, MUST NOT have both the "allow-record" and "no-record" preconditions as "current", as this would be contradictory. However, each direction of a media session may contain a separate precondition. For example, both participants in a session may assert their desire to record. Alternatively, one party may assert his desire to record, while restricting the other's right to record. 4. Differences in the use of preconditions The initial use case described for the Preconditions Framework was Shacham, et al. Expires May 23, 2006 [Page 3] Internet-Draft SIP Preconditions for Media Privacy November 2005 resource reservation to ensure Quality of Service. Specifically, one party requires the other to verify that resources are available before accepting the call. The use and the call flows for our purposes differ somewhat. For example, while a precondition answerer will likely require time to reserve a resource, the acceptance or rejection of a recording precondition is expected to be almost immediate. The decision could be made based on local policy, as would be done by a help desk or an emergency call center which would never accept a call without recording. Otherwise, the recipient would be prompted with a dialog such as "Mike Jones is calling -- Would you like to accept the call and give him permission to record?" Therefore, while [2] states that a UAS receiving an offer with preconditions "SHOULD NOT alert the user until all the mandatory preconditions are met", this is not appropriate for our application. For this reason, a response of 183 will generally not be sent by the answerer who is a callee, as is done in [2]. If the anwerer has a local policy about recording, a 200 response will be sent immediately to accept the precondition or a 580 response to reject it. If the user needs to be prompted to accept the preconditions, a 180 will be sent, followed by a 200 or 580. When the callee is the offerer of the precondition, the flow will also differ because of the almost immediate nature of the answerer's response. The caller answerer may return the current status of the preconditions in the PRACK, as permitted in [5], and need not send a separate UPDATE later as is done in the QoS case. 5. Scenarios 5.1. Setting up a session with "no-record" or "allow-record" precondition by caller A invites B into a session, but wants to ensure that B will not record the call. The INVITE request contains an SDP body with the following media line: m=audio 20000 RTP/AVP 0 a=curr:no-record e2e none a=des:no-record mandatory e2e send a=des:no-record none e2e recv If B accepts the preconditions as well as the call, it responds to this request by sending a 200 response containing the following media line: Shacham, et al. Expires May 23, 2006 [Page 4] Internet-Draft SIP Preconditions for Media Privacy November 2005 m=audio 30000 RTP/AVP 0 a=curr:no-record e2e recv a=des:no-record mandatory e2e recv a=des:no-record none e2e send If, on the other hand, B wishes to reject the preconditions, it sends a 580 (Precondition-Failure) response, as per [2]. As suggested there, B SHOULD include a media line that describes the reason for the failure: m=audio 30000 RTP/AVP 0 a=des:no-record failure e2e recv If A were asserting its desire to record, rather than its restriction of B's recording, the above interaction would take place with the "allow-record" precondition type, with A setting the "recv" direction to be mandatory so that he may record the input, rather than the "send" direction as above. 5.2. Setting up a session with "no-record" or "allow-record" precondition by callee B receives an INVITE request from A that includes no mention of recording. However, B would like to ensure that A does not record the call. B replies with a 183 provisional response that includes the precondition in the SDP media line as follows: m=audio 20000 RTP/AVP 0 a=curr:no-record e2e none a=des:no-record mandatory e2e send a=des:no-record none e2e recv If B has a local policy set that always insists that the other party not record the call, the UAS would immediately send this response without ringing him. Otherwise, his device would ring him to accept the call, and to ask whether a recording assertion should first be made. If he chose to accept it and restrict A's recording, the 183 would then be sent. A replies to this response with a PRACK, containing an SDP body with the following media line: m=audio 30000 RTP/AVP 0 a=curr:no-record e2e recv a=des:no-record mandatory e2e recv a=des:no-record none e2e send B responds to the PRACK with a 200 response. If B has not yet accepted the call, his UA will alert him with a ring. Once he accepts, the UAS will send a 200 response to the initial INVITE Shacham, et al. Expires May 23, 2006 [Page 5] Internet-Draft SIP Preconditions for Media Privacy November 2005 request. If B has already accepted, the 200 response will be sent automatically. If A wishes to reject the preconditions, it responds with a PRACK and immediately sends a CANCEL, following the procedure described in [2]. The CANCEL SHOULD contain an SDP description indicating the reason for failure, as was mentioned above regarding the 580 response. If B were asserting its desire to record, rather than its restriction of A's recording, the above interaction would take place with the "allow-record" precondition type, with B setting the "recv" direction to be mandatory so that he may record the input, rather than the "send" direction as above. 6. Introducing a recording assertion in the middle of a call Once a call is established, the nature of the conversation may become more sensitive and a user may wish to impose a restriction on the other party. Alternatively, a user may decide that he wishes to record and wants to get the approval of the other participant. If A wishes to restrict recording by B, it sends an INVITE containing the following media line: m=audio 20000 RTP/AVP 0 a=curr:no-record e2e none a=des:no-record mandatory e2e send a=des:no-record none e2e recv If B accepts the restriction, it responds with a 200 response containing the following media line: m=audio 30000 RTP/AVP 0 a=curr:no-record e2e recv a=des:no-record mandatory e2e recv a=des:no-record none e2e send A then responds with an ACK. B may also respond with a 580 response to the INVITE, which will prompt A to send a BYE request to terminate the session. 7. Security Considerations This document, itself, is concerned with providing SIP session participants with a negotiation mechanism for agreeing on acceptable recording guidelines. The recorded evidence of agreement provided by Shacham, et al. Expires May 23, 2006 [Page 6] Internet-Draft SIP Preconditions for Media Privacy November 2005 this mechanism gives call participants a measure of security. However, the negotiation does not necessarily impose any behavior on the device being used in the call (ie. to disallow recording by the user), although vendors may choose to have their devices comply to it. 8. IANA Considerations We define two precondition types, "no-record" and "allow-record" in accordance with [2] and [4]. Precondition type tag: no-record Purpose: Restrict the recording of one's media stream by another call participant Status type: e2e Precondition strength: No optional precondition available Precondition type tag: allow-record Purpose: Assert one's desire to record the media stream of another call participant Status type: e2e Precondition strength: optional precondition available 9. References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Sparks, R., Handley, A., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [4] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation Protocol (SIP) Preconditions Framework", RFC 4032, March 2005. [5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in the Session Initiation Protocol (SIP)", RFC 3262, June 2002. Shacham, et al. Expires May 23, 2006 [Page 7] Internet-Draft SIP Preconditions for Media Privacy November 2005 Authors' Addresses Ron Shacham Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA Email: rs2194@cs.columbia.edu Henning Schulzrinne Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA Email: hgs@cs.columbia.edu Wolfgang Kellerer DoCoMo Eurolabs Landsberger Str. 312 Munich 80687 Germany Email: kellerer@docomolab-euro.com Srisakul Thakolsri DoCoMo Eurolabs Landsberger Str. 312 Munich 80687 Germany Email: thakolsri@docomolab-euro.com Shacham, et al. Expires May 23, 2006 [Page 8] Internet-Draft SIP Preconditions for Media Privacy November 2005 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 (2005). 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. Shacham, et al. Expires May 23, 2006 [Page 9]