[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 4458

SIP WG                                                       C. Jennings
Internet-Draft                                             Cisco Systems
Expires: August 14, 2004                               February 14, 2004


                   SIP Conventions for Voicemail URIs
                  draft-jennings-sip-voicemail-uri-01

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.

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

   This Internet-Draft will expire on August 14, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   SIP systems are often used to initiate connections to voicemail or
   unified messaging systems. This document describes a convention for
   forming SIP Request URIs that request particular services from
   unified messaging systems.

   This work is being discussed on the sip@ietf.org mailing list.










Jennings                Expires August 14, 2004                 [Page 1]

Internet-Draft             SIP Voicemail URI               February 2004


Table of Contents

   1.   Conventions  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.   Mechanism (UAS and Proxy)  . . . . . . . . . . . . . . . . .   4
   3.1  Target . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.2  Reason Header Usage  . . . . . . . . . . . . . . . . . . . .   5
   3.3  Retrieving Messages  . . . . . . . . . . . . . . . . . . . .   5
   4.   Interaction with Netann  . . . . . . . . . . . . . . . . . .   5
   5.   Interaction with History . . . . . . . . . . . . . . . . . .   5
   6.   Limitations of Voicemail URI . . . . . . . . . . . . . . . .   6
   7.   Examples . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   7.1  Proxy Forwards No Answer to Voicemail  . . . . . . . . . . .   6
   7.2  Zero Configuration UM System . . . . . . . . . . . . . . . .   8
   7.3  TDM Voice Mail Connected via a Gateway . . . . . . . . . . .   9
   7.4  Call Coverage  . . . . . . . . . . . . . . . . . . . . . . .   9
   8.   Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   9.   PSTN Mapping . . . . . . . . . . . . . . . . . . . . . . . .  10
   10.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  11
   11.  Security Considerations  . . . . . . . . . . . . . . . . . .  11
   11.1 Integrity Protection of Forwarding in SIP  . . . . . . . . .  12
   11.2 Privacy Related Issues on the Second Call Leg  . . . . . . .  13
   12.  Changes from 00 Version  . . . . . . . . . . . . . . . . . .  14
   13.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  14
        Normative References . . . . . . . . . . . . . . . . . . . .  14
        Informative References . . . . . . . . . . . . . . . . . . .  14
        Author's Address . . . . . . . . . . . . . . . . . . . . . .  15
        Intellectual Property and Copyright Statements . . . . . . .  16























Jennings                Expires August 14, 2004                 [Page 2]

Internet-Draft             SIP Voicemail URI               February 2004


1. Conventions

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

2. Introduction

   Unified messaging systems (UM) have developed out of traditional
   voice mail systems. They can be used for storing and interacting with
   voice, video, faxes, email and instant messaging. Users often use SIP
   to initiate communications with them. When a SIP call is routed to a
   UM, there is a requirement for the UM to be able to figure out
   several bits of information from the call so that it can deliver the
   desired services. The UM needs to know what mailbox should be used
   for the context of this call and possible reasons about what type of
   service is desired. This includes knowing the type of media (voice or
   IM for example). Many voice mail systems provide different greetings
   depending whether the reason the call was sent to voicemail was that
   the user was busy or because the user did not answer. All of this
   information can be delivered in existing SIP signaling from the call
   control that retargets the call to the UM, but there are no
   standardized conventions for describing how the desired mailbox and
   service requested are expressed. It would be possible for every
   vendor to make this configurable so that any site can get it to work;
   however, this is not a very realistic view of achieving
   interoperability among call control, gateways, and unified messaging
   systems from different vendors. These requirements and more are
   described in the History Requirements [9]. This document describes a
   convention for describing this mailbox and service information in the
   SIP URI so that vendors and operators can build interoperable
   systems. It meets some but not all of the requirements in [9].

   The work in the History Info [10] draft can be used in similar
   systems. It is more comprehensive and covers a much wider set of
   requirements. A key difference from this system is that history
   allows the UM to look at the history of the call and decided on what
   the best treatment is for the call. This work requires the call
   control system to know something about the history of the call and
   specifically ask the UM to invoke a particular service.

   If there were no need to interoperate with TDM based voicemail
   systems or allow TDM systems to use VoIP unified messaging systems,
   this problem would be a little easier. The problem that is introduced
   in the VoIP to TDM case is as follows. The SIP system needs to tell a
   PSTN GW both the subscriber's mailbox identifier (which typically
   looks like a phone number) and the address of the voicemail system in
   the TDM network (again a phone number).



