IPTEL Working Group J.Yu Internet Draft Nuestar Intended status: Standards track D. Hancock Expires: December 2007 CableLabs F. Andreasen Cisco July 4, 2007 DAI Parameter for the "tel" URI draft-yu-tel-dai-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 1, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines a "dai" parameter for the "tel" Uniform Resource Identifier (URI) to support the Dial Around Indicator (DAI). The "dai" parameter is associated with the "cic" parameter, defined in [RFC4694], and indicates how the carrier identified in the "cic" parameter was selected. This document also expands the use of the "cic" parameter to support pre-subscribed and dialed long-distance carrier requirements. Yu et al Expires January 4, 2008 [Page 1] Internet-Draft DAI Parameter for the "tel" URI June 2007 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. Table of Contents 1. Introduction...................................................2 2. Abbreviations..................................................3 3. Formal Syntax..................................................3 4. Normative Rules................................................4 5. Examples......................................................12 6. Security Considerations.......................................13 7. IANA Considerations...........................................13 8. References....................................................13 1. Introduction Before equal access was supported in the United States, only AT&T's subscribers could dial "1" to reach AT&T when they made long distance calls. Other long distance carriers' subscribers needed to dial extra digits to reach their long distance carriers. For the fair competition, the Federal Communication Commission in the U.S. mandated the support for equal access that allowed any long distance carrier's subscriber to follow the same dialing plan to reach his/her pre-subscribed long distance carrier. The regulatory bodies in many other countries also have mandated equal access. To allow a telephony subscriber to use a non-pre-subscribed long distance carrier for some of their long distance calls, the U.S. has implemented the dialing prefix "10XXX" that was later expanded to "101XXXX" in the dialing plan. The prefix allows the caller to use "XXX" or "XXXX" to specify the long distance carrier to handle that particular call. This dialing prefix was also used to identify the local toll carrier in the United States when equal access also applied to the local toll calls. One of the purposes of the DAI is to indicate to the long distance carrier that receives a call from the local exchange carrier whether the call came from a pre-subscribed customer or not. Due to operator-assisted calls, where the called party or a third party may be charged for the call in some cases, the DAI is also used to indicate to the receiving long distance carrier if it is the primary or alternate preferred long distance carrier of the charged party. The long distance carrier information, the Carrier Identification Code (CIC), can be carried in the "cic" parameter [RFC4694], a parameter of the "tel" Uniform Resource Identifier (URI) [RFC3966]. The "cic" parameter defined in [RFC4694] identifies the freephone service provider that serves the freephone number. As described in [RFC4694], it can also be used to carry the CIC associated with the carrier who is to handle a call to a geographic telephone number; such usage is leveraged in this document. When the carrier that is Yu et al Expires Decemeber 2007 [Page 2] Internet-Draft DAI Parameter for the "tel" URI June 2007 assigned the CIC receives the call, the "dai" parameter defined in this document indicates to that carrier how it was selected. 2. Abbreviations ANSI American National Standards Institute BNF Backus-Naur Form CIC Carrier Identification Code (also cic) DAI Dial Around Indicator (also dai) FCC Federal Communications Commission ENUM Telephone Number Mapping GSTN Global Switched Telephone Network GW Gateway IETF Internet Engineering Task Force IP Internet Protocol ISUP Integrated Services Digital Network User Part SS7 Signaling System number 7 SW Switch URI Uniform Resource Identifier 3. Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) as described in RFC 4234 [RFC4234] and defines the "dai" parameter by extending the "parameter" production rule of the "tel" URI defined in [RFC3966]. Parameter =/ dai dai = ";dai=" "no-ind" / "presub" / "presub-da" / "presub-daUnkwn" / "da" / "CIC-chrgPty" / "altCIC-chrgPty" / "verbal-clgPty" / "verbal-chrgPty" / "emergency" / "presubUnkwn-da" / "operator" The "dai" parameter can appear in the "tel" URI at most once. The "dai" parameter MUST NOT be present if the "cic" parameter is not present. When the "cic" parameter is present due to carrier selection, the "dai" parameter MUST be present so that its presence in the tel URI can differentiate the carrier selection case from the freephone case. Please see [RFC4694] for the syntax specification of the "cic" parameter. Below are the descriptions of the values of the "dai" parameter. Yu et al Expires Decemeber 2007 [Page 3] Internet-Draft DAI Parameter for the "tel" URI June 2007 "no-ind": indicates that it is not known how the carrier identified in the CIC was selected. "presub": indicates that the CIC contains the caller's presubscribed carrier. "presub-da": indicates that the CIC contains the caller's dialed carrier-identification-code; the selected carrier is the caller's presubscribed carrier. "presub-daUnkwn": indicates that the CIC may contain either a caller dialed carrier-identification-code or the caller's presubscribed carrier. "da": indicates that the CIC contains the caller's dialed carrier- identification-code; the selected carrier is not the caller's presubscribed carrier. "CIC-chrgPty": indicates that the CIC contains the preferred carrier of the charged party. "altCIC-chrgPty": indicates that the CIC contains the alternate carrier of the charged party. "verbal-clgPty": indicates that the CIC contains the carrier delivered verbally by the calling party. "verbal-chrgPty": indicates that the CIC contains the carrier delivered verbally by the charged party. "emergency": indicates that the CIC is selected for emergency call handling. "presubUnkwn-da": indicates that the CIC contains the caller's dialed carrier-identification-code; it is not known if the selected carrier is the caller's presubscribed carrier. "operator": indicates that the CIC contains a carrier selected by a network operator. 4. Normative Rules This section discusses how a network node adds the "dai" parameter to the "tel" URI or handles a received "tel" URI that contains the "dai" parameter. Since the "dai" parameter goes with the "cic" parameter, the latter is included in some of the discussions below. The phone numbers of the caller and called party are geographic numbers in the discussions. Yu et al Expires Decemeber 2007 [Page 4] Internet-Draft DAI Parameter for the "tel" URI June 2007 When the call signaling message contains a "tel" URI that carries the "cic" parameter, ENUM [RFC3761] could map the phone number in the "tel" URI to other URI(s) such as SIP URI [RFC3261]. In that case, the mapped URI instead of the parameters in the "tel" URI MAY be used to route the call. In this document it is assumed that ENUM is not involved. 4.1. Network Model The network model in Figure 1 is used to help describing the rules for sending and receiving the "dai" parameter. The discussion below focuses on the handling of the "tel" URI in the signaling messages. It is assumed that the signaling message will contain the "cic" and "dai" parameters after it leaves "Network Node A" for a call originated by the user or after it leaves "GSTN GW" when the call comes from the PSTN. +-------------------------------+ | | +---------+ +---------+ +---------+ +---------+ | Network | | Network | | Network | | User | | Node C |-----| Node B |-----| Node A |------| Device | +---------+ +---------+ +---------+ +---------+ | | | | | | | | +---------+ +---------+ | +----------| GSTN | | GSTN | +--------------------------| GW |------| SW | +---------+ +---------+ Figure 1. Network Model "User Device" generates the signaling message requesting a call setup. "Network Node A" represents those network nodes that receive the call request and can analyze the type of call (e.g., local toll, long distance or international based on the calling party number/address and called party number) and determine or identify the carrier that is to handle the call. The latter can be based on the information from the caller (e.g., "101XXXX"), the presubscribed carrier information in the service profile of the caller, or via the involvement of an operator that interacts with the calling party, called party (e.g., for collect call) or a third party (e.g., when the call is charged to a third party) for an operator-assisted call. If configured by the network operator, Node A can apply a preferred CIC for all calls where carrier selection is needed. Note that although Figure 1 shows Node A as a single entity, its responsibilities can be shared amongst multiple Node As such that the Node A that is connected to or communicates with the user device is Yu et al Expires Decemeber 2007 [Page 5] Internet-Draft DAI Parameter for the "tel" URI June 2007 separate from the Node A that determines or identifies the carrier to handle the call. "Network Node B" represents those network nodes that are not associated with the carrier identified in the "cic" parameter and need to route the signaling message that contains the "cic" and "dai" parameters towards the carrier identified in the "cic" parameter. "Network Node C" represents those network nodes that receive the signaling message from "Network Node B" and belongs to the carrier identified in the "cic" parameter. "GSTN GW" stands for "Global Switched Telephone Network (GSTN) Gateway (GW)". It interfaces between the Internet Protocol (IP) domain and the GSTN domain for signaling protocols and the user traffic. The GSTN includes the wireline network, wireless network and other circuit-switched network. Signaling traffic and user traffic could be handled by separate network nodes. In this document, both types of traffic are handled by "GSTN GW" to simplify the discussion. "GSTN Switch (SW)" is a circuit switch in the GSTN that is connected with the GSTN GW. "User Device", "Network Node A", "Network Node B" and "Network Node C" are in the IP domain. "Network Node A", "Network Node B" and "Network Node C" can route the calls to the GSTN via the GSTN GW. The rules for various scenarios are described below. 4.2. Adding the "dai" Parameter to the "tel" URI This section discusses those cases where "Network Node A" receives a call request from "User Device" and may need to add the "dai" parameter to the "tel" URI. If the "cic" Parameter is included and "Network Node A" does not know how the carrier is selected or does not want to reveal how the carrier is selected (if it is allowed to do it), "Network Node A" MUST include the "dai" Parameter and set it to "no-ind". 4.2.1. CIC Information provided in call signaling from "User Device" "User Device" can provide the CIC information via call signaling in two ways. a. Include the "cic" parameter in the "tel" URI to carry the selected CIC. It is outside the scope of this document as to how "User Device" adds the "cic" parameter to the "tel" URI. "User Device" SHOULD NOT include the "dai" parameter in the "tel" URI. When included by the "User Device", "Network Node A" SHALL ignore the "dai" parameter. Yu et al Expires Decemeber 2007 [Page 6] Internet-Draft DAI Parameter for the "tel" URI June 2007 b. Include the selected CIC information in the dialed string (e.g., "101XXXX" followed by a national number). [String] specifies one way to deliver the dialed string in the SIP protocol [RFC3261]. It is outside the scope of this document as to how the dialed string is carried in the signaling message and how "Network Node A" knows how to identify the caller selected CIC information when applicable and the called phone number from the received dialed string. When receiving a call request containing the "cic" parameter or the CIC information in the signaling message from "User Device" and an operator is not involved in call handling, "Network Node A" MUST follow the rules described below. The cases where an operator is involved in determining/selecting a carrier to handle the call are addressed in 4.2.3 and 4.2.4 below. - If the call is to be handled by the carrier "Network Node A" is associated with (that is, the carrier network is the network within which Node A resides), "Network Node A" MUST remove the "cic" parameter, if present in the "tel" URI, and MUST NOT include the "dai" parameter if it needs to forward the signaling message to another network node. - If "Network Node A" selects a carrier other than the caller's pre- subscribed carrier or the one specified by "User Device" to handle the call (e.g., does not allow the caller to specify the carrier to handle the call), "Network Node A" MUST set the "cic" parameter to contain the CIC it selects and include the "cic" parameter, if not yet present, in the "tel" URI. "Network Node A" MUST include the "dai" parameter in the "tel" URI and set it to "operator". - If the "User Device" specified carrier is the same as the caller's pre-subscribed carrier and "Network Node A" knows that the CIC information is provided by "User Device", "Network Node A" MUST set the "cic" parameter to contain the caller's pre-subscribed carrier's CIC and include the parameter, if not yet present, in the "tel" URI. "Network Node A" MUST set the "dai" parameter to "presub-da" and include the parameter in the "tel" URI. - If "Network Node A" is not sure whether the CIC information is provided by "User Device" (e.g., a proxy server between "User Device" and "Network Node A" is involved), it MUST set the "dai" parameter to "presub-daUnkwn" in the process described above. - If the "User Device" specified carrier is different from the caller's pre-subscribed carrier, "Network Node A" MUST set the "cic" parameter to contain the "User Device" specified carrier and include the parameter, if not yet present, in the "tel" URI. "Network Node A" MUST set the "dai" parameter to "da" and include the parameter in the "tel" URI. Yu et al Expires Decemeber 2007 [Page 7] Internet-Draft DAI Parameter for the "tel" URI June 2007 - If the "User Device" specifies a carrier and "Network Node A" cannot determine if the selected carrier is the caller's presubscribed carrier, "Network Node A" MUST set the "cic" parameter to contain the "User Device" specified carrier and include the parameter, if not yet present, in the "tel" URI. "Network Node A" MUST set the "dai" parameter to "presubUnkwn-da" and include the parameter in the "tel" URI. 4.2.2. CIC Information not provided in call signaling from "User Device" In this scenario, "User Device" did not provide any CIC information in call signaling and an operator is not involved in call handling. "Network Node A" MUST follow the rules described below. The cases where an operator is involved in determining/selecting a carrier to handle the call are addressed in 4.2.3 and 4.2.4 below. - If the call is to be handled by the carrier "Network Node A" is associated with, "Network Node A" MUST NOT include the "cic" and "dai" parameters in the "tel" URI if it needs to forward the signaling message to another network node. - If "Network Node A" selects a carrier that is different from the caller's pre-subscribed carrier to handle the call, it MUST set the "cic" parameter to contain the CIC it selects and include the parameter in the "tel" URI. "Network Node A" MUST include the "dai" parameter in the "tel" URI and set it to "operator". - If the caller has a pre-subscribed carrier that can handle the call, "Network Node A" MUST set the "cic" parameter to contain the caller's pre-subscribed carrier's CIC and include the parameter in the "tel" URI. "Network Node A" MUST set the "dai" parameter to "presub" and include the parameter in the "tel" URI. 4.2.3. Operator-assisted call handling, caller pays for the call When an operator is involved in handling the call request from the caller, "Network Node A" may or may not have the CIC information available from the signaling message. If the caller is to pay for the call, the operator may interact with the caller to determine the carrier to handle the call when applicable. If the CIC information is available from call signaling and the operator also interacts with the caller to get the CIC information, the CIC provided by the operator MUST be used. How the caller indicates an operator-assisted call and passes the CIC information in call signaling is outside the scope of this document. "Network Node A" through the assistance of an operator MUST follow the rules described below. Yu et al Expires Decemeber 2007 [Page 8] Internet-Draft DAI Parameter for the "tel" URI June 2007 - If the call is to be handled by the carrier "Network Node A" is associated with, "Network Node A" MUST remove the "cic" parameter, if present in the "tel" URI, and MUST NOT include the "dai" parameter if it needs to forward the signaling message to another network node. - If "Network Node A" selects a carrier other than the caller's pre- subscribed carrier or the one specified by "User Device" or indicated by the caller during the interaction with the operator to handle the call, "Network Node A" MUST set the "cic" parameter to contain the CIC it selects and include the parameter, if not yet present, in the "tel" URI. "Network Node A" MUST include the "dai" parameter in the "tel" URI and set it to "operator". - If the carrier specified by "User Device" in call signaling or by the caller via the interaction with the operator or selected by "Network Node A" is the same as the caller's pre-subscribed carrier, "Network Node A" MUST set the "cic" parameter to contain the caller's pre-subscribed carrier's CIC and include the parameter, if not yet present, in the "tel" URI. "Network Node A" MUST set the "dai" parameter to "presub-da" and include the parameter in the "tel" URI. - If "Network Node A" is not sure whether the CIC information is provided by "User Device" or the operator did not indicate if the CIC information came from the caller, it MUST set the "dai" parameter to "presub-daUnkwn" in the process described above. - If the carrier specified by "User Device" in call signaling or by caller via the interaction with the operator is different from the caller's pre-subscribed carrier, "Network Node A" MUST set the "cic" parameter to contain the CIC of the selected carrier and include the parameter, if not yet present, in the "tel" URI. "Network Node A" MUST set the "dai" parameter to "da" and include the parameter in the "tel" URI. - If the operator receives verbal instructions from the caller to use a specific carrier and it is not unknown if that carrier is the caller's presubscribed carrier, "Network Node A" MUST set the "cic" parameter to contain the CIC of the specified carrier and include the parameter, if not yet present, in the "tel" URI. "Network Node A" MUST set the "dai" parameter to "verbal-clgPty" and include the parameter in the "tel" URI. 4.2.4. Operator-assisted call handling, caller does not pay for the call There are cases where the call is charged to the called party or a third party. How the caller indicates an operator-assisted call and passes the CIC information in call signaling is outside the scope of this document. The caller will indicate to the operator that either the called party or a third party is to pay for the call. The Yu et al Expires Decemeber 2007 [Page 9] Internet-Draft DAI Parameter for the "tel" URI June 2007 operator then checks with the charged party if he/she agrees to pay for the call and may verbally get the CIC information from the charged party or retrieve the primary and alternate preferred carrier information from some databases. It is assumed that the "tel" URI in the call signaling from "User Device" does not contain the "cic" parameter and/or "dai" parameter. They are ignored if they are present. "Network Node A" through the assistance of an operator MUST follow the rules described below. - If the call is to be handled by the carrier "Network Node A" is associated with, "Network Node A" MUST remove the "cic" parameter, if present, and MUST NOT include the "dai" parameter in the "tel" URI. - If "Network Node A" selects the carrier to handle the call, it MUST set the "cic" parameter to contain the CIC it selects and include the parameter in the "tel" URI. "Network Node A" MUST include the "dai" parameter in the "tel" URI and set it to "operator". - If the charged party's primary preferred carrier is used for the call handling, "Network Node A" MUST set the "cic" parameter to contain that carrier's CIC and include the parameter in the "tel" URI. "Network Node A" MUST set the "dai" parameter to "CIC-chrgPty" and include the parameter in the "tel" URI. How "Network Node A" knows that the selected carrier is the charged party's primary preferred carrier is outside the scope of this document. - If the charged party's alternate preferred carrier is used for the call handling, "Network Node A" MUST set the "cic" parameter to contain that carrier's CIC and include the parameter in the "tel" URI. "Network Node A" MUST set the "dai" parameter to "altCIC- chrgPty" and include the parameter in the "tel" URI. How "Network Node A" knows that the selected carrier is the charged party's alternate preferred carrier is outside the scope of this document. - If the operator receives verbal instructions from the charged party to use a specific carrier and it is not unknown if that carrier is the charged party's primary or alternate preferred carrier, "Network Node A" MUST set the "cic" parameter to contain the CIC of the specified carrier and include the parameter in the "tel" URI. "Network Node A" MUST set the "dai" parameter to "verbal-chrgPty" and include the parameter in the "tel" URI. - If the caller contacts an operator for an emergency situation and a carrier that "Network Node A" is not associated with needs to handle the call, "Network Node A" MUST set the "cic" parameter to the CIC of that carrier and include the parameter in the "tel" URI. "Network Node A" MUST set the "dai" parameter to "emergency" and include the parameter in the "tel" URI. Yu et al Expires Decemeber 2007 [Page 10] Internet-Draft DAI Parameter for the "tel" URI June 2007 4.2.5. Call signaling received from the GSTN SW by GSTN GW The GSTN GW may receive the Signaling System number 7 (SS7) Integrated Services Digital Network User Part (ISUP) signaling message from the GSTN SW that contains the CIC information. For example, American National Standards Institute (ANSI) ISUP carries the CIC information in the "Carrier Selection Information" parameter. There is a one-to-one mapping between the ANSI ISUP "Carrier Selection Information" parameter and the "dai" parameter. 4.3. Handling the "tel" URI with the "cic", or "cic" and "dai" This section discusses how "Network Node A", "Network Node B", "Network Node C" or "GSTN GW" handles the signaling messages that contain the "dai" and "cic" parameters in the "tel" URI. Scenarios that do not involve the "dai" parameter in the "tel" URI are outside the scope of this document. A. Network Node A After "Network Node A" has added the "dai" parameter and/or "cic" parameter to the "tel" URI and is ready to route the call, it MUST route the call based on the rules described in [RFC4694] to "Network Node B", "Network Node C" or "GSTN GW". "Network Node A" MAY record the "dai" value in the call detail record. If the carrier that Network A is associated with is the one to handle the call, Network Node A removes the "cic" and/or "dai" if they are present before routing the call. B. Network Node B Since "Network Node B" is not associated with the carrier identified by the CIC in the "cic" parameter, it MUST route the call based on the "cic" parameter as stated in [RFC4694] to another "Network Node B", "Network Node C" or "GSTN GW". "Network Node B" MAY record the "dai" value in the call detail record. C. Network Node C Since "Network Node C" is associated with the carrier identified by the CIC in the "cic" parameter, it removes the "cic" parameter and the "dai" parameter, if present, before it determines how to handle the call. "Network Node C" MAY record the "dai" value in the call detail record. How "Network Node C" continues the call routing/handling is outside the scope of this document. D. GSTN GW Yu et al Expires Decemeber 2007 [Page 11] Internet-Draft DAI Parameter for the "tel" URI June 2007 If "GSTN GW" determines that the call is to be routed from the IP domain to "GSTN SW", and SS7 ISUP is used in the GSTN, then the "GSTN GW" MUST map the "dai" parameter to the corresponding ISUP parameter. Note that when interworking with ANSI ISUP, the "dai" parameter is mapped to the ISUP "Carrier Selection Information" parameter. There is a one-to-one mapping between the ANSI ISUP "Carrier Selection Information" parameter and the "dai" parameter. When "GSTN GW" receives a signaling message from "GSTN SW" that contains the carrier selection information, it MUST set the "dai" parameter based on the received carrier selection information. The mapping between the "dai" parameter and ISUP is outside the scope of this document. "GSTN GW" MUST route the call based on the "cic" parameter as stated in [RFC4694] to "Network Node A", "Network Node B" or "Network Node C". "GSTN GW" MAY record the "dai" value in the call detail record. E. User Device "User Device" is not expected to receive signaling messages that contain the "dai" and/or "cic" parameters. If the received signaling messages contain the "tel" URI with the "dai" and/or "cic" parameters, "User device" SHALL ignore the parameter(s). 5. Examples A. A caller whose pre-subscribed carrier has a CIC of "+1-6789" makes an outbound call with the following "tel" URI: tel:+1-202-533-1234 "Network Node A" adds the "dai" and "cic" parameters to the "tel" URI as shown below. tel:+1-202-533-1234;cic=+1-6789;dai=presub B. A caller whose pre-subscribed carrier has a CIC of "+1-6789" makes an outbound call to +1-202-533-1234 and specifies to use the CIC of "+1-2345" in call signaling with the following "tel" URI: tel:+1-202-533-1234;cic=+1-2345 "Network Node A" recognizes that the caller has selected a non- presubscribed carrier to handle the call. "Network Node A" adds the "dai" parameter to the "tel" URI as shown below. tel:+1-202-533-1234;cic=+1-2345;dai=da C. A caller makes a collect call to +1-202-533-1234 through an operator. The operator at "Network Node A" interacts with the called party and gets a verbal approval to use the CIC of "+1-3456". Yu et al Expires Decemeber 2007 [Page 12] Internet-Draft DAI Parameter for the "tel" URI June 2007 "Network Node A" adds the "dai" and "cic" parameters to the "tel" URI as shown below. tel:+1-202-533-1234;cic=+1-3456;dai=verbal-chrgPty 6. Security Considerations In addition to those security implications discussed in [RFC3966], there may be new security implications associated with the "dai" parameter depending on the carrier who uses the information. Changing the content of the "dai" parameter may cause a call to be rejected by or cause some problems (e.g., collecting call charge) to the carrier who handles the call. For example, changing from "presub" to "da" may cause the call to be rejected if the carrier that is to handle the call only handles calls from its pre-subscribed subscribers. Changing "da" to "presub" may cause a call that would be rejected to be processed by a carrier who later finds out it cannot collect the call charge from the caller or has to pay more than the call charge to collect the call charge from the caller via a third party (e.g., local exchange carrier). It is RECOMMENDED that protocols carrying the "tel" URI provide hop by hop integrity for the URI including the parameters. This allows detection of any unauthorized changes to the contents of the "tel" URI. Please note that the information in the "dai" parameter may not be authenticated; therefore, the use of the information by the recipient of the "tel" URI is done at its own risk. 7. IANA Considerations The "dai" parameter defined in this document needs to be registered with IANA as a new parameter for the "tel" URI [RFC3966]. 1. Parameter name - dai Applicability - used to indicate how a carrier was chosen for handling a call Mandatory or optional - optional Restrictions on syntax - see Section 5 Reference to a specification - defined in this document 8. References 8.1. Normative References [RFC2119] S. Bradner, RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels", March 1997. Yu et al Expires Decemeber 2007 [Page 13] Internet-Draft DAI Parameter for the "tel" URI June 2007 [RFC3966] H. Schulzrinne, RFC 3966, "The tel URI for Telephone Numbers", December 2004. [RFC4234] D. Crocker and P. Overell, RFC 4234, "Augmented BNF for Syntax Specifications: ABNF", October 2005. [RFC4694] J. Yu, RFC 4694, "NP Parameters for the "tel" URI", October 2006. 8.2. Informative References [RFC3261] J. Rosenberg, et al., RFC 3261, "SIP: Session Initiation Protocol", June 2002. [RFC3761] P. Faltstrom and M. Mealling, RFC 3761, "The E.164 to Uniform Resource Identifiers (URI) - Dynamic Delegation Discovery System (DDDS) Application (ENUM)", April 2004. [String] B. Rosen, draft-rosen-iptel-dialstring-05.txt, "Dialstring parameter for the Session Initiation Protocol Uniform Resource Identifier", June 2006 (Work in Progress). 9. Change History (Note to editor - please remove this section in final version.) 9.1. Changes from version 01->02 - Section 3: clarified descriptions of "dai" parameter values - Section 4.2.5, plus various other places: removed text that said the "dai" parameter was not included in certain cases, since we now use "no-ind" these cases. - Section 4.3, o Item A: added text specifying that if Node-A is the carrier then it removes "cic" o Item D: added procedures for inbound calls from GSTN Acknowledgments The authors would like to thank Martin Dolly and Penn Pfautz for their assistances in providing the relevant information on the DAI. Authors' Addresses James Yu NeuStar, Inc. 46000 Center Oak Plaza Sterling, VA 20166 U.S.A. Phone: +1-571-434-5572 Yu et al Expires Decemeber 2007 [Page 14] Internet-Draft DAI Parameter for the "tel" URI June 2007 Email: james.yu@neustar.biz David Hancock CableLabs 858 Coal Creek Circle Louisville, CO 80027-9750 U.S.A. Phone: +1-303-661-3381 Email: d.hancock@cablelabs.com Flemming Andreasen Cisco Systems, Inc. 499 Thornall Street, 8th Floor Edison, NJ 08837 U.S.A. Email: fandreas@cisco.com Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Yu et al Expires Decemeber 2007 [Page 15] Internet-Draft DAI Parameter for the "tel" URI June 2007 This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Yu et al Expires Decemeber 2007 [Page 16]