August 2005 IETF 63 - SIPPING

Specifying Media Privacy Requirements in

SIP

Ron ShachamHenning Schulzrinne

{hgs,rs2194}@cs.columbia.eduDept. of Computer Science

Columbia University

August 2005 IETF 63 - SIPPING

Overview Motivation:

Speakerphones, output devices and session mobility can compromise a call participant’s privacy.

Unauthorized recording. Goals:

Allow users to specify privacy demanded from the other device;

whether recording of the session is allowed; at call setup and anytime during the call.

Scope: While a device may be unable to enforce requirements, they provide clear indication of intent similar to GEOPRIV embedded handling instructions

(distribution and retention)

August 2005 IETF 63 - SIPPING

Applications

Proxy only routes the call to a device that has the right level of privacy

Disallow the other call participant from transferring the call to a public device, turning on his speakerphone, or recording the call

Force the other participant’s device to retrieve the session from a public device when the conversation becomes more private

August 2005 IETF 63 - SIPPING

Privacy Definitions Privacy levels

1 = only device user may access the media 2 = anyone in the device user’s organization (school, company,

circle of friends, etc.) may access the media 3 = anyone may access the media

A device may have multiple privacy levels, based on different settings: A phone has level 1 when the receiver Is used, level 2 when

speakerphone is used. Privacy levels of a device may change based on its

surroundings: If nobody else is in the room, even speakerphone has level 1, but

when somebody walks in, it changes to level 2 or level 3.

August 2005 IETF 63 - SIPPING

Protocol Extensions—Caller Preferences

New feature preference: privacy Accept-Contact: *;privacy=1;require

causes the proxy server to only route the call to a device on which only the user can view or hear

The device must respect this level of privacy (e.g., no speakerphone or transfer to a public device) for the duration of the call, unless it is updated through SDP mechanism

August 2005 IETF 63 - SIPPING

Protocol Extensions—SDP Attributes Session-level attributes only May be used at call setup or in mid-call re-INVITE Privacy

“a=required-privacy:user” demands that the other device not make media available to anyone besides the user

“a=provided-privacy:user” expresses that no other user has access to the media

When “required-privacy” is used in an offer, the answer must include the “provided-privacy” attribute with a value within the required range. The device must respect this level for the duration of the call, unless it is updated.

Recording “a=norecord” disallows recording of the session When used in an offer, answer must also contain this attribute

value.

August 2005 IETF 63 - SIPPING

Extension: preconditions

Use SIP preconditions to establish mutually acceptable media privacy

Is this sufficiently useful to be implemented?

August 2005 IETF 63 - SIPPING

Open Issues

Useful enough? Need “Require” header to ensure that old

systems don’t unintentionally pretend that they are honoring the media privacy request

“Privacy” “Sharing”?