Jennings                Expires August 14, 2004                 [Page 3]

Internet-Draft             SIP Voicemail URI               February 2004


   One topic that causes some confusion in the requirements for this has
   to do with the fact that the related PSTN mechanism can carry two
   addresses. These correspond to the original target of the call and
   the most recent target to which it has been redirected. In general,
   the original target is used to find the voice mail box. The target
   that most recently redirected is not as useful for voicemail but is
   very useful for billing. It is often used to bill the most recent
   portion of the call leg. This work addresses only the requirements
   for UM system, and billing is completely out of scope. The History
   draft is much more extensive and covers more cases that might be
   useful for billing, but this work does not.

   The question has been asked why the To header cannot be used to
   understand which mailbox to use. One of the problems with this is
   that the call control proxies cannot modify the To header, and the
   UAC often set it incorrectly because they do not have information
   about the subscribers in the domain they are trying to call. This
   happens because the routing of the call often translates the URI
   multiple times before it results in an identifier for the desired
   user that is valid in the namespace that the UM system understands.

   Another set of requirements that this mechanism can deal with is the
   call coverage naming issues. The problem is when Bill calls the 800
   number that sends him to the helpdesk, the proxy may first fork the
   call to Alice (who works at the help desk), and then if Alice does
   not answer in a few seconds fork the call on to Bob (who also works
   at the helpdesk). Both Alice and Bob would like to be informed that
   the call was to the help desk before they answer the call. If neither
   answers, the call may get sent to the help desk's voice mailbox, not
   Bob's or Alice's.

3. Mechanism (UAS and Proxy)

   The mechanism works by encoding the information for the desired
   service in the SIP URI that is sent to the UM system. Two chunks of
   information are encoded, the first being the target mailbox to use
   and the second being the SIP error code that caused this retargeting
   and indicates the desired service. The target mailbox can be put in
   the user part of the URI and is also put in a target URI parameter
   while the reason is put in the Reason header. For example, if the
   proxy wished to use Alice's mailbox because her phone was busy, the
   URI sent to the UM system could be something like:

   sip:alice@um.example.com;target=alice

   and include a Reason header like:

   Reason: SIP ;cause=486



Jennings                Expires August 14, 2004                 [Page 4]

Internet-Draft             SIP Voicemail URI               February 2004


3.1 Target

   The target parameter indicates the mailbox to use. In many cases the
   user portion of the SIP URI could be set to the same value but it
   does not have to be. For example in the case of a voice mail system
   on the PSTN, the user portion will contain the phone number of the
   voice mail system while the target will contain the phone number of
   the subscriber's mailbox.

3.2 Reason Header Usage

   The Reason header, defined in RFC-3326 [7], is used to indicates the
   target="RFC2119"service that the UAS receiving the message should
   perform. It corresponds to the SIP Status-Code that results in the
   desired service being requested. A mapping between some common
   services and reason codes are:

          +------------------------------+------------------+
          | Service                      | Reason Parameter |
          +------------------------------+------------------+
          | Busy                         | 486              |
          | No answer                    | 408              |
          | Unconditional                | 302              |
          | Deflect                      | 487              |
          | No Contacts/Failure of UA    | 410              |
          +------------------------------+------------------+

   This drafts extends the Reason headers to be allowed in a SIP request
   outside of a Dialog.

3.3 Retrieving Messages

   The UM system MAY use the fact that the From header is the same as
   the URI target as a hint that the user wishes to retrieve messages.

4. Interaction with Netann

   This approach is designed to interact well with the netann mechanism.
   A netann parameter[8] can be used to indicate exactly which initial
   prompt to play.

5. Interaction with History

   The History mechanism[10] provides considerably more information that
   is useful for a UM system. This work does not stop a UM system from
   taking advantage of the History information if it is present and
   using that to handle the call.




Jennings                Expires August 14, 2004                 [Page 5]

Internet-Draft             SIP Voicemail URI               February 2004


