1 / 8

SIP Extensions for Caller Identity and Privacy <draft-ietf-sip-privacy-01.txt>

SIP Extensions for Caller Identity and Privacy <draft-ietf-sip-privacy-01.txt>. Flemming Andreasen (fandreas@cisco.com)

fabiana-fullam
Télécharger la présentation

SIP Extensions for Caller Identity and Privacy <draft-ietf-sip-privacy-01.txt>

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  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] "<" addr-spec ">" *(";" 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

More Related