Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


Network Working Group J. Lim Request for Comments: 5346 W. Kim Category: Informational C. Park

                                                             L. Conroy
                                                          October 2008
       Operational Requirements for ENUM-Based Softswitch Use

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.


 This document describes experiences of operational requirements and
 several considerations for ENUM-based softswitches concerning call
 routing between two Korean Voice over IP (VoIP) carriers, gained
 during the ENUM pre-commercial trial hosted by the National Internet
 Development Agency of Korea (NIDA) in 2006.
 These experiences show that an interim solution can maintain the
 stability of ongoing commercial softswitch system operations during
 the initial stage of ENUM service, where the DNS does not have
 sufficient data for the majority of calls.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
 2.  Call Routing on Softswitch . . . . . . . . . . . . . . . . . .  2
 3.  Infrastructure ENUM Trial in Korea . . . . . . . . . . . . . .  3
 4.  Operational Requirements for ENUM-Based Softswitches . . . . .  4
   4.1.  Call Routing Cases for DNS Response Codes  . . . . . . . .  4
     4.1.1.  Trial Policies . . . . . . . . . . . . . . . . . . . .  4
     4.1.2.  Trial ENUM Lookup Rules  . . . . . . . . . . . . . . .  6
   4.2.  Call Routing Cases for Domainparts . . . . . . . . . . . .  7
 5.  Trial Results  . . . . . . . . . . . . . . . . . . . . . . . .  9
 6.  '' Considerations . . . . . . . . . . . . . . . . . .  9
 7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
 8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
 9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   9.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
   9.2.  Informative References . . . . . . . . . . . . . . . . . . 11

Lim, et al. Informational [Page 1] RFC 5346 Enum-Based Softswitch Use October 2008

