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]