Internet DRAFT - draft-bharatia-sipping-redirect
draft-bharatia-sipping-redirect
SIPPING Working Group Jayshree Bharatia
Internet Draft Sanjoy Sen
Category: Standards Track Ray Yuhanna
Expires on May 2002 Scott Orton
Mark Watson
NORTEL NETWORKS
November 2001
Redirection Service Capability in SIP
<draft-bharatia-sipping-redirect-00.txt>
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
Abstract
SIP is selected as a session control protocol for many VOIP
applications. Hence it should provide capabilities for supporting
such redirection-based services as automatic call distribution for
call centers, third-party voicemail, follow-me service etc. The
concept of Call Redirection is implicit in the capabilities already
defined for SIP Proxies and Clients. However, in order to allow
redirection to be used as a component of other services (in
particular voicemail), and in order to facilitate inter-working with
existing services, these capabilities needs to operate in a
consistent and well-defined way, and also need to support transfer
of certain additional pieces of information, such as redirecting and
redirected-to addresses, redirecting reason, redirection counter
etc. This draft discusses this required set of information,
evaluates existing work and proposes solution to this effect.
Table of Contents
SIP Voicemail Solutions November 2001
Status of this Memo................................................1
Abstract...........................................................1
1 Conventions used in this document ..............................2
2 Introduction: Redirection Services .............................2
3 Redirection Information ........................................3
4 Existing Mechanisms in SIP .....................................6
5 Other Solution Options .........................................7
6 Examples of using the Redirection Information ..................9
7 Security Considerations .......................................18
8 IANA Considerations ...........................................19
9 References ....................................................19
10 Acknowledgments .............................................19
11 Author's Address ............................................19
12 Full Copyright Statement ....................................19
1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119.
2 Introduction: Redirection Services
Call redirection is a standard feature currently provided by the
traditional PBX and CO switches in Enterprise/PSTN and ISDN
networks. Typical applications for call redirection are in automatic
call distribution (ACD) for call centers, third-party voicemail,
follow-me service etc. Since SIP is being selected as a session
control protocol for many VOIP applications, it becomes a natural
choice for supporting such services and beyond.
The concept of Call Redirection is implicit in the capabilities
already defined for SIP Proxies and Clients. However, in order to
allow redirection to be used as a component of other services (in
particular voicemail), and in order to facilitate inter-working with
existing redirection services, these capabilities needs to operate
in a consistent and well-defined way, and also need to support
transfer of certain additional pieces of information.
The intention is not to duplicate ISDN Diversion services in SIP
networks - the move to SIP based session control allows us the
opportunity to redesign certain aspects of these legacy services and
in particular allows us to move from a model in which services
themselves are monolithically standardized, to one where the subject
of standardization is 'service capabilities' which can be built into
services by service providers or end-users.
Nonetheless, attention must be paid to inter-working with legacy
services. Usually this can be limited to capabilities for the
Internet Draft Expires May 2002 [Page 2]
SIP Voicemail Solutions November 2001
transfer of information associated, without impact on the functional
behavior of the SIP elements.
In order to understand what information may need to be carried
between SIP entities and possible PSTN entities involved in the
call, we examine first the services currently offered in the
PSTN/ISDN. [Q.952] describes a list of redirection services for
PSTN. SIP should contain capabilities, which allow services to be
built at least as advanced as these, and hopefully considerably
better. Examples,
1. Pre-configured call forwarding service to a certain
destination address when the user is busy or not-available or
does not reply
2. Per-call call forwarding service triggered by the called
party themselves (call deflection)
3. A service, which notifies the calling party with redirected-
to information, when a redirection occurs. Certain privacy
restrictions need to be met while presenting the redirection
information.
4. A service, which notifies the redirecting party with
redirected-to information, when a redirection occurs. Certain
privacy restrictions need to be met while presenting the
redirection information.
5. The presentation of the address of the redirecting user to
the user that the call is redirected to.
6. It should be possible to restrict the maximum number of times
a call is forwarded (e.g., to avoid a loop).
The above services should operate in a consistent manner for calls
originating (terminating) in an IP network and terminating
(originating) in the PSTN.
3 Redirection Information
This section presents a non-exhaustive list of information elements
that are required to be carried between call-control entities in
support of services such as those listed above. For each such
information element, we have provided a definition (i.e., WHAT is
this information?), assessed its applicability (i.e., WHY is it
useful?) and WHERE would it appear in current SIP messages.
Voicemail is used as an example but the capabilities discussed here
could be relevant to any service residing on a service platform to
which a call is redirected.
Internet Draft Expires May 2002 [Page 3]
SIP Voicemail Solutions November 2001
In this context, there are two approaches to carry this information
required by the service platform to perform the service:
A) Service-specific: if the information is required to be understood
only by the domain addressed in the Request-URI, then the information
can be encoded on the left-hand-side of the Request-URI [RFC3087].
For example, the Request-URI for depositing a voicemail could be of
the following form, indicating that the call should be directed to
voicemail box 025643, and that the greeting should be the `busy'
greeting:
Vm025643_busy@myVoicemail.myProvider.com
Approach (A) has the advantage of not requiring any specific
client capabilities, but the disadvantage of potential obscurity
in the provisioning of the service and the absence of a mechanism
to authenticate the information. This also does not satisfy any
privacy requirements as the subscriber information can be derived
from the Request-URI.
B) Generic: if the information may be required to be understood by
other entities, then a standardized mechanism is required to carry
it. In this case it would be more appropriate to use existing SIP
headers.
Approach (B) has the disadvantage that clients must support the
`generic' information headers before they can access the service,
but the advantage is that other entities (e.g., proxies, gateways)
can see the information and thereby enhance the service (for
instance by authenticating the information).
The information we consider is as follows:
1) Calling party address, e.g., SIP URL, E.164
WHAT: The party who placed the call
WHY: A voicemail system, for example, can provide special
service based on recognition of certain address-domain or DN
(e.g., play a different-than-normal greeting or allow out-
calling from the voicemail system).
WHERE: This information is carried in the From header and/or
Remote-Party-ID, where privacy restrictions apply. In many
cases a user may have multiple addresses a subset of which is
understood by the redirection service (e.g., for certain
legacy voicemail systems, this parameter can be a DN or a
local number required by that system). Consider a scenario
Internet Draft Expires May 2002 [Page 4]
SIP Voicemail Solutions November 2001
where A calls B in SIP domain and the call is forwarded to
B's voicemail in PSTN domain. Then, A's SIP URI in the From
header is not adequate to represent A to the PSTN voicemail
system.
2) Original called party address, e.g., SIP URL, E.164
WHAT: The original address called by the caller
WHY: For our voicemail example, this would allow the system
to locate the called party's mailbox
WHERE: This is typically carried in the To header. As stated
earlier, in many cases a user may have multiple addresses a
subset of which is understood by the redirection service.
3) Redirected-to address, e.g., SIP URL, E.164
WHAT: The address towards which the call has been forwarded
or must be forwarded
WHY: Needed for routing the forwarded leg of the call and for
notifying the calling party of the new destination of the
call. Can also be used to provide special service contexts,
e.g., different addresses for voice-mail and fax
deposit/retrieval services in a unified messaging system.
WHERE: For an INVITE forwarded onwards from the redirecting
party, this information is just the Request-URI.
4) Redirecting address, e.g., SIP URL, E.164
WHAT: The address from which the call is redirected. For the
first redirection, this is the same as the original called
party address.
WHY: In case the redirected-to party would need to know the
redirecting party address, during multiple call forwarding.
WHERE: If there is a single redirection, then this
information is equal to the originally called party and so is
carried in the To header. For multiple redirections, this
information is not carried in any of current SIP headers, but
could be encoded into the SIP URI if following approach (A).
5) Redirecting reason(s)
WHAT: The reason for (each) redirection
WHY: This information might be useful for presentation to the
redirected-to party. A voicemail service can also use this
information to play out the corresponding announcement.
WHERE: No current SIP header carries this information, but
could be encoded into the SIP URI if following approach (A).
6) Redirection counter
Internet Draft Expires May 2002 [Page 5]
SIP Voicemail Solutions November 2001
WHAT: A counter, which is incremented each time a redirection
occurs during session set-up.
WHY: Useful for eliminating possible loops or wastage of
network resources, when a forwarding chain gets too long.
Also, for an IP<->PSTN call, a separate counter is required
to consolidate the number of call forwards in both the
segments (IP and PSTN). This is required for a network
provider operating both the segments.
WHERE: Typically SIP uses the Max-Forwards header to limit
the number of entities that a message can pass. However, this
applies to every time a request passes a SIP entity and is
not limited to redirection as discussed here.
PRIVACY Requirement: There may be privacy restrictions in presenting
the address information (e.g., called, calling, redirected-to,
redirecting) of the party's involved in the call. At any point, the
SIP UA or the Proxy should be able to hide the address information
before sending a message containing the above information to an un-
trusted party. The framework described in [Priv] can be used as
discussed later in this draft.
The above parameters need to be sent in the direction of the
redirected-to party or service (downstream direction). For a simple
voicemail service example, the mandatory parameters are calling
party address, original called party address or redirecting address,
the redirected-to address and the redirecting reason(s). In the
upstream direction, parameters that may be used for redirection
notification to the calling party are redirected-to address and the
redirecting reason. All trusted SIP entities involved in redirection
should be able to create and modify redirection information.
4 Existing Mechanisms in SIP
The existing SIP protocol does not provide explicit mechanisms for
carrying some of the information required for supporting
redirection-based services. In particular, it does not provide a
vehicle to carry some of the redirection information such as
redirecting reasons, redirection counter and the redirecting address
towards the redirected-to party.
There is also no explicit way to carry some or all of this
information to the calling party.
[Div] provides a partial solution to the problem. It defines a new
SIP header, Diversion, which conveys some, not all, of the
redirection information. The Diversion header is added when a SIP
Internet Draft Expires May 2002 [Page 6]
SIP Voicemail Solutions November 2001
Proxy or an UA changes the destination of the call from that derived
by normal routing. The main advantages of the Diversion header are
that it creates a placeholder for all information that a re-
directing service endpoint might need and is extensible. However,
under the existing behavior, the calling party is not notified of
the diversion information and the privacy issues are not dealt with.
[Div] is also not a Working Group draft.
[RFC3087] provides examples of using the Request-URI to carry the
redirection address that would map to a specific mailbox service.
Not only does this generate URI's that are cumbersome and difficult
to parse, this also assumes that the UAC or Proxy have knowledge of
the service context. It also has other shortcomings, stemming from
the fact that information so encoded is only visible to the
addressed domain. Devices between the client (or its proxy) and the
service platform may need to see this information for two reasons:
1) Proxies may be required to authenticate this information
2) Gateways may be required to map this information into other
systems
So, without explicit mechanisms for carrying this information, it
can only ever be authenticated by the entity inserting it (which may
be the client) and can never be mapped into other systems. This
latter point means that PSTN Voicemail servers could not be used to
offer service to SIP endpoints and SIP voicemail servers could not
be used to offer service to PSTN endpoints.
In support of these scenarios we now consider options for explicit
support of redirection information in SIP.
5 Other Solution Options
1) REMOTE-PARTY-ID Header:
The primary use of this extension [Priv] is for communication of the
identity of the parties with support of generic privacy
requirements. The Remote-Party-ID (RPI) header can be easily
extended to include all the information described in Section 3.
Every time a redirection occurs, an RPI header is added, if
required, with the <address-spec> of the redirecting party. A series
of RPI headers are thus built up as multiple redirections occur,
charting the history of the call.
Similarly, RPI could be used to communicate the redirected-to
address to the calling party in the 181 response.
Internet Draft Expires May 2002 [Page 7]
SIP Voicemail Solutions November 2001
Two new "rpi-pty-type" are defined: "redirecting" and "redirected-
to". The other parameters, which in this case, characterize the
identity of the redirecting and redirected-to party, such as
redirecting reason, the order in the redirection list (redirection
counter) etc., can be added as extensions. The extended syntax is as
follows:
Remote-Party-ID = "Remote-Party-ID" ":" [display-name]" <"addr-
spec">" *(";" rpi-token)
rpi-token = rpi-screen | rpi-pty-type | rpi-id-type | rpi-
privacy | rpi-redirect | other-rpi-token |
rpi-screen = "screen" "=" ("no" | "yes" )
rpi-pty-type = "party" "=" ( "calling" | "called" |
"redirecting" | "redirected-to" | token )
rpi-id-type = "id-type" "=" ( "subscriber" | "user" |"alias" |
"return" | "term" | token )
rpi-privacy = "privacy" "=" 1#(("full" | "name" | "uri" |
"off" | token ) [ "-" ( "network" | token ) ] )
other-rpi-token = token ["-"] ["=" (token | quoted-string)]
rpi-redirect = "redirect" "=" rpi-rd-count ["," rpi-rd-reason]
rpi-id-count = 1*DIGIT
rpi-rd-reason = "busy" | "noAnswer" | "unconditional" | token |
quoted-string
One important advantage of using RPI header for redirection is that
it allows us to deal with the privacy issues. Since privacy is one
of the more important requirements for any redirection-based
service, we can effectively reuse an existing framework instead of
re-inventing one for a new header. [Priv] is already a SIPPING
Working Group draft and hence, has certain lead-time advantage.
2) STATE header:
In [Dcs] usage, the UAC or UAS are not required to create or modify
a State header. If used for redirection, the UAC/UAS should be able
to create or modify a State header. In [Dcs] usage, a Proxy is not
allowed to modify or delete State header information, unless the
hostname parameter matches that of the Proxy's. If used to carry
redirection information, any participating Proxy should be able to
modify certain information (e.g., redirecting address, counter). The
only way that [Dcs] deals with privacy issues is by mandating use of
encryption.
Apart from these differences, the State header is extensible and
also flexible for exchanging redirection information between SIP
entities. This is also a current WG draft.
Internet Draft Expires May 2002 [Page 8]
SIP Voicemail Solutions November 2001
3) COOKIE header:
The Cookie header can also be used in a way similar to that of the
State header (see above). When used in "participatory" mode, SIP
entities are allowed to modify Cookie headers [Willis]. However, a
Cookie is normally used when there is a need for storage and usage
of persistent state information across sessions - this is not
applicable to redirection. The other disadvantages are - the idea is
still in its infancy, and this is currently not a WG draft.
6 Examples of using the Redirection Information
In this section, we provide two examples of how the redirection
information would be used in a voicemail system. The redirection
information is carried in the Remote-Party-ID headers. Other
redirection scenarios will be considered in future versions of the
draft.
Example 1: Call forward on busy
The call flow depicts the following scenario - user A calls user B,
but is forwarded by the Proxy to UserB's Voicemail Server (VMS) on
busy. The Proxy determines the voicemail box address of UserB and
inserts a RPI header in the INVITE. The Proxy sends the redirection
information to A in an RPI header in 181 response.
User A Proxy User B VMS
| | | |
| INVITE F1 | | |
|---------------->| INVITE F2 | |
| |----------------->| |
| (100 Trying) F3 | | |
|<----------------| 486 Busy F4 | |
| |<-----------------| |
| | | |
| | INVITE F5 |
|(181 Call Fwd) F6|---------------------------------->|
|<----------------| | |
| | 200 OK F7| |
| 200 OK F8 |<----------------------------------|
|<----------------| | |
| | ACK F9 | |
|---------------------------------------------------->|
| | | |
| RTP Established between A and voice-mail box for B |
|<-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m->|
Internet Draft Expires May 2002 [Page 9]
SIP Voicemail Solutions November 2001
| | | |
Flow Id Comments
INVITE F1 INVITE sip:UserB@nortelnetworks.com SIP/2.0
A->Proxy Via: SIP/2.0/UDP here.com:5060
From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@nortelnetworks.com>
Call-Id: 12345600@here.com
CSeq: 1 INVITE
Contact: BigGuy <sip:UserA@here.com>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserA 2890844526 2890844526 IN IP4 client.here.com
s=Session SDP
c=IN IP4 100.101.102.103
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/*Client for A prepares to receive data on port 49170
from the network. */
INVITE F2 INVITE sip:UserB1@ims.nortelnetworks.com SIP/2.0
Proxy->B1 Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=1
Via: SIP/2.0/UDP here.com:5060
Record-Route: <sip:UserB@nortelnetworks.com>
From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@nortelnetworks.com>
Call-Id: 12345600@here.com
CSeq: 1 INVITE
Contact: BigGuy <sip:UserA@here.com>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserA 2890844526 2890844526 IN IP4 client.here.com
s=Session SDP
c=IN IP4 100.101.102.103
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Internet Draft Expires May 2002 [Page 10]
SIP Voicemail Solutions November 2001
(100 Trying SIP/2.0 100 Trying
F3 Via: SIP/2.0/UDP here.com:5060
Proxy->A) From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@nortelnetworks.com>
Call-Id: 12345600@here.com
CSeq: 1 INVITE
Content-Length: 0
486 Busy SIP/2.0 486 Busy
F4 Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=1
B1->Proxy Via: SIP/2.0/UDP here.com:5060
From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@nortelnetworks.com>;tag=3
Call-Id: 12345600@here.com
CSeq: 1 INVITE
Content-Length: 0
INVITE F5 INVITE sip:VM@nortelnetworks.com SIP/2.0
Proxy->VM Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=2
Via: SIP/2.0/UDP here.com:5060
Record-Route: <sip:UserB@nortelnetworks.com>
From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@nortelnetworks.com>
Call-Id: 12345600@here.com
Remote-Party-ID: LittleGuy <9726852222>;
screen=yes; party=redirecting; id-type=alias;
redirect=1,busy
CSeq: 1 INVITE
Contact: BigGuy <sip:UserA@here.com>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserA 2890844526 2890844526 IN IP4 client.here.com
s=Session SDP
c=IN IP4 100.101.102.103
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
181 F6 SIP/2.0 181 Call is forwarding
(Proxy->A) Via: SIP/2.0/UDP here.com:5060
From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@nortelnetworks.com>
Call-Id: 12345600@here.com
Internet Draft Expires May 2002 [Page 11]
SIP Voicemail Solutions November 2001
Remote-Party-ID: TheVoiceMail; screen=yes;
party=redirected-to; id-type=subscriber;
redirect=1,busy
CSeq: 1 INVITE
Content-Length: 0
200 OK F7 SIP/2.0 200 OK
VM->Proxy Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=2
Via: SIP/2.0/UDP here.com:5060
Record-Route: <sip:UserB@nortelnetworks.com>
From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@nortelnetworks.com>;tag=3
Call-Id: 12345600@here.com
CSeq: 1 INVITE
Contact: TheVoiceMail <sip:VM@nortelnetworks.com>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserB 2890844527 2890844527 IN IP4
vm.nortelnetworks.com
s=Session SDP
c=IN IP4 110.111.112.114
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
200 OK F8 SIP/2.0 200 OK
Proxy->A Via: SIP/2.0/UDP nortelnetworks.com:5060; branch=2
Via: SIP/2.0/UDP here.com:5060
Record-Route: <sip:UserB@nortelnetworks.com>
From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@nortelnetworks.com>;tag=3
Call-Id: 12345600@here.com
CSeq: 1 INVITE
Contact: TheVoiceMail <sip:VM@nortelnetworks.com>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserB 2890844527 2890844527 IN IP4
vm.nortelnetworks.com
s=Session SDP
c=IN IP4 110.111.112.114
Internet Draft Expires May 2002 [Page 12]
SIP Voicemail Solutions November 2001
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
ACK F9 ACK sip:VM@nortelnetworks.com SIP/2.0
A->VM Via: SIP/2.0/UDP here.com:5060
Route:<sip:VM@nortelnetworks.com>
From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@nortelnetworks.com>;tag=3
Call-Id: 12345600@here.com
CSeq: 1 ACK
Content-Length: 0
/* RTP streams are established between A and VMS. The
VMS starts announcement for UserB */
Example 2: Multiple Call Forwarding
In this example, UA A calls UA B through a Proxy. Proxy determines
that B is busy and forwards the call to C, who is temporarily
unavailable. The Proxy now forwards the call to B's VMS.
A Proxy B C VMS
| | | | |
|--INVITE F1-->| | | |
| | | | |
| |--INVITE F2 ->| | |
|<--100 F3 ----| | | |
| |<-486 F4------| | |
| | | | |
|<---181 F5 ---| | | |
| |--------INVITE F6---------->| |
| | | | |
| |<--------180 F7-------------| |
|<---180 F8 ---| | | |
| | | | |
| . . . |--------INVITE------------->| |
| | timeout | |
|<---181 F9 ---| | | |
| | | | |
| |-------INVITE F10--------------------->|
| | | | |
Internet Draft Expires May 2002 [Page 13]
SIP Voicemail Solutions November 2001
| |<-200 F11------------------------------|
| | | | |
|<-200-F12-----| | | |
| | | | |
|--ACK F13-------------------------------------------->|
| | | | |
| | | | |
Flow Id Comments
INVITE F1 INVITE sip:UserB@nortelnetworks.com SIP/2.0
A->Proxy Via: SIP/2.0/UDP here.com:5060
From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@nortelnetworks.com>
Call-Id: 12345600@here.com
CSeq: 1 INVITE
Contact: BigGuy <sip:UserA@here.com>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserA 2890844526 2890844526 IN IP4 client.here.com
s=Session SDP
c=IN IP4 100.101.102.103
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/*Client for A prepares to receive data on port 49170
from the network. */
INVITE F2 INVITE sip:UserB1@ims.nortelnetworks.com SIP/2.0
Proxy->B1 Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=1
Via: SIP/2.0/UDP here.com:5060
Record-Route: <sip:UserB@nortelnetworks.com>
From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@nortelnetworks.com>
Call-Id: 12345600@here.com
CSeq: 1 INVITE
Contact: BigGuy <sip:UserA@here.com>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserA 2890844526 2890844526 IN IP4 client.here.com
s=Session SDP
Internet Draft Expires May 2002 [Page 14]
SIP Voicemail Solutions November 2001
c=IN IP4 100.101.102.103
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
(100 Trying SIP/2.0 100 Trying
F3 Via: SIP/2.0/UDP here.com:5060
Proxy->A) From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@nortelnetworks.com>
Call-Id: 12345600@here.com
CSeq: 1 INVITE
Content-Length: 0
486 Busy SIP/2.0 486 Busy
F4 Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=1
B1->Proxy Via: SIP/2.0/UDP here.com:5060
From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@nortelnetworks.com>;tag=3
Call-Id: 12345600@here.com
CSeq: 1 INVITE
Content-Length: 0
SIP/2.0 181 Call is forwarding
181 F5 Via: SIP/2.0/UDP here.com:5060
(Proxy->A) From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@nortelnetworks.com>
Call-Id: 12345600@here.com
Remote-Party-ID: PartyC <9726853333>; screen=yes;
party=redirected-to; id-type=alias;
redirect=1,busy
CSeq: 1 INVITE
Content-Length: 0
INVITE F6 INVITE sip:UserC1@nortelnetworks.com SIP/2.0
Proxy->C Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=2
Via: SIP/2.0/UDP here.com:5060
Record-Route: <sip:UserB@nortelnetworks.com>
From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@nortelnetworks.com>
Call-Id: 12345600@here.com
Remote-Party-ID: LittleGuy <9726852222 >;
screen=yes; party=redirecting; id-type=alias;
redirect=1,busy
CSeq: 1 INVITE
Contact: BigGuy <sip:UserA@here.com>
Internet Draft Expires May 2002 [Page 15]
SIP Voicemail Solutions November 2001
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserA 2890844526 2890844526 IN IP4 client.here.com
s=Session SDP
c=IN IP4 100.101.102.103
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
180 Ring F7 SIP/2.0 180 Ringing
C->Proxy Via: SIP/2.0/UDP there.com:5060
From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@nortelnetworks.com>;tag=5
Call-ID: 12345600@here.com
CSeq: 1 INVITE
Content-Length: 0
F8 180 SIP/2.0 180 Ringing
(Proxy->A) SIP/2.0/UDP here.com:5060
From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@nortelnetworks.com>
Call-Id: 12345600@here.com
CSeq: 1 INVITE
Content-Length: 0
/* User C is not available. INVITE is sent multiple
times until it times out. */
181 F9 Via: SIP/2.0/UDP here.com:5060
(Proxy->A) From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@nortelnetworks.com>
Call-Id: 12345600@here.com
Remote-Party-ID: TheVoiceMail; screen=yes;
party=redirected-to; id-type=subscriber;
redirect=2,noAnswer
CSeq: 1 INVITE
Content-Length: 0
INVITE F10 INVITE sip:VM@nortelnetworks.com SIP/2.0
Proxy->VM Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=3
Via: SIP/2.0/UDP here.com:5060
Record-Route: <sip:UserB@nortelnetworks.com>
From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@nortelnetworks.com>
Internet Draft Expires May 2002 [Page 16]
SIP Voicemail Solutions November 2001
Call-Id: 12345600@here.com
Remote-Party-ID: LittleGuy <9726852222>; screen=yes;
party=redirecting; id-type=alias; redirect=1,busy
Remote-Party-ID: PartyC <9726853333>; screen=yes;
party=redirecting; id-type=alias; redirect=2,noAnswer
CSeq: 1 INVITE
Contact: BigGuy <sip:UserA@here.com>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserA 2890844526 2890844526 IN IP4 client.here.com
s=Session SDP
c=IN IP4 100.101.102.103
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/* The proxy forwards the INVITE to VMS after adding
two RPI headers */
200 OK F11 SIP/2.0 200 OK
VM->Proxy Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=3
Via: SIP/2.0/UDP here.com:5060
Record-Route: <sip:UserB@nortelnetworks.com>
From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@nortelnetworks.com>;tag=3
Call-Id: 12345600@here.com
CSeq: 1 INVITE
Contact: TheVoiceMail <sip:VM@nortelnetworks.com>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserB 2890844527 2890844527 IN IP4
vm.nortelnetworks.com
s=Session SDP
c=IN IP4 110.111.112.114
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
200 OK F12 SIP/2.0 200 OK
Proxy->A Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=3
Internet Draft Expires May 2002 [Page 17]
SIP Voicemail Solutions November 2001
Via: SIP/2.0/UDP here.com:5060
Record-Route: <sip:UserB@nortelnetworks.com>
From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@nortelnetworks.com>;tag=3
Call-Id: 12345600@here.com
CSeq: 1 INVITE
Contact: TheVoiceMail <sip:VM@nortelnetworks.com>
Content-Type: application/sdp
Content-Length: <appropriate value>
v=0
o=UserB 2890844527 2890844527 IN IP4
vm.nortelnetworks.com
s=Session SDP
c=IN IP4 110.111.112.114
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
ACK F13 ACK sip:VM@nortelnetworks.com SIP/2.0
A->VM Via: SIP/2.0/UDP here.com:5060
Route:<sip:VM@nortelnetworks.com>
From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@nortelnetworks.com>;tag=3
Call-Id: 12345600@here.com
CSeq: 1 ACK
Content-Length: 0
/* RTP streams are established between A and VMS. VMS
starts announcement for UserB */
7 Security Considerations
In the proposed usage of RPI header, the security considerations
discussed in [Priv] applies. If the RPI header is received by an un-
trusted entity, the header may be discarded. For proper usage of the
RPI header in this context, it is required that there is a trust
relationship between the redirecting and redirected-to parties.
Integrity protection of messages carrying the RPI header towards the
service endpoint is of utmost importance, as a possible man-in-the-
middle attack can easily modify header information and subvert the
service.
Internet Draft Expires May 2002 [Page 18]
SIP Voicemail Solutions November 2001
8 IANA Considerations
The new tokens defined as extensions to the RPI header fields need
to be registered with IANA.
9 References
[RFC3087] "Control of Service Context using SIP Request-URI"
[Div] "Diversion Indication in SIP", draft-levy-sip-diversion-
02.txt
[Priv] "SIP Extensions for Caller Identity and Privacy", draft-
ietf-sip-privacy-02.txt
[Willis] "SIP Cookies", draft-willis-sip-cookies-00.txt
[Dcs] "SIP Extensions for supporting distributed call state",
draft-ietf-sip-state-02.txt
[Q.952] "Stage 3 Service Description for Call Offering
Supplementary Services using DSS 1 - Diversion
Supplementary Services"
10 Acknowledgments
The authors would like to thank Francois Audet, Mary Barnes, Anthony
Brown, Chris Hogg (Nortel) and Ari Immonen (Tecnomen) for their
useful comments and suggestions related to this draft.
11 Author's Address
Sanjoy Sen
Nortel Networks
sanjoy@nortelnetworks.com
Jayshree Bharatia
Nortel Networks
bharatia@nortelnetworks.com
Ray Yuhanna
Nortel Networks
yuhanna@nortelnetworks.com
Scott Orton
Nortel Networks
orton@nortelnetworks.com
Mark Watson
Nortel Networks
mwatson@nortelnetworks.com
12 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
Internet Draft Expires May 2002 [Page 19]
SIP Voicemail Solutions November 2001
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its successors or
assigns. This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE."
Internet Draft Expires May 2002 [Page 20]