6. Limitations of Voicemail URI

   This system requires the proxy that is requesting the service to
   understand what are valid targets on the UM system. For practical
   purposes this means that the approach is unlikely to work in many
   cases where the proxy is not configured with information about the UM
   system or if the proxy is not in the same administrative domain.

   This system requires the call control proxy to know what it wants the
   UM to do instead of giving the UM system the information about the
   call that allows the UM system to decide what to do. For example, if
   a call to the help desk got forwarded first to Alice, then to Bob,
   then finally to the helpdesk UM system, the UM system may want to
   leave a copy of the message in the primary help desk mail box and
   also leave a copy in Alice's mailbox since she was the primary person
   at the helpdesk. In addition the UM system might want to page Alice,
   Bob and their supervisor to let them know that no one is staffing the
   help desk. This system does not provide enough information to the UM
   system about what happened to the call to meet the needs of a
   scenario such as the one above.

   This system only works when the service the call control wants
   applied is fairly simple. For example it does not allow the proxy to
   express information like "Do not offer to connect to the target's
   colleague because that address was already tried".

   Some systems have expressed requirements for the UAC to understand
   when the call is re-targeted and get updated information about where
   it was targeted to as the call proceeds. This work does not address
   this requirement - History does, as does the option of just sending a
   1xx class message with a Reason header[7].

   The mechanism in this document does not address any billing issues
   associated with forwarded calls. This is a separate problem.

   These limitations discussed in this section are addressed by the
   History[10] work.

7. Examples

7.1 Proxy Forwards No Answer to Voicemail

   In this example, Alice calls Bob. Bob's proxy runs a timer and
   determines that Bob has not answered his phone, and the proxy
   forwards the call to Bob's voicemail. Alice's phone is at 192.168.0.1
   while Bob's phone is at 192.168.0.2. The important things to note is
   the URI and Reason header in message F4.




Jennings                Expires August 14, 2004                 [Page 6]

Internet-Draft             SIP Voicemail URI               February 2004


   F1: INVITE 192.168.0.1 -> proxy.example.com

   INVITE sip:15555551002@example.com;user=phone SIP/2.0
   Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
   From: Alice <sip:5551001@example.com>;tag=9fxced76sl
   To: sip:15555551002@example.com;user=phone
   Call-ID: c3x842276298220188511
   CSeq: 1 INVITE
   Max-Forwards: 70
   Contact: <sip:x123456x@192.168.0.1;transport=tcp>
   Content-Type: application/sdp
   Content-Length: *Body length goes here*

   * SDP goes here*


   F2: INVITE proxy.example.com -> 192.168.0.2

   INVITE sip:line1@192.168.0.2 SIP/2.0
   Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-1
   Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
   From: Alice <sip:5551001@example.com>;tag=9fxced76sl
   To: sip:15555551002@example.com;user=phone
   Call-ID: c3x842276298220188511
   CSeq: 1 INVITE
   Max-Forwards: 70
   Contact: <sip:x123456x@192.168.0.1;transport=tcp>
   Content-Type: application/sdp
   Content-Length: *Body length goes here*

   * SDP goes here*


   F3: 486 192.168.0.2 -> proxy.example.com

   SIP/2.0 486 Busy Here
   Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-1
   Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
   From: Alice <sip:5551001@example.com>;tag=9fxced76sl
   To: sip:15555551002@example.com;user=phone;tag=09xde23d80
   Call-ID: c3x842276298220188511
   CSeq: 1 INVITE
   Contact: <sip:x654321x@192.168.0.2;transport=tcp>
   Content-Length: 0


   F4: INVITE proxy.example.com -> um.example.com




Jennings                Expires August 14, 2004                 [Page 7]

Internet-Draft             SIP Voicemail URI               February 2004


   INVITE sip:bob@um.example.com;target=bob SIP/2.0
   Reason SIP ;cause=486
   Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-2
   Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
   From: Alice <sip:5551001@example.com>;tag=9fxced76sl
   To: sip:15555551002@example.com;user=phone
   Call-ID: c3x842276298220188511
   CSeq: 1 INVITE
   Max-Forwards: 70
   Contact: <sip:x123456x@192.168.0.1;transport=tcp>
   Content-Type: application/sdp
   Content-Length: *Body length goes here*

   * SDP goes here*


7.2 Zero Configuration UM System

   In this example, the UM system has no configuration information
   specific to any user. The proxy is configured to pass a URI that
   provides the prompt to play and an email address in the user portion
   of the URI to send the recorded message to.

   The call flow is the same as in the previous example except that the
   URI in F4 changes to specify the user part as Bob's email address,
   and the netann URI play parameter specifies where the greeting to
   play can be fetched from.


   F4: INVITE proxy.example.com -> um.example.com

   INVITE
      sip:bob@um.example.com;target=mailto:bob@example.com;
      play=http://www.example.com/bob/busy.way
      SIP/2.0
   Reason: SIP ;cause=486
   Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-2
   Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
   From: Alice <sip:5551001@example.com>;tag=9fxced76sl
   To: sip:15555551002@example.com;user=phone
   Call-ID: c3x842276298220188511
   CSeq: 1 INVITE
   Max-Forwards: 70
   Contact: <sip:x123456x@192.168.0.1;transport=tcp>
   Content-Type: application/sdp
   Content-Length: *Body length goes here*

   * SDP goes here*



