One document matched: draft-ietf-enum-softswitch-req-04.xml

<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='http://greenbytes.de/tech/webdav/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc strict="yes"?>
<?rfc sortrefs="yes"?>
<rfc ipr="full3978" category="info" docName="<draft-ietf-enum-softswitch-req-04.txt>">
<front>
<title abbrev="Enum-Based Softswitch Use">Operational Requirements for ENUM-Based Softswitch Use</title>

<!-- ************** JoonHong Lim ***************-->
<author initials="J." surname="Lim" fullname="JoonHyung Lim">
<organization abbrev="NIDA">National Internet Development Agency of Korea(NIDA)</organization>
<address>
    <postal>
        <street>3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu</street>
        <city>Seoul</city>
        <country>Korea</country>
    </postal>
    <phone>+82-2-2186-4548</phone>
    <email>jhlim@nida.or.kr</email>
   <uri>http://www.nida.or.kr</uri>
</address>
</author>

<!-- ************** Weon Kim ***************-->
<author initials="W." surname="Kim" fullname="Weon Kim">
<organization abbrev="NIDA">National Internet Development Agency of Korea(NIDA)</organization>
<address>
    <postal>
        <street>3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu</street>
        <city>Seoul</city>
        <country>Korea</country>
    </postal>
    <phone>+82-2-2186-4502</phone>
    <email>wkim@nida.or.kr</email>
   <uri>http://www.nida.or.kr</uri>
</address>
</author>


<!-- ************** ChanKi Park ***************-->
<author initials="C." surname="Park" fullname="ChanKi Park">
<organization abbrev="NIDA">National Internet Development Agency of Korea(NIDA)</organization>
<address>
    <postal>
        <street>3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu</street>
        <city>Seoul</city>
        <country>Korea</country>
    </postal>
    <phone>+82-2-2186-4504</phone>
    <email>ckp@nida.or.kr</email>
   <uri>http://www.nida.or.kr</uri>
</address>
</author>

<!-- ************** Lawrence Conroy ***************-->
<author initials="L." surname="Conroy" fullname="Lawrence Conroy">
<organization abbrev="RMRL">Roke Manor Research</organization>
<address>
    <postal>
        <street>Roke Manor</street>
        <street>Old Salisbury Lane</street>
        <city>Romsey</city>
        <country>United Kingdom</country>
    </postal>
    <phone>+44-1794-833666</phone>
    <email>lconroy@insensate.co.uk</email>
    <uri>http://www.sienum.co.uk</uri>
</address>
</author>

<date month="July" year="2008" />
<area>Applications</area>
<workgroup>ENUM</workgroup>
<keyword>DNS</keyword>
<keyword>E.164</keyword>
<keyword>NAPTR</keyword>
<keyword>Softswitch</keyword>
<keyword>Internet-Draft</keyword>
<keyword>Field Trial</keyword>

<abstract>
<t>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.</t>

<t>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.</t>
</abstract>

</front>


<middle>

<section anchor="intro" title="Introduction">

<t>ENUM <xref target="RFC3761"></xref> is a mapping system based on DNS <xref target="RFC1034"></xref> <xref target="RFC1035"></xref> that converts from an E.164 <xref target="E164"></xref> number to a domain name using the <xref target="RFC3403">Naming Authority Pointer (NAPTR)</xref> 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.</t>

<t>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.
<vspace blankLines='0' />
This has resulted in two documents, <xref target="draft-rfc3761bis"> the updated ENUM specification </xref> and <xref target="draft-enumservice-guide"> an Enumservice guide </xref>.</t>

<t>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.</t>

<t>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).</t>

</section>

<section anchor="callRouting" title="Call Routing on Softswitch">  
<t>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 <xref target="RFC3261"></xref>, H.323 <xref target="H323"></xref>, MGCP <xref target="RFC3435"></xref>, and others), to make call connections for VoIP service, often on the boundary point between the circuit and packet network.</t>

<t>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.</t>

<t>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. </t>

