SIP Extensions for Caller Identity and Privacy

<draft-ietf-sip-privacy-01.txt>

Flemming Andreasen (fandreas@cisco.com)

W. Marshall, K. K. Ramakrishnan, E. Miller, G. Russell, B. Beser, M. Mannette, K. Steinbrenner, D. Oran, F. Andreasen, J. Pickens, P. Lalwaney, J. Fellows, D.

Evans, K. Kelly, M. Watson

IETF - March 2001

I-D Status

• At the last IETF:– To date, very few comments received– No known issues– But “hum” did not reach consensus for WG Last

Call

• Since last IETF– Got one set of comments from Mark Watson– List discussion followed by list consensus on next

steps– I-D updated accordingly

The Comments

• Generalize Remote-Party-ID– Make usable for any type of identity information– Define basic ones and incl. extension mechanism

• Suggested five specific enhancements:– Requlatory Requirements– Types of Party– Types of Identity– Handling of Privacy Requirements– Location Information

The Comments, cont.

• Requlatory requirements– Both user and “network” must be able to

request privacy.

• Types of Party– Calling, called, connected, etc.

• Types of Identity– Subscriber, user, terminal, etc.

• Handling of privacy requirements – Each type may have its own requirement.

The Comments, cont.

• Location Information– Physical location of party, e.g. for E911

• Fair amount of list discussion led to consensus on:– Generalize Remote-Party-ID as suggested.– Include support for first four enhancements:

• Requlatory requirements

• Types of Party

• Types of Identity

• Handling of Privacy Requirements

The Comments, cont.

• Location Information was controversial though.

• However– Location information not required for all

applications.– A URL-based location information scheme

could be supported as an extension.

• Consensus on leaving out the specifics of location information from the draft.

Spec Changes

• Rpi-token (in Remote-Party-ID)– Removed rpi-type– Added rpi-pty-type, rpi-id-type, and rpi-privacy

• Anonymity– Removed “full”, “uri”, and “name”

• Updated processing rules incl. default handling of unknown Remote-Party-ID’s:– Must be marked as “non-screened”– Privacy must be afforded if requested.

Resulting Header Definitions

Remote-Party-ID = "Remote-Party-ID" ":" [display-name] "<" addr-spec ">" *(";" rpi-token)rpi-token = rpi-screen |rpi-pty-type | rpi-id-type | rpi-privacy | other-rpi-tokenrpi-screen = "screen" "=" ("no" | "yes" )rpi-pty-type = "party" "=" ( "calling" | "called" | token )rpi-id-type = "id-type" "=" ( "subscriber" | "user" |"alias" | "return" | "term" | token )rpi-privacy = "privacy" "=" 1#(("full" | "name" | "uri" | "off" | token ) [ "-" ( "network" | token ) ] ) other-rpi-token = token ["=" (token | quoted-string)]

Anonymity = "Anonymity" ":" 1#privacy-tagprivacy-tag = "ipaddr" | "off" | token