SIP Conventions for Voicemail URIs

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.

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. 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 . The work in the History Info 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). 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.

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

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.

The Reason header, defined in RFC-3326, 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.

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.

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

The History mechanism 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.

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

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.

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 ;tag=9fxced76sl To: sip:15555551002@example.com;user=phone Call-ID: c3x842276298220188511 CSeq: 1 INVITE Max-Forwards: 70 Contact: Content-Type: application/sdp Content-Length: *Body length goes here* * SDP goes here* ]]>

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 ;tag=9fxced76sl To: sip:15555551002@example.com;user=phone Call-ID: c3x842276298220188511 CSeq: 1 INVITE Max-Forwards: 70 Contact: Content-Type: application/sdp Content-Length: *Body length goes here* * SDP goes here* ]]>

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 ;tag=9fxced76sl To: sip:15555551002@example.com;user=phone;tag=09xde23d80 Call-ID: c3x842276298220188511 CSeq: 1 INVITE Contact: Content-Length: 0 ]]>

um.example.com 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 ;tag=9fxced76sl To: sip:15555551002@example.com;user=phone Call-ID: c3x842276298220188511 CSeq: 1 INVITE Max-Forwards: 70 Contact: Content-Type: application/sdp Content-Length: *Body length goes here* * SDP goes here* ]]>

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.

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 ;tag=9fxced76sl To: sip:15555551002@example.com;user=phone Call-ID: c3x842276298220188511 CSeq: 1 INVITE Max-Forwards: 70 Contact: Content-Type: application/sdp Content-Length: *Body length goes here* * SDP goes here* ]]> 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

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.

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 ;tag=9fxced76sl To: sip:15555551002@example.com;user=phone Call-ID: c3x842276298220188511 CSeq: 1 INVITE Max-Forwards: 70 Contact: Content-Type: application/sdp Content-Length: *Body length goes here* * SDP goes here* ]]>

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

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

This document updates the BNF in Section 25 of RFC 3261 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

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) 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: ISUP or ISDN PSTN Reason SIP Reason Parameter 0000 Unknown 300 0001 Call forwarding busy or called DTE busy 486 0010 Call forwarding no reply 408 1111 Call forwarding unconditional or systematic call redirection 302 1010 Call deflection or call forwarding by the called DTE 487 1001 Call forwarding DTE out of order 410 The redirection counters SHOULD be set to one unless additional information is available.

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 .

Parameter Name Reference target RFC XXXX Note to RFC Editor - replace XXXX with the RFC number of this document.

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

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.

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) 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 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 needs to be set in the ISUP or ISDN signaling.

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

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.