Jennings                Expires August 14, 2004                 [Page 8]

Internet-Draft             SIP Voicemail URI               February 2004


   In addition, if the proxy wished to indicate a VXML script that the
   UM should execute, it could add a parameter to the URI in the above
   message that looked like:

   voicexml=http://www.example.com/bob/busy.vxml


7.3 TDM Voice Mail Connected via a Gateway

   In this example, the voicemail system has a TDM interconnect to a
   gateway to the VoIP system. Bob's mailbox is +1 555 555-1002 while
   the address of the voicemail system on the TDM network is +1 555
   555-2000.

   The call flow is the same as in the previous example except for the
   URI in F4.


   F4: INVITE proxy.example.com -> gw.example.com

   INVITE sip:+1-555-555-2000@um.example.com;user=phone;\
          target=tel:+1-555-555-1002
          SIP/2.0
   Reason: SIP ;cause=486
   Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-2
   Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
   From: Alice <sip:5551001@example.com>;tag=9fxced76sl
   To: sip:15555551002@example.com;user=phone
   Call-ID: c3x842276298220188511
   CSeq: 1 INVITE
   Max-Forwards: 70
   Contact: <sip:x123456x@192.168.0.1;transport=tcp>
   Content-Type: application/sdp
   Content-Length: *Body length goes here*

   * SDP goes here*


7.4 Call Coverage

   In this example a user on the PSTN calls a 800 number. The GW sends
   this to the proxy which recognizes that the helpdesk is the target.
   Alice and Bob are staffing the help desk and are tried sequentially
   but neither answers, so the call is forwarded to the helpdesk's voice
   mail.

   The key item in this flow is that the invite to Alice and Bob looks
   like



Jennings                Expires August 14, 2004                 [Page 9]

Internet-Draft             SIP Voicemail URI               February 2004


   INVITE sip:bob@um.example.com;target=helpdesk SIP/2.0
   Reason: SIP ;cause=302


8. Syntax

   This document updates the BNF in Section 25 of RFC 3261 [3] to add
   the target-param to the uri-parameter as shown below.


   uri-parameter     =  transport-param / user-param /
                        method-param / ttl-param / maddr-param /
                        lr-param / target-param / other-param

   target-param      =  "target=" pvalue


9. PSTN Mapping

   The mapping to PSTN protocol is important both for gateways that
   connect the IP network to existing TDM equipment, such as PBX's and
   voicemail systems, and for gateways that connect the IP network to
   the PSTN network. Both ISDN and ISUP have signaling for this
   information that can be treated as roughly equivalent for the
   purposes here.

   The user portion of the URI SHOULD be used as the address of the
   voicemail system on the PSTN, while the target SHOULD be mapped to
   the original redirecting party on the PSTN side.

   If the gateway and Proxy are in the same Trust Domain (defined in RFC
   3325 [5]) and the Spec(T) includes compliance with this document and
   the Spec(T) asserts that the Proxy will do screening (whatever that
   means), then the gateway MAY claim it is screened; otherwise it
   SHOULD NOT assert that the diversion information is screened.

   This draft says nothing about what to put into the redirecting
   numbers, as that has billing implications outside the scope of this
   work. The requirements here will work fine if the redirecting number
   is not set on the PSTN side. It is not recommended that the GW map
   the target information into the redirecting party information, but
   doing so is not in violation of this document.

   The following SHOULD be used as the mapping between reason parameters
   and ISUP/ISDN redirect reason codes:






Jennings                Expires August 14, 2004                [Page 10]

Internet-Draft             SIP Voicemail URI               February 2004


   +-----------+----------------------------------------+--------------+
   | ISUP or   | PSTN Reason                            | SIP Reason   |
   | ISDN      |                                        | Parameter    |
   +-----------+----------------------------------------+--------------+
   | 0000      | Unknown                                | 300          |
   | 0001      | Call forwarding busy or called DTE     | 486          |
   |           | busy                                   |              |
   | 0010      | Call forwarding no reply               | 408          |
   | 1111      | Call forwarding unconditional or       | 302          |
   |           | systematic call redirection            |              |
   | 1010      | Call deflection or call forwarding by  | 487          |
   |           | the called DTE                         |              |
   | 1001      | Call forwarding DTE out of order       | 410          |
   +-----------+----------------------------------------+--------------+

   The redirection counters SHOULD be set to one unless additional
   information is available.

