Internet DRAFT - draft-shacham-sip-media-privacy
draft-shacham-sip-media-privacy
Session Initiation Protocol R. Shacham
Internet-Draft H. Schulzrinne
Expires: December 27, 2006 Columbia University
W. Kellerer
S. Thakolsri
DoCoMo Eurolabs
June 25, 2006
Use of the SIP Preconditions Framework for Media Privacy
draft-shacham-sip-media-privacy-02
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 27, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
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 December 27, 2006 [Page 1]
Internet-Draft SIP Preconditions for Media Privacy June 2006
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 December 27, 2006 [Page 2]
Internet-Draft SIP Preconditions for Media Privacy June 2006
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 December 27, 2006 [Page 3]
Internet-Draft SIP Preconditions for Media Privacy June 2006
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
<sip:mike@example.com> 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 December 27, 2006 [Page 4]
Internet-Draft SIP Preconditions for Media Privacy June 2006
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 December 27, 2006 [Page 5]
Internet-Draft SIP Preconditions for Media Privacy June 2006
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 December 27, 2006 [Page 6]
Internet-Draft SIP Preconditions for Media Privacy June 2006
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 December 27, 2006 [Page 7]
Internet-Draft SIP Preconditions for Media Privacy June 2006
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 December 27, 2006 [Page 8]
Internet-Draft SIP Preconditions for Media Privacy 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.
Shacham, et al. Expires December 27, 2006 [Page 9]