</section>

<section anchor="infraTrial" title="Infrastructure ENUM trial in Korea">

<t>As described in <xref target='intro'></xref>, 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 <xref target="RFC4114"></xref> 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 <xref target="RFC2136"></xref>.</t>

<t>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.</t>

<figure anchor="Figure-1" title="Infrastructure ENUM Trial System Topology">
<artwork>
                                 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
</artwork>
</figure>

</section>

<section anchor="ssRequirements" title="Operational Requirements for ENUM-based Softswitches">

<section anchor="callRoutingOnDNScode" title="Call routing cases for DNS response codes">

<t>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.</t>

<t>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.</t>

<section anchor="trialPolicies" title="Trial Policies">

<t>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.</t>

<t>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.</t>

<t>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.</t>

<t>The case where a valid URI was present is covered in <xref target='trialRules'></xref> 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 <xref target='trialRules'></xref> rule 2 B. </t>

<t>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 <xref target='trialRules'></xref> rule 2 A, second point.</t>

<t>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 <xref target='trialRules'></xref> 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.</t>

<t>Where a valid URI was provisioned, the ENUM lookup would complete by returning that value for further processing. This further processing is covered in <xref target="routingtype"></xref>.</t>

<t>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.</t>

<t>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.</t>

</section>

<section anchor ="trialRules" title="Trial ENUM Lookup Rules">
<t>In the Korean trial, the rules were:

<list style="numbers">
 <t>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).</t>

 <t>The ENUM module, acting as a DNS stub resolver, sends a query to a recursive name server.</t>

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

  <list style="letters">
   <t>Rcode=0 (No error condition)<vspace blankLines='0' />
   There is, potentially, an answer to the corresponding query. The normal call routing process needs to differentiate between the following conditions:
    <list style="symbols">
     <t>The response includes no URI (such as SIP or H.323) that can be used to initiate a call - <vspace blankLines='0' />
     The call fails immediately.<vspace blankLines='0' />
     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.</t>
     <t>There is at least one usable URI (such as SIP and/or H.323 URIs) - <vspace blankLines='0' />
     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 <xref target="routingtype"></xref>.</t>
    </list>
   </t>
   <t>Rcode=3 (Name error), 1 (Format Error), 2 (Server Failure), 4 (Not Implemented) or 5 (Refused)<vspace blankLines='0' />
   There is no valid answer for the query.<vspace blankLines='0' />
   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.<vspace blankLines='1' />
   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.
   <vspace blankLines='0' />
   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.</t>

  </list>
 </t>
</list>
</t>
</section>
</section>

<section anchor="routingtype" title="Call routing cases for domainparts">

<t>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.</t>

<t>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.</t>

<t>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. </t>

<t>These two types of domain routing are also affected by the Rcode=0 case described in <xref target="callRoutingOnDNScode"></xref>.</t>
 
<t>There are two choices for routing. These are described and compared here:
 <list style="numbers">
  <t>Case when using a fixed routing table:
   <list style="letters">
    <t>If the domain name part of the URI is found in the internal fixed routing table, the softswitch can use it.</t>
    <t>If the domain name part of URI does not exist in the fixed routing table, the call is forwarded to the PSTN.</t>
   </list>
  </t>
  <t>Case when using a recursive nameserver:
   <list style="letters">
    <t>If the domain name part of the URI can be resolved via the recursive nameserver, the softswitch can use it.</t>
    <t>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 <xref target="RFC3263"></xref> and <xref target="RFC3261"></xref>, or with Rcode=1, 2, 3, 4, or 5), the call must be forwarded to the PSTN.</t>
   </list>
  </t>
 </list>
</t>

<t>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.</t>

<t>With these choices, the two carriers could use ENUM DNS for call routing without any impact on their on-going commercial VoIP service.</t>
</section>

</section>

<section anchor="results" title="Trial Results">

<t>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) <xref target="RFC3261"></xref>.</t>