10. IANA Considerations

   This document adds a new value to the IANA registration in the
   sub-registry at http://www.iana.org/assignments/sip-parameters as
   defined in [6].


          Parameter Name  Reference
          target          RFC XXXX

   Note to RFC Editor - replace XXXX with the RFC number of this
   document.

11. Security Considerations

   This draft inherently discusses transactions involving at least 3
   parties. This makes the privacy issues somewhat more complex.

   The new URI parameters defined in this draft are generally sent from
   a Proxy or call control system to a unified messaging (UM) system or
   gateway to the PSTN, and then to a voicemail system. This tells the
   UM what service the proxy wishes to have performed. Just as any
   message sent from the proxy to the UM needs to be integrity
   protected, these need to be integrity protected. This stops attackers
   from doing things like causing a voicemail meant for the CEO of the
   company to go to an attacker's mailbox. RFC 3261 provides TLS and
   IPSEC mechanisms suitable for protecting against this.

   The signaling from the Proxy to the UM will reveal who is calling
   whom and possibly some information about the presence of a user based



Jennings                Expires August 14, 2004                [Page 11]

Internet-Draft             SIP Voicemail URI               February 2004


   on whether a call got sent to voicemail instead of being answered.
   This information can be protected by encrypting the SIP traffic
   between the Proxy and UM. Again, RFC 3261 contains mechanisms for
   accomplishing this using TLS and IPSEC.

   The S/MIME based mechanisms in RFC 3261 will generally not be
   applicable for protecting this information because they are meant for
   end to end issues and this is primarily a middle to end scenario.
   Ongoing work on middle to end [11] may allow S/MIME based schemes to
   be used for protecting this information. These schemes would allow
   the information to be hidden and integrity protected if there was
   another administrative domain between the Proxy and UM. The current
   scheme is based on hop by hop security and requires all hops between
   the Proxy and UM to be trusted, which is the case in many deployment
   scenarios.

11.1 Integrity Protection of Forwarding in SIP

   Forwarding of a call in SIP brings up a very strange trust issue.
   Consider the normal case of when A calls B, and then the call gets
   forwarded by a network element in the domain of B to C, and then C
   answers the call. A called B but ended up talking to C. This may be
   hard to separate from a man in the middle attack.

   There are two possible solutions for this. One is that B sends back
   information to A saying don't call me, call C and signs it as B. The
   problem with this is that it reveals the fact that B has forwarded to
   C and often B does not want to do this. For example, B may be a work
   phone that has been forwarded to a mobile or home phone. The user
   does not want to reveal their mobile or home phone number but, even
   more importantly, does not want to reveal that they are not in the
   office but are instead working from home.

   The other possible solution for this is that A needs to trust B only
   to forward to a trusted identity. This requires a hop by hop
   transitive trust such that each hop will only send to a trusted next
   hop and each hop will only do things that the user at that hop
   desired. This solution is enforced in SIP using the SIPS URI and TLS
   based hop by hop security. It protects from an off axis attack but if
   one of the hops is not trustworthy, the call may be subverted to an
   attacker.

   Any redirection of a call to an attacker's mailbox is a very serious
   issue. It is trivial for the attacker to make the mailbox seem very
   much like the real mailbox and forward the message to the real
   mailbox so that the fact that the messages have been intercepted or
   even tampered with is not detected.




Jennings                Expires August 14, 2004                [Page 12]

Internet-Draft             SIP Voicemail URI               February 2004


