Network Working Group S. Levy
Internet-Draft J. Yang
Intended status: Historic Cisco Systems
Expires: November 2, 2009 B. Byerly
May 01, 2009
Diversion Indication in SIP
draft-levy-sip-diversion-09
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 November 2, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Levy, et al. Expires November 2, 2009 [Page 1]
Internet-Draft Diversion header May 2009
Abstract
This document proposes an extension to the Session Initiation
Protocol (SIP). This extension provides the ability for the called
SIP user agent to identify from whom the call was diverted and why
the call was diverted.
The extension defines a general header, Diversion, which conveys the
diversion information from other SIP user agents and proxies to the
called user agent.
This extension allows enhanced support for various features,
including Unified Messaging, Third-Party Voicemail, and Automatic
Call Distribution (ACD). SIP user agents and SIP proxies which
receive diversion information may use this as supplemental
information for feature invocation decisions.
Requirements Language
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 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. When is the Diversion header used? . . . . . . . . . . . . 6
5. Extension syntax . . . . . . . . . . . . . . . . . . . . . . . 6
6. Detailed semantics . . . . . . . . . . . . . . . . . . . . . . 7
6.1. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 7
6.3. Redirect Server Behavior . . . . . . . . . . . . . . . . . 7
6.4. Proxy Server Behavior . . . . . . . . . . . . . . . . . . 8
6.4.1. Proxy Logic for Diversion header . . . . . . . . . . . 8
7. Examples using Diversion header . . . . . . . . . . . . . . . 8
7.1. Call Forward Unconditional . . . . . . . . . . . . . . . . 9
7.1.1. Network Call Forward Unconditional, P2 recursing . . . 9
7.1.2. Network Call Forward Unconditional, P1
non-recursing P2 non-recursing . . . . . . . . . . . . 9
7.1.3. Network Call Forward Unconditional, P1 recursing
P2 non-recursing . . . . . . . . . . . . . . . . . . . 10
7.1.4. Endpoint Call Forward Unconditional, P1 recursing
P2 non-recursing . . . . . . . . . . . . . . . . . . . 12
7.2. Call Forward on Busy . . . . . . . . . . . . . . . . . . . 12
7.2.1. Network Call Forward on Busy, P2 recursing . . . . . . 12
7.2.2. Network Call Forward on Busy, P1 non-recursing P2
non-recursing . . . . . . . . . . . . . . . . . . . . 13
Levy, et al. Expires November 2, 2009 [Page 2]
Internet-Draft Diversion header May 2009
7.2.3. Network Call Forward on Busy, P1 recursing P2
non-recursing . . . . . . . . . . . . . . . . . . . . 14
7.2.4. Endpoint Call Forward on Busy, P1 recursing P2
non-recursing . . . . . . . . . . . . . . . . . . . . 15
7.3. Call Forward on No-Answer . . . . . . . . . . . . . . . . 16
7.3.1. Network Call Forward on No-Answer, P2 recursing . . . 17
7.3.2. Network Call Forward on No-Answer, P1
non-recursing P2 non-recursing . . . . . . . . . . . . 17
7.3.3. Network Call Forward on No Answer, P1 recursing P2
non-recursing . . . . . . . . . . . . . . . . . . . . 18
7.3.4. Endpoint Call Forward on No-Answer, P1 recursing,
P2 non-recursing B non-recursing . . . . . . . . . . . 19
7.4. Call Forward on Unavailable . . . . . . . . . . . . . . . 20
7.4.1. Network Call Forward on Unavailable, P2 recursing . . 21
7.4.2. Network Call Forward on Unavailable, P1
non-recursing P2 non-recursing . . . . . . . . . . . . 21
7.4.3. Network Call Forward on Unavailable, P1 recursing
P2 non-recursing . . . . . . . . . . . . . . . . . . . 23
7.5. Multiple Diversions . . . . . . . . . . . . . . . . . . . 23
7.5.1. Call Forward Unconditional and Call Forward Busy . . . 24
7.5.2. Call Forward Unconditional and Call Forward No
Answer . . . . . . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9. Further Examples . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Night Service/Automatic Call Distribution (ACD) using
Diversion header . . . . . . . . . . . . . . . . . . . . . 27
9.2. Voicemail Service using Diversion header . . . . . . . . . 35
9.3. Q&A on alternative approaches . . . . . . . . . . . . . . 39
10. Mapping ISUP/ISDN Redirection information to SIP Diversion
header . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.1. Mapping ISUP/ISDN Diversion Reason codes . . . . . . . . . 40
10.2. Mapping ISUP Redirection information to SIP Diversion
header . . . . . . . . . . . . . . . . . . . . . . . . . . 40
10.2.1. ISUP Definitions . . . . . . . . . . . . . . . . . . . 41
10.2.2. ISUP parameters . . . . . . . . . . . . . . . . . . . 41
10.2.3. ISUP to SIP translation . . . . . . . . . . . . . . . 42
10.2.4. SIP to ISUP translation . . . . . . . . . . . . . . . 42
10.2.5. Example of ISUP to SIP translation . . . . . . . . . . 42
10.2.6. Example of SIP to ISUP translation . . . . . . . . . . 43
10.3. Mapping ISDN Redirection information to SIP Diversion
header . . . . . . . . . . . . . . . . . . . . . . . . . . 44
10.3.1. ISDN Definitions . . . . . . . . . . . . . . . . . . . 44
10.3.2. ISDN parameters . . . . . . . . . . . . . . . . . . . 44
10.3.3. ISDN to SIP translation . . . . . . . . . . . . . . . 45
10.3.4. SIP to ISDN translation . . . . . . . . . . . . . . . 46
10.3.5. Example of ISDN to SIP translation . . . . . . . . . . 46
10.3.6. Example of SIP to ISDN translation . . . . . . . . . . 47
10.4. Information loss in SIP to ISUP/ISDN translation . . . . . 48
Levy, et al. Expires November 2, 2009 [Page 3]
Internet-Draft Diversion header May 2009
10.4.1. Loss of diversion URI information . . . . . . . . . . 48
10.4.2. Loss of diversion reason information . . . . . . . . . 48
10.4.3. Loss of diversion counter information . . . . . . . . 49
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
12. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 49
13. Normative References . . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
Levy, et al. Expires November 2, 2009 [Page 4]
Internet-Draft Diversion header May 2009
1. Introduction
In the legacy telephony network, redirection information is passed
through the network in ISDN/ISUP signaling messages. This
information is used by various service providers and business
applications to support enhanced features for the end user.
An analogous mechanism of providing redirection information would
enable such enhanced features for SIP users.
The Diversion header allows implementation of feature logic based on
from whom the call was diverted.
Version 06 (and forward) of the draft adds support for privacy and
screening information.
2. Definitions
diversion:
A change to the ultimate destination endpoint of a request. A change
in the Request-URI of a request that was not caused by a routing
decision. This is also sometimes called a deflection or redirection.
A diversion can occur when the "user" portion of the Request-URI is
changed for a reason other than expansion or translation.
A diversion can occur when only the "host" portion of the Request-URI
has changed if the change was due to a non-routing decision.
divertor:
The entity which diverted the call.
recursing:
A SIP proxy or user agent which handles a received or internally
generated 3xx response by forking new request(s) itself.
non-recursing:
A SIP proxy or user agent which handles a received or internally
generated 3xx response by forwarding it upstream.
3. Abbreviations
CFUNC: Call Forward Unconditional
CFTOD: Call Forward Time-of-Day
CFB: Call Forward on Busy
CFNA: Call Forward on No Answer
CFUNV: Call Forward Unavailable
ACD: Automatic Call Distribution
Levy, et al. Expires November 2, 2009 [Page 5]
Internet-Draft Diversion header May 2009
4. Overview
In order to implement certain third-party features such as third-
party voicemail and Automatic Call Distribution (ACD) applications,
diversion information needs to be given to the called third-party so
that he may respond to the caller intelligently.
In these situations, the party receiving a diverted call needs
answers for two questions:
Question 1: From whom was the request diverted?
Question 2: Why was the request diverted?
This document proposes usage of the Diversion header to answer these
questions for the party receiving the diverted call.
Insertion of the previous Request-URI (before the diversion occurred)
into the Diversion header answers question 1.
Insertion of the "reason" tag into the Diversion header (by the
divertor) answers question 2.
4.1. When is the Diversion header used?
The Diversion header SHOULD be added when a SIP proxy server, SIP
redirect server, or SIP user agent changes the ultimate endpoint
which will receive the call.
Diversion information SHOULD NOT be added for normal call routing
changes to the Request-URI. Thus, the Diversion header is not added
when features such as speed dial change the Request-URI.
When a diversion occurs, a Diversion header SHOULD be added to the
forwarded request or forwarded 3xx response. The Diversion header
MUST contain the Request-URI of the request prior to the diversion.
The Diversion header SHOULD contain a reason that the diversion
occurred.
Existing Diversion headers received in an incoming request MUST NOT
be removed or changed in forwarded requests.
Existing Diversion headers received in an incoming response MUST NOT
be removed or changed in the forwarded response.
A Diversion header is added when features such as call forwarding or
call deflection change the Request-URI.
5. Extension syntax
The syntax of the Diversion header is:
Levy, et al. Expires November 2, 2009 [Page 6]
Internet-Draft Diversion header May 2009
Diversion = "Diversion" ":" 1# (name-addr *( ";" diversion_params ))
diversion-params = diversion-reason | diversion-counter |
diversion-limit | diversion-privacy |
diversion-screen | diversion-extension
diversion-reason = "reason" "="
( "unknown" | "user-busy" | "no-answer" |
"unavailable" | "unconditional" |
"time-of-day" | "do-not-disturb" |
"deflection" | "follow-me" |
"out-of-service" | "away" |
token | quoted-string )
diversion-counter = "counter" "=" 1*2DIGIT
diversion-limit = "limit" "=" 1*2DIGIT
diversion-privacy = "privacy" "=" ( "full" | "name" |
"uri" | "off" | token | quoted-string )
diversion-screen = "screen" "=" ( "yes" | "no" | token |
quoted-string )
diversion-extension = token ["=" (token | quoted-string)]
The following is an extension of tables 4 and 5 in [RFC3261]for the
Diversion header:
where enc. e-e ACK BYE CAN INV OPT REG
_____________________________________________________________
Diversion R h - - - o - -
Diversion 3xx h - - - o - -
6. Detailed semantics
6.1. UAS Behavior
A SIP UAS which receives a request and returns a 3xx SHOULD add a
Diversion header containing the previous Request-URI and the reason
for the diversion.
6.2. UAC Behavior
A SIP UAC which receives a 3xx containing a Diversion header SHOULD
copy the Diversion header into each downstream forked request which
resulted from the 3xx.
6.3. Redirect Server Behavior
A SIP redirect server which receives a request and returns a 3xx
containing a Contact which diverts the request to a different
endpoint SHOULD add a Diversion header containing the Request-URI
from the incoming request and the reason for the diversion.
Levy, et al. Expires November 2, 2009 [Page 7]
Internet-Draft Diversion header May 2009
6.4. Proxy Server Behavior
A non-recursing SIP proxy which receives a 3xx containing a Diversion
header SHOULD forward the 3xx containing the Diversion header
upstream unchanged.
A SIP proxy which receives a request and invokes a feature which
changes the Request-URI of the forwarded request in order to divert
the request to a different endpoint SHOULD add a Diversion header
containing the Request-URI from the incoming request and the reason
for the diversion.
A SIP proxy which receives a request and returns a 3xx containing a
Contact which diverts the request to a different endpoint SHOULD add
a Diversion header containing the Request-URI from the incoming
request and the reason for the diversion.
6.4.1. Proxy Logic for Diversion header
if (pdu.is_request()) {
if (request-URI is changed due to a called feature) {
if (proxy.is_recursing()) {
Add the Diversion header (indicating the reason
that the call has been diverted) to
the downstream forwarded request(s).
} else {
Add the Diversion header (indicating the reason
that the call has been diverted) to
the upstream forwarded 3xx response.
}
}
} else if (pdu.is_response()) {
if (pdu.is_3xx()) {
if (proxy.is_recursing()) {
Copy Diversion header into forwarded INVITE(s).
} else {
Forward response upstream.
}
}
}
7. Examples using Diversion header
There are several implementations of call forwarding features that
can be implemented by either recursing or non-recursing SIP proxies
or SIP user agents.
A SIP proxy or user agent which generates or forwards 3xx's upstream
is non-recursing. A SIP proxy or user agent which handles received
(or internally generated) 3xx's itself is recursing.
The following examples illustrate usage of the Diversion header for
Levy, et al. Expires November 2, 2009 [Page 8]
Internet-Draft Diversion header May 2009
some of the variants of recursing and non-recursing proxies and user
agents.
7.1. Call Forward Unconditional
Usage of the Diversion header is shown below for several variant
implementations of Call Forward Unconditional.
7.1.1. Network Call Forward Unconditional, P2 recursing
In this message flow, the call would normally be routed to Bob@B.
However, Proxy 2 (P2) recursively implements Call Forward
Unconditional (CFUNC) to Carol@C.
+------------------------+
| Bob@P2: CFUNC->Carol@C |
+------+-----------------+
\
\
A P1 P2 B C
recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | | | |
| | |--INVITE Carol@C------->|
| | | Diversion: Bob@P2 |
| | | ;reason=unconditional
| | | | |
| | |<-200-------------------|
| | | | |
| |<-200---------| | |
| | | | |
|<-200---------| | | |
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
7.1.2. Network Call Forward Unconditional, P1 non-recursing P2 non-
recursing
In this message flow, Proxy 2 (P2) non-recursively implements Call
Forward Unconditional (CFUNC) to Carol@C. Proxy 1 (P1) is non-
recursing.
Levy, et al. Expires November 2, 2009 [Page 9]
Internet-Draft Diversion header May 2009
+------------------------+
| Bob@P2: CFUNC->Carol@C |
+------+-----------------+
\
\
A P1 P2 B C
non-recursing non-recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | | | |
| |<-302---------| | |
| | Contact: Carol@C | |
| | Diversion: Bob@P2 | |
| | ;reason=unconditional | |
| | | | |
| |--ACK-------->| | |
| | | | |
|<-302---------| | | |
| Contact: Carol@C | | |
| Diversion: Bob@P2 | | |
| ;reason=unconditional | | |
| | | | |
|--ACK-------->| | | |
| | | | |
|--INVITE Carol@C------------------------------------->|
| Diversion: Bob@P2 | | |
| ;reason=unconditional | | |
| | | | |
|<-200-------------------------------------------------|
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
7.1.3. Network Call Forward Unconditional, P1 recursing P2 non-
recursing
In this message flow, Proxy 2 (P2) non-recursively implements Call
Forward Unconditional (CFUNC) to Carol@C. Proxy 1 (P1) is recursing.
Levy, et al. Expires November 2, 2009 [Page 10]
Internet-Draft Diversion header May 2009
+------------------------+
| Bob@P2: CFUNC->Carol@C |
+------+-----------------+
\
\
A P1 P2 B C
recursing non-recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | | | |
| |<-302---------| | |
| | Contact: Carol@C | |
| | Diversion: Bob@P2 | |
| | ;reason=unconditional | |
| | | | |
| |--ACK-------->| | |
| | | | |
| |--INVITE Carol@C---------------------->|
| | Diversion: Bob@P2 | |
| | ;reason=unconditional | |
| | | | |
| |<-200----------------------------------|
| | | | |
|<-200---------| | | |
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
7.1.4. Endpoint Call Forward Unconditional, P1 recursing P2 non-
recursing
In this message flow, user agent server B (B) non-recursively
implements Call Forward Unconditional (CFUNC) to Carol@C. Proxy 2
(P2) is non-recursing. Proxy 1 (P1) is recursing.
Levy, et al. Expires November 2, 2009 [Page 11]
Internet-Draft Diversion header May 2009
+-----------------------+
| Bob@B: CFUNC->Carol@C |
+------+----------------+
\
\
A P1 P2 B C
recursing non-recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | |--INV Bob@B--->| |
| | | | |
| | |<-302----------| |
| | | Contact: Carol@C |
| | | Diversion: Bob@B |
| | | ;reason=unconditional
| | | | |
| | |--ACK--------->| |
| | | | |
| |<-302---------| | |
| | Contact: Carol@C | |
| | Diversion: Bob@B | |
| | ;reason=unconditional | |
| | | | |
| |--ACK-------->| | |
| | | | |
| |--INVITE Carol@C------------------------>|
| | Diversion: Bob@B | |
| | ;reason=unconditional | |
| | | | |
| |<-200------------------------------------|
| | | | |
|<-200---------| | | |
| | | | |
|--ACK-------------------------------------------------->|
| | | | |
| | | | |
7.2. Call Forward on Busy
Usage of the Diversion header is shown below for several variant
implementations of Call Forward on Busy.
7.2.1. Network Call Forward on Busy, P2 recursing
In this message flow, Proxy 2 (P2) recursively implements Call
Forward on Busy (CFB) to Carol@C.
Levy, et al. Expires November 2, 2009 [Page 12]
Internet-Draft Diversion header May 2009
+----------------------+
| Bob@P2: CFB->Carol@C |
+------+---------------+
\
\
A P1 P2 B C
recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | | | |
| | |--INV Bob@B->| |
| | | | |
| | |<-486--------| |
| | | | |
| | |--ACK------->| |
| | | | |
| | |--INVITE Carol@C------->|
| | | Diversion: Bob@P2 |
| | | ;reason=user-busy |
| | | | |
| | |<-200-------------------|
| | | | |
| |<-200---------| | |
| | | | |
|<-200---------| | | |
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
7.2.2. Network Call Forward on Busy, P1 non-recursing P2 non-recursing
In this message flow, Proxy 2 (P2) non-recursively implements Call
Forward on Busy (CFB) to Carol@C. Proxy 1 (P1) is non-recursing.
Levy, et al. Expires November 2, 2009 [Page 13]
Internet-Draft Diversion header May 2009
+----------------------+
| Bob@P2: CFB->Carol@C |
+------+---------------+
\
\
A P1 P2 B C
non-recursing non-recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | | | |
| | |--INV Bob@B->| |
| | | | |
| | |<-486--------| |
| | | | |
| | |--ACK------->| |
| | | | |
| |<-302---------| | |
| | Contact: Carol@C | |
| | Diversion: Bob@P2 | |
| | ;reason=user-busy | |
| | | | |
| |--ACK-------->| | |
| | | | |
|<-302---------| | | |
| Contact: Carol@C | | |
| Diversion: Bob@P2 | | |
| ;reason=user-busy | | |
| | | | |
|--ACK-------->| | | |
| | | | |
|--INVITE Carol@C------------------------------------->|
| Diversion: Bob@P2 | | |
| ;reason=user-busy | | |
| | | | |
|<-200-------------------------------------------------|
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
7.2.3. Network Call Forward on Busy, P1 recursing P2 non-recursing
In this message flow, Proxy 2 (P2) non-recursively implements Call
Forward on Busy (CFB) to Carol@C. Proxy 1 (P1) is recursing.
Levy, et al. Expires November 2, 2009 [Page 14]
Internet-Draft Diversion header May 2009
+----------------------+
| Bob@P2: CFB->Carol@C |
+------+---------------+
\
\
A P1 P2 B C
recursing non-recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | | | |
| | |--INV Bob@B->| |
| | | | |
| | |<-486--------| |
| | | | |
| | |--ACK------->| |
| | | | |
| |<-302---------| | |
| | Contact: Carol@C | |
| | Diversion: Bob@P2 | |
| | ;reason=user-busy | |
| | | | |
| |--ACK-------->| | |
| | | | |
| |--INVITE Carol@C---------------------->|
| | Diversion: Bob@P2 | |
| | ;reason=user-busy | |
| | | | |
| |<-200----------------------------------|
| | | | |
|<-200---------| | | |
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
7.2.4. Endpoint Call Forward on Busy, P1 recursing P2 non-recursing
In this message flow, user agent server B (B) non-recursively
implements Call Forward on Busy (CFB) to Carol@C. Proxy 2 (P2) is
non-recursing. Proxy 1 (P1) is recursing.
Levy, et al. Expires November 2, 2009 [Page 15]
Internet-Draft Diversion header May 2009
+---------------------+
| Bob@B: CFB->Carol@C |
+------+--------------+
\
\
A P1 P2 B C
recursing non-recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | | | |
| | |--INV Bob@B->| |
| | | | |
| | |<-302--------| |
| | | Contact: Carol@C |
| | | Diversion: Bob@B |
| | | ;reason=user-busy |
| | | | |
| | |--ACK------->| |
| | | | |
| |<-302---------| | |
| | Contact: Carol@C | |
| | Diversion: Bob@B | |
| | ;reason=user-busy | |
| | | | |
| |--ACK-------->| | |
| | | | |
| |--INVITE Carol@C---------------------->|
| | Diversion: Bob@B | |
| | ;reason-user-busy | |
| | | | |
| |<-200----------------------------------|
| | | | |
|<-200---------| | | |
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
7.3. Call Forward on No-Answer
Usage of the Diversion header is shown below for several variant
implementations of Call Forward on No-Answer.
Levy, et al. Expires November 2, 2009 [Page 16]
Internet-Draft Diversion header May 2009
7.3.1. Network Call Forward on No-Answer, P2 recursing
In this message flow, Proxy 2 (P2) recursively implements Call
Forward on No Answer (CFNA) to Carol@C.
+-----------------------+
| Bob@P2: CFNA->Carol@C |
+------+----------------+
\
\
A P1 P2 B C
recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | | | |
| | |--INV Bob@B->| |
| | | | |
| | |<-180--------| |
| | | | |
| | | | |
| | | | |
| | timeout | |
| | |--INVITE Carol@C------->|
| | | Diversion: Bob@P2 |
| | | ;reason=no-answer |
| | | | |
| | |<-200-------------------|
| | | | |
| |<-200---------| | |
| | | | |
|<-200---------| | | |
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
7.3.2. Network Call Forward on No-Answer, P1 non-recursing P2 non-
recursing
In this message flow, Proxy 2 (P2) non-recursively implements Call
Forward on No Answer (CFNA) to Carol@C. Proxy 1 (P1) is non-
recursing.
Levy, et al. Expires November 2, 2009 [Page 17]
Internet-Draft Diversion header May 2009
+-----------------------+
| Bob@P2: CFNA->Carol@C |
+------+----------------+
\
\
A P1 P2 B C
non-recursing non-recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | | | |
| | |--INV Bob@B->| |
| | | | |
| | |<-180--------| |
| | | | |
| | | | |
| | | | |
| | timeout | |
| |<-302---------| | |
| | Contact: Carol@C | |
| | Diversion: Bob@P2 | |
| | ;reason=no-answer | |
| | | | |
| |--ACK-------->| | |
| | | | |
|<-302---------| | | |
| Contact: Carol@C | | |
| Diversion: Bob@P2 | | |
| ;reason=no-answer | | |
| | | | |
|--ACK-------->| | | |
| | | | |
|--INVITE Carol@C------------------------------------->|
| Diversion: Bob@P2 | | |
| ;reason=no-answer | | |
| | | | |
|<-200-------------------------------------------------|
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
7.3.3. Network Call Forward on No Answer, P1 recursing P2 non-recursing
In this message flow, Proxy 2 (P2) non-recursively implements Call
Forward on No Answer (CFNA) to Carol@C. Proxy 1 (P1) is recursing.
Levy, et al. Expires November 2, 2009 [Page 18]
Internet-Draft Diversion header May 2009
+-----------------------+
| Bob@P2: CFNA->Carol@C |
+------+----------------+
\
\
A P1 P2 B C
recursing non-recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | | | |
| | |--INV Bob@B->| |
| | | | |
| | |<-180--------| |
| | | | |
| | | | |
| | | | |
| | timeout | |
| |<-302---------| | |
| | Contact: Carol@C | |
| | Diversion: Bob@P2 | |
| | ;reason=no-answer | |
| | | | |
| |--ACK-------->| | |
| | | | |
| |--INVITE Carol@C---------------------->|
| | Diversion: Bob@P2 | |
| | ;reason=no-answer | |
| | | | |
| |<-200----------------------------------|
| | | | |
|<-200---------| | | |
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
7.3.4. Endpoint Call Forward on No-Answer, P1 recursing, P2 non-
recursing B non-recursing
In this message flow, user agent server B (B) non-recursively
implements Call Forward on No Answer (CFNA) to Carol@C. Proxy 2 (P2)
is non-recursing. Proxy 1 (P1) is recursing.
Levy, et al. Expires November 2, 2009 [Page 19]
Internet-Draft Diversion header May 2009
+----------------------+
| Bob@B: CFNA->Carol@C |
+------+---------------+
\
\
A P1 P2 B C
recursing non-recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | | | |
| | |--INV Bob@B->| |
| | | | |
| | | | |
| | | | |
| | | timeout |
| | |<-302--------| |
| | | Contact: Carol@C |
| | | Diversion: Bob@B |
| | | ;reason=no-answer |
| | | | |
| | |--ACK------->| |
| | | | |
| |<-302---------| | |
| | Contact: Carol@C | |
| | Diversion: Bob@B | |
| | ;reason=no-answer | |
| | | | |
| |--ACK-------->| | |
| | | | |
| |--INVITE Carol@C---------------------->|
| | Diversion: Bob@B | |
| | ;reason-no-answer | |
| | | | |
| |<-200----------------------------------|
| | | | |
|<-200---------| | | |
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
7.4. Call Forward on Unavailable
Usage of the Diversion header is shown below for several variant
implementations of Call Forward on Unavailable.
Levy, et al. Expires November 2, 2009 [Page 20]
Internet-Draft Diversion header May 2009
7.4.1. Network Call Forward on Unavailable, P2 recursing
In this message flow, Proxy 2 (P2) recursively implements Call
Forward on Unavailable (CFUNV) to Carol@C.
+------------------------+
| Bob@P2: CFUNV->Carol@C |
+------+-----------------+
\
\
A P1 P2 B C
recursing
| | | | |
|--INV Bob@P1->| | | |
|<-100---------| | | |
| |--INV Bob@P2->| | |
| |<-100---------| | |
| | |--INV Bob@B->| |
| | |--INV Bob@B->| |
| | |--INV Bob@B->| |
| | | ... | |
| | |--INV Bob@B->| |
| | timeout | |
| | |--INVITE Carol@C------->|
| | | Diversion: Bob@P2 |
| | | ;reason=unavailable
| | | | |
| | |<-200-------------------|
| | | | |
| |<-200---------| | |
| | | | |
|<-200---------| | | |
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
7.4.2. Network Call Forward on Unavailable, P1 non-recursing P2 non-
recursing
In this message flow, Proxy 2 (P2) non-recursively implements Call
Forward on Unavailable (CFUNV) to Carol@C. Proxy 1 (P1) is non-
recursing.
Levy, et al. Expires November 2, 2009 [Page 21]
Internet-Draft Diversion header May 2009
+------------------------+
| Bob@P2: CFUNV->Carol@C |
+------+-----------------+
\
\
A P1 P2 B C
non-recursing non-recursing
| | | | |
|--INV Bob@P1->| | | |
| | | | |
| |--INV Bob@P2->| | |
| | | | |
| |<-100---------| | |
| | | | |
|<-100---------| | | |
| | |--INV Bob@B->| |
| | |--INV Bob@B->| |
| | |--INV Bob@B->| |
| | | ... | |
| | |--INV Bob@B->| |
| | timeout | |
| |<-302---------| | |
| | Contact: Carol@C | |
| | Diversion: Bob@P2 | |
| | ;reason=unavailable | |
| | | | |
| |--ACK-------->| | |
| | | | |
|<-302---------| | | |
| Contact: Carol@C | | |
| Diversion: Bob@P2 | | |
| ;reason=unavailable | | |
| | | | |
|--ACK-------->| | | |
| | | | |
|--INVITE Carol@C------------------------------------->|
| Diversion: Bob@P2 | | |
| ;reason=unavailable | | |
| | | | |
|<-200-------------------------------------------------|
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
Levy, et al. Expires November 2, 2009 [Page 22]
Internet-Draft Diversion header May 2009
7.4.3. Network Call Forward on Unavailable, P1 recursing P2 non-
recursing
In this message flow, Proxy 2 (P2) non-recursively implements Call
Forward on Unavailable (CFUNV) to Carol@C. Proxy 1 (P1) is recursing.
+------------------------+
| Bob@P2: CFUNV->Carol@C |
+------+-----------------+
\
\
A P1 P2 B C
recursing non-recursing
| | | | |
|--INV Bob@P1->| | | |
|<-100---------| | | |
| |--INV Bob@P2->| | |
| |<-100---------| | |
| | |--INV Bob@B->| |
| | |--INV Bob@B->| |
| | |--INV Bob@B->| |
| | | ... | |
| | |--INV Bob@B->| |
| | timeout | |
| |<-302---------| | |
| | Contact: Carol@C | |
| | Diversion: Bob@P2 | |
| | ;reason=unavailable | |
| | | | |
| |--ACK-------->| | |
| | | | |
| |--INVITE Carol@C---------------------->|
| | Diversion: Bob@P2 | |
| | ;reason=unavailable | |
| | | | |
| |<-200----------------------------------|
| | | | |
|<-200---------| | | |
| | | | |
|--ACK------------------------------------------------>|
| | | | |
| | | | |
7.5. Multiple Diversions
Usage of the Diversion header when multiple diversions occur are
shown the following two examples.
Levy, et al. Expires November 2, 2009 [Page 23]
Internet-Draft Diversion header May 2009
7.5.1. Call Forward Unconditional and Call Forward Busy
In this message flow, Proxy 2 (P2) implements Call Forward
Unconditional (CFUNC) to Carol@C. C then implements Call Forward on
Busy (CFB) to 5551234@D. P2 is non-recursing. P1 is recursing. C is
non-recursing.
Levy, et al. Expires November 2, 2009 [Page 24]
Internet-Draft Diversion header May 2009
+------------------------+ +-------------------------+
| Bob@P2: CFUNC->Carol@C | | Carol@C: CFB->5551234@D |
+---------------+--------+ +--------+----------------+
\ \
\ \
A P1 P2 B C D
recursing non-recursing non-recursing
| | | | | |
|--INV Bob@P1->| | | | |
| | | | | |
| |--INV Bob@P2->| | | |
| | | | | |
| |<-302---------| | | |
| | Contact: Carol@C | | |
| | Diversion: Bob@P2 | | |
| | ;reason=unconditional | | |
| | | | | |
| |--ACK-------->| | | |
| | | | | |
| |--INVITE Carol@C---------------------->| |
| | Diversion: Bob@P2 | | |
| | ;reason=unconditional | | |
| | | | | |
| |<-302----------------------------------| |
| | Contact: 5551234@D | | |
| | Diversion: Carol@C | | |
| | ;reason=user-busy | | |
| | ;privacy="full" | | |
| | Diversion: Bob@P2 | | |
| | ;reason=unconditional | | |
| | | | | |
| |--ACK--------------------------------->| |
| | | | | |
| |--INVITE 5551234@D------------------------------->|
| | Diversion: Carol@C | | |
| | ;reason=user-busy | | |
| | ;privacy="full" | | |
| | Diversion: Bob@P2 | | |
| | ;reason=unconditional | | |
| | | | | |
| |<-200---------------------------------------------|
| | | | | |
|<-200---------| | | | |
| | | | | |
|--ACK----------------------------------------------------------->|
| | | | | |
| | | | | |
Levy, et al. Expires November 2, 2009 [Page 25]
Internet-Draft Diversion header May 2009
7.5.2. Call Forward Unconditional and Call Forward No Answer
In this message flow, Proxy 2 (P2) implements Call Forward
Unconditional (CFUNC) to Carol@C. (P2 would normally have routed the
call to B). C then implements Call Forward on No Answer (CFNA) to
5551234@D. P2 is recursing. C is recursing.
+------------------------+ +--------------------------+
| Bob@P2: CFUNC->Carol@C | | Carol@C: CFNA->5551234@D |
+------------------+-----+ +-----+--------------------+
\ \
\ \
A P1 P2 B C D
recursing recursing
| | | | | |
|--INV Bob@P1->| | | | |
| | | | | |
| |--INV Bob@P2->| | | |
| | | | | |
| | |--INV Carol@C->| |
| | | Diversion: Bob@P2 |
| | | ;reason=unconditional |
| | | | | |
| | |<--180---------| |
| | | | | |
| |<-180---------| | | |
| | | | | |
|<-180---------| | | | |
| | | | | |
| | | | | |
| | | | timeout |
| | | | |--INV 5551234@D->|
| | | | |Diversion: Carol@C
| | | | | ;reason=no-answer
| | | | | ;privacy="full"
| | | | |Diversion: Bob@P2
| | | | | ;reason= unconditional
| | | | | |
| | | | |<-200------------|
| | | | | | |
| | |<-200----------| | |
| | | | | | |
| |<-200---------| | | | |
| | | | | | |
|<-200---------| | | | | |
| | | | | | |
|--ACK--------------------------------------------------------->|
| | | | | | |
| | | | | | |
Levy, et al. Expires November 2, 2009 [Page 26]
Internet-Draft Diversion header May 2009
8. Security Considerations
There are some privacy considerations when using the Diversion
header.
Usage of the Diversion header implies that the diverting UAS trusts
the diverted-to UAS.
Usage of the Diversion header by SIP proxies or SIP user agents can
cause information leakage of route information and called information
to untrusted SIP proxies and untrusted callers in upstream 3xx's.
Leakage of this information can be mitigated by having a recursing
trusted upstream proxy server.
For a SIP network architecture where all proxies are required to be
non-recursive, Diversion header hiding may be considered necessary in
order to prevent leakage of route information to the caller. To
accomplish Diversion header hiding, a trusted upstream proxy would
add a Record-Route header and use a secret key to encrypt the
contents of the Diversion header in 3xx's which are forwarded
upstream. On receipt of re-INVITEs the proxy would decrypt the
contents of the Diversion header (using its secret key) and forward
the INVITE.
There is no currently defined interaction of the Diversion and Hide
headers.
Question: Should there be?
9. Further Examples
Only the relevant headers have been included in the following
examples. The contents of the SDPs has also been omitted.
9.1. Night Service/Automatic Call Distribution (ACD) using Diversion
header
In the following 2 message flows two separate companies,
WeSellPizza.com and WeSellFlowers.com, have contracted with a third
company, NightService.com to provide nighttime support for their
incoming voice calls.
In the first flow, Alice calls out for pizza. In the second flow,
Alice calls for roses. In both instances, the same night service
company (and receptionist, Carol) answers the call. However, because
the Diversion header is used, Carol is able to customize her greeting
to the caller.
+-------------------------------------+
| WeSellPizza@P2: CFTOD->nightserv@P3 |
+-------------+-----------------------+
\
\
UAC P1 P2 P3 UAS1
Levy, et al. Expires November 2, 2009 [Page 27]
Internet-Draft Diversion header May 2009
(WeSellPizza.com) (NightService.com)
(ACD)
| [1] | | | |
|-INV pizza@P1-->| | | |
| | | | |
| | | | |
| | [2] INVITE WeSellPizza@P2 | |
| |--------------->| | |
| | | | |
| | | [3] | |
| | |-INV nightserv@P3->| |
| | | Diversion: WeSellPizza@P2 |
| | | ;reason=time-of-day |
| | | | |
| | | | [4] |
| | | |-INV Carol@uas1----->|
| | | Diversion: WeSellPizza@P2 |
| | | ;reason=time-of-day |
| | | | |
| | | |<-[5] 200------------|
| | |<-[6] 200----------| |
| |<-[7] 200-------| | |
|<-[8] 200-------| | | |
| | | | |
|--[9] ACK----------------------------------------------------------------->|
| | | | |
|<============================================="Hello, WeSellPizza"=========|
| | | | |
| | | | |
Alice calls for pizza.
[1] SIP UAC to SIP proxy server 1:
INVITE sip:pizza@p1.isp.com SIP/2.0
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: sip:pizza@p1.isp.com
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
The ISP's originating proxy translated the keyword pizza to the
company WeSellPizza.com
[2] SIP proxy server 1 to SIP proxy server 2 (WeSellPizza.com):
INVITE sip:WeSellPizza@p2.isp.com SIP/2.0
Levy, et al. Expires November 2, 2009 [Page 28]
Internet-Draft Diversion header May 2009
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: sip:pizza@p1.isp.com
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
It's after midnight and the pizza people are in bed. Fortunately,
WeSellPizza.com has contracted with NightService.com to answer
their nighttime calls. Thus, P2 implements CFTOD to
to NightService.com.
[3] SIP proxy server 2 (WeSellPizza.com) to
SIP proxy server 3 (NightService.com):
INVITE sip:NightService@p3.isp.com SIP/2.0
Via: SIP/2.0/UDP p2.isp.com
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: sip:pizza@p1.isp.com
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Diversion: <sip:WeSellPizza@p2.isp.com>
;reason=time-of-day
Content-Type: application/sdp
Carol is available to receive the incoming call.
[4] SIP proxy server 3 (NightService.com) to UAS1 (Carol):
INVITE sip:carol@uas1.nightservice.com SIP/2.0
Via: SIP/2.0/UDP p3.isp.com
Via: SIP/2.0/UDP p2.isp.com
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: sip:pizza@p1.isp.com
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Diversion: <sip:WeSellPizza@p2.isp.com>
;reason=time-of-day
Content-Type: application/sdp
The ACD keys off the Diversion header to pull up the WeSellPizza FAQ
on Carol's web browser.
Levy, et al. Expires November 2, 2009 [Page 29]
Internet-Draft Diversion header May 2009
[5] UAS1 to SIP proxy server 3:
SIP/2.0 200 OK
Via: SIP/2.0/UDP p3.isp.com
Via: SIP/2.0/UDP p2.isp.com
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
Contact: carol@uas1.nightservice.com
From: sip:alice@isp.com
To: <sip:pizza@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
[6] SIP proxy server 3 to SIP proxy server 2:
SIP/2.0 200 OK
Via: SIP/2.0/UDP p2.isp.com
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
Contact: carol@uas1.nightservice.com
From: sip:alice@isp.com
To: <sip:pizza@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
[7] SIP proxy server 2 to SIP proxy server 1:
SIP/2.0 200 OK
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
Contact: carol@uas1.nightservice.com
From: sip:alice@isp.com
To: <sip:pizza@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
[8] SIP proxy server 1 to UAC
SIP/2.0 200 OK
Via: SIP/2.0/UDP alice-pc.isp.com
Contact: carol@uas1.nightservice.com
From: sip:alice@isp.com
To: <sip:pizza@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Levy, et al. Expires November 2, 2009 [Page 30]
Internet-Draft Diversion header May 2009
Content-Type: application/sdp
[9] SIP UAC to UAS1:
ACK sip:uas1.nightservice.com SIP/2.0
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: <sip:pizza@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
The RTP flows begin and Carol answers "Hello, WeSellPizza.
How may I help you?"
+---------------------------------------+
| WeSellFlowers@P4: CFTOD->nightserv@P3 |
+-------------+-------------------------+
\
\
UAC P1 P4 P3 UAS1
(WeSellFlowers.com) (NightService.com)
(ACD)
| [1] | | | |
|-INV roses@P1->| | | |
| | | | |
| | [2] INVITE WeSellFlowers@P4 | |
| |--------------->| | |
| | | | |
| | [3] | | |
| |<-302-----------| | |
| | Contact: nightservice@P3 | |
| | Diversion: WeSellFlowers@P4 | |
| | ;reason=time-of-day | |
| | | | |
| |--[4] ACK------>| | |
| | | | |
| | [5] | | |
| |-INVITE nightservice@P3------------>| |
| | Diversion: WeSellFlowers@P4 | |
| | ;reason=time-of-day | |
| | | | |
| | | | [6] |
| | | -INV Carol@uas1----->|
| | | Diversion: WeSellFlowers@P4
| | | ;reason=time-of-day
| | | |
| | | |<-[7] 200------------|
| |<-[8] 200---------------------------| |
|<-[9] 200------| | | |
Levy, et al. Expires November 2, 2009 [Page 31]
Internet-Draft Diversion header May 2009
| | | | |
|--[10] ACK---------------------------------------------------------->|
| | | | |
|<======================================="Hello, WeSellFlowers"=======|
| | | | |
| | | | |
Alice calls for roses.
[1] SIP UAC to SIP proxy server 1:
INVITE sip:roses@p1.isp.com SIP/2.0
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: sip:roses@p1.isp.com
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
The ISP's originating proxy translated the keyword roses to the
company WeSellFlowers.com
[2] SIP proxy server 1 to SIP proxy server 4 (WeSellFlowers.com):
INVITE sip:WeSellFlowers@p4.isp.com SIP/2.0
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: sip:roses@p1.isp.com
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
It's now 1am and the florists are also in bed. Fortunately,
WeSellFlowers.com has contracted with NightService.com to answer
their nighttime calls, too. Thus, P4 implements CFTOD to
to NightService.com.
[3] SIP proxy server 4 (WeSellFlowers.com) to
SIP proxy server 1 (NightService.com):
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
Contact: NightService@p3.isp.com
From: sip:alice@isp.com
To: <sip:roses@p1.isp.com>;tag=p4
Call-ID: 12345600@alice-pc.isp.com
Levy, et al. Expires November 2, 2009 [Page 32]
Internet-Draft Diversion header May 2009
CSeq: 1 INVITE
Diversion: <sip:WeSellFlowers@p4.isp.com>
;reason=time-of-day
[4] SIP proxy server 1 to SIP proxy server 4 (WeSellFlowers.com):
ACK sip:uas1.nightservice.com SIP/2.0
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: <sip:roses@p1.isp.com>;tag=p4
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
[5] SIP proxy server 1 (WeSellFlowers.com) to
SIP proxy server 3 (NightService.com):
INVITE sip:NightService@p3.isp.com SIP/2.0
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: sip:roses@p1.isp.com
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Diversion: <sip:WeSellFlowers@p4.isp.com>
;reason=time-of-day
Content-Type: application/sdp
Carol is available to receive the incoming call.
[6] SIP proxy server 3 (NightService.com) to UAS1 (Carol):
INVITE sip:carol@uas1.nightservice.com SIP/2.0
Via: SIP/2.0/UDP p3.isp.com
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: sip:roses@p1.isp.com
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Diversion: <sip:WeSellFlowers@p4.isp.com>
;reason=time-of-day
Content-Type: application/sdp
The ACD keys off the Diversion header to pull up
the WeSellFlowers FAQ on Carol's web browser.
[7] SIP UAS1 to SIP proxy server 3:
SIP/2.0 200 OK
Levy, et al. Expires November 2, 2009 [Page 33]
Internet-Draft Diversion header May 2009
Via: SIP/2.0/UDP p3.isp.com
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
Contact: carol@uas1.nightservice.com
From: sip:alice@isp.com
To: <sip:roses@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
[8] SIP proxy server 3 to SIP proxy server 1:
SIP/2.0 200 OK
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
Contact: carol@uas1.nightservice.com
From: sip:alice@isp.com
To: <sip:roses@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
[9] SIP proxy server 1 to UAC
SIP/2.0 200 OK
Via: SIP/2.0/UDP alice-pc.isp.com
Contact: carol@uas1.nightservice.com
From: sip:alice@isp.com
To: <sip:roses@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
[10] SIP UAC to SIP UAS1:
ACK sip:uas1.nightservice.com SIP/2.0
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: <sip:roses@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
The RTP flows begin and Carol answers "Hello, WeSellFlowers.
How may I help you?"
Levy, et al. Expires November 2, 2009 [Page 34]
Internet-Draft Diversion header May 2009
9.2. Voicemail Service using Diversion header
Bob has contracted his Voicemail to a third-party company,
Voicemail.com. In this message flow, Bob has hit the Do-Not-Disturb
button on his phone. The Do-Not-Disturb functionality of Bob's phone
is configured to CFUNC (Call Forward Unconditional) to
voicemail@isp.com. Because the Diversion header is used,
Voicemail.com is able to place the incoming call into Bob's voice
mailbox.
+---------------------------------------------+
| Bob@UAS1: CFDoNotDisturb->voicemail@isp.com |
+--------------------------------------+------+
\
\
UAC1 P1 P2 UAS1 UAS2
(Voicemail.com)
| | | | |
|--[1] INV Bob@P1->| | | |
| | | | |
| |--[2] INV Bob@P2->| | |
| | | | |
| | [3] INV Bob@uas1->| |
| | | | |
| | [4] <- 302-------| |
| | Contact: voicemail@isp.com |
| | Diversion: Bob@uas1 |
| | ;reason=do-not-disturb |
| | | | |
| | |[5] ACK------>| |
| | | | |
| |<-[6] 302---------| | |
| | Contact: voicemail@isp.com | |
| | Diversion: Bob@uas1 | |
| | ;reason=do-not-disturb | |
| | | | |
| |--[7] ACK-------->| | |
|<-[8] 302---------| | | |
| Contact: voicemail@isp.com | | |
| Diversion: Bob@uas1 | | |
| ;reason=do-not-disturb | | |
| | | | |
|--[9] ACK-------->| | | |
| | | | |
|--[10] INVITE voicemail@isp.com------------------------------->|
| Diversion: Bob@uas1 | | |
| ;reason=do-not-disturb | | |
| | | | |
|<--[11] 200----------------------------------------------------|
Levy, et al. Expires November 2, 2009 [Page 35]
Internet-Draft Diversion header May 2009
| | | | |
|---[12] ACK--------------------------------------------------->|
| | | | |
| | | | |
Alice calls Bob.
[1] SIP UAC to SIP proxy server 1:
INVITE sip:Bob@p1.isp.com SIP/2.0
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: sip:Bob@p1.isp.com
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
The ISP's originating proxy routes the request to proxy 2 (P2)
[2] SIP proxy server 1 to SIP proxy server 2:
INVITE sip:Bob@p2.isp.com SIP/2.0
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: sip:Bob@p1.isp.com
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
[3] SIP proxy server 2 to UAS1 (Bob's SIP phone):
INVITE sip:Bob@uas1.isp.com SIP/2.0
Via: SIP/2.0/UDP p2.isp.com
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: sip:Bob@p1.isp.com
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
Since Bob had hit the Do-Not-Disturb button on his SIP phone,
Bob's phone forwards the call to his voicemail service.
[4] User agent server 1 (UAS1) to SIP proxy server 2 (P2)
SIP/2.0 302 Moved Temporarily
Levy, et al. Expires November 2, 2009 [Page 36]
Internet-Draft Diversion header May 2009
Via: SIP/2.0/UDP p2.isp.com
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
Contact: Voicemail@isp.com
From: sip:alice@isp.com
To: <sip:Bob@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Diversion: <sip:Bob@uas1.isp.com>
;reason=do-not-disturb
[5] SIP proxy server 2 to UAS1 (Bob's SIP phone):
ACK sip:Bob@uas1.isp.com SIP/2.0
Via: SIP/2.0/UDP p2.isp.com
From: sip:alice@isp.com
To: <sip:Bob@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
[6] SIP proxy server 2 (P2) to SIP proxy server 1 (P1):
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP p1.isp.com
Via: SIP/2.0/UDP alice-pc.isp.com
Contact: Voicemail@isp.com
From: sip:alice@isp.com
To: <sip:Bob@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Diversion: <sip:Bob@uas1.isp.com>
;reason=do-not-disturb
[7] SIP proxy server 1 to SIP proxy server 2:
ACK sip:Bob@p2.isp.com SIP/2.0
Via: SIP/2.0/UDP p1.isp.com
From: sip:alice@isp.com
To: <sip:Bob@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
[8] SIP proxy server 1 (P1) to UAC (alice-pc):
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP alice-pc.isp.com
Contact: Voicemail@isp.com
From: sip:alice@isp.com
To: <sip:Bob@p1.isp.com>;tag=uas1
Levy, et al. Expires November 2, 2009 [Page 37]
Internet-Draft Diversion header May 2009
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Diversion: <sip:Bob@uas1.isp.com>
;reason=do-not-disturb
[9] SIP UAC to SIP proxy server 1:
ACK sip:Bob@p1.isp.com SIP/2.0
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: <sip:Bob@p1.isp.com>;tag=uas1
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
[10] SIP UAC (alice-pc) to Voicemail server.
INVITE sip:Voicemail@isp.com SIP/2.0
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: sip:Bob@p1.isp.com
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Diversion: <sip:Bob@uas1.isp.com>
;reason=do-not-disturb
Content-Type: application/sdp
[11] Voicemail server to SIP UAC (alice-pc):
SIP/2.0 200 OK
Via: SIP/2.0/UDP alice-pc.isp.com
Contact: Voicemail@isp.com
From: sip:alice@isp.com
To: <sip:Bob@p1.isp.com>;tag=uas2
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Content-Type: application/sdp
[12] SIP UAC to Voicemail server:
ACK sip:Voicemail@isp.com SIP/2.0
Via: SIP/2.0/UDP alice-pc.isp.com
From: sip:alice@isp.com
To: <sip:Bob@p1.isp.com>;tag=uas2
Call-ID: 12345600@alice-pc.isp.com
CSeq: 1 INVITE
Because the Diversion header is present, the Voicemail
server is able to place Alice's message into Bob's voice
Levy, et al. Expires November 2, 2009 [Page 38]
Internet-Draft Diversion header May 2009
mailbox.
9.3. Q&A on alternative approaches
Question 1:
Why do we need the Diversion header when we can see the To: header?
Answer:
a) The To: header is not guaranteed to have significance to the
called party.
For example, the To: header may contain a locally significant URL (to
the caller) such as a private numbering plan, speed dial digits,
telephony escape digits, or telephony prefix digits.
Without a Diversion header, enumerating all possible locally
significant To: headers that anyone might use to contact
Bob@uas1.isp.com becomes a configuration problem at Voicemail@isp.com
and is prone to namespace collision.
Support for Diversion headers enables Bob to contract a third-party
service (Voicemail@isp.com) with a single globally significant URL
for his voice mailbox (Bob@uas1.isp.com).
b) Given a set of multiple diversions, there is a policy decision of
which Diversion header takes precedence for service logic. Different
services (or even different users for the same service) may want to
configure this policy differently (first, last,second to last, etc).
Question 2:
Why do we need the Diversion header when we can see the Via: header?
Answer:
The Via header does not contain information about servers whom have
deflected the call (using a 3xx).
10. Mapping ISUP/ISDN Redirection information to SIP Diversion header
The discussions below regarding ISUP/ISDN reflect generic elements in
ISUP/ISDN. In some variations of ISUP/ISDN, the information elements
are represented differently. Regardless of the ISUP/ISDN variant,
translation should be performed for the "first redirecting number"
and the "last redirecting number".
In order to prevent ambiguity, it is important to highlight a
terminology mismatch between ISUP/ISDN and SIP. In SIP, a "redirect"
indicates the act of returning a 3xx response. In ISUP/ISDN a
"redirection" is diversion of a call by a network entity. In ISUP/
ISDN a call may also be deflected (by an endpoint). Diversion is the
more generic term which refers to either the act of an network
redirection or endpoint deflection.
Levy, et al. Expires November 2, 2009 [Page 39]
Internet-Draft Diversion header May 2009
In SIP, Diversion can be implemented as either an upstream 3xx (non-
recursive) or an additionally forked downstream request (recursive).
In the following text, a lower-case "redirect" indicates the SIP
usage, while an uppercase "Redirect" indicates ISUP usage.
10.1. Mapping ISUP/ISDN Diversion Reason codes
ISUP and ISDN define the following diversion reasons:
0000 = Unknown
0001 = Call forwarding busy or called DTE busy
0010 = Call forwarding no reply
1111 = Call forwarding unconditional or systematic call redirection
1010 = Call deflection or call forwarding by the called DTE
1001 = Call forwarding DTE out of order
Mapping of ISUP/ISDN reason codes to Diversion reason codes is
performed as follows:
ISUP/ISDN reason code Diversion reason code
0001 "user-busy"
0010 "no-answer"
1111 "unconditional"
1010 "deflection"
1001 "unavailable"
0000 all others
10.2. Mapping ISUP Redirection information to SIP Diversion header
This section describes how generic ISUP diversion information
elements may be translated across an ISUP/SIP gateway.
Levy, et al. Expires November 2, 2009 [Page 40]
Internet-Draft Diversion header May 2009
10.2.1. ISUP Definitions
Called party number The number of the party to which the
call is currently being routed.
Redirecting number The number to which the call was
being routed when the last diversion
occurred.
Redirecting reason The reason that the last diversion
occurred.
Original called number The number to which the call was
being routed when the first
diversion occurred.
Original redirecting reason The reason that the first diversion
occurred.
Redirection counter The count of the total number of
diversions that have occurred.
Address Presentation Indication of whether presentation
is allowed or restricted.
10.2.2. ISUP parameters
When a SIP call transits a SIP/ISUP gateway, the following
information in the ISUP message should be examined/set when
translating SIP Diversion headers to ISUP diversion information:
1) Redirecting Number
2) Redirecting reason
3) Redirecting address presentation
4) Original called number
5) Original redirecting reason
6) Original address presentation
7) Redirection counter.
An ISUP message contains information on the first and last diversions
that occurred. The Redirection Number is to which the call was being
routed when the last diversion occurred. The Redirecting Reason is
the reason that the last diversion occurred.
The Original Called Number is the number to which the call was being
routed when the first diversion occurred. The Original Redirecting
Reason is the reason that the first diversion occurred.
When only one Diversion has occurred, the number to which the call
was being routed when the diversion occurred is in the Redirecting
Levy, et al. Expires November 2, 2009 [Page 41]
Internet-Draft Diversion header May 2009
Number and the reason for that diversion is carried in the Redirect
Reason.
10.2.3. ISUP to SIP translation
The ISUP Redirecting Number SHOULD be used to set the value of the
name-addr of the top-most Diversion header. The ISUP Redirecting
Number address presentation SHOULD be used to set the value of the
diversion-privacy of the top-most Diversion header. The ISUP
Redirecting Reason SHOULD be used to set the value of the diversion-
reason of the top-most Diversion header. When present, the Original
Called Number SHOULD be used to set the name-addr of the bottom-most
Diversion header. When present, the Original Redirecting Reason
SHOULD be used to set the diversion-reason of the bottom-most
Diversion header.When present, the Original address presentation
SHOULD be used to set the diversion-privacy of the bottom-most
Diversion header.
The Redirect Counter value minus 1 SHOULD be stored in the diversion-
counter associated with the top-most Diversion header. Presence of
the diversion-counter for the bottom-most Diversion header is
optional. If present the diversion-counter of the bottom-most
Diversion header SHOULD be 1.
10.2.4. SIP to ISUP translation
The name-addr of the top-most Diversion header SHOULD be used to set
the ISUP Redirecting Number. The diversion-reason of the top-most
Diversion header SHOULD be used to set the ISUP Redirecting
Reason.The diversion-privacy of the top-most Diversion header SHOULD
be used to set the ISUP Redirecting Address Presentation. When
multiple Diversion headers are present, the name-addr of the bottom-
most Diversion header SHOULD be used to set the ISUP Original
Redirecting Number.
When multiple Diversion headers are present, the diversion-reason of
the bottom-most Diversion header SHOULD be used to set the ISUP
Original Redirecting Reason. When multiple Diversion headers are
present, the diversion-privacy of the bottom-most Diversion header
SHOULD be used to set the ISUP Original Redirecting Address
Presentation.
The ISUP Redirection counter SHOULD be set equal to the sum of the
counters of all Diversion headers in the SIP message. A Diversion
header which does not explicitly specify a diversion-counter tag
counts as 1.
10.2.5. Example of ISUP to SIP translation
Levy, et al. Expires November 2, 2009 [Page 42]
Internet-Draft Diversion header May 2009
ISUP/SIP GW
|
--IAM--------------------------------->|
Called Party Number =+19195551004 |
Redirecting Number =+19195551002 |
Address Presentation =presentation restricted
Original Called Number =+19195551001 |
RedirectionInformation: |
Original redirecting reason = Unconditional (1111)
Redirecting Reason = User busy (0001)
Redirection counter = 5 |
|
|--INVITE +19195551004------>
| Diversion: <tel:+19195551002>
| ;reason=user-busy
| ;privacy="full"
| ;counter=4
| Diversion: <tel:+19195551001>
| ;reason=unconditional
| ;counter=1
|
|
10.2.6. Example of SIP to ISUP translation
ISUP/SIP GW
|
|<--INVITE +19195551004------
| Diversion: <tel:+19195551002>
| ;reason=user-busy
| ;privacy="full"
| ;counter=4
| Diversion: <tel:+19195551001>
| ;reason=unconditional
| ;counter=1
|
|
|
<--IAM---------------------------------|
Called Party Number =+19195551004 |
Redirecting Number =+19195551002 |
Address Presentation =presentation restricted
Original Called Number =+19195551001 |
RedirectionInformation: |
Original redirecting reason = Unconditional (1111)
Redirecting Reason = User busy (0001)
Redirection counter = 5 |
Levy, et al. Expires November 2, 2009 [Page 43]
Internet-Draft Diversion header May 2009
10.3. Mapping ISDN Redirection information to SIP Diversion header
An ISDN message can contain up to two instances of a Redirecting
number information element. When a diversion occurs, an additional
Redirection number information element is added. When a third (or
greater) diversion occurs, the new Redirecting number information
element replaces the bottom-most Redirection number information
element.
10.3.1. ISDN Definitions
Called party number The number of the party to which the
call is currently being routed.
Redirecting number
information element Aggregate information element
which contains Redirecting number
and Reason for diversion.
Redirecting number The number to which the call was
being routed when the last diversion
occurred.
Reason for diversion The reason that the last diversion
occurred.
Origin of Number Indicates whether number is user
provided and screened or network
provided
Presentation Status Indicates if presentation is
allowed or prohibited
10.3.2. ISDN parameters
When a SIP call transits a SIP/ISDN gateway, the following
information in the ISDN message should be examined/set when
translating SIP Diversion headers to ISDN diversion information:
Levy, et al. Expires November 2, 2009 [Page 44]
Internet-Draft Diversion header May 2009
1) Redirecting number of the top-most Redirecting number
information element
2) Reason for diversion of the top-most Redirection number
information element
3) Origin of Number and Presentation Status of the top-most
Redirection number information element
4) Redirection number of the bottom-most Redirection number
information element
5) Reason for diversion of the bottom-most Redirection number
information element.
6) Origin of Number and Presentation Status of the bottom-most
Redirection number information element
An ISDN message contains information on the first and last diversions
that occurred. The top-most Redirection number information element
contains information (including the Redirecting number, Origin of
Number, Presentation Status, and Reason for diversion) about the last
diversion that occurred. The bottom-most Redirection number
information element contains information (including the Redirecting
number, Origin of Number, Presentation Status,and Reason for
diversion) about the first diversion that occurred.
If only one Diversion has occurred, only one Redirection number
information element is present.
The Redirecting Number information element has the same Type of
Number/Numbering Plan, and Digits as the Calling Party Number
information element.
There is no Redirection counter associated with this ISDN information
element.
Notice that the order of the Redirection number information elements
in an ISDN message (top=first, bottom=last) is reversed from the
order of Diversion headers in a SIP message (top=last, bottom=first).
10.3.3. ISDN to SIP translation
The Redirecting number of the top-most ISDN Redirecting number
information element SHOULD be used to set the value of the name-addr
of the bottom-most Diversion header. The Reason for Diversion of the
top-most ISDN Redirecting number information element SHOULD be used
to set the value of the diversion-reason of the bottom-most Diversion
header.
The Origin of Number of the top-most ISDN Redirecting number
information element SHOULD be used to set the value of the diversion-
screen of the bottom-most Diversion header. The Presentation Status
of the top-most ISDN Redirecting number information element SHOULD be
used to set the value of the diversion-privacy of the bottom-most
Diversion header.
The Redirecting number of the bottom-most ISDN Redirecting number
information element SHOULD be used to set the value of the name-addr
Levy, et al. Expires November 2, 2009 [Page 45]
Internet-Draft Diversion header May 2009
of the top-most Diversion header. The Reason for Diversion of the
bottom-most ISDN Redirecting number information element SHOULD be
used to set the value of the diversion-reason of the top-most
Diversion header.
The Origin of Number of the bottom-most ISDN Redirecting number
information element SHOULD be used to set the value of the diversion-
screen of the top-most Diversion header. The Presentation Status of
the bottom-most ISDN Redirecting number information element SHOULD be
used to set the value of the diversion-privacy of the top-most
Diversion header.
Presence of the diversion-counter in each of the Diversion headers is
optional. If present, the diversion-counter of each Diversion header
SHOULD be 1.
10.3.4. SIP to ISDN translation
The name-addr of the top-most Diversion header SHOULD be used to set
the Redirecting number of the bottom-most ISDN Redirecting number
information element.
The diversion-reason of the top-most Diversion header SHOULD be used
to set the Reason for Diversion of the bottom-most ISDN Redirecting
number information element.
The diversion-screen of the top-most Diversion header SHOULD be used
to set the Origin of Number of the bottom-most ISDN Redirecting
number information element.
The diversion-privacy of the top-most Diversion header SHOULD be used
to set the Presentation Status of the bottom-most ISDN Redirecting
number information element.
The name-addr of the bottom-most Diversion header SHOULD be used to
set the Redirecting number of the top-most ISDN Redirecting number
information element.
The diversion-reason of the bottom-most Diversion header SHOULD be
used to set the Reason for Diversion of the top-most ISDN Redirecting
number information element.
The diversion-screen of the bottom-most Diversion header SHOULD be
used to set the Origin of Number of the top-most ISDN Redirecting
number information element.
The diversion-privacy of the bottom-most Diversion header SHOULD be
used to set the Presentation Status of the top-most ISDN Redirecting
number information element.
10.3.5. Example of ISDN to SIP translation
Levy, et al. Expires November 2, 2009 [Page 46]
Internet-Draft Diversion header May 2009
ISDN/SIP GW
|
--Setup------------------------------->|
Called party number =+19195551004
Redirecting number information element:
Redirecting number =+19195551001
Reason for redirection = Unconditional (1111)
Origin of Number = passed network screening
Presentation Status = presentation allowed
Redirecting number information element:
Redirecting number =+19195551002
Reason for redirection = User busy (0001)
Origin of Number = passed network screening
Presentation Status = presentation prohibited
|
|--INVITE tel:+19195551004---->
| Diversion: <tel:+19195551002>
| ;reason=user-busy
| ;screen="yes"
| ;privacy="off"
| Diversion: <tel:+19195551001>
| ;reason=unconditional
| ;screen="yes"
| ;privacy="full"
|
|
10.3.6. Example of SIP to ISDN translation
Levy, et al. Expires November 2, 2009 [Page 47]
Internet-Draft Diversion header May 2009
ISDN/SIP GW
|
<--Setup-------------------------------|
Called party number =+19195551004
Redirecting number information element:
Redirecting number =+19195551001
Reason for redirection = Unconditional (1111)
Origin of Number = passed network screening
Presentation Status = presentation allowed
Redirecting number information element:
Redirecting number =+19195551002
Reason for redirection = User busy (0001)
Origin of Number = passed network screening
Presentation Status = presentation prhibited
|
|<--INVITE tel:+19195551004----
| Diversion: <tel:+19195551002>
| ;reason=user-busy
| ;screen="yes"
| ;privacy="off
| Diversion: <tel:+19195551001>
| ;reason=unconditional
| ;screen="yes"
| ;privacy="full"
|
10.4. Information loss in SIP to ISUP/ISDN translation
Because ISUP and ISDN only support a subset of the information in a
SIP Diversion header, information loss occurs during translation at a
SIP/ISUP or SIP/ISDN boundary.
10.4.1. Loss of diversion URI information
Because ISUP and ISDN only support a subset of URI types,
(specifically tel: URIs and sip:x@y;user=phone URIs) Diversion
information occurring for other URI types may be lost when crossing
from SIP to ISDN or ISUP.
10.4.2. Loss of diversion reason information
Because ISUP and ISDN only support a subset of the reason codes
supported by the Diversion header, specific reason code information
may be lost when crossing from SIP to ISDN or ISUP.
Levy, et al. Expires November 2, 2009 [Page 48]
Internet-Draft Diversion header May 2009
10.4.3. Loss of diversion counter information
Because ISDN does not support a counter field (indicating the number
of diversions that have occurred), counter information may be lost
when crossing from SIP to ISDN.
11. IANA Considerations
This document requires an IANA registration. This document defines a
new SIP header field name: Diversion.
Header Name Compact Form Reference
----------- ------------ ---------
Diversion none [RFCXXXX]
Note to RFC Editor: Please replace RFC XXXX with the RFC number of
this specification.
12. Acknowlegements
We would like to thank David Williams, Ameet Kher, Satya Khatter,
Manoj Bhatia, Shail Bhatnagar, Denise Caballero-Mccann, Kara Adams,
and Charles Eckel of Cisco Systems and Bert Culpepper of InterVoice-
Brite for their insights, inputs, and comments.
13. Normative References
[RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[RFC3261] "SIP: Session Initiation Protocol", RFC 3261, June 2002.
Authors' Addresses
Steve Levy
Cisco Systems
7025 Kit Creek Road P.O. Box 14987 Research Triangle Park,
NC 27709
USA
Email: stlevy@cisco.com
Levy, et al. Expires November 2, 2009 [Page 49]
Internet-Draft Diversion header May 2009
J. R. Yang
Cisco Systems
7025 Kit Creek Road P.O. Box 14987 Research Triangle Park,
NC 27709
USA
Email: jryang@cisco.com
Bryan J. Byerly
Levy, et al. Expires November 2, 2009 [Page 50]