From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5806.txt | 2971 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2971 insertions(+) create mode 100644 doc/rfc/rfc5806.txt (limited to 'doc/rfc/rfc5806.txt') 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: + ;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: + ;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: ;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: ;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: ;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: ;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: ;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: ;tag=p4 + Call-ID: 12345600@alice-pc.isp.com + CSeq: 1 INVITE + Diversion: + ;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: ;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: + ;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: + ;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: ;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: ;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: ;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: ;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: ;tag=uas1 + Call-ID: 12345600@alice-pc.isp.com + CSeq: 1 INVITE + Diversion: + ;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: ;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: ;tag=uas1 + Call-ID: 12345600@alice-pc.isp.com + CSeq: 1 INVITE + Diversion: + ;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: ;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: ;tag=uas1 + Call-ID: 12345600@alice-pc.isp.com + CSeq: 1 INVITE + Diversion: + ;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: ;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: + ;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: ;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: ;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: + | ;reason=user-busy + | ;privacy="full" + | ;counter=4 + | Diversion: + | ;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: + | ;reason=user-busy + | ;privacy="full" + | ;counter=4 + | Diversion: + | ;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: + | ;reason=user-busy + | ;screen="yes" + | ;privacy="off" + | Diversion: + | ;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: + | ;reason=user-busy + | ;screen="yes" + | ;privacy="off + | Diversion: + | ;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] + -- cgit v1.2.3