ENUM J. Lim Internet Draft W. Kim Intended Status: Informational C. Park Expires: August 27, 2007 NIDA February 23, 2007 ENUM-based Softswitch Requirement 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 27, 2007 Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes operational requirement and several considerations for ENUM-based softswitch, which can route a call between 2 Korean VoIP carriers during the ENUM pre-commercial trial hosted by National Internet Development Agency of Korea(NIDA) in 2006. This experience can be 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. Lim, et.al. Expires - September 27, 2007 [Page 1] Table of Contents 1. Introduction...................................................2 2. Call Routing on Softswitch.....................................2 3. Infrastructure ENUM trial in Korea.............................3 4. Requirement for ENUM-based Softswitch..........................4 4.1 Call routing cases for DNS response code...................4 4.2 Type of domain routing.....................................4 5. Trial Results..................................................5 6. 'e164.arpa' consideration......................................6 7. Security consideration.........................................6 8. IANA Considerations............................................7 9. References.....................................................7 10. Acknowledgments...............................................7 Author's Addresses................................................8 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, because infrastructure ENUM that provides routing information between carriers. In case of VoIP service, VoIP carrier that wants to integrate various protocols uses softswitch. However, It is still inefficient for interconnection, number portability, and protocol information among carriers because softswitch does not have end-to-end routing information for all carriers. These informations can be stored in DNS, as a ENUM-basis. Therefore, carriers can expect many benefits If they use a ENUM for call routing on softswitch. To make sure these benefits and to verify the performance of ENUM- enabled softswitch, NIDA had cooperated with 2 Korean VoIP service providers for Infrastructure ENUM trial in 2006. NIDA is a non-profit organization with a mandate to manage 2.8.e164.arpa domain name representing +82 country code of Korea, and also promote a Internet- related things in national wide, including a ENUM. so, NIDA provides ENUM DNS to each VoIP service provider for call routing and ENUM DNS was able to access publicly. 2.Call Routing on Softswitch Lim, et.al. Expires - September 27, 2007 [Page 2] 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 a call, first of all, softswitch must discover routing information associating with the E.164 number comes from caller, on its own routing table, and then caller can connect the callee directly. Today, call routing based on prefix of number has used not only for legacy PSTN switch, but also for softswitch very widely. So, if softswitch can use ENUM DNS for call routing, in the beginning, most of calls queried to ENUM DNS would be failed in case of small group of carriers, however it will be getting more answer from ENUM DNS if group of carriers is getting bigger. 3.Infrastructure ENUM trial in Korea As described on section 1, NIDA and 2 VoIP Service Provider built up ENUM-based softswitch and made a interconnection using centralized ENUM DNS operated by NIDA. Provisioning the E.164 number based on EPP described in RFC4114 is also implemented and update the ENUM DNS instantly, using Dynamic Update(RFC2136). Call routing +---------------------------------------------+ | | | | +-----+------+ +-----------------+ +------+-----+ |Softswitch A|------| ENUM DNS(+82) |------|Softswitch B| +-----+------+ | (Tier1,2) | +------+-----+ | +--------+--------+ | +-----+------+ | +------+-----+ | IP Phone A | |Dynamic update | IP Phone B | +------------+ |(RFC2136) +------------+ | +------------+ +--------+--------+ +------------+ | EPP Client | | Registration | | EPP Client | | |------| server |------| | +------------+ +-----------------+ +------------+ Provisioning E.164 Numbers(RFC4114) Carrier A NIDA Carrier B Figure 1 : Infrastructure ENUM Trial system topology Lim, et.al. Expires - September 27, 2007 [Page 3] 4.Requirement for ENUM-based Softswitch 4.1 call routing cases for DNS response code 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. (3) if the ENUM module receives the answer, call routing process may branch off several way. It depends on Rcode value in answer section of DNS messages[4] as shown below. a. Rcode=0 (No error condition) There is a answer to coressponding query. However call routing process must different for following conditions. i. If there is not a certain URI that can initiate a call such as SIP, H.323, and etc, call must fail immediately. ii. if there are more than 2 SIP or H.323 URI, softswitch can pick one based on the preference and order value in NAPTR RR. b. Rcode=3(Name error), 1(Format Error), 2(Server Failure), 4(Not Implemented) or 5(Refused) There is no valid answer for NAPTR RR. So, softswitch must convert the number with its vendor specific method subsequently such as prefix-based method. In this case, it means call must be delivered through PSTN for call routing. 4.2 type of domain routing If the DNS response has valid URI such as SIP and H.323, softswitch can resolve a domain name of certain URI to route a call by searching two different sources. One is recursive nameserver, and the other is fixed routing table in softswitch, storing domain name and its corresponding IP address. Lim, et.al. Expires - September 27, 2007 [Page 4] If there are many points of interconnection, recursive nameserver is useful for resolving a domain name, But if there are just few known carriers and they do not change the interconnection information frequently, a fixed routing table maps domain name to corresponding IP address is more efficient rather than querying to recursive nameserver everytime. In addition, carriers would like to charge a interconnection fee for all received call, so they tend to make interconnection only with trusted carriers based on sort of agreement between carriers. These two types of domain routing are also affected on Rcode=0 case described on section 4.1 (1) Case for using fixed routing table a. If domain name part of URI is able to find on fixed routing table, softswitch can use it. b. If domain name part of URI does not exist on fixed routing table, it gets forwards to PSTN. (2) Case for using recursive nameserver a. If domain name part of URI is able to resolve on recursive nameserver, softswitch can use it. b. If domain name part of URI is not able to resolve on recursive nameserver due to any condition such as Rcode=1, 2, 3, 4, or 5, call must get forward to PSTN. Case '(1)' seems like inefficient because administrator maintains two management points of numbers which are ENUM DNS and softswitch itself. However it will be able to minimize failure ratio of call routing from transition period of ENUM. So case '(1)' implemented on softswitch for trial and hereafter if ENUM will be filled, case '(2)' will be reasonable choice. With these requirements, 2 carriers could use ENUM DNS for call routing without any affect on their on-going commercial VoIP service. 5.Trial Results To provide a stable commercial service, ENUM-based Softswitch must have certain performance as much as Non-ENUM Softswitch has. Only difference between 2 types of softswitch is searching mechanism for call routing information which can be stored in softswitch itself or external DNS. Therefore delay time for call routing, is important to guarantee quality of Service. During the trial, each carrier measured this delay time based on SIP protocol, so called "Answer Delay time" defined as elapsed time between requesting a call('INVITE' message) and receiving a response('200OK'message)[7]. Lim, et.al. Expires - September 27, 2007 [Page 5] Call Type ENUM Non-ENUM Carrier A->A 2.33 2.28 Carrier A->B 2.23 2.25 Carrier A->other(PSTN) 4.11 3.79 Carrier B->B 2.18 2.05 Carrier B->A 2.19 2.19 Carrier B->other(PSTN) 3.95 3.41 Table 1 : Average Answer Delay time (sec) As it shown on Table 1, there are few difference for time(under a sec) between ENUM and Non-ENUM case. Therefore a caller of each carrier is hard to feel the difference as aspect of quality when a call initiates. It means ENUM definitely works well with softswitch on commercial basis. To make the trial more realistic, The resolver that was used by ENUM- based softswitch was a recursive nameserver can be accessed publicly, just because a tough condition would be better for verify the fact that a ENUM-based softswitch works as much as Non-ENUM softswitch providing a commercial VoIP service. 6.'e164.arpa' consideration During the trial, Infrastructure ENUM deployed on ?.8.e164.arpa? zone that could be accessible from public internet. With this condition, each carrier had a question whether the centralized number management under the ENUM DNS is a realistic or not. Sometimes it is ambiguous to draw the line among carriers in the aspect of responsibility for number management. In addition, they also had a question why Infrastructure ENUM needs to be accessible publicly. To prevent disclosure of telephone number, they prefer to access the ENUM DNS privately. Therefore ENUM module embedded on softswitch is need to be flexible to adopt these considerations during the interim period of ENUM. 7.Security consideration This document basically follows the same security consideration of RFC3761 and 'draft-ietf-enum-infrastructure-05.txt'[6] because the ENUM DNS could be accessed from public internet. In addition, If the recursive DNS handles ENUM queries coming from softswitch is compromised by attacker, It will be able to fail a call or occur delay to call. Therefore, recursive DNS may let in the local network as same as softswitch, and restrict access from outside with proper access-list policy. Lim, et.al. Expires - September 27, 2007 [Page 6] 8.IANA Considerations This document is only advisory, and does not include any IANA considerations. 9.References 9.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. [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [6] J. Livingood, Pfautz, P., R. Stastny, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM", draft-ietf-enum- infrastructure-05, Jan 2007. 9.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 10.Acknowledgments Thanks to Richard Shockey, Jason Livingood and Karsten Fleischhauer who helped guide the direction of this document. Lim, et.al. Expires - September 27, 2007 [Page 7] Author's Addresses JoonHyung Lim National Internet Development Agency of Korea(NIDA) 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 Development Agency of Korea(NIDA) 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 ChanKi Park National Internet Development Agency of Korea(NIDA) 3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu Seoul, Korea Phone: +82-2-2186-4504 Email: ckp@nida.or.kr URI: http://www.nida.or.kr Full 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. 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. 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 Lim, et.al. Expires - September 27, 2007 [Page 8] 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Lim, et.al. Expires - September 27, 2007 [Page 9]