Download presentation
Presentation is loading. Please wait.
Published byRosamond Washington Modified over 9 years ago
1
SIP Extensions for Caller Identity and Privacy 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
2
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
3
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
4
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.
5
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
6
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.
7
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.
8
Resulting Header Definitions Remote-Party-ID = "Remote-Party-ID" ":" [display-name] " " *(";" rpi-token) rpi-token = rpi-screen |rpi-pty-type | rpi-id-type | rpi-privacy | other-rpi-token rpi-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-tag privacy-tag = "ipaddr" | "off" | token
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.