<texttable anchor='Table-1' title="Average Answer Delay time (sec)">
 <ttcol align='center'>Call Type</ttcol>
 <ttcol align='center'>ENUM</ttcol>
 <ttcol align='center'>Non-ENUM</ttcol>
  <c>Carrier A->A</c>
  <c>2.33</c>
  <c>2.28</c>

  <c>Carrier A->B</c>
  <c>2.23</c>
  <c>2.25</c>

  <c>Carrier A->other(PSTN)</c>
  <c>4.11</c>
  <c>3.79</c>

  <c>Carrier B->B</c>
  <c>2.18</c>
  <c>2.05</c>

  <c>Carrier B->A</c>
  <c>2.19</c>
  <c>2.19</c>

  <c>Carrier B->other(PSTN)</c>
  <c>3.95</c>
  <c>3.41</c>
</texttable>

<t>As shown in <xref target="Table-1"></xref>, 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.</t>

<t>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.</t>

</section>

<section anchor="zoneCons" title="'e164.arpa' considerations">
 
<t>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.</t>

<t>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.</t>

<t>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.</t>

</section>

<section anchor="secCons" title="Security Considerations">

<t>This document inherits the security considerations described in RFC 3761 and <xref target="RFC5067"></xref>, as the ENUM DNS used with softswitches in this trial could be accessed publicly.</t>

<t>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.</t>

</section>
 
<section anchor="ianaCons" title="IANA Considerations">

<t>This document is only advisory, and does not have any IANA considerations.</t>

</section>

<section anchor="acks" title="Acknowledgements">

<t>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.</t>

</section>

</middle>

<back>

<references title='Normative References'>

<reference anchor="RFC3761">
<front>
<title>The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)</title>
<author initials="P." surname="Faltstrom" fullname="Patrick Faltsrom">
<organization />
<address>
<postal><street /><city /><region /><code /><country /></postal>
<phone /><facsimile /><email /><uri />
</address>
</author>
<author initials="M." surname="Mealling" fullname="Micheal Mealling">
<organization />
<address>
<postal><street /><city /><region /><code /><country /></postal>
<phone /><facsimile /><email /><uri />
</address>
</author>
<date month="April" year="2004" />
</front>
<seriesInfo name="RFC" value="3761" />
</reference>

<reference anchor="E164">
<front>
<title>The International Public Telecommunication Number Plan</title>
<author>
<organization abbrev="ITU-T">ITU-T</organization>
<address>
<postal><street /><city /><region /><code /><country /></postal>
<phone /><facsimile /><email /><uri />
</address>
</author>
<date month="February" year="2005" />
</front>
<seriesInfo name="Recommendation" value="E.164" />
</reference>

<reference anchor="RFC1034">
<front>
<title> DOMAIN NAMES - CONCEPTS AND FACILITIES </title>
<author initials="P." surname="Mockapetris" fullname="">
<organization/>
<address>
<postal><street /><city /><region /><code /><country /></postal>
<phone /><facsimile /><email /><uri />
</address>
</author>
<date year="1987" month="November"/>
</front>
<seriesInfo name="RFC" value="1034" />
<format type='TXT' target='http://www.ietf.org/rfc/rfc1034.txt' />
</reference>

<reference anchor='RFC1035'>
<front>
<title abbrev='Domain Implementation and Specification'>Domain names - implementation and specification</title>
<author initials='P.' surname='Mockapetris' fullname='P. Mockapetris'>
<organization>USC/ISI</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country></postal>
<phone>+1 213 822 1511</phone></address></author>
<date year='1987' day='1' month='November' /></front>
<seriesInfo name='STD' value='13' />
<seriesInfo name='RFC' value='1035' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc1035.txt' />
</reference>

<reference anchor="RFC3403">
<front>
<title>Dynamic Delegation Discovery System (DDDS) 
Part Three: The Domain Name System (DNS) Database</title>
<author initials="M." surname="Mealling" fullname="Micheal Mealling">
<organization />
<address>
<postal><street /><city /><region /><code /><country /></postal>
<phone /><facsimile /><email /><uri />
</address>
</author>
<date month="October" year="2002" />
</front>
<seriesInfo name="RFC" value="3403" />
</reference>

