[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
SIP Working Group                                           W. Marshall
Internet Draft                                          K. Ramakrishnan
Document: <draft-dcsgroup-sip-privacy-01.txt>                      AT&T
Category: Informational
                                                              E. Miller
                                                             G. Russell
                                                              CableLabs

                                                               B. Beser
                                                            M. Mannette
                                                        K. Steinbrenner
                                                                   3Com

                                                                D. Oran
                                                           F. Andreasen
                                                                  Cisco

                                                             J. Pickens
                                                                  Com21

                                                            P. Lalwaney
                                                             J. Fellows
                                                               Motorola

                                                               D. Evans
                                                 Secure Cable Solutions

                                                               K. Kelly
                                                               NetSpeak

                                                            March, 2000


   SIP Extensions for Caller Identity, Privacy and Operator Services


Status of this Memo

   This document is an Internet-Draft and is NOT offered in accordance
   with Section 10 of RFC2026[1], and the author does not provide the
   IETF with any rights other than to publish as an Internet-Draft.

   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


DCS Group        Internet Draft - Expiration 9/30/00                1

                  SIP Extensions for Caller Privacy        March 2000


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   The distribution of this memo is unlimited.  It is filed as <draft-
   dcsgroup-sip-privacy-01.txt>, and expires September 30, 2000. Please
   send comments to the authors.



1. Abstract

   The Session Initiation Protocol (SIP) [4] is an application layer
   control (signaling) protocol for creating, modifying and terminating
   sessions with one or more participants. In the current PSTN, call
   signaling messages travel through switches which act as trusted
   intermediaries. The signaling messages typically include calling
   party identification information which may be delivered to the
   called party. The calling party is able to suppress the delivery of
   such information to the called party in order to maintain privacy.

   In a Voice over IP environment using SIP user agents as the
   equivalent of telephones and SIP proxies as trusted intermediaries,
   there may still be requirements to provide calling party
   identification information, yet communicating parties may also
   desire to maintain their privacy. In this document, we describe
   three proposed SIP extensions. The first one may be used to support
   calling and called party, i.e. remote party, identification
   including a remote party-type to identify special types of callers
   such as operators. The second extension allows a party to request
   privacy in the above mentioned environment and includes a
   recognition that privacy in a VoIP environment extends beyond simply
   hiding SIP level user information, to potentially hiding the parties
   IP address information as well. The third extension allows a user
   agent to be requested to extend special operation to some calls such
   as operator services.


2. Conventions used in this document

   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 RFC-2119 [2].


3. Introduction

   In the telephone network, calling identity information is needed to
   support the Calling Number Delivery and Calling Name Delivery
   services which provide the called party with identity information
   about the calling party prior to the called party answering the
   call; the calling party is here identified as the station
   originating the call. In order for this service to be dependable,
   the called party must be able to trust that the calling identity

DCS Group        Internet Draft - Expiration 9/30/00                2

                  SIP Extensions for Caller Privacy        March 2000


   information being presented is valid. Consider for example a tele-
   marketer presenting himself with the identity of one of your co-
   workers, or, even worse, an automated credit-card activation system
   using calling identity information as an authentication check. In
   order for the calling identity information to be trustworthy, the
   information must come from a trusted source.

   Calling identity information may also be needed to support
   regulatory requirements for a public telephony service. An example
   of this is the Customer Originated Trace service, which enables a
   called party to have the identity of a calling party recorded by the
   telephony service provider. This enables, e.g., the receiver of
   harassing phone calls to make the identity of the originator of such
   calls available to the proper authority. Again, in order for this
   service to be useful, the Calling Identity information recorded must
   be trustworthy.

   One scenario for establishing such trust is for a SIP user agent to
   require that all incoming SIP invitations arrive through a trusted
   SIP proxy. For simplicity we will assume that each SIP user agent is
   associated with a single SIP proxy, which we will refer to as a DCS-
   proxy in this document. DCS-proxies are interconnected with other
   DCS-proxies which may or may not trust each other. When a SIP user
   agent originates a call through its DCS-proxy, it trusts that the
   DCS-proxy will carry out the service requested, even if other DCS-
   proxies are involved. The DCS-proxy however does not trust the SIP
   user agent since it will typically reside at the customer premise.

   When a call is placed, the calling identity delivery services reveal
   privacy information to the called party, and the calling party
   therefore has the option to block the delivery of this information
   to the called party. In the PSTN, this is typically achieved by
   subscribing to a Calling Identity Delivery Blocking service but can
   be done on an individual call basis as well. When the Calling
   Identity Delivery Blocking Service is invoked, information about the
   calling party is still passed through the trusted intermediaries,
   however presentation restriction indicators are set in the signaling
   messages to signal the far-end side, that the calling identity
   information is not to be provided to the called party.

   More generally, we may say that the service provided is that of
   preventing the called party from obtaining information about the
   calling party that may either be used to identify the party or
   reveal location information about the party. In an IP environment,
   IP addressing information may provide the other party with
   information to reach or identify the calling party. IP addressing
   information may reveal some level of location information, for
   instance if one has knowledge of which addresses are deployed where,
   or by revealing that a given caller is using a different IP-address
   or address block than usual.

   When such a privacy service is to be provided in a SIP environment,
   it leads to two requirements. First, calling identity information

DCS Group        Internet Draft - Expiration 9/30/00                3

                  SIP Extensions for Caller Privacy        March 2000


   present in SIP messages must not be delivered in an intelligible
   form to the called party, yet it must be possible to determine the
   identity of the call originator even in the case where the call is
   routed through one or more untrusted intermediaries. Secondly, when
   using SIP in an IP environment, IP addressing information must be
   able to be hidden from the other party. Furthermore, in an IP
   environment, these requirements apply equally well in the opposite
   direction, i.e. the calling party may wish to identify the called
   party and the called party may have privacy concerns as well.


4. SIP Extensions

   In the following we present our proposed SIP extensions for Calling
   and Called Identity Delivery, and Privacy as well as an extension
   for requesting special call processing, e.g. for operator services.
   We then present an example of how the privacy extensions may be used
   to provide the privacy service.

   The syntax specification in the following uses the augmented Backus-
   Naur Form (BNF) as described in RFC-2234 [3].


4.1 CALLING AND CALLED PARTY IDENTITY DELIVERY

   For the Calling and Called Identity Delivery, we assume that a SIP
   user agent can determine if invitations are arriving through its
   DCS-proxy, and thereby can be trusted, or not. Furthermore, as in
   the current telephone network, the trusted DCS-proxy is assumed to
   either receive or possess calling party information that enables it
   to determine the identity of the calling party. In the following, we
   will use the term remote party to refer to calling and called party,
   where a distinction is not important.

   The calling party identity information could be provided to the
   called party's DCS-proxy as the "display-name" in the "name-addr"
   part of a From header field [4]. Even though the "display-name" is
   part of the "From" header, it is not considered part of the call leg
   identifier. SIP user agents and DCS-proxies would therefore be able
   to manipulate the value of this parameter, including adding,
   modifying, and deleting Calling Identity information. This was in
   fact suggested in a previous version of this document, but based on
   Working Group feedback, it was preferred to introduce a separate
   header field for this.

   The header field suggested is called Remote-Party-ID, which is added
   to an INVITE message to identify the caller and provides a long-
   lived identification of the caller. The header field may also be
   added to the response to provide a long-lived identification of the
   called party. The Remote-Party-ID header field is inserted by the
   originating SIP user agent, and is verified and possibly modified by
   its DCS Proxy. The DCS-proxy authenticates the information provided,
   for example by digitally signing the Remote-Party-ID or simply

DCS Group        Internet Draft - Expiration 9/30/00                4

                  SIP Extensions for Caller Privacy        March 2000


   providing a Message Authentication Code (MAC); the details depend on
   the authentication scheme used. Whenever the call originator
   requests privacy and the message crosses a trust boundary, the
   Remote-Party-ID must be encrypted to ensure that its confidentiality
   is maintained while still enabling the call originator to be
   identified (by the encrypting proxy).

   The terminating DCS Proxy forwards the Remote-Party-ID header to the
   destination SIP user agent in an intelligible form (if possible)
   only if the user agent has subscribed to Caller ID/Calling Name
   delivery service, and the originator has not requested privacy.
   Similar operation may be performed in the reverse direction. The
   proposed header syntax follows:

     Remote-Party-ID    = "Remote-Party-ID" ":" [display-name]
                                "<" addr-spec ">" *(";" rpi-token)

     rpi-token          = rpi-id | rpi-type | rpi-auth |
                                                other-rpi-token

     rpi-id             = "rpi-id" "=" ("private" | "unavailable"
                                                                | "na")

     rpi-type           = "rpi-type" "=" ("operator" | token)

     rpi-auth           = "auth" "=" auth-scheme #auth-param
     auth-scheme        = token
     auth-param         = token "=" (token | quoted-string)

     other-rpi-token    = token ["=" (token | quoted-string)]

   Furthermore, we define the value "private" for "other-param" in an
   "addr-spec", to indicate that the user part of an "addr-spec" is in
   a non-intelligible form. The syntax for "other-param" is therefore
   refined to:

     other-param        = (token | (token "=" (token | quoted-string)))
                          | "private"

   The "display-name" in Remote-Party-ID is a text string that
   identifies the account name of the party. The "addr-spec" contains
   information identifying the party either in clear-text or encrypted
   form. In the latter case, the "user" part of the "addr-spec"
   contains the encrypted party information, whereas the "hostport"
   identifies the entity that can decrypt the information. Furthermore,
   an "other-param" value of "private" will be present to indicate that
   the "addr-spec" is encrypted.

   The following example illustrates this:

     Remote-Party-ID: <sip: e(555-1212)@myproxy; private>

   where e(x) indicates that x is encrypted.

DCS Group        Internet Draft - Expiration 9/30/00                5

                  SIP Extensions for Caller Privacy        March 2000



   When the called party subscribes to calling identity delivery
   services, and the remote party information is not readily available,
   the "rpi-id" token indicates the nature of the "addr-spec" provided.
   The value "private" indicates that the remote party information is
   encrypted, and consequently the user agent should not attempt to
   display it. The value "unavailable" indicates that calling identity
   information was not available and the addr-spec provided should be
   ignored. When the called party does not subscribe to calling
   identity delivery services, the value "na" may be provided.


   The "rpi-type" token allows the SIP user agent to identify different
   types of callers which may be used to determine if special
   privileges should be extended to a given party. The string
   "operator" is a reserved identifier indicating that a telephony
   service provider operator is the remote party. The SIP user agent
   may for instance decide to honor a request for Busy-Line
   Verification or Emergency Interrupt by an operator; a request it
   might otherwise refuse.

   As noted above, calling identity information must be trustworthy in
   order to be useful. In the absence of a trust relationship between
   all the proxies involved in a call, it must therefore be possible to
   add authenticity information to the Remote-Party-ID as well as
   specify who authenticated the information.

   The "auth" token provides this function by authenticating everything
   in the Remote-Party-ID that precedes the "auth" token (up until but
   not including the semi-colon). The actual syntax and semantics
   depend on the authentication scheme used. Details on usage with pgp
   is specified later in this document.

   Multiple "auth" tokens may be present which allows proxies to state
   that the Remote-Party-ID information provided is authentic without
   necessarily claiming that the identity of the remote party is
   correct. For example, a call between A and B where A is served by
   Proxy PA and B is served by Proxy PB might have the following
   Remote-Party-ID:

     Remote-Party-ID: <sip:A@mynet.com;user=ip>;
                        auth=pgp signature="abc", signed-by="PA";
                        auth=pgp signature="xyz", signed-by="PB"

   which implies that PA certifies that the call was originated by A,
   whereas PB certifies that PA certifies that the call was originated
   by A. Had PB trusted PA, then PB could instead have removed the
   "auth" token from PA, and simply have certified the information
   itself.

   Finally, it should be noted, that when a proxy encrypts the Remote-
   Party-ID information, the proxy may choose to add additional "url-
   parameters" (in the form of "other-param") to the "addr-spec" to

DCS Group        Internet Draft - Expiration 9/30/00                6

                  SIP Extensions for Caller Privacy        March 2000


   identify the encryption algorithm used as well as integrity checks
   for the "addr-spec". These parameters could be useful to the proxy
   when the "addr-spec" is used for a subsequent call, e.g. call return
   or call trace, however this would be internal to the proxy and is
   consequently not specified. This operation should not be confused
   with the authentication parameters specified above where the
   authenticating party, e.g. proxy, may differ from the verifying
   party, e.g. user agent.


4.1.1 Remote-Party-ID Authenticity with PGP

   This section details the use of pgp for the rpi-token by refining
   the auth syntax as follows:

        rpi-auth        = "auth" "=" auth-scheme #auth-param
        auth-scheme     = "pgp"
        auth-param      = pgp-response

   where pgp-response is defined in RFC 2543, Section 15.1.2.

   An example was provided in the previous section.


4.2 PRIVACY

   In support of privacy, the originator of a call must have a way of
   suppressing the delivery of calling identity information to the
   called party. One way of achieving that could simply be to omit the
   information from the Remote-Party-ID field. However, for DCS-proxy
   to DCS-proxy communication, where the information would still need
   to be passed, a presentation restriction indicator would then be
   needed.

   Also, in order to maintain complete privacy in an IP environment,
   calling party IP-address information may have to be concealed from
   the terminating party as well. The cost and complexity of providing
   IP address level privacy rather than simply SIP level privacy is
   likely to differ enough to warrant two separate services. The
   calling party will thus need to signal the DCS-proxy which privacy
   service it is requesting.

   We therefore propose to extend SIP with a new header field called
   Anonymity which allows an originating SIP user agent to indicate the
   degree of privacy that should be provided by the DCS proxy.  The
   value "URI" requests the party's identity not be provided to the
   destination. The value "Name" requests the calling name not be
   provided.  The value "IPAddr" requests IP privacy such that the
   destination is not given the originator's IP address. The value
   "Full" requests both URI and Name blocking and IP address privacy.
   The header field also allows a receiving SIP user agent to indicate
   its desire for privacy in its response to the first INVITE request.



DCS Group        Internet Draft - Expiration 9/30/00                7

                  SIP Extensions for Caller Privacy        March 2000


   This will operate similarly to privacy requested by the originating
   party.

   The syntax for the proposed header field follows:

        Anonymity       = "Anonymity" ":"  *privacy-tag
        privacy-tag     = "Full" | "URI" | "Name" | "IPAddr" | "Off"

   If privacy is requested, it MUST be one or more of "Full", "URI",
   "Name", or "IPAddr". The value "Off" indicates that no privacy is
   requested, and MUST be the only value if present.


4.3 Operator Services Call Processing

   Some calls have special call processing requirements that may not be
   satisfied by normal user agent call processing. For example, when a
   user is engaged in a call and another call arrives, such a call
   might be rejected with a busy indication. However, some PSTN
   operator services require special call processing. In particular,
   the Busy line verification (BLV) and Emergency interrupt(EI)
   services initiated by an operator from an Operator Services Position
   System (OSPS) on the PSTN network have such a need.

   In order to inform the SIP user agent, that special treatment should
   be given to a call, we propose a new OSPS header field which may be
   set to a value indicating when a special type of call processing is
   requested. We define two values in this header, namely "BLV" for
   busy line verification and "EI" for emergency interrupt:

        OSPS            = "OSPS" ":" OSPS-Tag
        OSPS-Tag        = "BLV" | "EI" | token

   If the user agent decides to honor such a request, the response of
   the user agent to an INVITE with either "BLV" or "EI" will not be a
   busy indication. When such a request is received, the user agent may
   look at the Remote-Party-ID, and decide only to honor the request if
   "rpi-type" is "operator" and Remote-Party-ID was authenticated by
   the user agent's DCS-proxy.



4.4 Example of Use

   In this Section, we will illustrate how the request for privacy may
   work in practice. It should be noted that the privacy service
   described can be implemented in a number of ways; we merely describe
   one possible solution in this section.


   The Figure below illustrates a basic privacy example scenario




DCS Group        Internet Draft - Expiration 9/30/00                8

                  SIP Extensions for Caller Privacy        March 2000


                +---------+             +--------+
     1: INVITE  | DCS     | 2: INVITE   | DCS    | 3: INVITE
       +------->| proxy-o |------------>| proxy-t|---------+
       |        +---------+             +--------+         |
       |                                                   |
       |                 trust boundary                    |
   . . |. . . . . . . . . . . . . . . . . . . . . . .. . . | . . .
       |                                                   |
       |                                                   \/
   +------+                  RTP/RTCP                   +------+
   |MTA-o |<------------------------------------------->|MTA-t |
   +------+                                             +------+

                Figure 1 - Basic Privacy Example


   The originating user agent (MTA-o) sends an INVITE (1) message
   requesting URI and name privacy to DCS-proxy-o. DCS-proxy-o ensures
   that valid calling identity information is included in the message
   before it sends INVITE (2) to DCS-proxy-t, which in this case is
   trusted. DCS-proxy-t examines the Anonymity header field included in
   the INVITE and sees that URI and name privacy is requested. DCS-
   proxy-t therefore encrypts the "addr-spec" in the Remote-Party-ID,
   puts the result in the "user" part, inserts itself as the
   "hostport", and adds an "auth" parameter to the end, e.g. using a
   pgp signature. If MTA-t subscribes to caller-id, DCS-proxy-t also
   inserts "rpi-id=private" in the Remote-Party-ID. Finally, if a
   "display-name" was provided in the Remote-Party-ID, DCS-proxy-t
   simply removes it.

   While this illustrates the basic operation of the service, there are
   additional issues that need to be considered. In SIP, there are
   additional fields that can reveal the identity of the calling party,
   either in part or completely. In the cases of calling name and
   calling number privacy, the "addr-spec", e.g. SIP-URL, as well as
   "display-name" part of the From header field may contain calling
   party information. This privacy problem can be overcome by having
   MTA-o supply a cryptographically random identifier for the userinfo,
   and a non-identifying hostname, e.g. "localhost". Also, when the
   session description protocol (SDP) is used to describe the media in
   the session, the use of SDP fields revealing calling identity
   information needs to be considered as well. Similar concerns apply
   to the use of RTCP.

   The second example we look at is one where full privacy is
   requested, i.e. both calling name and number privacy, as well as IP
   address privacy. The Figure below illustrates how IP address privacy
   can be achieved by inserting a trusted intermediary, an anonymizer,
   for the media streams between MTA-o and MTA-t.





DCS Group        Internet Draft - Expiration 9/30/00                9

                  SIP Extensions for Caller Privacy        March 2000


                +---------+             +--------+
     1: INVITE  | DCS     | 2: INVITE   | DCS    | 3: INVITE
       +------->| proxy-o |------------>| proxy-t|----------+
       |        +---------+             +--------+          |
       |                  \           /                     |
       |                   \         /                      |
       |      SIP           +--------+           SIP        |
       | +----------------->| anony- |-------------------+  |
       | |          +------>|  mizer |--------+          |  |
       | |          |       +--------+        |          |  |
       | |          |                         |          |  |
       | |          |                         |          |  |
       | |          |     trust boundary      |          |  |
   . . |.|. . . . . | . . . . . . . . . . . . | . . .. . |..| . . .
       | |          |                         |          |  |
       | |          |                         |         \/ \/
   +------+ RTP/RTCP|                         |RTP/RTCP +------+
   |MTA-o |<--------+                         +-------->|MTA-t |
   +------+                                             +------+

                Figure 2 - Full Privacy Example


   For all signaling and media exchange purposes, the anonymizer adds a
   level of indirection thereby hiding the IP address(es) of MTA-o from
   MTA-t. This indirection is used both for the media streams and SIP
   signaling, beyond the initial INVITE, exchanged directly between
   MTA-o and MTA-t.

   Also, the following commonly used header fields may reveal privacy
   information, which can be remedied as described:

  @ The From header field must not reveal any calling identity
     information in the SIP-URL. This can be remedied, e.g. by
     supplying a cryptographically random identifier for the userinfo,
     and a non-identifying hostname, e.g. "localhost". The "display-
     name" must be anonymous.
  @ A Contact header field must be set to point to the anonymizer to
     prevent any direct signaling between MTA-o and MTA-t
  @ Via header fields identifying either MTA-o or DCS-proxy-o must be
     hidden, e.g. by encryption or simple stateful removal and re-
     insertion by DCS-proxy-t.
  @ Call-ID should not be based on MTA-o's IP-address

   Furthermore, when SDP is used to describe the media in the session,
   the session descriptions exchanged by the user agents need to be
   modified to direct the media streams to the anonymizer. Again, the
   use of SDP fields revealing calling identity information needs to be
   considered as well. Similar concerns apply to the use of RTCP.


5. Security Considerations



DCS Group        Internet Draft - Expiration 9/30/00               10

                  SIP Extensions for Caller Privacy        March 2000


   A user requesting complete privacy must still authenticate himself
   to the DCS-Proxy, and therefore the SIP messages between MTA-o and
   DCS-proxy-o must be protected.  Likewise, it is necessary that the
   proxies take precautions to protect the user identification
   information from eavesdropping and interception.  Use of IPSec
   between MTA and DCS-proxy as well as between proxies is recommended.



6. References


   1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997

   3  Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
      Specifications: ABNF", RFC 2234, Internet Mail Consortium and
      Demon Internet Ltd., November 1997

   4  Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,
      "SIP: Session Initiation Protocol," RFC 2543, March 1999.



7.    Acknowledgments

   The Distributed Call Signaling work in the PacketCable project is
   the work of a large number of people, representing many different
   companies.  The authors would like to recognize and thank the
   following for their assistance: John Wheeler, Motorola; David
   Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows,
   Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin,
   Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks;
   Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho,
   Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung-
   Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent
   Cable Communications.


8. Author's Addresses

   Bill Marshall
   AT&T
   Florham Park, NJ  07932
   Email: wtm@research.att.com

   K. K. Ramakrishnan
   AT&T
   Florham Park, NJ  07932
   Email: kkrama@research.att.com


DCS Group        Internet Draft - Expiration 9/30/00               11

                  SIP Extensions for Caller Privacy        March 2000



   Ed Miller
   CableLabs
   Louisville, CO  80027
   Email: E.Miller@Cablelabs.com

   Glenn Russell
   CableLabs
   Louisville, CO  80027
   Email: G.Russell@Cablelabs.com

   Burcak Beser
   3Com
   Rolling Meadows, IL  60008
   Email: Burcak_Beser@3com.com

   Mike Mannette
   3Com
   Rolling Meadows, IL  60008
   Email: Michael_Mannette@3com.com

   Kurt Steinbrenner
   3Com
   Rolling Meadows, IL  60008
   Email: Kurt_Steinbrenner@3com.com

   Dave Oran
   Cisco
   Acton, MA  01720
   Email: oran@cisco.com

   Flemming Andreasen
   Cisco
   Edison, NJ
   Email: fandreas@cisco.com

   John Pickens
   Com21
   San Jose, CA
   Email: jpickens@com21.com

   Poornima Lalwaney
   Motorola
   San Diego, CA  92121
   Email: plalwaney@gi.com

   Jon Fellows
   Motorola
   San Diego, CA  92121
   Email: jfellows@gi.com

   Doc Evans
   Secure Cable Solutions

DCS Group        Internet Draft - Expiration 9/30/00               12

                  SIP Extensions for Caller Privacy        March 2000


   Westminster, CO  30120
   Email: drevans@securecable.com

   Keith Kelly
   NetSpeak
   Boca Raton, FL  33587
   Email: keith@netspeak.com















































DCS Group        Internet Draft - Expiration 9/30/00               13

                  SIP Extensions for Caller Privacy        March 2000



Full Copyright Statement

   "Copyright (C) The Internet Society (date). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.  The limited permissions granted above are perpetual and
   will not be revoked by the Internet Society or its successors or
   assigns.  This document and the information contained herein is
   provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIMS 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."

   Expiration Date This memo is filed as <draft-dcsgroup-sip-privacy-
   01.txt>, and expires September 30, 2000.




























DCS Group        Internet Draft - Expiration 9/30/00               14