IPTEL Working Group J. Yu Internet Draft NeuStar Document: draft-ietf-iptel-tel-np-05.txt June 3, 2005 Category: Standards Track New Parameters for the "tel" URI to Support Number Portability 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. 3668. 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 December 2, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All rights reserved. Abstract This document defines several new parameters in the "tel" Uniform Resource Identifier (URI) to carry the number portability (NP)- related information that can be passed to the next-hop network node after an NP database dip has been performed. This work is being discussed on the iptel@ietf.org mailing list. Yu Expires December 2, 2005 [Page 1] Internet-Draft New Parameters for the "tel" URI June 2005 to Support Number Portability 1. 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]. 2. Introduction Number portability (NP) [RFC3482] allows the telephony subscribers to keep their telephone numbers when they change service provider (service provider portability), move to a new location (location portability), or change the subscribed services (service portability). The NP implementations in many countries presently support service provider portability for geographic telephone numbers and freephone numbers (e.g., 800 numbers in the North America). NP impacts call signaling and routing. One impact is the need to carry the NP-related information in the "tel" URI [RFC3966] for protocols such as the Session Initiation Protocol (SIP) [RFC3261] and H.323 [H323] after the NP database dip has been performed. Another impact is for a Voice over IP (VoIP) server to use the NP-related information in a received "tel" URI to determine routing. A routing number is associated with a geographical telephone number that has been ported out from a donor carrier to another carrier. A donor carrier is the initial carrier where a geographical telephone number was located before ever being ported. A "non-ported" geographical telephone number does not have any routing number associated with it because the first N digits of the geographical telephone number can be used for routing. A routing number can also be used to indicate the switch or network node that originates a call or service similar to the Jurisdiction Information Parameter in Signaling System Number 7 (SS7) Integrated Services Digital Network User Part (ISUP). The NP database dip indicator is used to inform the downstream servers or switches during call setup that there is no need to perform the NP database dip for a geographical telephone number again. A "Carrier Identification Code (CIC)" identifies the current freephone service provider for a freephone number. This parameter can also be used to carry the pre-subscribed or dialed long distance carrier information; however, that is outside the scope of this document. This document defines several new parameters for the "tel" Uniform Resource Identifier (URI) [RFC3966] to support NP. Section 3 lists the abbreviations used in this document. Section 4 provides the formal syntax definition. Section 5 describes the rules for a network node that deals with some or all of the parameters defined in this document for a "tel" URI. Section 6 provides a few examples to show how those parameters defined in this document are added to a Yu Expires December 2, 2005 [Page 2] Internet-Draft New Parameters for the "tel" URI June 2005 to Support Number Portability "tel" URI after retrieving NP-related information from the NP database. Section 7 discusses the security considerations. 3. Abbreviations ABNF Augmented Backus-Naur Form ANSI American National Standards Institute CIC Carrier Identification Code (also cic) CIP Carrier Identification Parameter FCI Forward Call Indicator GAP Generic Address Parameter GSTN Global Switched Telephone Network IC Identification Code IETF Internet Engineering Task Force IP Internet Protocol ISUP Integrated Services Digital Network User Part JIP Jurisdiction Information Parameter NP Number Portability NPDB Number Portability Database npdi NP Database Dip Indicator rn Routing Number PNTI Ported Number Translation Indicator SIP Session Initiation Protocol SS7 Signaling System Number 7 URI Uniform Resource Identifier VoIP Voice over IP 4. Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) as described in RFC-2234 [RFC2234] and defines new parameters in accordance with the ABNF for the "tel" URI provided in RFC 3966 [RFC3966]. rn = *1(routing-number) npdi = *1(npdb-dip-indicator) cic = *1(carrier-id-code) routing-number = "rn=" global-rn / local-rn global-rn = "+" 1*global-hex-digits local-rn = 1*phonedigit-hex rn-context rn-context = ";rn-context=" rn-descriptor rn-descriptor = domainname / global-hex-digits global-hex-digits = "+" 1*3(phonedigit) *phonedigit-hex phonedigit = DIGIT / [ visual-separator ] phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ] visual-separator = "-" / "." / "(" / ")" domainname = *( domainlabel "." ) toplabel ["."] domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum alphanum = ALPHA / DIGIT npdb-dip-indicator = "npdi" Yu Expires December 2, 2005 [Page 3] Internet-Draft New Parameters for the "tel" URI June 2005 to Support Number Portability carrier-id-code = "cic=" global-cic / local-cic global-cic = "+" 1*global-hex-digits local-cic = 1*phonedigit-hex cic-context cic-context = ";cic-context=" rn-descriptor The "routing-number", "npdb-dip-indicator" or "carrier-id-code" each can appear in the "tel" URI at most once. For a "global-rn", the routing number information after "+" MUST begin with a valid E.164 [E164] country code. Hexadecimal digit is allowed after the country code in the "global-rn". For a "local-rn", the routing number in the "rn" parameter MUST be interpreted according to the "rn-context". For example, if a national routing number is in the "rn" parameter, the "rn-context" MUST contain a valid E.164 country code after "+" if it is in the "global-hex-digits" format. Hexadecimal digit is allowed in the "local-rn". For a "global-cic", the CIC information after "+" MUST begin with a valid E.164 country code. For a "local-cic", the CIC value in the "cic" parameter MUST be interpreted according to the "cic-context". For example, if the national CIC value is in the "cic" parameter, the "cic-context" SHALL contain a valid E.164 country code after "+" if it is in the "global-hex-digits" format. 5. Normative Rules This section discusses how a network node handles a received "tel" URI that contains one or more of the parameters defined in this document or has accessed an NP database for a freephone number or geographical telephone number and needs to add some of the parameters defined in this document to a "tel" URI. In countries where there is no freephone number portability or geographical telephone number portability, the call routing can be based on the leading digits of the freephone number or geographical telephone number. This document does not describe those scenarios. Please note that two accesses to the freephone databases are normally done for routing a call to a freephone number. The first one is done by the originating network that queries a freephone database for the CIC information so that the call can be routed to the serving freephone service provider of the called freephone number. When the call reaches the serving freephone provider, the second database access is performed to map the freephone number to a geographical telephone number and/or internal routing information. This document does not address the case where internal routing information is returned. Yu Expires December 2, 2005 [Page 4] Internet-Draft New Parameters for the "tel" URI June 2005 to Support Number Portability The first freephone database contains the CIC information for all the active freephone numbers while the second one usually contains mapping information only for those freephone numbers served by a freephone service provider. Because the originating carrier may provide freephone service, its freephone database would contain the CIC information for all the active freephone numbers plus the mapping information for those freephone numbers it serves. This document refers to the two database accesses as "the first freephone database access" and "the second freephone database access". When handling the "rn" and "cic" parameters and the phone numbers in the "tel" URI for the purposes such as database access and routing, the visual separators in them are removed before using the information in them. When a network node handles a "tel" URI that contains invalid "rn" or "cic" information, it may release the call or drop the invalid parameter and access the appropriate NP database or freephone database to see if it can retrieve a valid routing number for a geographical telephone number or valid CIC for the freephone number. 5.1 Handling "tel" URI with Defined Parameter or Parameters If the "tel" URI contains the "npdi" parameter, the network node SHALL NOT retrieve the NP-related information for geographical telephone numbers even if it is set to do so. If the "tel" URI contains the "cic" parameter whose CIC value is different from the one this network node is associated with, this network node SHALL NOT retrieve the NP-related information for the geographical telephone number or perform the first freephone database access for the freephone number in the "tel" URI. For the "cic" and "rn" parameters and either a freephone number or geographical telephone number, the order of processing is to look for the "cic" parameter first for call routing. If the CIC information is not useful or the "cic" parameter does not exist, then the next step is to look for the "rn" parameter. If the information in the "rn" parameter is not useful or the "rn" parameter does not exist, then the freephone number or geographical telephone number is used. If the network node does not know how to route based on the "cic" or "rn" parameter, the local policies SHALL decide whether to stop the call processing or continue the call processing by ignoring the invalid/unknown information. When looking for the "cic" parameter and that parameter exists in the "tel" URI: - The network node SHALL ignore the "cic" parameter if the CIC identifies a carrier or service provider associated with that node and look for the "rn" parameter for making the routing decision. Yu Expires December 2, 2005 [Page 5] Internet-Draft New Parameters for the "tel" URI June 2005 to Support Number Portability It SHALL remove the "cic" parameter when it routes the call to the next-hop network node that belongs to another carrier or service provider. - The network node SHALL invoke special handling process if the "cic" parameter contains a code that requires such a treatment. For example, a CIC value of "0110" in the response to a freephone DB query in the North America indicates "local, translated geographical telephone number provided"). In this particular example, the "cic" parameter is ignored. Please note that this particular CIC value of "+1-0110" normally will not appear in the call setup message. It is given as an example to show that such special CIC values may exist. The exact code values and the handling of them are outside the scope of this document. - Otherwise, the network node SHALL make the routing decision based on the CIC. The network node SHALL NOT remove the "cic" parameter unless it is handing over the call to the carrier or service provider identified by the CIC and the local policies require it to remove the "cic" parameter. How the call is actually routed based on the CIC value in the "cic" parameter is outside the scope of this document. When looking for the "rn" parameter and that parameter exists in the "tel" URI: - If the routing number in the "rn" parameter points to this network node (e.g., the call has reached the intended network node), this network node SHALL look for the freephone number or geographical telephone number for making the routing decision. It SHALL remove the "rn" parameter when setting up the call to the next-hop network node regardless if that next-hop network node is in the same or different network. - If the routing number in the "rn" parameter points to a network this network node is in (e.g., in some countries the routing number gets the call to the serving carrier network where another NP database access is required to locate the serving switch), this network node SHALL look for the freephone number or geographical telephone number for making the routing decision. The network node MAY access the NP database for routing information if it is set to do so. It SHALL remove the "rn" parameter if the next-hop network node belongs to another carrier or service provider. - Otherwise, the network node SHALL make the routing decision based on the routing number in the "rn" parameter. How the call is actually routed based on the routing number in the "rn" parameter is outside the scope of this document. When the "cic" or "rn" parameter is not used for routing, the network node uses the freephone number or geographical telephone number for making routing decisions. It may access the NP database if it is set to do so, or it may route the call to a designated Yu Expires December 2, 2005 [Page 6] Internet-Draft New Parameters for the "tel" URI June 2005 to Support Number Portability network node that will access the NP database, or it may route the call based on the local routing table. How the call is handled at this stage is outside the scope of this document. See Section 5.2 for rules in adding the parameter or parameters defined in this document to the "tel" URI if the network node is set to access the NP database. 5.2 Adding Defined Parameter or Parameters to the "tel" URI There are two cases in terms of NP database access. One is for a geographical telephone number and the other is for a freephone number. They are discussed in Sections 5.2.1 and 5.2.2 for a "tel" URI that is used for routing. Section 5.2.3 discusses a special case where the "rn" parameter is added to a "tel" URI that is associated with the first network node that handles the call request from the caller. Section 5.3.4 discusses the addition of the parameter or parameters defined in this document to the "tel" URI due to protocol conversion. 5.2.1 Retrieving NP-related information for a geographical telephone number When a network node accesses an NP database for a geographical telephone number: - If the network node retrieves a routing number, it SHALL add the "rn" parameter to the "tel" URI to carry the routing number information in the "global-rn" or "local-rn" format. It SHALL also add the "npdi" parameter. - If the network node does not retrieve a routing number (e.g., for a non-ported geographical telephone number), it SHALL add the "npdi" parameter to the "tel" URI. The network node SHALL follow the rules described in Section 5.1 for using the information in the "tel" URI to make the routing decision. 5.2.2 Retrieving NP-related information for a freephone number When a network node performs the first or second freephone database access for a freephone number: - If the network node retrieves a CIC that identifies a carrier or service provider associated with that network node, or indicates that a geographic number is supplied (e.g., "+1-0110" means "local, translated geographical telephone number provided"), it would have retrieved a geographical telephone number. The network node SHALL NOT add the "cic" parameter and SHALL replace the freephone number in the "tel" URI with the retrieved geographical telephone number in either the "global-number" or "local-number" format. Yu Expires December 2, 2005 [Page 7] Internet-Draft New Parameters for the "tel" URI June 2005 to Support Number Portability Some freephone databases may not return the geographical telephone number but internal routing information in a proprietary format (e.g., switch ID and trunk group ID). That case is outside the scope of this document. - If the network node retrieves a CIC that belongs to another freephone service provider, the network node SHALL add the "cic" parameter to the "tel" URI that contains the CIC in the "global- cic" or "local-cic" format. The originating carrier may have business agreements with a freephone service provider to return the geographical telephone number in addition to the CIC. When a geographical telephone number is returned, the network node SHALL replace the freephone number in the "tel" URI with the returned geographical telephone number in either the "global-number" or "local-number" format. - If the network node retrieves a geographical telephone number (which is the typical case for the second freephone database access), the network node SHALL replace the freephone number in the "tel" URI with the retrieved geographical telephone number in either the "global-number" or "local-number" format. When a geographical telephone number is returned in the response, it is possible that the NP-related information for that geographical telephone number could also be returned. In that case, the network node SHALL add the "npdi" parameter and SHALL add the "rn" parameter to contain the routing number in either the "global-rn" or "local-rn" format only when the routing number is available. The network node SHALL follow the rules described in Section 5.1 for using the information in the "tel" URI to make the routing decision. 5.2.3 Adding location information about the caller In SS7 ISUP, the JIP identifies the switch that originates the call and the information in it may be used by the serving carrier to determine the call charge to the caller or by the involved carriers to determine the settlement amount between them. A network node that is the first to handle the call request from the caller MAY include the "rn" parameter to the "tel" URI associated with the caller, if one exists. For example, if the network node is a Global Switched Telephone Network (GSTN) gateway that receives an ISUP message that contains the JIP, the correct location information in the JIP can be placed in the "rn" parameter of the "tel" URI that is associated with the caller. Please note that the information in the "rn" parameter may not be authenticated; therefore, the use of the information by the recipient of the "tel" URI for anything related to charging is done at its own risk. Yu Expires December 2, 2005 [Page 8] Internet-Draft New Parameters for the "tel" URI June 2005 to Support Number Portability 5.2.4 Adding the parameter or parameters defined in this document due to protocol conversion A GSTN gateway needs to convert between SS7 ISUP and the VoIP protocol such as SIP or H.323. This type of network node SHALL map between the corresponding ISUP parameters and the parameters defined in this document associated with the "tel" URI for routing and MAY map between the corresponding ISUP parameters and the parameters defined in this document that are in the "tel" URI associated with the caller. Since ISUP support for NP depends on the individual country, the following discussion applies to a situation when a network node is to map between the NP information in the American National Standards Institute (ANSI) ISUP and the NP-related parameters in the "tel" URI. For a ported geographical telephone number, the network node SHALL convert the routing number in the ISUP Called Party Number parameter to a routing number in either the "global-rn" or "local-rn" format and carry it in the "rn" parameter for a "tel" URI that is used for routing. The network node SHALL convert the phone number that is marked as the "ported number" in the ISUP Generic Address Parameter (GAP) to a phone number in either the "global-number" or "local- number" format [RFC3966] and put it in the global-number-digits or local-number-digits (see [RFC3966]) part of the "tel" URI that is used for routing. For a non-ported geographical telephone number, the network node SHALL convert the phone number in the ISUP Called Party Number parameter to a phone number in either the "global-number" or "local- number" format and put it in the global-number-digits or local- number-digits (see [RFC3966]) part of the "tel" URI that is used for routing. A "rn" SHALL NOT appear in the "tel" URI unless the local policies require the network node to include it. It is outside the scope of this document how to include the "rn" parameter if the local policies require the network node to do so. The network node SHALL include the "npdi" parameter in the "tel" URI that is used for routing when the Ported Number Translation Indicator (PNTI) bit in the Forward Call Indicator (FCI) parameter is set to "1". The network node SHALL include the "cic" parameter in either the "global-cic" or "local-cic" format in the "tel" URI that is used for routing when the ISUP Carrier Identification Parameter (CIP) is present. The network node MAY include the "rn" parameter in the "tel" URI associated with the caller information when the ISUP JIP is present. This may be subject to the network node's local policy and/or the signaling protocol that carries the "tel" URI. Yu Expires December 2, 2005 [Page 9] Internet-Draft New Parameters for the "tel" URI June 2005 to Support Number Portability Mapping NP-related parameters in a "tel" URI to the NP-related information in the ISUP message depends on the national ISUP implementation and is outside the scope of this document. 6. Examples A. A "tel" URI, tel:+1-800-123-4567, contains a freephone number "+1- 800-123-4567". Assume that this freephone number is served by a freephone service provide with a CIC "+1-6789". After retrieving the NP-related information, the "tel" URI would be set to tel:+1-800-123-4567;cic=+1-6789 B. A "tel" URI, tel:+1-800-123-4567;cic=+1-6789, is handled by a network node in the serving freephone service provider's network. Assume that the freephone number is mapped to a geographical telephone number "+1-202-533-1234". After retrieving the NP- related information, the "tel" URI would be set to tel:+1-202-533-1234 C. A "tel" URI, tel:+1-202-533-1234, contains a geographical telephone number "+1-202-533-1234". Assume that this geographical telephone number is ported and is associated with a routing number "1-202-544-0000". After retrieving the NP-related information, the "tel" URI would be set to tel:+1-202-533-1234;rn=+1-202-544-0000;npdi D. A "tel" URI, tel:+1-202-533-6789, contains a geographical telephone number "+1-202-533-6789". Assume that this geographical telephone number is not ported. After accessing the NP database, the "tel" URI would be set to tel:+1-202-533-6789;npdi E. A "tel" URI, tel:+1-202-533-1234;rn=+1-202-000-0000;npdi, contains an invalid routing number (e.g., no routing information on "+1- 202-000-0000"), the network node may drop the "rn" parameter and access the NP database again. F. A "tel" URI, tel:+1-800-123-456, contains a freephone number "+1- 800-123-456" that is one digit short. When accessing the freephone database, there won't be any "cic" information for this freephone number. The call would be released. G. A "tel" URI, tel:+1-800-123-4567;cic=+1-56789, is handled by a network node in an originating or transit network. The "cic" information is invalid. The network node may drop the "cic" parameter and access the freephone database again. If the same wrong CIC information is received, the network node would release the call because it does not know how to route the call with an Yu Expires December 2, 2005 [Page 10] Internet-Draft New Parameters for the "tel" URI June 2005 to Support Number Portability invalid CIC. If the valid information is received, the network node will include the "cic" to contain the received CIC and route the call based on the "cic". 7. Security Considerations In addition to those security implications discussed in the revised "tel" URI [RFC3966], there are new security implications associated with the parameters defined in this document. If the value of the "rn" or "cic" in the "tel" URI is changed illegally when the signaling message carrying the "tel" URI is en route to the destination entity, the signaling message or call may be routed to the wrong network or network node causing the call setup to be rejected. If the "npdi" is illegally inserted into the "tel" URI when the signaling message carrying the "tel" URI is en route to the destination entity, the call may be routed to the wrong network or network node causing the call setup to be rejected. It is less a problem if the "npdi" is illegally removed. An additional NPDB query may be performed to retrieve the routing number information and have the "npdi" included again. If the "rn" in the "tel" URI that is associated with the caller is illegally changed or inserted, the call charge based on that "rn" would be incorrect. It is RECOMMENDED that protocols carrying the "tel" URI ensure message integrity during the message transfer between the two communicating network nodes so as to detect any unauthorized changes to the content of the "tel" URI and other information. 8. Normative References [RFC2119] S. Bradner, RFC2119, "Key words for use in RFCs to Indicate Requirement Levels," March 1997. [RFC3966] H. Schulzrinne, RFC3966, "The tel URI for Telephone Numbers," December 2004. [RFC2234] D. Crocker and P. Overell, RFC2234, "Augmented BNF for Syntax Specifications: ABNF," November 1997. [E164] ITU-T Recommendation E.164, "The international public telecommunication numbering plan," May 1997. 9. Informative References [RFC3482] M. Foster, T. McGarry and J. Yu, RFC3482, "Number Portability in the GSTN: An Overview," February 2003. Yu Expires December 2, 2005 [Page 11] Internet-Draft New Parameters for the "tel" URI June 2005 to Support Number Portability [RFC3261] J. Rosenberg, et al., RFC3261, "SIP: Session Initiation Protocol," June 2002. [H323] ITU-T Recommendation H.323, "Packet-Based Multimedia Communications Systems," November 2000. 10. Acknowledgments The author would like to thank Penn Pfautz, Jon Peterson, Jonathan Rosenberg, Henning Schulzrinne, Antti Vaha-Sipila, Flemming Andreasen and Mike Hammer for their discussions and comments. 11. Author's Address James Yu NeuStar, Inc. 46000 Center Oak Plaza Sterling, VA 20166 U.S.A. Phone: +1-571-434-5572 Email: james.yu@neustar.biz 12. Full Copyright Statement Copyright (C) The Internet Society (2005). 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. 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 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. Intellectual Property Rights Statement 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. Yu Expires December 2, 2005 [Page 12] Internet-Draft New Parameters for the "tel" URI June 2005 to Support Number Portability 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Yu Expires December 2, 2005 [Page 13]