11.2 Privacy Related Issues on the Second Call Leg

   When A calls B and gets redirected to C, occasionally people say
   there is a requirement for the call leg from B to C to be anonymous.
   This is not the PSTN: there is no call leg from B to C; instead there
   is a VoIP session between A and C. If A had put a To header
   containing B in the initial invite message, unless something special
   is done about it, C will see that To header. If the person who
   answers phone C says "I think you dialed the wrong number, who were
   you trying to reach?" A will probably specify B.

   If A does not want C to see that the call was to B, A needs a special
   relationship with the Proxy that does the forwarding so that it will
   not reveal that information, and the call should go through an
   anonymizer service that provides session or user level privacy (as
   described in RFC 3323 [4]) service before going to C. It's not hard
   to figure out how to meet this requirement, but it is difficult to
   figure out why anyone would want this service.

   If B wants to make sure that C does not see that the call was to B,
   it is easier but a bit weird. The usual argument is Bill wants to
   forward his phone to Monica but does not want Monica to find out his
   phone number. It is a little weird that Monica would want to accept
   all Bill's calls without knowing how to call Bill to complain. The
   only person Monica will be able to complain to is Hillary who tried
   to call Bill. Several popular web portals will send SMS alert message
   about things like stock prices and weather to mobile phone users
   today. Some of these contain no information about the account on the
   web portal that imitated them, making it nearly impossible for the
   mobile phone owner to stop them. This anonymous message forwarding
   has turned out to be a really bad idea even where no malice was
   intended. Clearly some people are fairly dubious about the need for
   this, but never mind: let's look at how it is solved.

   In the general case, the proxy needs to route the call through an
   Anonymization Service and everything will be cleaned up. Any
   Anonymization service that performs the "Privacy: Header" Service in
   RFC 3323 [5] MUST remove the reason and target URI parameters from
   the URI. RFC 3325 already makes it pretty clear you would need to
   clean up this sort of information.

   There is a specialized case of some interest where the mechanism in
   this document is being used in conjunction with RFC 3325 and the UM
   and the Proxy are both in the trust domain. It this limited case, the
   problem that B does not want reveal their address to C can be solved
   by ensuring that the target parameter URI should never be in a
   message that is forwarded outside the trust domain. If it is passed
   to a PSTN device in the trust domain, the appropriate privacy flag



Jennings                Expires August 14, 2004                [Page 13]

Internet-Draft             SIP Voicemail URI               February 2004


   needs to be set in the ISUP or ISDN signaling.

12. Changes from 00 Version

   The reason information was moved from being a tag in the URI to using
   the Reason header.

13. Acknowledgements

   Mary Barnes, Dean Willis, and Steve Levy have spent significant time
   with me helping me understand the requirements and pros and cons of
   various approaches. I would like to thank them very much for this,
   and since this is an acknowledgements section I would also like to
   acknowledge Rohan Mahy's help with the various documents on this
   subject and his encouragement to work on a solution that brings some
   consensus to this topic.

Normative References

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

   [2]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [3]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [4]  Peterson, J., "A Privacy Mechanism for the Session Initiation
        Protocol (SIP)", RFC 3323, November 2002.

   [5]  Jennings, C., Peterson, J. and M. Watson, "Private Extensions to
        the Session Initiation Protocol (SIP) for Asserted Identity
        within Trusted Networks", RFC 3325, November 2002.

   [6]  Camarillo, G., "The Internet Assigned Number Authority Universal
        Resource Identifier  Parameter Registry for the Session
        Initiation Protocol", draft-ietf-sip-uri-parameter-reg-01 (work
        in progress), November 2003.

   [7]  Schulzrinne, H., Oran, D. and G. Camarillo, "The Reason Header
        Field for the Session Initiation Protocol (SIP)", RFC 3326,
        December 2002.

Informative References

   [8]   Burger, E., "Basic Network Media Services with SIP",



Jennings                Expires August 14, 2004                [Page 14]

Internet-Draft             SIP Voicemail URI               February 2004


         draft-burger-sipping-netann-07 (work in progress), September
         2003.

   [9]   Barnes, M., "SIP Generic Request History Capability
         Requirements", draft-ietf-sipping-req-history-04 (work in
         progress), June 2003.

   [10]  Barnes, M., "An Extension to the Session Initiation Protocol
         for Request History  Information",
         draft-ietf-sip-history-info-01 (work in progress), October
         2003.

   [11]  Ono, K. and S. Tachimoto, "End-to-middle security in the
         Session Initiation Protocol(SIP)",
         draft-ono-sipping-end2middle-security-00 (work in progress),
         June 2003.


Author's Address

   Cullen Jennings
   Cisco Systems
   170 West Tasman Drive
   Mailstop SJC-21/2
   San Jose, CA  95134
   USA

   Phone: +1 408 902-3341
   EMail: fluffy@cisco.com






















Jennings                Expires August 14, 2004                [Page 15]

Internet-Draft             SIP Voicemail URI               February 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2004). 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 assignees.

   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



Jennings                Expires August 14, 2004                [Page 16]

Internet-Draft             SIP Voicemail URI               February 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Jennings                Expires August 14, 2004                [Page 17]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/