summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5806.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5806.txt')
-rw-r--r--doc/rfc/rfc5806.txt2971
1 files changed, 2971 insertions, 0 deletions
diff --git a/doc/rfc/rfc5806.txt b/doc/rfc/rfc5806.txt
new file mode 100644
index 0000000..d2f43e8
--- /dev/null
+++ b/doc/rfc/rfc5806.txt
@@ -0,0 +1,2971 @@
+
+
+
+
+
+
+Independent Submission S. Levy
+Request for Comments: 5806 Cisco Systems
+Category: Historic M. Mohali, Ed.
+ISSN: 2070-1721 Orange Labs
+ March 2010
+
+
+ Diversion Indication in SIP
+
+Abstract
+
+ This RFC, which contains the text of an Internet Draft that was
+ submitted originally to the SIP Working Group, is being published now
+ for the historical record and to provide a reference for later
+ Informational RFCs. The original Abstract follows.
+
+ 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 that
+ receive diversion information may use this as supplemental
+ information for feature invocation decisions.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for the historical record.
+
+ This document defines a Historic Document for the Internet community.
+ This is a contribution to the RFC Series, independently of any other
+ RFC stream. The RFC Editor has chosen to publish this document at
+ its discretion and makes no statement about its value for
+ implementation or deployment. Documents approved for publication by
+ the RFC Editor are not a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5806.
+
+
+
+
+
+
+Levy & Mohali Historic [Page 1]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+IESG Note
+
+ This document contains an early proposal to the IETF SIP Working
+ Group that was not chosen for standardization. Discussions on the
+ topic resulted in the informational RFC 3325, "Private Extensions to
+ the Session Initiation Protocol (SIP) for Asserted Identity within
+ Trusted Networks", and the standard solution that was chosen can be
+ found in RFC 4244, "An Extension to the Session Initiation Protocol
+ (SIP) for Request History Information".
+
+Copyright Notice
+
+ Copyright (c) 2010 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
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 2]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 2. Terminology .....................................................4
+ 2.1. Requirements Language ......................................4
+ 2.2. Definitions ................................................4
+ 2.3. Abbreviations ..............................................5
+ 3. Overview ........................................................5
+ 3.1. When Is the Diversion Header Used? .........................6
+ 4. Extension Syntax ................................................6
+ 5. Detailed Semantics ..............................................7
+ 5.1. UAS Behavior ...............................................7
+ 5.2. UAC Behavior ...............................................7
+ 5.3. Redirect Server Behavior ...................................7
+ 5.4. Proxy Server Behavior ......................................7
+ 6. Examples Using Diversion Header .................................8
+ 6.1. Call Forward Unconditional .................................8
+ 6.2. Call Forward on Busy ......................................13
+ 6.3. Call Forward on No-Answer .................................17
+ 6.4. Call Forward on Unavailable ...............................21
+ 6.5. Multiple Diversions .......................................24
+ 7. Security Considerations ........................................27
+ 8. Further Examples ...............................................27
+ 8.1. Night Service/Automatic Call Distribution (ACD)
+ Using Diversion Header ....................................27
+ 8.2. Voicemail Service Using Diversion Header ..................36
+ 8.3. Questions and Answers on Alternative Approaches ...........41
+ 9. Mapping ISUP/ISDN Redirection Information to SIP
+ Diversion Header ...............................................42
+ 9.1. Mapping ISUP/ISDN Diversion Reason Codes ..................42
+ 9.2. Mapping ISUP Redirection Information to SIP
+ Diversion Header ..........................................43
+ 9.3. Mapping ISDN Redirection Information to SIP
+ Diversion Header ..........................................47
+ 9.4. Information Loss in SIP to ISUP/ISDN Translation ..........52
+ 10. Contributors ..................................................53
+ 11. Acknowledgements ..............................................53
+ 12. Normative References ..........................................53
+
+
+
+
+
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 3]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+1. Introduction
+
+ This RFC, which contains the text of an Internet Draft that was
+ submitted originally to the SIP Working Group, is being published now
+ for the historical record and to provide a reference for later
+ Informational RFCs.
+
+ In the legacy telephony network, redirection information is passed
+ through the network in ISDN/ISUP (ISDN User Part) 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.
+
+2. Terminology
+
+2.1. 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].
+
+2.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 that diverted the call.
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 4]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+ recursing:
+
+ A SIP proxy or user agent that handles a received or internally
+ generated 3xx response by forking new request(s) itself.
+
+ non-recursing:
+
+ A SIP proxy or user agent that handles a received or internally
+ generated 3xx response by forwarding it upstream.
+
+2.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
+
+3. 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.
+
+
+
+
+
+
+Levy & Mohali Historic [Page 5]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+3.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 that
+ 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.
+
+4. Extension Syntax
+
+ The syntax of the Diversion header is:
+
+ 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)]
+
+
+
+
+Levy & Mohali Historic [Page 6]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+ 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 - -
+
+5. Detailed Semantics
+
+5.1. UAS Behavior
+
+ A SIP User Agent Service (UAS) that receives a request and returns a
+ 3xx SHOULD add a Diversion header containing the previous Request-URI
+ and the reason for the diversion.
+
+5.2. UAC Behavior
+
+ A SIP UAC that receives a 3xx containing a Diversion header SHOULD
+ copy the Diversion header into each downstream forked request that
+ resulted from the 3xx.
+
+5.3. Redirect Server Behavior
+
+ A SIP redirect server that receives a request and returns a 3xx
+ containing a Contact that 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.
+
+5.4. Proxy Server Behavior
+
+ A non-recursing SIP proxy that receives a 3xx containing a Diversion
+ header SHOULD forward the 3xx containing the Diversion header
+ upstream unchanged.
+
+ A SIP proxy that receives a request and invokes a feature that
+ 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 that receives a request and returns a 3xx containing a
+ Contact that 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 & Mohali Historic [Page 7]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+5.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.
+ }
+ }
+ }
+
+6. 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 that generates or forwards 3xxs upstream is
+ non-recursing. A SIP proxy or user agent that handles received (or
+ internally generated) 3xxs itself is recursing.
+
+ The following examples illustrate usage of the Diversion header for
+ some of the variants of recursing and non-recursing proxies and user
+ agents.
+
+6.1. Call Forward Unconditional
+
+ Usage of the Diversion header is shown below for several variant
+ implementations of Call Forward Unconditional.
+
+6.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.
+
+
+
+Levy & Mohali Historic [Page 8]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+ +------------------------+
+ | 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------------------------------------------------>|
+| | | | |
+| | | | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 9]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+6.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.
+
+ +------------------------+
+ | 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------------------------------------------------>|
+| | | | |
+| | | | |
+
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 10]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+6.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.
+
+ +------------------------+
+ | 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------------------------------------------------>|
+| | | | |
+| | | | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 11]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+6.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.
+
+ +-----------------------+
+ | 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-------------------------------------------------->|
+| | | | |
+| | | | |
+
+
+
+
+
+
+Levy & Mohali Historic [Page 12]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+6.2. Call Forward on Busy
+
+ Usage of the Diversion header is shown below for several variant
+ implementations of Call Forward on Busy.
+
+6.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.
+
+ +----------------------+
+ | 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------------------------------------------------>|
+| | | | |
+| | | | |
+
+
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 13]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+6.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.
+
+ +----------------------+
+ | 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------------------------------------------------>|
+| | | | |
+| | | | |
+
+
+
+
+Levy & Mohali Historic [Page 14]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+6.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.
+
+ +----------------------+
+ | 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------------------------------------------------>|
+| | | | |
+| | | | |
+
+
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 15]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+6.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.
+
+ +---------------------+
+ | 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------------------------------------------------>|
+| | | | |
+| | | | |
+
+
+
+
+
+
+Levy & Mohali Historic [Page 16]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+6.3. Call Forward on No-Answer
+
+ Usage of the Diversion header is shown below for several variant
+ implementations of Call Forward on No-Answer.
+
+6.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------------------------------------------------>|
+| | | | |
+| | | | |
+
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 17]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+6.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.
+
+ +-----------------------+
+ | 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------------------------------------------------>|
+| | | | |
+
+
+
+Levy & Mohali Historic [Page 18]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+6.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.
+
+ +-----------------------+
+ | 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------------------------------------------------>|
+| | | | |
+| | | | |
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 19]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+6.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.
+
+ +----------------------+
+ | 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------------------------------------------------>|
+| | | | |
+
+
+
+Levy & Mohali Historic [Page 20]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+6.4. Call Forward on Unavailable
+
+ Usage of the Diversion header is shown below for several variant
+ implementations of Call Forward on Unavailable.
+
+6.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------------------------------------------------>|
+| | | | |
+| | | | |
+
+6.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 & Mohali Historic [Page 21]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+ +------------------------+
+ | 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 & Mohali Historic [Page 22]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+6.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------------------------------------------------>|
+| | | | |
+| | | | |
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 23]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+6.5. Multiple Diversions
+
+ Usage of the Diversion header when multiple diversions occur are
+ shown the following two examples.
+
+6.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 & Mohali Historic [Page 24]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+ +------------------------+ +-------------------------+
+ | 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 & Mohali Historic [Page 25]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+6.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 & Mohali Historic [Page 26]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+7. 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 3xxs. 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 3xxs that 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?
+
+8. Further Examples
+
+ Only the relevant headers have been included in the following
+ examples. The contents of the Session Description Protocols (SDPs)
+ have also been omitted.
+
+8.1. Night Service/Automatic Call Distribution (ACD) Using Diversion
+ Header
+
+ In the following two 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 27]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+ +-------------------------------------+
+ | WeSellPizza@P2: CFTOD->nightserv@P3 |
+ +------------+------------------------+
+ \
+ \
+UAC P1 P2 P3 UAS1
+ (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
+
+
+
+
+Levy & Mohali Historic [Page 28]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+ 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
+ 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 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 29]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+ [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.
+
+ [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
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 30]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+ [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
+ 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?"
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 31]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+ +---------------------------------------+
+ | 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------| | | |
+| | | | |
+|--[10] ACK---------------------------------------------------------->|
+| | | | |
+|<======================================="Hello, WeSellFlowers"=======|
+| | | | |
+| | | | |
+
+
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 32]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+ 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 1 a.m. 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
+ 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
+ CSeq: 1 INVITE
+ Diversion: <sip:WeSellFlowers@p4.isp.com>
+ ;reason=time-of-day
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 33]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+ [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.
+
+
+
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 34]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+ [7] SIP UAS1 to SIP proxy server 3:
+
+ SIP/2.0 200 OK
+ 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 & Mohali Historic [Page 35]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+8.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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 36]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+ +---------------------------------------------+
+ | 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----------------------------------------------------|
+| | | | |
+|---[12] ACK--------------------------------------------------->|
+| | | | |
+| | | | |
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 37]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 38]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+ [4] User agent server 1 (UAS1) to SIP proxy server 2 (P2)
+
+ SIP/2.0 302 Moved Temporarily
+ 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
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 39]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+ [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
+ 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
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 40]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+ [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 mailbox.
+
+8.3. Questions and Answers 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.).
+
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 41]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+ 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).
+
+9. 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 that refers to either the act of an network
+ redirection or endpoint deflection.
+
+ 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 lowercase "redirect" indicates the SIP
+ usage, while an uppercase "Redirect" indicates ISUP usage.
+
+9.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
+
+
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 42]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+ 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
+
+9.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.
+
+9.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.
+
+
+
+
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 43]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+9.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 the number 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
+ Number and the reason for that diversion is carried in the Redirect
+ Reason.
+
+9.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.
+
+
+
+Levy & Mohali Historic [Page 44]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+ The Redirection 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.
+
+9.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 that does not explicitly specify a diversion-counter tag
+ counts as 1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 45]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+9.2.5. Example of ISUP to SIP Translation
+
+ 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
+ |
+ |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 46]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+9.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 |
+
+9.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.
+
+9.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 that
+ contains Redirecting number and Reason
+ for diversion.
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 47]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+ 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 the number is user
+ provided and screened or network
+ provided.
+
+ Presentation Status Indicates if presentation is allowed or
+ prohibited.
+
+9.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:
+
+ 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.
+
+
+
+Levy & Mohali Historic [Page 48]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+ 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).
+
+9.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
+ 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.
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 49]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+9.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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 50]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+9.3.5. Example of ISDN to SIP Translation
+
+ 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"
+ |
+ |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Levy & Mohali Historic [Page 51]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+9.3.6. Example of SIP to ISDN Translation
+
+ 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"
+ |
+
+9.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.
+
+9.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.
+
+9.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 & Mohali Historic [Page 52]
+
+RFC 5806 Diversion Indication in SIP March 2010
+
+
+9.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.
+
+10. Contributors
+
+ Special acknowledgement to both Bryan Byerly and JR Yang. As
+ original authors of this document, both were instrumental is getting
+ this document written.
+
+11. Acknowledgements
+
+ We would like to thank David Williams, Ameet Kher, Satya Khatter,
+ Manoj Bhatia, Shail Bhatnagar, Denise Caballero-Mccann, Kara Adams,
+ Charles Eckel of Cisco Systems, and Bert Culpepper of InterVoice-
+ Brite for their insights, inputs, and comments.
+
+12. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+ A., Peterson, J., Sparks, R., Handley, M., and E.
+ Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+ June 2002.
+
+Authors' Addresses
+
+ Steve Levy
+ Cisco Systems
+ 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park,
+ NC 27709
+ USA
+
+ EMail: stlevy@cisco.com
+
+ Marianne Mohali (editor)
+ Orange Labs
+ 38-40 rue du General Leclerc
+ Issy-Les-Moulineaux Cedex 9 92794
+ France
+
+ Phone: +33145294514
+ EMail: marianne.mohali@orange-ftgroup.com
+
+
+
+
+Levy & Mohali Historic [Page 53]
+