1. Introduction

 ENUM [RFC3761] is a mapping system based on DNS [RFC1034] [RFC1035]
 that converts from an E.164 [E164] number to a domain name using the
 Naming Authority Pointer (NAPTR) [RFC3403] resource record type.
 ENUM is able to store different service types (such as fax, email,
 homepage, SIP, H.323 and so on) for every E.164 number.  It
 originally focused on how end-users could gain access to other end-
 users' communication contact information through the Internet.
 Recently, discussion on the need to update RFC 3761 has begun to
 ensure that the standard also works in the "Infrastructure ENUM"
 scenario, where ENUM provides routing information between carriers.
 This resulted in two documents, the updated ENUM specification
 [RFC3761bis] and an Enumservice guide [ENUMSERVICE-GUIDE].
 When providing VoIP service, a VoIP carrier that wants to integrate
 various protocols typically uses a softswitch.  However, such a
 system is still inefficient for interconnection, number portability,
 and sharing protocol support information among carriers, because each
 softswitch does not have complete end-to-end routing information for
 all carriers.  This information can be stored in DNS, using ENUM.
 Therefore, carriers can expect to gain many advantages if they use
 ENUM within the call routing functions of their softswitches.
 To confirm these benefits and to verify the performance of ENUM-
 enabled softswitches, NIDA cooperated with two Korean VoIP service
 providers for an Infrastructure ENUM trial in 2006.  NIDA is a non-
 profit organization with a mandate to manage
 (representing the +82 country code of Korea).  NIDA promotes and
 facilitates technical cooperation on a national scale between
 partners, and this includes ENUM.  During the trial, NIDA provided a
 centralized ENUM DNS to each VoIP service provider for call routing.
 The data used in this Infrastructure trial was also accessible to the
 public (i.e., it was an Internet-based system, rather than a closed

2. Call Routing on Softswitch

 In the PSTN (Public Switched Telephone Network), hardware-based
 switches predominate.  A softswitch provides similar functionality,
 but is implemented on a computer system by software.  It typically
 has to support various signalling protocols (such as SIP [RFC3261],
 H.323 [H323], Media Gateway Control Protocol (MGCP) [RFC3435], and
 others) to make call connections for VoIP service, often on the
 boundary point between the circuit and packet network.

Lim, et al. Informational [Page 2] RFC 5346 Enum-Based Softswitch Use October 2008

 To make a call, first of all a softswitch must discover routing
 information.  It has to process the E.164 number that comes from a
 caller through its own routing table.  The goal is to determine how
 the call can be routed towards the callee, so that either the call
 can be processed through the softswitch or the caller can connect to
 the callee directly.
 Today, call routing is often based on a prefix of the dialled number.
 This is used very widely not only for legacy PSTN switches, but also
 for softswitches.  So, if a softswitch exclusively uses ENUM DNS for
 call routing, then, in the beginning most of the calls queried to
 ENUM DNS would fail if there are only a small group of carriers
 provisioning data into ENUM.  However, a softswitch will have a
 higher success rate with ENUM DNS as the number of carriers grows,
 and so the overall percentage of numbers provisioned in ENUM
 increases.  In short, ENUM as a long-term solution has obvious
 benefits, but the problem lies in migrating from today's prefix-based
 routing towards that long-term ENUM-based solution.

3. Infrastructure ENUM Trial in Korea

 As described in Section 1, NIDA and two VoIP service providers built
 ENUM-processing modules into their softswitches, interconnected these
 via the IP network, and provisioned their trial users' numbers into a
 centralized ENUM DNS system operated by NIDA.  The carriers
 provisioned their E.164 numbers using Extensible Provisioning
 Protocol (EPP) [RFC4114] to a centralized Registration Server (also
 operated by NIDA).  Changes to the ENUM data were implemented and
 updated to the ENUM DNS instantly, using DNS Dynamic Update
 In the trial, the EPP-based provisioning sub-system was developed and
 operated separately from the carriers' main customer provisioning
 systems and protocols.  It was not integrated, as the carriers
 already operated their own customer provisioning systems that were
 totally different from the EPP-based model, and (as mission-critical
 components) those were not open to modification.

Lim, et al. Informational [Page 3] RFC 5346 Enum-Based Softswitch Use October 2008

                                  Call routing
                |                                             |
                |                                             |
          +-----+------+      +-----------------+      +------+-----+
          |Softswitch A|------|  ENUM DNS(+82)  |------|Softswitch B|
          +-----+------+      |    (Tier1,2)    |      +------+-----+
                |             +--------+--------+             |
          +-----+------+               |               +------+-----+
          | IP Phone A |               |Dynamic Update | IP Phone B |
          +------------+               |(RFC 2136)     +------------+
          +------------+      +--------+--------+      +------------+
          | EPP Client |      |  Registration   |      | EPP Client |
          |            |------|     Server      |------|            |
          +------------+      +-----------------+      +------------+
                     Provisioning E.164 Numbers(RFC 4114)
            Carrier A                 NIDA                Carrier B
          Figure 1: Infrastructure ENUM Trial System Topology

4. Operational Requirements for ENUM-Based Softswitches

4.1. Call Routing Cases for DNS Response Codes

 To use ENUM DNS, each softswitch needs to have an ENUM module that
 converts from an E.164 number to the ENUM domain name (as defined in
 RFC 3761) and processes a query to ENUM DNS.  This ENUM module uses
 the algorithm specified in RFC 3761.
 However, in the initial stage of ENUM DNS roll-out, ENUM shares call
 routing information from a limited number of carriers.  There is the
 problem that a softswitch can't find all of the call routing
 information it needs just using ENUM.  To solve this problem, ENUM-
 based softswitches have to follow a consistent set of rules.

4.1.1. Trial Policies

 As a matter of policy in this trial, all telephone numbers in use
 within an "ENUM only" number range (i.e., ones in which an endpoint
 could only be reached via a URI found during an ENUM lookup of a
 telephone number in this range, and for which there was no PSTN Point
 of Interconnect) were arranged to return a NAPTR response.  For
 ranges in which there was a PSTN Point of Interconnect, this was not

Lim, et al. Informational [Page 4] RFC 5346 Enum-Based Softswitch Use October 2008

 Thus, no data (at all) needed to be provisioned into an associated
 ENUM domain for such a number if it were possible to "reach" that
 number via the PSTN, unless there were also an IP-based Point of
 Interconnect serving that number and the serving carrier chose to
 make this option available.
 In those domains in which NAPTRs for ENUM processing were
 provisioned, these NAPTRs were always 'terminal' rules -- non-
 terminal NAPTRs were not used.  If non-terminal NAPTRs were to be
 provisioned, then the standard operation of ENUM processing might
 have required extra DNS lookups before the set of NAPTRs for a
 telephone number could be evaluated.  The delay and indeterminacy
 this would introduce was not considered acceptable.
 The case where a valid URI was present is covered in Section 4.1.2
 (rule 2 A, second point).  The case where an ENUM entry was not
 provisioned for a number that had an active PSTN Point of
 Interconnect is covered in Section 4.1.2 (rule 2 B).
 For "ENUM only" ranges, where a given number in that range was in
 service (i.e., there was an IP-based Point of Interconnect to a
 carrier), a valid SIP or H.323 URI was always provisioned into the
 associated ENUM domain.  This is covered in Section 4.1.2 (rule 2 A,
 second point).
 In such an "ENUM only" range, if the number was not in service, a TXT
 record was provisioned but no valid NAPTRs would be present.  This
 ensured that a query for NAPTRs in a given (out of service, "ENUM
 only" range) domain would succeed (i.e., return a RCODE of 0), but
 that the number of answers would also be zero.  This is covered in
 Section 4.1.2 (rule 2 A, first point).  Note that this point also
 covers the case where only NAPTRs that cannot be used to initiate a
 call exist in such a zone.
 Where a valid URI was provisioned, the ENUM lookup would complete by
 returning that value for further processing.  This further processing
 is covered in Section 4.2.
 For "ENUM only" ranges, there was a further policy requirement that
 an IP-based Point of Interconnect specified inside a NAPTR (as the
 domainpart of a valid URI) must be accessible for all potential
 carriers.  The server could reject a subsequent SIP Invitation, but
 its machine address had to resolve.  This was intended to avoid the
 condition where the domain name did not resolve, the softswitch logic
 would attempt to place the call via the PSTN, and this would fail
 and/or loop.

Lim, et al. Informational [Page 5] RFC 5346 Enum-Based Softswitch Use October 2008

 This "must resolve" requirement was not needed for numbers that had
 an active PSTN Point of Interconnect (i.e., the vast majority of
 assigned numbers).  If the domain name did not resolve, the call
 would "drop back" to PSTN processing.

4.1.2. Trial ENUM Lookup Rules

 In the Korean trial, the rules were:
 1.  The ENUM module of the softswitch converts an E.164 number coming
     from the VoIP subscriber to an ENUM domain name (as defined in
     RFC 3761).
 2.  The ENUM module, acting as a DNS stub resolver, sends a query to
     a recursive name server.
 3.  If the ENUM module receives a DNS answer, the call routing
     process may branch off in several ways, depending on the Rcode
     value in the DNS response message, as shown below.
     A.  Rcode=0 (No error condition)
         There is, potentially, an answer to the corresponding query.
         The normal call routing process needs to differentiate
         between the following conditions:
         +  The response includes no URI (such as SIP or H.323) that
            can be used to initiate a call --
            The call fails immediately.
            Note: In the trial, the condition in which a telephone
  1. is valid,
  1. can only be reached via the Internet, but
  1. is not currently in service
            is indicated by an ENUM domain that DOES exist but DOES
            NOT include any supported (routable) NAPTRs.  A softswitch
            receiving this response interprets it as indicating that
            the call can be dropped immediately -- it would fail if
            passed to the PSTN.
         +  There is at least one usable URI (such as SIP and/or H.323
            URIs) --
            The softswitch picks one based on the preference and order
            field values in the NAPTR Resource Record Set, and routes
            the call using the method described in Section 4.2.

Lim, et al. Informational [Page 6] RFC 5346 Enum-Based Softswitch Use October 2008

     B.  Rcode=3 (Name error), 1 (Format Error), 2 (Server Failure), 4
         (Not Implemented), or 5 (Refused)
         There is no valid answer for the query.
         The softswitch has no choice but to route the call using the
         E.164 number with its vendor-specific method (such as a
         prefix-based method).  In this case, it means that the call
         has to be delivered through the PSTN for onward call routing.
         It is also important to stress that the ENUM DNS servers must
         respond to all queries they receive from the softswitches.
         If the ENUM module in a softswitch does not receive a
         response, it will eventually time out, and the ENUM module
         will treat this as a DNS error.  However, the delay involved
         is long in terms of the normal call setup time, and should be
         It would have been possible to modify the DNS code in each
         softswitch to have shorter time-outs than normal to cover
         misconfiguration of a DNS server, but this choice was not
         considered in the trial.  The softswitch DNS stack was used
         for several purposes other than "pure" ENUM lookups.
         Configuring it in a non-complaint manner was considered
         unacceptable, due to the need to analyze the impact of that
         choice on other DNS operations thoroughly before it could be
         implemented safely.

4.2. Call Routing Cases for Domainparts

 If the DNS response has a valid URI, such as SIP or H.323, the
 softswitch can resolve the domain name part of that URI to route a
 call by searching two different sources.  One is a recursive
 nameserver, and the other is a fixed routing table held in the
 softswitch, mapping from the domain name to the corresponding
 gateway's host name and IP address.
 If there are many points of interconnection, using a recursive
 nameserver is useful for resolving a domain name, but if there are
 just a few known carriers and they do not change this interconnection
 information frequently, a fixed (internal) routing table mapping from
 domain name to the corresponding gateway hostname and IP address is
 more efficient (rather than querying the recursive nameserver every
 time).  In addition, carriers would like to charge an interconnection
 fee for all received calls, so they tend to make interconnection only
 with trusted carriers based on some sort of bilateral agreement
 between these carriers.  They may agree on a specific gateway for
 this purpose, so the interconnection information is often private to
 the parties of this particular agreement.

Lim, et al. Informational [Page 7] RFC 5346 Enum-Based Softswitch Use October 2008

 In principle, these two approaches could be used in parallel, but in
 practice, if the DNS-based approach could be used, there would be no
 point in retaining the expensive and elaborate "offline"
 infrastructure to exchange and install the tables for domain routing.
 In this trial, uncertainty over the performance and reliability of
 ENUM-based processing meant that the softswtitches were configured so
 that they could be switched between the two approaches immediately.
 This was a temporary expedient only, and would not be a reasonable
 approach in the long term.
 These two types of domain routing are also affected by the Rcode=0
 case described in Section 4.1.
 There are two choices for routing.  These are described and compared
 1.  Case when using a fixed routing table:
     A.  If the domain name part of the URI is found in the internal
         fixed routing table, the softswitch can use it.
     B.  If the domain name part of the URI does not exist in the
         fixed routing table, the call is forwarded to the PSTN.
 2.  Case when using a recursive nameserver:
     A.  If the domain name part of the URI can be resolved via the
         recursive nameserver, the softswitch can use it.
     B.  If the domain name part of the URI cannot be resolved on the
         recursive nameserver for any reason (such as a response with
         no usable resource records according to [RFC3263] and
         [RFC3261], or with Rcode=1, 2, 3, 4, or 5), the call must be
         forwarded to the PSTN.
 Case (1) seems inefficient because the administrator maintains two
 management points for numbers: the ENUM DNS and the softswitch
 itself.  However, this configuration can minimize the call routing
 failure ratio during the transition period of ENUM (when there are
 relatively few provisioned ENUM entries and so few IP-based Points Of
 Interconnection).  Thus, case (1) could reasonably be implemented on
 the softswitches during the trial phase, and thereafter, as ENUM
 entries are populated, case (2) would be a reasonable choice.
 With these choices, the two carriers could use ENUM DNS for call
 routing without any impact on their ongoing commercial VoIP service.

Lim, et al. Informational [Page 8] RFC 5346 Enum-Based Softswitch Use October 2008

5. Trial Results

 To provide a stable commercial service, an ENUM-based softswitch must
 have a defined performance, in the same way as must any non-ENUM-
 based softswitch.  The only difference between these two types of
 softswitches is the searching mechanism for call routing information,
 which can be stored in the softswitch itself or in the DNS.
 Therefore, a similar delay time for call routing is important to
 guarantee quality of service.  During the trial, each carrier
 measured this delay time when using the SIP protocol.  This was based
 on the "Answer Delay time", defined as the elapsed time between
 requesting a call ('INVITE' message) and receiving a response ('200
 OK' message) [RFC3261].
             |        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 shown in Table 1, there is little difference in time (under a
 second) between the ENUM and non-ENUM cases.  Therefore, it is
 difficult for a caller with either carrier to detect the choice (ENUM
 or non-ENUM) as an aspect of quality when a call initiates.  This
 means that ENUM definitely works well with softswitches on a
 commercial basis.
 To make the trial more realistic, the resolver that was used by these
 ENUM-based softswitches was a recursive nameserver that could be
 accessed publicly.  This was done as it was felt that a tough
 condition would be better to verify the fact that an ENUM-based
 softswitch works as well as a non-ENUM-based softswitch in providing
 a commercial VoIP service.

6. '' Considerations

 During the trial, the Infrastructure ENUM deployed in the zone could be accessed via the (public) Internet.  In
 this situation, each carrier questioned whether or not the
 centralized number management under the ENUM DNS was realistic.

Lim, et al. Informational [Page 9] RFC 5346 Enum-Based Softswitch Use October 2008

 Another issue concerned responsibility for routing errors.  All
 carriers can use the shared ENUM data to route their calls.  However,
 if there are routing errors (due to the data being provisioned
 incorrectly), it is not always clear who has responsibility for these
 errors and who can correct the data.  The errors occur in the
 networks of the carriers placing the calls.  Unless the identity of
 the carrier responsible for delivering service to this telephone
 number is known, it is not obvious (to the carrier handling the
 error) who should be informed of these problems.  This is a
 particular issue when number portability is introduced.
 In addition, the carriers also question whether or not Infrastructure
 ENUM needs to be accessible publicly.  To prevent disclosure of
 telephone numbers, they would prefer to access the ENUM DNS
 privately.  Therefore, any ENUM module embedded in a softswitch needs
 to be flexible to adopt these considerations during the interim
 period of ENUM, before common policies and agreements have been

7. Security Considerations

 This document inherits the security considerations described in RFC
 3761 and [RFC5067], as the ENUM DNS used with softswitches in this
 trial could be accessed publicly.
 In addition, if the recursive resolvers handling ENUM queries coming
 from a softswitch were to be compromised by an attacker, that
 attacker would be able to force calls to fail or cause delay to
 calls.  Therefore, the DNS resolvers used should allow access from
 the local network to which the softswitch is connected, whilst
 restricting access from outside, using a proper access-list policy.

8. Acknowledgements

 Thanks to Richard Shockey, Jason Livingood, Karsten Fleischhauer, Jim
 Reid, and Otmar Lendl who helped guide the direction of this
 document, and to Suresh Krishnan, whose GEN-ART review was very

Lim, et al. Informational [Page 10] RFC 5346 Enum-Based Softswitch Use October 2008

9. References

9.1. Normative References

 [E164]        ITU-T, "The International Public Telecommunication
               Number Plan", Recommendation E.164, February 2005.
 [RFC1034]     Mockapetris, P., "Domain names - concepts and
               facilities", STD 13, RFC 1034, November 1987.
 [RFC1035]     Mockapetris, P., "Domain names - implementation and
               specification", STD 13, RFC 1035, November 1987.
 [RFC3403]     Mealling, M., "Dynamic Delegation Discovery System
               (DDDS)  Part Three: The Domain Name System (DNS)
               Database", RFC 3403, October 2002.
 [RFC3761]     Faltstrom, P. and M. Mealling, "The E.164 to Uniform
               Resource Identifiers (URI) Dynamic Delegation Discovery
               System (DDDS) Application (ENUM)", RFC 3761,
               April 2004.

9.2. Informative References

               Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA
               Registration of Enumservices: Guide, Template, and IANA
               Considerations", Work in Progress, September 2008.
 [H323]        ITU-T, "Packet-based multimedia communications
               systems", Recommendation H.323, 2003.
 [RFC2136]     Vixie, P., Thomson, S., Rekhter, Y., and J.  Bound,
               "Dynamic Updates in the Domain Name System (DNS
               UPDATE)", RFC 2136, April 1997.
 [RFC3261]     Rosenberg, J., Schulzrinne, H., Camarillo, G.,
               Johnston, A., Peterson, J., Sparks, R., Handley, M.,
               and E. Schooler, "SIP: Session Initiation Protocol",
               RFC 3261, June 2002.
 [RFC3263]     Rosenberg, J., "Session Initiation Protocol (SIP):
               Locating SIP Servers", RFC 3263, June 2002.
 [RFC3435]     Andreasen, F. and B. Foster, "Media Gateway Control
               Protocol (MGCP) Version 1.0", RFC 3435, January 2003.

Lim, et al. Informational [Page 11] RFC 5346 Enum-Based Softswitch Use October 2008

 [RFC3761bis]  Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
               Uniform Resource Identifiers (URI) Dynamic Delegation
               Discovery System (DDDS) Application (ENUM)", Work
               in Progress, February 2008.
 [RFC4114]     Hollenbeck, S., "E.164 Number Mapping for the
               Extensible Provisioning Protocol (EPP)", RFC 4114,
               June 2005.
 [RFC5067]     Lind, S. and P. Pfautz, "Infrastructure ENUM
               Requirements", RFC 5067, November 2007.

Lim, et al. Informational [Page 12] RFC 5346 Enum-Based Softswitch Use October 2008

Authors' Addresses

 JoonHyung Lim
 National Internet Development Agency of Korea(NIDA)
 3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu
 Phone: +82-2-2186-4548
 Weon Kim
 National Internet Development Agency of Korea(NIDA)
 3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu
 Phone: +82-2-2186-4502
 ChanKi Park
 National Internet Development Agency of Korea(NIDA)
 3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu
 Phone: +82-2-2186-4504
 Lawrence Conroy
 Roke Manor Research
 Roke Manor
 Old Salisbury Lane
 United Kingdom
 Phone: +44-1794-833666

Lim, et al. Informational [Page 13] RFC 5346 Enum-Based Softswitch Use October 2008

Full Copyright Statement

 Copyright (C) The IETF Trust (2008).
 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

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
 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
 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

Lim, et al. Informational [Page 14]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5346.txt · Last modified: 2008/10/02 22:52 (external edit)