Operational Requirements for ENUM-Based Softswitch Use
draft-ietf-enum-softswitch-req-04

ENUM                                                              J. Lim
Internet-Draft                                                    W. Kim
Intended status: Informational                                   C. Park
Expires: January 10, 2009                                           NIDA
                                                               L. Conroy
                                                                    RMRL
                                                            July 9, 2008

         Operational Requirements for ENUM-Based Softswitch Use
                <draft-ietf-enum-softswitch-req-04.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 January 10, 2009.

Lim, et al.             Expires January 10, 2009                [Page 1]
Internet-Draft          Enum-Based Softswitch Use              July 2008

Abstract

   This document describes experiences of operational requirements and
   several considerations for ENUM-based softswitches concerning call
   routing between two Korean VoIP carriers, gained during the ENUM pre-
   commercial trial hosted by National Internet Development Agency of
   Korea (NIDA) in 2006.

   These experiences show that an interim solution can maintain the
   stability of on-going 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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Call Routing on Softswitch . . . . . . . . . . . . . . . . . .  4
   3.  Infrastructure ENUM trial in Korea . . . . . . . . . . . . . .  5
   4.  Operational Requirements for ENUM-based Softswitches . . . . .  6
     4.1.  Call routing cases for DNS response codes  . . . . . . . .  6
       4.1.1.  Trial Policies . . . . . . . . . . . . . . . . . . . .  6
       4.1.2.  Trial ENUM Lookup Rules  . . . . . . . . . . . . . . .  7
     4.2.  Call routing cases for domainparts . . . . . . . . . . . .  8
   5.  Trial Results  . . . . . . . . . . . . . . . . . . . . . . . . 11
   6.  'e164.arpa' considerations . . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     10.2. Informative References . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 19

Lim, et al.             Expires January 10, 2009                [Page 2]
Internet-Draft          Enum-Based Softswitch Use              July 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-
   user's communications 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 has resulted in two documents, the updated ENUM specification
   [draft-rfc3761bis] and an Enumservice guide
   [draft-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 2.8.e164.arpa.
   (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
   scheme).

Lim, et al.             Expires January 10, 2009                [Page 3]
Internet-Draft          Enum-Based Softswitch Use              July 2008

2.  Call Routing on Softswitch

   In the PSTN (Public Switched Telephone Network), hardware-based
   switches predominate in the network.  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], MGCP [RFC3435], and others), to make call
   connections for VoIP service, often on the boundary point between the
   circuit and packet network.

   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.

Lim, et al.             Expires January 10, 2009                [Page 4]
Internet-Draft          Enum-Based Softswitch Use              July 2008

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 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 [RFC2136].

   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.

                                    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

Lim, et al.             Expires January 10, 2009                [Page 5]
Internet-Draft          Enum-Based Softswitch Use              July 2008

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

   Thus no data needed to be provisioned at all 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,

Lim, et al.             Expires January 10, 2009                [Page 6]
Internet-Draft          Enum-Based Softswitch Use              July 2008

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

   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:

Lim, et al.             Expires January 10, 2009                [Page 7]
Internet-Draft          Enum-Based Softswitch Use              July 2008

           +  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
              number is valid, can only be reached via the Internet, but
              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
              values in the NAPTR Resource Record Set, and routes the
              call using the method described in Section 4.2.

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

Lim, et al.             Expires January 10, 2009                [Page 8]
Internet-Draft          Enum-Based Softswitch Use              July 2008

   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.

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

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

Lim, et al.             Expires January 10, 2009                [Page 9]
Internet-Draft          Enum-Based Softswitch Use              July 2008

           [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 hereafter 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 on-going commercial VoIP service.

Lim, et al.             Expires January 10, 2009               [Page 10]
Internet-Draft          Enum-Based Softswitch Use              July 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
   softswitch 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 non-ENUM-based softswitch in providing a
   commercial VoIP service.

Lim, et al.             Expires January 10, 2009               [Page 11]
Internet-Draft          Enum-Based Softswitch Use              July 2008

6.  'e164.arpa' considerations

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

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

Lim, et al.             Expires January 10, 2009               [Page 12]
Internet-Draft          Enum-Based Softswitch Use              July 2008

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.

Lim, et al.             Expires January 10, 2009               [Page 13]
Internet-Draft          Enum-Based Softswitch Use              July 2008

8.  IANA Considerations

   This document is only advisory, and does not have any IANA
   considerations.

Lim, et al.             Expires January 10, 2009               [Page 14]
Internet-Draft          Enum-Based Softswitch Use              July 2008

9.  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 helpful.

Lim, et al.             Expires January 10, 2009               [Page 15]
Internet-Draft          Enum-Based Softswitch Use              July 2008

10.  References

10.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",
              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.

10.2.  Informative References

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

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

   [draft-enumservice-guide]

Lim, et al.             Expires January 10, 2009               [Page 16]
Internet-Draft          Enum-Based Softswitch Use              July 2008

              Hoeneisen, B., Mayrhofer, A., and J. Livingood, "Guide and
              Template for IANA Registrations of Enumservices",
              draft-ietf-enum-enumservices-guide-10.txt (work in
              progress), May 2008.

   [draft-rfc3761bis]
              Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
              Uniform Resource Identifiers (URI) Dynamic Delegation
              Discovery System (DDDS) Application (ENUM)",
              draft-ietf-enum-rfc3761bis-03.txt (work in progress),
              February 2008.

Lim, et al.             Expires January 10, 2009               [Page 17]
Internet-Draft          Enum-Based Softswitch Use              July 2008

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

   Lawrence Conroy
   Roke Manor Research
   Roke Manor
   Old Salisbury Lane
   Romsey
   United Kingdom

   Phone: +44-1794-833666
   Email: lconroy@insensate.co.uk
   URI:   http://www.sienum.co.uk

Lim, et al.             Expires January 10, 2009               [Page 18]
Internet-Draft          Enum-Based Softswitch Use              July 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
   "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
   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.

Lim, et al.             Expires January 10, 2009               [Page 19]