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

Versions: 00 01 02 03 04 05 06 RFC 4458

Network Working Group                                        C. Jennings
Internet-Draft                                             Cisco Systems
Expires: January 12, 2006                                  July 11, 2005


                 Conventions for Voicemail URIs in SIP
                  draft-jennings-sip-voicemail-uri-04

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 January 12, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The SIP protocol is often used to initiate connections to voicemail
   or unified messaging systems.  This specification describes a
   convention for forming SIP Service URIs that request particular
   services from unified messaging systems.








Jennings                Expires January 12, 2006                [Page 1]

Internet-Draft              SIP Voicemail URI                  July 2005


Table of Contents

   1.   Conventions  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.   Mechanism (UAS and Proxy)  . . . . . . . . . . . . . . . . .   4
     3.1  Target . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2  Cause  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.3  Retrieving Messages  . . . . . . . . . . . . . . . . . . .   5
   4.   Interaction with History . . . . . . . . . . . . . . . . . .   5
   5.   Limitations of Voicemail URI . . . . . . . . . . . . . . . .   5
   6.   Examples . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1  Proxy Forwards No Answer to Voicemail  . . . . . . . . . .   6
     6.2  Zero Configuration UM System . . . . . . . . . . . . . . .   8
     6.3  TDM Voice Mail Connected via a Gateway . . . . . . . . . .   9
     6.4  Call Coverage  . . . . . . . . . . . . . . . . . . . . . .   9
   7.   Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   8.   PSTN Mapping . . . . . . . . . . . . . . . . . . . . . . . .  10
   9.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  11
   10.  Security Considerations  . . . . . . . . . . . . . . . . . .  11
     10.1   Integrity Protection of Forwarding in SIP  . . . . . . .  12
     10.2   Privacy Related Issues on the Second Call Leg  . . . . .  13
   11.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  14
   12.  References . . . . . . . . . . . . . . . . . . . . . . . . .  14
     12.1   Normative References . . . . . . . . . . . . . . . . . .  14
     12.2   Informative References . . . . . . . . . . . . . . . . .  15
        Author's Address . . . . . . . . . . . . . . . . . . . . . .  15
        Intellectual Property and Copyright Statements . . . . . . .  16
























Jennings                Expires January 12, 2006                [Page 2]

Internet-Draft              SIP Voicemail URI                  July 2005


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, it is necessary that the UM be able to obtain 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 and
   possible reasons for the type of service desired from the UM.  This
   includes knowing the type of media (voice or IM, for example).  Many
   voice mail systems provide different greetings depending whether the
   call went to voicemail because 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
   could get it to work; however, this approach is unrealistic for
   achieving interoperability among call control, gateways, and unified
   messaging systems from different vendors.  This specification
   describes a convention for describing this mailbox and service
   information in the SIP URI so that vendors and operators can build
   interoperable systems.

   The work in the History Info [9] 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 decide on the
   best treatment 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 to 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).

   One topic that causes some confusion in the requirements has to do



Jennings                Expires January 12, 2006                [Page 3]

Internet-Draft              SIP Voicemail URI                  July 2005


   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 a 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
   specify which mailbox to use.  One problem is that the call control
   proxies cannot modify the To header, and the UACs 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.  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 has been
   sent 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 URI cause parameter.  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;cause=486


3.1  Target

   The target parameter indicates the mailbox to use.  In many cases the



Jennings                Expires January 12, 2006                [Page 4]

Internet-Draft              SIP Voicemail URI                  July 2005


   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  Cause

   The URI cause parameter is used to indicate the 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                      | Cause Parameter |
           +------------------------------+-----------------+
           | Busy                         | 486             |
           | No answer                    | 408             |
           | Unconditional                | 302             |
           | Deflect                      | 487             |
           | No Contacts/Failure of UA    | 410             |
           +------------------------------+-----------------+


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 History

   The History mechanism[9] 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.  It is reasonable to have systems in
   which both the information in this specification and the History
   information are included and one or both are used.

5.  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 in which the proxy is not configured with information about the
   UM system or 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 information about the call



Jennings                Expires January 12, 2006                [Page 5]

Internet-Draft              SIP Voicemail URI                  July 2005


   that allows it to decide what to do.  For example, if a call to the
   help desk got forwarded first to Alice, then to Bob, and then finally
   to the helpdesk UM system, the UM system might want to leave a copy
   of the message in the primary help desk mailbox 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 such a scenario.

   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 has already been tried".

   Some systems have expressed the requirement that the UAC 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 specification do not address any billing issues
   associated with forwarded calls.  This is a separate problem.

   The limitations discussed in this section are addressed by the
   History[9] work.

6.  Examples

6.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 in message F4.















Jennings                Expires January 12, 2006                [Page 6]

Internet-Draft              SIP Voicemail URI                  July 2005


   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







Jennings                Expires January 12, 2006                [Page 7]

Internet-Draft              SIP Voicemail URI                  July 2005


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

   INVITE sip:bob@um.example.com;target=bob;cause=486 SIP/2.0
   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*


