Request for Comments: 4458 Cisco Systems
Category: Informational F. Audet
Nortel Networks
J. Elwell
Siemens plc
April 2006
Session Initiation Protocol (SIP) URIs for Applications
such as Voicemail and Interactive Voice Response (IVR)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Session Initiation Protocol (SIP) is often used to initiate
connections to applications such as voicemail or interactive voice
recognition systems. This specification describes a convention for
forming SIP service URIs that request particular services based on
redirecting targets from such applications.
Table of Contents
1. Introduction ....................................................3
2. Mechanism (User Agent Server and Proxy) .........................4
2.1. Target .....................................................4
2.2. Cause ......................................................4
2.3. Retrieving Messages ........................................5
3. Interaction with Request History Information ....................5
4. Limitations of Voicemail URI ....................................6
5. Syntax ..........................................................6
6. Examples ........................................................7
6.1. Proxy Forwards Busy to Voicemail ...........................7
6.2. Endpoint Forwards Busy to Voicemail ........................9
6.3. Endpoint Forwards Busy to TDM via a Gateway ...............11
6.4. Endpoint Forwards Busy to Voicemail with History Info .....13
6.5. Zero Configuration UM System ..............................14
6.6. Call Coverage .............................................15
7. IANA Considerations ............................................15
8. Security Considerations ........................................16
8.1. Integrity Protection of Forwarding in SIP .................16
8.2. Privacy Related Issues on the Second Call Leg .............17
9. Acknowledgements ...............................................18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................18
1. Introduction
Many applications such as Unified Messaging (UM) systems and
Interactive Voice Recognition (IVR) systems have been developed out
of traditional telephony. They can be used for storing and
interacting with voice, video, faxes, email, and instant messaging
services. Users often use SIP to initiate communications with these
applications. When a SIP call is routed to an application, it is
necessary that the application be able to obtain several bits of
information from the session initiation message so that it can
deliver the desired services.
For the purpose of this document, we will use UM as the main example,
but other applications may use the mechanism defined in this
document. The UM needs to know what mailbox should be used and
possible reasons for the type of service desired from the UM. Many
voicemail 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 conventions for describing how the desired
mailbox and the 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, gateway, 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.
If there were no need to interoperate with Time Division Multiplexing
(TDM)-based voicemail systems or to allow TDM systems to use VoIP
unified messaging systems, this problem would be a little easier to
solve. The problem that is introduced in the Voice over IP (VoIP) to
TDM case is as follows. The SIP system needs to tell a Public
Switched Telephone Network (PSTN) gateway 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).
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 User Agent Clients
(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.
2. Mechanism (User Agent Server and Proxy)
The mechanism works by encoding the information for the desired
service in the SIP Request-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 status code that caused this
retargeting and that indicates the desired service. The userinfo and
hostport parts of the Request-URI will identify the voicemail
service, the target mailbox can be put in the target parameter, and
the reason can be put in the cause parameter. For example, if the
proxy wished to use Bob’s mailbox because his phone was busy, the URI
sent to the UM system could be something like:
sip:voicemail@example.com;target=bob%40example.com;cause=486
2.1. Target
Target is a URI parameter that indicates the address of the
retargeting entity: in the context of UM, this can be the mailbox
number. For example, in the case of a voicemail system on the PSTN,
the user portion will contain the phone number of the voicemail
system, while the target will contain the phone number of the
subscriber’s mailbox.
2.2. Cause
Cause is a URI parameter that is used to indicate the service that
the User Agent Server (UAS) receiving the message should perform.
The following values for this URI parameter are defined:
+---------------------------------+-------+
| Redirecting Reason | Value |
+---------------------------------+-------+
| Unknown/Not available | 404 |
| User busy | 486 |
| No reply | 408 |
| Unconditional | 302 |
| Deflection during alerting | 487 |
| Deflection immediate response | 480 |
| Mobile subscriber not reachable | 503 |
+---------------------------------+-------+
The mapping to PSTN protocols is important both for gateways that
connect the IP network to existing TDM customer’s equipment, such as
Private Branch Exchanges (PBXs) and voicemail systems, and for
gateways that connect the IP network to the PSTN network. Integrated
Services Digital Network User Part (ISUP) has signaling encodings for
this information that can be treated as roughly equivalent for the
purposes here. For this reason, this specification uses the names of
Redirecting Reason values defined in ITU-T Q.732.2-5 [8]. In this
specification, the Redirecting Reason Values are referred to as
"Causes". It should be understood that the term "Cause" has nothing
to do with PSTN "Cause values" (as per ITU-T Q.850 [9] and RFC 3398
[5]) but are instead mapped to ITU-T Q.732.2-5 Redirecting Reasons.
Since ISUP interoperates with other PSTN networks, such as Q.931 [10]
and QSIG [11], using well-known rules, it makes sense to use the ISUP
names as the most appropriate superset. If no appropriate mapping to
a cause value defined in this specification exists in a network, it
would be mapped to 302 "Unconditional". Similarly, if the mapping
occurs from one of the causes defined in this specification to a PSTN
system that does not have an equivalent reason value, it would be
mapped to that network’s equivalent of "Unconditional". If a new
cause parameter needs to be defined, this specification will have to
be updated.
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 number on the PSTN side.
The redirection counters SHOULD be set to one unless additional
information is available.
2.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.
3. Interaction with Request History Information
The Request History mechanism [6] provides more information relating
to multiple retargetings. 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.
History-Info specifies a means of providing the UAS and UAC with
information about the retargeting of a request. This information
includes the initial Request-URI and any retarget-to URIs. This
information is placed in the History-Info header field, which, except
where prevented by privacy considerations, is built up as the request
progresses and, upon reaching the UAS, is returned in certain
responses.
History-Info, when deployed at relevant SIP entities, is intended to
provide a comprehensive trace of retargeting for a SIP request, along
with the SIP response codes that led to retargeting.
History-Info can complement this specification. In particular, when
a proxy inserts a URI containing the parameters defined in this
specification into the Request-URI of a forwarded request, the proxy
can also insert a History-Info header field entry into the forwarded
request, and the URI in that entry will incorporate these parameters.
Therefore, even if the Request-URI is replaced as a result of
rerouting by a downstream proxy, the History-Info header field will
still contain these parameters, which may be of use to the UAS.
Consequently, UASes that make use of this information may find the
information in the History-Info header and/or in the Request-URI,
depending on the capability of the proxy to support generation of
History-Info or on the behavior of downstream proxies; therefore,
applications need to take this into account.
4. Limitations of Voicemail URI
This specification requires the proxy that is requesting the service
to understand whether the UM system it is targeting supports the
syntax defined in this specification. Today, this information is
provided to the proxy by configuration. For practical purposes, this
means that the approach is unlikely to work in cases in which the
proxy is not configured with information about the UM system or in
which the UM is not in the same administrative domain.
This approach only works when the service that 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".
The limitations discussed in this section are addressed by History-
Info [6].
5. Syntax
The ABNF[4] grammar for these parameters is shown below. The
definitions of pvalue and Status-Code are defined in the ABNF in RFC
3261[1].
target-param = "target" EQUAL pvalue
cause-param = "cause" EQUAL Status-Code
Note 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.
6. Examples
This section provides some example use cases for the solution
proposed in this document. For the purpose of this document, UM is
used as the main example, but other applications may use this
mechanism. The examples are intended to highlight the potential
applicability of this solution and are not intended to limit its
applicability.
Also, the examples show just service retargeting on busy, but can
easily be adapted to show other forms of retargeting.
In several of the examples, the URIs are broken across more than one
line. This was only done for formatting and is not a valid SIP
message. Some of the characters in the URIs are not correctly
escaped to improve readability. The examples are all shown using
sip: with UDP transport, for readability. It should be understood
that using sips: with TLS transport is preferable.
6.1. Proxy Forwards Busy to Voicemail
In this example, Alice calls Bob. Bob’s proxy determines that Bob is
busy, and the proxy forwards the call to Bob’s voicemail. Alice’s
phone is at 192.0.2.1, while Bob’s phone is at 192.0.2.2. The
important thing to note is the URI in message F7.
Alice Proxy Bob voicemail
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
|(100 Trying) F3 | | |
|<---------------| 486 Busy F4 | |
| |<-------------| |
| | ACK F5 | |
| |------------->| |
|(181 Call is Being Forwarded) F6 |
|<---------------| | INVITE F7 |
| |--------------------------------->|
* Rest of flow not shown *
F1: INVITE 192.0.2.1 -> proxy.example.com
INVITE sip:+15555551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
F2: INVITE proxy.example.com -> 192.0.2.2
INVITE sip:+15555551002@192.0.2.2 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
F4: 486 192.0.2.2 -> proxy.example.com
SIP/2.0 486 Busy Here
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone;tag=09xde23d80
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Content-Length: 0
F7: INVITE proxy.example.com -> um.example.com
INVITE sip:voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
6.2. Endpoint Forwards Busy to Voicemail
In this example, Alice calls Bob. Bob is busy, but forwards the
session directly to his voicemail. Alice’s phone is at 192.0.2.1,
while Bob’s phone is at 192.0.2.2. The important thing to note is
the URI in the Contact in message F3.
Alice Proxy Bob voicemail
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
| | 302 Moved F3 | |
| 302 Moved F4 |<-------------| |
|<---------------| | |
| ACK F5 | | |
|--------------->| ACK F6 | |
| |------------->| |
| INVITE F7 |
|-------------------------------------------------->|
* Rest of flow not shown *
F1: INVITE 192.0.2.1 -> proxy.example.com
INVITE sip:+15555551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
F2: INVITE proxy.example.com -> 192.0.2.2
INVITE sip:line1@192.0.2.2 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
F3: 302 192.0.2.2 -> proxy.example.com
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone;tag=09xde23d80
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Contact: <sip: voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486;>
Content-Length: 0
F7: INVITE proxy.example.com -> um.example.com
INVITE sip: voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
6.3. Endpoint Forwards Busy to TDM via a Gateway
In this example, the voicemail is reached via a gateway to a TDM
network. Bob’s number is +1 555 555-1002, while voicemail’s number
on the TDM network is +1-555-555-2000.
The call flow is the same as in Section 6.2 except for the Contact
URI in F4 and the Request URI in F7.
Alice Proxy Bob voicemail
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
|(100 Trying) F3 | | |
|<---------------| 302 Moved F4 | |
| |<-------------| |
| | ACK F5 | |
| |------------->| |
|(181 Call is Being Forwarded) F6 |
|<---------------| | INVITE F7 |
| |--------------------------------->|
* Rest of flow not shown *