ENUM JoonHyung Lim Internet Draft Weon Kim Expires: April 19, 2007 NIDA October 16, 2006 ENUM-based Softswitch Requirement draft-lim-kim-enum-based-softswitch-00.txt 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 April 19, 2007 Abstract This document describes simple requirement for softswitch, which use ENUM DNS to route a call on VoIP service. This requirement is one of interim solution to maintain stability of on-going commercial softswitch system while initial stage of ENUM service that does not have sufficient data. Table of Contents 1. Introduction...................................................2 2. Terminology....................................................2 3. Call-Routing of Softswitch.....................................2 4. Requirement for ENUM-based Softswitch..........................3 5. 'e164.arpa' consideration......................................4 Lim & Kim Expires - April 19, 2007 [Page 1] ENUM-based Softswitch Requirement October 2006 6. Security Considerations........................................4 7. IANA Consideration.............................................4 8. References.....................................................4 Author's Addresses................................................5 Intellectual Property and Copyright Statements ...................5 1. Introduction ENUM[1] is a mapping system based on DNS[3] that converts from E.164[2] number to domain name using 'Naming Authority Pointer(NAPTR)' resource record, which is able to store different service types such as fax, email, homepage, and etc., for every E.164 number. It originally focused on how end-user could access to other end-user's information through the Internet. Recently, various discussions are needed about RFC3761[1], because infrastructure ENUM that provides routing information between carriers. Specially, In case of VoIP service, VoIP carrier that wants to integrate various protocols uses softswitch. However, It is inefficient for interconnection and number portability between carriers because softswitch does not have all numbers that carriers dealing with and it has its own number translation method for E.164 that is not compatible to others. Therefore, carriers expect many benefits If they use a ENUM for routing purpose on softswitch. However, it is too difficult to establish complete ENUM system all over the world simultaneously. Interim period, which fills up the data to ENUM DNS and make sure regulation of each country with NRA(National Regulatory Authority) is necessary. During the interim period, a group of carriers, which willing to gather their own call-routing data to one ENUM DNS are also needed to route a call that can not find a answer on ENUM DNS. So, this document introduces simple requirement about call-routing on ENUM-based softswitch that operated by VoIP carriers. 2. Terminology 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 BCP 14, RFC 2119 [6]. 3. Call-Routing of Softswitch Lim & Kim Expires - April 19, 2007 [Page 2] ENUM-based Softswitch Requirement October 2006 In the PSTN(Public Switched Telephone Network), Only hardware-typed switch rules the network. Softswitch is the switch implemented on computer system by software. It usually controls various signaling protocols which are SIP[7], H.323[8], MGCP[9], and etc., to make call connections for VoIP service on the boundary point between circuit and packet network. To make call routing, first of all, Softswitch translate the number as vendor specific method to routing information, which can find destination. Today, prefix-based number translation has not only used in legacy PSTN switch, but also used in softswitch very widely. This kind of vendor specific call routing is only reference to their own routing information, so if there is a carrier wants to get out or get in, rest of carriers make some change routing information on their softswitch. It is not efficient on the aspect of number management. Today, many carriers dealing with VoIP for several years, faces same difficulties of inefficiency. For example, carriers process various signaling protocols, and interconnect to multiple carriers without any centralized point. Therefore, if softswitches are able to transform E.164 number to routing information by using ENUM DNS, it will be more efficient on call routing. 4. Requirement for ENUM-based Softswitch To use ENUM DNS, softswitch need to have ENUM module that converts from E.164 number to ENUM domain name defined in RFC3761 and process a query to ENUM DNS. ENUM module MUST follow the RFC3761. However, initial stage of ENUM DNS shares call routing information from limited carriers, so It makes problem that softswitch can't find all of call routing information on ENUM DNS. To solve this problem, ENUM-based softswitch MUST follow the below. 1. ENUM module of softswitch converts E.164 number comes from the VoIP subscriber to domain name defined RFC3761. 2. ENUM module of softswitch as a stub resolver, send a query to recursive name server with domain name described above. 3. If the 'Rcode' field is '3', which means 'non-existence domain' in answer section of DNS message defined RCF1035[4], softswitch MUST translate the number with its vendor specific prefix-based translation subsequently. Even if the interim period, carriers can use ENUM DNS for number translation without any affect on their on-going commercial service. Lim & Kim Expires - April 19, 2007 [Page 3] ENUM-based Softswitch Requirement October 2006 At the first time, most of calls queried to ENUM DNS is almost hard to get the answer in case of small group of carriers, however it will be getting more answer from ENUM DNS if group of carriers is getting more bigger. It seems like inefficient because administrator maintains two management points of numbers which is ENUM DNS and softswitch itself. However it will be able to minimize failure ratio of call routing from transition period of ENUM, and hereafter if ENUM comes to fill, there is single management point on ENUM without any major changes on softswitch. 5. e164.arpa' consideration Today, some discussions about Infrastructure ENUM consideration based on RFC3761, is related to new 'e164.arpa' tree. ENUM module embeded on softswitch MUST follow the new e164.arpa tree when new branch method of e164.arpa for Infrastructue ENUM is set. 6. Security Considerations If the recursive DNS handles ENUM queries from softswitch is compromised by attacker, It will be able to make wrong call routing or occur delay to call. Therefore, recursive DNS MAY lets in the local network as same as softswitch, and restrict access from outside with proper access-list policy. 7. IANA Consideration This document is only advisory, and does not include any IANA considerations. 8. References 8.1. Normative References [1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [2] International Telecommunication Union-Telecommunication Standardization Sector, "The International Public Telecommunication Numbering Plan", Recommendation E.164", February 2005. [3] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 1034, November 1987. [4] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", RFC 1035, November 1987. Lim & Kim Expires - April 19, 2007 [Page 4] ENUM-based Softswitch Requirement October 2006 [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [7] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol", RFC 2119, June 2002. [8] "Packet-based multimedia communications systems", ITU-T Recommendation H.323, 2003. [9] F. Andreasen, B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003 Authors' Addresses JoonHyung Lim National Internet Develompment Agency of Korea 3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu, Seoul Korea Phone: +82-2-2186-4548 Email: jhlim@nida.or.kr URI: http://www.nida.or.kr Weon Kim National Internet Develompment Agency of Korea 3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu, Seoul Korea Phone: +82-2-2186-4502 Email: wkim@nida.or.kr URI: http://www.nida.or.kr Intellectual Property 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. Lim & Kim Expires - April 19, 2007 [Page 5] ENUM-based Softswitch Requirement October 2006 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lim & Kim Expires - April 19, 2007 [Page 6]