<!--
<reference anchor='RFC3986'>
<front>
<title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization>W3C/MIT</organization>
</author>
<author initials='R.T.' surname='Fielding' fullname='Roy T. Fielding'>
<organization>Day Software</organization>
</author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization>Adobe Systems</organization>
</author>
<date year='2005' month='January' />
</front>
<seriesInfo name='RFC' value='3986' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc3986.txt' />
</reference>
-->

</references>

<references title='Informative References'>

<reference anchor='RFC5067'>
<front>
<title>Infrastructure ENUM Requirements</title>
<author initials='S.' surname='Lind' fullname='Steven Lind'>
<organization /></author>
<author initials='P.' surname='Pfautz' fullname='Penn Pfautz'>
<organization /></author>
<date year='2007' month='November' />
</front>
<seriesInfo name='RFC' value='5067' />
</reference>

<!-- note - although the reference should be to the following draft, that merely inherits its security considerations from the RFC above, so the ref has been changed to RFC 5067, "cutting out the middleman" -->

<!--<reference anchor="draft-enum-infrastructure">
<front>
<title abbrev="Infrastructure ENUM">The E.164 to Uniform 
Resource Identifiers (URI) Dynamic Delegation Discovery System 
(DDDS) Application for Infrastructure ENUM</title>
<author initials="J." surname="Livingood" fullname="Jason Livingood">
<organization />
</author>
<author initials="P." surname="Pfautz" fullname="Penn Pfautz">
<organization />
</author>
<author initials="R." surname="Stastny" fullname="Richard Stastny">
<organization />
</author>
<date year="2007" month="November" />
</front>
<seriesInfo name="draft" value="ietf-enum-infrastructure-07.txt (work in progress)" />
<format type='TXT' target="http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-07.txt" />
</reference>
-->

<reference anchor="draft-rfc3761bis">
<front>
<title abbrev="E.164 to URI DDDS Application">The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
</author>
<author initials="L." surname="Conroy" fullname="Lawrence Conroy">
<organization>Roke Manor Research</organization>
</author>
<author initials="K." surname="Fujiwara" fullname="Kazunori Fujiwara">
<organization>Japan Registry Service Co., Ltd.</organization>
</author>
<date year="2008" month="February" />
</front>
<seriesInfo name="internet-draft" value="draft-ietf-enum-rfc3761bis-03.txt" />
</reference>

<reference anchor="draft-enumservice-guide">
<front>
<title>Guide and Template for IANA Registrations of Enumservices</title>
<author initials="B." surname="Hoeneisen" fullname="Bernie Hoeneisen">
<organization>SWITCH</organization>
</author>
<author initials="A." surname="Mayrhofer" fullname="Alexander Mayrhofer">
<organization>enum.at GmbH</organization>
</author>
<author initials="J." surname="Livingood" fullname="Jason Livingood">
<organization>Comcast Cable Communications</organization>
</author>
<date year="2008" month="May" />
</front>
<seriesInfo name="internet-draft" value="draft-ietf-enum-enumservices-guide-10.txt" />
</reference>

<reference anchor='RFC3261'>
<front>
<title>SIP: Session Initiation Protocol</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'>
<organization /></author>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'>
<organization /></author>
<author initials='G.' surname='Camarillo' fullname='G. Camarillo'>
<organization /></author>
<author initials='A.' surname='Johnston' fullname='A. Johnston'>
<organization /></author>
<author initials='J.' surname='Peterson' fullname='J. Peterson'>
<organization /></author>
<author initials='R.' surname='Sparks' fullname='R. Sparks'>
<organization /></author>
<author initials='M.' surname='Handley' fullname='M. Handley'>
<organization /></author>
<author initials='E.' surname='Schooler' fullname='E. Schooler'>
<organization /></author>
<date year='2002' month='June' />
</front>
<seriesInfo name='RFC' value='3261' />
<format type='TXT' octets='647976' target='http://www.ietf.orgrfc/rfc3261.txt' />
</reference>

