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]