SIP Steve Levy Internet-Draft J. R. Yang draft-levy-sip-diversion-08.txt Cisco Systems Bryan Byerly Expires: February 25,2005 August 25, 2004 Diversion Indication in SIP draft-levy-sip-diversion-08 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 25, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document proposes an extension to the Session Initiation Protocol (SIP). This extension provides the ability for the called SIP user agent to identify from whom the call was diverted and why the call was diverted. The extension defines a general header, Diversion, which conveys the diversion information from other SIP user agents and proxies to the called user agent. This extension allows enhanced support for various features, including Unified Messaging, Third-Party Voicemail, and Automatic Call Distribution (ACD). SIP user agents and SIP proxies which receive diversion information may use this as supplemental information for feature invocation decisions. Levy/Byerly/Yang draft-levy-sip-diversion-08.txt Page 1 Internet Draft Diversion Indication in SIP August 2004 1 Introduction In the legacy telephony network, redirection information is passed through the network in ISDN/ISUP signaling messages. This information is used by various service providers and business applications to support enhanced features for the end user. An analogous mechanism of providing redirection information would enable such enhanced features for SIP users. The Diversion header allows implementation of feature logic based on from whom the call was diverted. Version 06 (and forward) of the draft adds support for privacy and screening information. 2 Definitions diversion: A change to the ultimate destination endpoint of a request. A change in the Request-URI of a request that was not caused by a routing decision. This is also sometimes called a deflection or redirection. A diversion can occur when the "user" portion of the Request-URI is changed for a reason other than expansion or translation. A diversion can occur when only the "host" portion of the Request-URI has changed if the change was due to a non-routing decision. divertor: The entity which diverted the call. recursing: A SIP proxy or user agent which handles a received or internally generated 3xx response by forking new request(s) itself. non-recursing: A SIP proxy or user agent which handles a received or internally generated 3xx response by forwarding it upstream. 3 Abbreviations CFUNC: Call Forward Unconditional CFTOD: Call Forward Time-of-Day CFB: Call Forward on Busy CFNA: Call Forward on No Answer CFUNV: Call Forward Unavailable ACD: Automatic Call Distribution 4 Overview In order to implement certain third-party features such as third-party voicemail and Automatic Call Distribution (ACD) applications, diversion information needs to be given to the called third-party so that he may respond to the caller intelligently. In these situations, the party receiving a diverted call needs answers for two questions: Question 1: From whom was the request diverted? Question 2: Why was the request diverted? This document proposes usage of the Diversion header to answer these questions for the party receiving the diverted call. Insertion of the previous Request-URI (before the diversion occurred) into the Diversion header answers question 1. Insertion of the "reason" tag into the Diversion header (by the divertor) answers question 2. Levy/Byerly/Yang draft-levy-sip-diversion-08.txt Page 2 Internet Draft Diversion Indication in SIP August 2004 4.1 When is the Diversion header used? The Diversion header SHOULD be added when a SIP proxy server, SIP redirect server, or SIP user agent changes the ultimate endpoint which will receive the call. Diversion information SHOULD NOT be added for normal call routing changes to the Request-URI. Thus, the Diversion header is not added when features such as speed dial change the Request-URI. When a diversion occurs, a Diversion header SHOULD be added to the forwarded request or forwarded 3xx response. The Diversion header MUST contain the Request-URI of the request prior to the diversion. The Diversion header SHOULD contain a reason that the diversion occurred. Existing Diversion headers received in an incoming request MUST NOT be removed or changed in forwarded requests. Existing Diversion headers received in an incoming response MUST NOT be removed or changed in the forwarded response. A Diversion header is added when features such as call forwarding or call deflection change the Request-URI. 5 Extension Syntax The syntax of the Diversion header is: 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" | "de