<reference anchor="H323">
<front>
<title>Packet-based multimedia communications systems</title>
<author>
<organization abbrev="ITU-T">ITU-T</organization>
<address>
<postal><street /><city /><region /><code /><country /></postal>
<phone /><facsimile /><email /><uri />
</address>
</author>
<date year="2003" />
</front>
<seriesInfo name="Recommendation" value="H.323" />
</reference>

<reference anchor='RFC3435'>
<front>
<title>Media Gateway Control Protocol (MGCP) Version 1.0</title>
<author initials='F.' surname='Andreasen' fullname='F. Andreasen'>
<organization /></author>
<author initials='B.' surname='Foster' fullname='B. Foster'>
<organization /></author>
<date year='2003' month='January' />
</front>
<seriesInfo name='RFC' value='3435' />
<format type='TXT' octets='467084' target='http://www.ietf.org/rfc/rfc3435.txt' />
</reference>

<reference anchor='RFC4114'>
<front>
<title>E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)</title>
<author initials='S.' surname='Hollenbeck' fullname='S. Hollenbeck'>
<organization /></author>
<date year='2005' month='June' />
</front>
<seriesInfo name='RFC' value='4114' />
<format type='TXT' octets='31490' target='http://www.ietf.org/rfc/rfc4114.txt' />
</reference>

<reference anchor='RFC2136'>
<front>
<title abbrev='DNS Update'>Dynamic Updates in the Domain Name System (DNS UPDATE)</title>
<author initials='P.' surname='Vixie' fullname='Paul Vixie'>
<organization>Internet Software Consortium</organization>
<address>
<postal>
<street>Star Route Box 159A</street>
<street>Woodside</street>
<street>CA 94062</street></postal>
<phone>+1 415 747 0204</phone>
<email>paul@vix.com</email></address></author>
<author initials='S.' surname='Thomson' fullname='Susan Thomson'>
<organization>Bellcore</organization>
<address>
<postal>
<street>445 South Street</street>
<street>Morristown</street>
<street>NJ 07960</street></postal>
<phone>+1 201 829 4514</phone>
<email>set@thumper.bellcore.com</email></address></author>
<author initials='Y.' surname='Rekhter' fullname='Yakov Rekhter'>
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<street>CA 95134-1706</street></postal>
<phone>+1 914 528 0090</phone>
<email>yakov@cisco.com</email></address></author>
<author initials='J.' surname='Bound' fullname='Jim Bound'>
<organization>Digital Equipment Corp.</organization>
<address>
<postal>
<street>110 Spitbrook Rd ZK3-3/U14</street>
<street>Nashua</street>
<street>NH 03062-2698</street></postal>
<phone>+1 603 881 0400</phone>
<email>bound@zk3.dec.com</email></address></author>
<date year='1997' month='April' />
<area>Applications</area>
<keyword>domain name</keyword>
<keyword>domain name system</keyword>
</front>
<seriesInfo name='RFC' value='2136' />
<format type='TXT' octets='56354' target='ftp://ftp.isi.edu/in-notes/rfc2136.txt' />
<format type='HTML' octets='67722' target='http://xml.resource.org/public/rfc/html/rfc2136.html' />
<format type='XML' octets='54818' target='http://xml.resource.org/public/rfc/xml/rfc2136.xml' />
</reference>

<reference anchor='RFC3263'>
<front>
<title abbrev='Locating SIP Servers'>Session Initiation Protocol (SIP): Locating SIP Servers</title>
<author initials='J.' surname='Rosenberg' fullname='Jonathon Rosenberg'>
<organization /><address />
</author>
<date year='2002' month='June' />
</front>
<seriesInfo name='RFC' value='3263' />
</reference>

</references>

</back>
</rfc>