6.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 which the recorded message is to be sent.

   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 [8] 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%40example.com;cause=486;
      play=http://www.example.com/bob/busy.way
      SIP/2.0
   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 January 12, 2006                [Page 8]

Internet-Draft              SIP Voicemail URI                  July 2005


   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


6.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;cause=486
          SIP/2.0
   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*


6.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 January 12, 2006                [Page 9]

Internet-Draft              SIP Voicemail URI                  July 2005


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


7.  Syntax

   This specification updates the ABNF 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 / other-param /
                        target-param / cause-param

   target-param      =  "target"  EQUAL pvalue

   cause-param       =  "cause" EQUAL Status-Code

   It is worth noting that the ABNF requires some characters to be
   escaped if they occur in the value of the target parameters.  For
   example, the "@" character needs to be escaped.

8.  PSTN Mapping

   The mapping to the PSTN protocols is important both for gateways that
   connect the IP network to existing TDM equipment, such as PBXs 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
   specification, 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 specification.



Jennings                Expires January 12, 2006               [Page 10]

Internet-Draft              SIP Voicemail URI                  July 2005


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

   +-----------+----------------------------------------+--------------+
   | ISUP or   | PSTN Reason                            | URI Cause    |
   | 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.

9.  IANA Considerations

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


      Parameter Name  Predefined Values  Reference
      ____________________________________________
      target          No                 [RFCAAAA]
      cause           Yes                [RFCAAAA]

   [Note to IANA: Please replace AAAA with the RFC number of this
   specification.

10.  Security Considerations

   This draft discusses transactions involving at least three parties,
   which increases the complexity of the privacy issues.

   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.  These new
   parameters tell 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 messages need to be integrity
   protected to stop attackers from, for example, causing a voicemail



Jennings                Expires January 12, 2006               [Page 11]

Internet-Draft              SIP Voicemail URI                  July 2005


   meant for a company's CEO to go to an attacker's mailbox.  RFC 3261
   provides a TLS mechanism suitable for performing this integrity
   protection.

   The signaling from the Proxy to the UM will reveal who is calling
   whom and possibly some information about a user's presence based on
   whether the call was answered or sent to voicemail.  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.

   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 [10] 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 that all hops
   between the Proxy and UM be trusted, which is the case in many
   deployment scenarios.

10.1  Integrity Protection of Forwarding in SIP

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

   There are two possible solutions.  One is that B sends back
   information to A saying don't call me, call C and signs it as B. The
   problem is that this solution involves revealing that B has forwarded
   to C, which B often may not want to do.  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.

   The other possible solution 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 diverted to an attacker.

   Any redirection of a call to an attacker's mailbox is serious.  It is



Jennings                Expires January 12, 2006               [Page 12]

Internet-Draft              SIP Voicemail URI                  July 2005


   trivial for an attacker to make its mailbox seem very much like the
   real mailbox and forward the messages to the real mailbox so that the
   fact that the messages have been intercepted or even tampered with
   escapes detection.

10.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 and 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 forwarding Proxy to induce it not to reveal
   that information.  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 is not hard to figure out how to
   meet this requirement, but it is unclear why anyone would want this
   service.

   The scenario in which B wants to make sure that C does not see that
   the call was to B is easier to deal with 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 hard to imagine 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, when she tries 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
   initiated 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 is present.  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 in which the mechanisms



Jennings                Expires January 12, 2006               [Page 13]

Internet-Draft              SIP Voicemail URI                  July 2005


   in this specification are being used in conjunction with RFC 3325,
   and the UM and the Proxy are both in the trust domain.  In this
   limited case, the problem that B does not want to 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 needs to be set in the ISUP or ISDN
   signaling.

11.  Acknowledgments

   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.  Lyndsay Campbell helped catch mistakes.  I would
   like to thank them very much for this assistance, and I would also
   like to acknowledge Rohan Mahy's help and encouragement with respect
   to this subject.

12.  References

12.1  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 (IANA)
        Uniform Resource Identifier (URI) Parameter Registry for the
        Session Initiation Protocol (SIP)", BCP 99, RFC 3969,
        December 2004.

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




Jennings                Expires January 12, 2006               [Page 14]

Internet-Draft              SIP Voicemail URI                  July 2005


12.2  Informative References

   [8]   Burger, E., "Basic Network Media Services with SIP",
         draft-burger-sipping-netann-11 (work in progress),
         February 2005.

   [9]   Barnes, M., "An Extension to the Session Initiation Protocol
         for Request History Information",
         draft-ietf-sip-history-info-06 (work in progress),
         January 2005.

   [10]  Ono, K. and S. Tachimoto, "End-to-middle security in the
         Session Initiation Protocol(SIP)",
         draft-ono-sipping-end2middle-security-04 (work in progress),
         February 2005.


Author's Address

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

   Phone: +1 408 421-9990
   Email: fluffy@cisco.com























Jennings                Expires January 12, 2006               [Page 15]

Internet-Draft              SIP Voicemail URI                  July 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

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




Jennings                Expires January 12, 2006               [Page 16]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/