ETSI ENUM Plugtests™ Final Report Objective

The ETSI ENUM Plugtests event will provide a vendor-neutral setting for equipment manufacturers, operators, ISPs, registries, software companies and systems integrators to carry out controlled interoperability and conformance testing.

Date

30 May - 3 June 2005

Location

ETSI (Einstein Building), France

Number of participants

16 participants from 13 different companies

ETSI ENUM Plugtests™ Final Report

August 2005

Table of Contents 1

INTRODUCTION..................................................................................................................................... 3

1.1 OVERVIEW - A FRAMEWORK FOR ENUM ............................................................................................ 3 1.2 ENUM PLUGTEST GOALS ...................................................................................................................... 3 1.3 ENUM PLUGTEST WORKING PROCEDURES ......................................................................................... 4 1.3.1 ENUM CONSULTATION PROCESS ......................................................................................................... 4 1.3.1.1 Consultation Results........................................................................................................................... 5 2

ENUM – TECHNICAL ASPECTS ......................................................................................................... 6

2.1 2.2 2.3 3

ENUM STORAGE INFRASTRUCTURE ..................................................................................................... 6 ENUM CLIENT PROCESSING ................................................................................................................. 7 NAPTR RESOURCE RECORD ELEMENTS.............................................................................................. 8 ENUM TEST APPROACH.................................................................................................................... 11

3.1 3.2 3.2.1 3.2.2 3.3 3.4

TEST REQUIREMENTS/PREFERENCES ................................................................................................. 11 “BLACK BOX” INSTRUMENTATION METHODS ................................................................................... 11 DNS MONITORING .............................................................................................................................. 12 CALL MONITORING ............................................................................................................................. 12 ENUM TEST SITE INSTRUMENTATION PLAN ..................................................................................... 13 ENUM TEST SITE ARCHITECTURE ..................................................................................................... 13

4

TEST VECTOR DESIGN ...................................................................................................................... 15

5

EXPERIENCES FROM THE FIRST ENUM PLUGTEST................................................................ 19

5.1 5.2 5.3 6

EQUIPMENT CONFIGURATION EXPERIENCES ..................................................................................... 19 ACTUAL TEST VECTOR PROVISIONING............................................................................................... 20 OTHER NOTES ....................................................................................................................................... 21 CONCLUSIONS FROM THE FIRST ENUM PLUGTEST............................................................... 22

APPENDIX 1 – TEST VECTORS USED ................................................................................................... 24 A.1 - TEST VECTORS ...................................................................................................................................... 24 APPENDIX 2 – LIST OF ATTENDEES..................................................................................................... 29 APPENDIX 3 – FORMAL SATISFACTION SURVEY RESULTS ........................................................ 30

Table of Figures Figure 1: Plugtest Network Configuration.........................................................................................13

Total Number of Pages in this Report: 30

Version 1.0

Page 2/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

1

August 2005

Introduction

1.1 Overview - A Framework for ENUM The emerging technology of ENUM is attracting a lot of interest. By mapping telephone numbers to domain names, and from those to URLs, ENUM will be a key driver for the increasing convergence between the internet and telephony worlds. ENUM provides a framework for delivering telephony services with Voice over IP (VoIP) technology using SIP or H.323 servers, integrated messaging solutions, as well as new uses for email and web services. Operators will be able to use ENUM to simplify call routing and number portability mechanisms. ENUM can also offer innovative solutions for inter-operator MMS, multimedia applications and gaming. Relevant standards documents include RFC3761, published by the IETF, and ETSI documents TS 102 051 and TS 102 172. Various segments of the telecommunications industry are planning to invest in ENUM. Trials have taken place in some countries, though these have tended to focus on governance issues, implementation models and the identification of roles and responsibilities. Populating the Domain Name System (DNS) with large volumes of telephone numbers will present challenges, most notably in the areas of provisioning and data management. The ETSI ENUM Plugtests event provided a vendor-neutral setting for equipment manufacturers, operators, ISPs, registries, software companies and systems integrators to carry out controlled interoperability and conformance testing.

1.2 ENUM Plugtest Goals The ETSI ENUM Plugtest event had the following objectives and benefits: •

Execute preliminary ENUM interoperability tests using a network containing a testbed of DNS servers, SIP/H.323 systems, and other ENUM-aware hardware and software.

•

Initiate the formation of a group for organisations who wish to carry out ENUM interoperability testing.

•

Study the behaviour and failure modes of ENUM-aware systems.

•

Suggest best common practices for robust operation and configuration of ENUM-capable systems.

•

Gain insight into operational requirements for real-world deployment of ENUM.

•

Identify potential work items for standards-making bodies.

Version 1.0

Page 3/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

August 2005

1.3 ENUM Plugtest Working Procedures For this first ENUM Plugtest, it was deemed important to gain industry-wide consensus on the kind of testing that would be appropriate at this time, and how such testing could be made widely available. This was necessary because to date no attempt had been made to provide a framework for ENUM interoperability testing in a vendor-neutral setting. As such, the first Plugtest concentrated on developing the test suite and demonstrating its effectiveness rather than on pure conformance testing. Conformance testing, as is typically done for telecommunications standard protocols, is not well matched to Internet protocols, where there are quite wide variations in implementations and yet interoperation is still achieved - using the motto "be liberal in what you accept, but conservative in what you send". Thus the test suite could also be used to guide implementers in the kind of incorrect data that their systems may encounter and will be expected to process, if at all possible. Existing web-based ENUM clients were instrumented to allow analysis of the ENUM zones that were provisioned; logs of the zone contents were used to inform the test vectors produced, and to explore what errors in provisioned zones existed. In addition, it was felt that consultation of those active in standardisation and implementation of ENUM was important. Thus, a set of meetings were arranged to further this consultation.

1.3.1 ENUM Consultation Process An initial meeting was held at Sophia Antipolis in November 2004 to discuss the need for and details of a Plugtest for ENUM. At this meeting, it was decided that there would be a need for such a test within six months, and that the ETSI Plugtest service would be an appropriate neutral body to provide the necessary test environment. Subsequently, the ENUM Plugtest was discussed at the ETSI TISPAN meeting in January 2005 to clarify test requirements and to ensure that this test event would fit with the work being done on specifications for ENUM in TISPAN WG4. A final meeting was held in Vienna in April 2005, with a number of Registries, Registrars and Provisioning system manufacturers active in ENUM trials. Some of the participants in this meeting took part by teleconference. At this meeting it was decided that there were substantial differences between national regulations, the Registry systems (and their Tier 1 Registry / Registrar interfaces). These differed to the point that it would not be feasible for the Plugtest to provide a meaningful test of this interface, nor across the Registry/Validation (or Authentication) Agency interface. Each of these interfaces was unique, which would severely constrain the scope for interoperability testing. The costs of providing these interfaces and repeatedly reconfiguring software for each of them would outweigh any likely benefits from testing them during the limited time available for the Plugtest. It is hoped that as regulatory experience is shared across Europe this situation will change. If so, subsequent ENUM Plugtests can include tests of (at least) a common subset of the protocols used across the Registry / Registrar interface, and potentially across the Registry / Validation & Authentication Entity interface. It was agreed at these preparatory meetings and at the Plugtest that there should be concerted attempts to standardise the registration process where possible, in Version 1.0

Page 4/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

August 2005

particular the architecture and protocol extensions used for validation. This standardisation effort could be done through IETF, possibly in co-operation with ETSI. [Update - since this meeting, a set of extensions to the provisioning interfaces and protocols have been proposed to the IETF, and were presented at the IETF63 meeting in Paris, August 2005]

1.3.1.1

Consultation Results

After consultation at these meetings, it was agreed that the strategy for this first ENUM Plugtest would be to concentrate on the following goals: •

To develop pure ENUM protocol/processing tests,

•

To use these to test available ENUM Clients,

•

Stress-test clients with unusual data sets,

•

To detect common errors and to explore the symptoms exposed with potentially common DNS infrastructure misconfigurations.

As an additional goal, zone contents generated by existing provisioning systems could be compared with the test vectors used, to confirm that those systems did in fact produce valid entries.

Version 1.0

Page 5/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

2

August 2005

ENUM – Technical Aspects

ENUM is a DNS-based mechanism to store Universal Resource Identifiers (URIs) that can be retrieved using an E.164 number as an initial key. ENUM consists of 4 main elements: •

An Input algorithm to convert an E.164 number to a Fully Qualified Domain Name (FQDN).

•

A configured domain space consisting of a cloud of DNS servers used to store data associated with E.164 numbers (using the above algorithm), together with a DNS provisioning scheme to ensure that the DNS registration and delegation is coordinated amongst the servers.

•

A Resource Record type (NAPTR) that can be stored in DNS and can be returned in response to queries from a client for all records of this type in the zone associated with the FQDN.

•

Processing Algorithms by which the returned record set can be evaluated and from which a record can be selected, with a URI generated from that record.

The fundamental Domain Name System specification is defined in RFC1034 and 1035. The input algorithm to convert an E.164 number into an ENUM FQDN is specified in RFC3761. The NAPTR Resource Record Type is documented in RFC3403. The response-processing algorithm is defined in RFC3761 and in RFC3402.

2.1 ENUM Storage Infrastructure ENUM uses a standard hierarchical distributed DNS delegation and storage approach. The ENUM domain space is organised as an inverted tree, with a global server set responsible for the apex of the ENUM domain space, delegating authority for portions of its domain space to other servers. In simple terms, this apex is the root of a tree which grows downwards. These servers in turn delegate authority to yet other servers that hold the data associated with individual telephone numbers. The domain space organisation of ENUM reflects the delegation of authority over E.164 numbers from the ITU-T (responsible for the global root of the E.164 number space) to the Countries (or regional groups of Countries) responsible for portions of the E.164 number space reflecting their designated Country Codes. Within an individual Country, E.164 numbers are assigned for service provided to individual users by the National Regulatory Authority. This is reflected in the partitioning of the equivalent e164.arpa domain space. Thus the ITU-T and the IAB (Internet Architecture Board) have agreed a Contractor to run the global Registry, in the same way that the ITU-T does for the E.164 number space. This Registry maintains the servers that are responsible for the global apex of the ENUM domain space, and is often called the ENUM Tier 0 Registry. For those Countries that choose to allow it, a designated Country Registry Contractor is delegated a portion of the domain space under e164.arpa associated with that Country's E.164 number space. Each such Contractor runs a system that is usually called an ENUM Tier 1 Registry. When a Tier 1 Registry receives a valid request to register a domain within its authority, it will delegate authority for the ENUM domain associated with an E.164 number to the individual who is provided service via that telephone number (or the agent that maintains for them the DNS servers Version 1.0

Page 6/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

August 2005

authoritative for that domain). These authoritative DNS servers are normally called ENUM Tier 2 servers, and typically it is these servers that host the records for their domains used to construct URIs by clients. The Tier 0 and Tier 1 systems are typically configured as Delegation Only servers, holding only Name Server information on the servers to which they have delegated authority for a portion of the domain space under their control. There were proposals to use other methods in place of standard delegation and in particular for the Tier 1 servers to store NAPTR resource records rather than the traditional Name Server information. These proposals were rejected at the IETF63 meeting held in Paris in August 2005. In practice, there will be a set of provisioning/registration protocols used between providers to ensure that the registration requests can be delivered to the correct system, that the right of the potential registrant to make this registration has been authorised, and that the data necessary to coordinate the delegation between the servers is made. There is currently a wide variation between different schemes used in different Countries. However, there is consensus to move towards a common protocol based on Extensible Provisioning Protocol (EPP), with extensions to cover the specific requirements for ENUM registration. It is expected that there will be a strong driver for testing these Registration interfaces in the future, as competition between providers will be enhanced if they can use a system for their services rather than requiring different interfaces for each Country. The fundamental specification for EPP is given in RFCs 3730, 3731, 3732, 3733, 3734 and 3735.

2.2 ENUM Client Processing An ENUM Client is involved in three tasks - it is passed an E.164 number and converts this into an associated Fully Qualified Domain Name (FQDN), uses a Resolver to query DNS for NAPTR records available within that FQDN, and processes the response and any Resource Record set (RRset) this holds to generate a URI. Operation of the algorithm to convert from an E.164 number to a domain name is straightforward, and can be tested relatively easily. The procedure is to remove all characters but digits from a fully qualified, international format E.164 number, reverse the order of the characters, intersperse '.' characters between the digits, and append the string "e164.arpa" to the end. It should be noted that, due to delays in Countries requesting ITU-T for ENUM delegations, some implementers have become impatient and have produced clients that query using one of several non-standard ENUM domain apexes, instead of the officially sanctioned "e164.arpa". All ENUM clients that were involved in the Plugtest could be (and were) configured to use this official domain space. As ENUM processing uses DNS, it is important to test the behaviour of the node in the face of problems in the DNS delegation for the zones it will query, as well as those cases where a resource record set holding the expected zone content is returned. The ENUM Client should be resilient to such failures, as well as the expected ones that it will encounter with incorrect provisioning of zone content. Also, the size of ENUM responses is larger than usually needed for most DNS queries. With large responses, some DNS options may need to be used; thus Clients may need to send queries with Version 1.0

Page 7/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

August 2005

suitably set EDNS0 options or use TCP rather than UDP transport. The resolving and authoritative DNS Servers will need to support such queries and transports. Finally, intermediary nodes (such as DNS Recursive Resolvers, or Firewalls), if misconfigured, may interfere with the queries and responses, and one goal of testing is to allow exploration of the symptoms these problems generate. This leaves the details of NAPTR processing to be tested. There are a number of standards documents that specify the elements of a NAPTR and how an ENUM client should process it, and the following is a brief summary.

2.3 NAPTR Resource Record Elements There are six fields in a NAPTR Resource Record RRData element. These are the Order, Preference, Flags, Service, RegExp, and Replacement fields. The Order and Preference fields hold unsigned 16 bit integer values. The Flags, Service, and RegExp fields all hold string values. The Replacement field holds an uncompressed Domain Name. These Integer, Domain Name and String types are all defined in RFC1034. Within a zone, multiple NAPTR records can be stored, and all are returned in response to an appropriate DNS query on that domain. Responses are subject to normal DNS response size restriction and processing. Large NAPTR RRsets could be truncated unless the queries were made using EDNS0 or over a TCP connection. Note that RFC3403 section 4.1 specifies that the Replacement field (if non-empty) holds an uncompressed domain name, and further states that the RegExp and Replacement fields are mutually exclusive - i.e. that exactly one of these fields is non-empty in any NAPTR. The processing rules for a NAPTR used with ENUM are specified in RFC3402 and RFC3761, and qualified in RFC3403. The elements when dealing with a NAPTR are: −

Order and Preference values are both used to sort the record set into a priority order, with fields having a lower numerical value having a better priority. In principle, the Order value can be considered the most significant part, whilst the Preference value is the least significant; the combination of these fields is used to sort the records into priority order. Note that RFC3761 states that the Order value MUST be considered. Records with a losing Order value (one that is numerically higher than other NAPTRs in this set) are to be discarded. It further states that Preference values are advisory; that is, NAPTRs remaining after they have been sorted on Order field value should be further sorted according to the Preference field values, but this is advisory and may be overridden by local knowledge held by the ENUM client. It should be noted that, after extensive enquiry, there are NO ENUM Clients that are strictly compliant with the above specification; they all (at most) treat these two fields as major and minor sort terms, and do not discard NAPTRs because they have "losing" Order field values, even though as specified this is a "MUST strength" command.

−

The content of the Flags field is defined in RFC3403 and reinforced by RFC3761. Note that these standards specify that an empty Flags field implies that this is a non-terminal NAPTR (processing of which is defined in RC3402). RFC3761 further states that there is only one, terminal, Flag value that is defined for use with ENUM. This is "u", indicating that the expected output from this NAPTR is a URI.

Version 1.0

Page 8/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

August 2005

[See also note after RegExp and Replacement field descriptions below] −

The content of the Service field is defined in RFC3403 (and RFC3402) as being specific to each individual Dynamic Delegation Discovery System (DDDS) Application. RFC3761 (which defines the DDDS Application “E2U”) details the syntax of the field content, when used in ENUM. RFC3761 obsoletes the earlier RFC2916, and the syntax of this field has changed; some provisioning systems and/or clients still only support the obsolete syntax of RFC2916, and so are inherently non-compliant with the current standard. RFC3761 defines the Service field as consisting of a token indicating this DDDS Application (“E2U”) followed by one or more Enumservice Identifiers, separated by '+' characters. Each of the Enumservice Identifiers consists of a set of one or more tokens of up to 32 characters in length, with a ':' separating the tokens if there is more than one in an Enumservice identifier. For completeness, note that RFC2916 defined the Service field as consisting of one Resolution Protocol (e.g. 'sip', 'tel', 'ldap') followed by a '+' character as a separator, followed by the Resolution Service token ('E2U'). In short, the Enumservice names of 3761 replaced the URI scheme names of the obsolete standard, and the order of the Service field elements is now reversed, with the 'E2U' token appearing at the beginning (left) of the service field in RFC3761 compliant NAPTRs whilst it was at the end (right) in RFC2916.

−

The RegExp field is defined in RFC3402, and is carried within a NAPTR as a DNS String value. There are some restrictions involved in provisioning this field within a DNS Resource Record; notably escaping characters that are reserved within DNS master zone file format and also valid within the RegExp field. The field content is interpreted as a POSIX Extended Regular Expression. This consists of a first part used to pattern match against the (DDDS Application specific) Application Unique String (AUS) being applied to the current NAPTR Resource Record set, and a second part used to generate an output string from static text and potentially from sub-patterns matched in the AUS.

−

The Replacement field is defined in RFC3403. It is used to hold an uncompressed Fully Qualified Domain Name that is used as the key for the next query on the DNS.

Notes: There are two kinds of DDDS rules (each held in a NAPTR, when using ENUM) according to the processing algorithm specified in RFC3402. These are terminal and non-terminal rules. In a nonterminal rule, the output is a key to be used in a re-query on the rule database. In ENUM terms, this is a FQDN to be used in a subsequent DNS query for NAPTRs. In a terminal rule, the output is as specified in the associated (terminal) flag. For ENUM, this is the "u" flag, and the output is a URI. There is currently some ambiguity over which of the RegExp and Replacement fields should be empty in each NAPTR. The descriptive text associated with the RegExp and Replacement field definitions in section 4.1 of RFC3403 is less than perfect. The Replacement field is described as being used to hold the next domain name to be searched, so it seems clear that it can be non-empty only within NAPTRs that are non-terminal. If it is non-empty, then by definition, the RegExp field must be empty. The use of the RegExp is slightly more problematic. In section 4.1 of RFC3403, this is also described as being used to generate a new domain - however, the next paragraph of the text Version 1.0

Page 9/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

August 2005

contradicts this by describing its normal use to generate the output of a terminal rule. At worst, this means that the RegExp field might, possibly, be used to generate a domain name within nonterminal rules. The RegExp field WILL be used in NAPTR records that are terminal (which, in ENUM processing, means that the NAPTR will have a flags field containing the flag "u"), as the Replacement field cannot produce a URI and so is inappropriate for use in the ENUM terminal rule case. Finally, the Enumservice specification process described in RFC3761 does not permit the definition of Enumservices to be used in non-terminal NAPTR records - only ones in which there is a defined URI type as the expected output of NAPTR processing. This means that, currently, there is no way for the Service field to be non-empty (and valid) within non-terminal NAPTRs used with ENUM there can be no Enumservice element, and the service field needs at least one such element to be syntactically valid.

Version 1.0

Page 10/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

3

August 2005

ENUM Test Approach

As mentioned earlier, the approach taken for this first ENUM Plugtest was to ask those active in the field what their requirements and preferences were for tests, and to attempt to meet these goals.

3.1 Test Requirements/Preferences From the consultation meetings, the following goals were collated: − Black Box Testing should be used. Access to the software-internal interfaces of an Embedded ENUM client is often not possible, and such nodes form a significant part of the client population. − If at all possible, co-location of the devices under test with the main test site should not be required to carry out at least a subset of the available tests. Not all clients are easy to ship to a central test site. For example, PSTN Gateways are not portable, and these may well have embedded ENUM clients. − If possible, it should be possible for a remote ENUM client to run at least some of the tests using the global DNS infrastructure (i.e. these tests should not require a special DNS forwarder configuration). − It should be possible to use remote PSTN outcalling interfaces & SIP Registrar/Proxies, rather than requiring use of PSTN/SIP dial-out interfaces provided by a central site. Again, Gateway units are often hard-wired to use what are to them local PSTN and/or SIP interfaces, and re-configuration to use such interfaces provided in another Country could prove difficult. − The tests should not require instrumented access to ENUM Tier 0 or Tier 1 DNS Servers. It can be difficult to instrument the ENUM Tier 1 DNS servers that are authoritative for an E.164 Country Code, both because these are live, production systems that provide responses for all ENUM clients (not just those that happen to be under test), and also because they are normally not under the control of the test operator (or even accessible by that operator other than using a standard DNS Resolver). Instrumentation of (and access to) the ENUM Tier 0 DNS servers is simply not practical because they are operated by a number of different organisations across the world.

3.2 “Black Box” Instrumentation Methods A Black Box testing approach can be used. This requires a set of test vectors to be designed that are stored in test zones, and that the ENUM clients under test are stimulated to process E.164 numbers associated with these test zones. The externally visible interactions of the node under test can be used to infer its internal design. An ENUM client uses DNS queries as part of its processing, and so monitoring these DNS queries and responses is an important instrumentation technique. In addition, ENUM Client processing is almost always involved as the precursor to an attempt at initiating a communications session, so it is possible to monitor the behaviour of the ENUM client by instrumenting the call attempts that follow from its processing. Note that a common strategy for ENUM-aware client nodes is to attempt to place a PSTN call to the input E.164 number if the ENUM client does not return an appropriate URI. This default behaviour may be triggered both in the case that there is such a DNS delegation problem and in the case where the ENUM client has received a NAPTR record set, but has failed to select a URI for other reasons. Thus, it is important that PSTN calls to the input E.164 numbers are monitored, as that indicates that the node has given up and is exhibiting this default fall back behaviour. Version 1.0

Page 11/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

August 2005

3.2.1 DNS Monitoring ENUM Clients will make DNS queries as part of their normal operation, so monitoring these DNS queries is an important tool. Such monitoring can be broken down into three elements: −

Monitoring the queries that are passed via an instrumented DNS Recursive Resolver (or forwarder). In this case, it is the DNS sending side that is instrumented. The advantage of this technique is that it may be possible to configure a remote ENUM client to forward all of its DNS requests to this Resolver, so permitting instrumentation of queries from a non-local client.

−

Monitoring the authoritative name servers (either the Tier 1 servers authoritative for a country code, or those to which authority over an individual ENUM zone has been delegated). In this case, it is the DNS receiving side that is instrumented. This has the advantage that clients anywhere can make queries, and only these authoritative servers need to be monitored. The major disadvantage is that it is unlikely that the delegating Tier 0 and Tier 1 servers can be instrumented, so that only the Tier 2 authoritative server that delivers the NAPTR records to the clients is a suitable instrumentation point.

−

Monitoring DNS traffic passed via a node that traces all traffic passing via its network connection. This case is similar to the first one, but differs in that the client does not need to be configured to use a defined Resolver, but the traffic sent by the client does need to pass the monitoring node. This almost always requires that the client and this packet-monitoring node are co-located.

3.2.2 Call Monitoring Many of the test cases can be designed to trigger the node under test to place a call. Thus instrumenting this process can indicate the results of ENUM client processing, and the URI that a client has chosen. As in the case of DNS instrumentation, there are two options for monitoring calls. The sending side at which call attempts are initiated can be monitored, and/or the receiving side at which calls are accepted can be monitored. Selecting the NAPTR content to ensure that such calls are placed to a "Call Receiver" that forms part of the test infrastructure allows such attempts to be instrumented. In many ways, this is the best approach, as it allows clients anywhere to place calls, and this behaviour can be monitored by a single instrumented system under the control of the test operators. However, there are situations in which this is not feasible. For example, if the ENUM test domains are available publicly, they will have to have been registered in the public ENUM infrastructure. It may not be possible to make such a registration for the telephone number range associated with the test site. In fact it proved impossible to arrange this in France in time for the ENUM Plugtest. It may instead require public ENUM registrations for the test vectors in a Country different from the test site. The E.164 numbers chosen for these registrations may well not be under the control of the test operators, or the complexity (and cost) of redirecting incoming calls to the test site may be unreasonable. Another approach may be to insist that all nodes under test place calls via the same outbound "Call Sender" (a PBX or Proxy). This can be arranged relatively easily if all units under test are local to the test infrastructure and are willing to make SIP registrations to the local proxy, but is not possible

Version 1.0

Page 12/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

August 2005

where units under test are tied to remote components (such as where these units are configured to send SIP session invitations only via remote outbound proxies).

3.3 ENUM Test Site Instrumentation Plan From the preferences of potential test users, and an analysis of the available techniques, a plan was developed to support this first test. With its focus on ENUM Client testing, a number of zones were to be populated with content that would test border cases for client implementations. These zones were to be published external to the test site, so that externally hosted clients could query these zones. Each of the zones represented a different test vector. To ensure that the test vectors were available to remote ENUM clients, public ENUM registrations were to be made for the domains associated with the E.164 numbers used for the test vectors. The plan was for each telephone number in the range used for the tests to be processed by a client, with each individual test resulting in either a rejection of the zone content or causing the client to initiate a SIP call or a PSTN call, as it had already been confirmed that there were no Plugtest attendees who required H.323 processing.

3.4 ENUM Test Site Architecture

Figure 1: Plugtest Network Configuration The test site was configured with the System architecture shown in figure 1. This consisted of DNS Servers, a number of "Test and Instrumentation" servers, SIP phones, and a SIP/PSTN PBX. The test site hosted DNS servers to which authority for the ENUM registrations associated with the test vectors had been delegated. These name servers were provisioned with the test zone content, and acted as the Tier 2 servers for these test vectors. For more detailed behaviour testing, several other DNS servers were installed at the main test site so that the impact of certain of the DNS specific test vectors (and the introduction of different Version 1.0

Page 13/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

August 2005

misconfigured intermediary servers) could be shown and the symptoms of using such intermediaries could be explored. An instrumented Recursive Resolver was made available, so that ENUM client queries could be tracked as needed. However, as both the Parent (Tier 1) Authoritative DNS server and the Tier 2 DNS server (to which authority for the test zones had been delegated) were both instrumented, this Recursive Resolver was intended only for assisting in debugging clients if needed. Each of the Test and Instrumentation servers was a general purpose Linux machine that was used for monitoring unit-under-test behaviour. A SIP Proxy/PSTN PBX was installed (running the Asterisk PBX/SIP software package - see ). It used an E1 interface to the PSTN via the site-local telephone network interface. This system was configured as a "Call Receiver", with incoming PSTN (and SIP) calls triggered by the tests being directed to voice announcement software, allowing test disposition to be human recognisable. In addition, calls triggered by ENUM Clients under test were also logged. It was also configured to allow local SIP clients that registered with it to place calls to the PSTN as needed. To this end, each of the groups testing their systems was provided with a suitably configured SIP telephone, registered with the Asterisk gateway.

Version 1.0

Page 14/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

4

August 2005

Test Vector Design

The specifications for ENUM are held in RFC3401, RFC3402, RFC3403, RFC3761, and in the individual Enumservice specifications that are being processed as standards through the IETF. For completeness, the obsolete documents RFC2915 and RFC2916 reflect the original specifications for ENUM; these have since been replaced by the above documents, but some ENUM Clients (and Provisioning systems) still only support the obsolete documents, and so it is worthwhile testing for this behaviour as well. This body of documents forms the basis for testing. There are additional specifications and clarifications to these documents within TISPAN TS 102 172, and at the time of writing another document (currently “draft-ietf-enum-experiences-02.txt”) is being processed to clarify the interpretation that should be made of the basic specifications. Whilst this first ENUM test vector set does not fully reflect these clarifications, it is expected that future test sets will incorporate the proposals of the "Experiences" document, once it is finally approved. Of course, for a test set to be useful, it should reflect the kinds of behaviour that have been observed in existing products. This set has been informed by analysis of ENUM zones queried using Webbased ENUM Clients. The Web ENUM Lookup service (see ) has been under development for some time, and the queries placed using this service were logged to check the data provisioned into publicly available zones. Finally, discussions have taken place with development teams working on ENUM Clients, and experiences of the kind of errors made during development have been reflected in this test vector set. One important factor that has been taken into account in the implementation of these test vectors is that, from wide discussion, very few ENUM Client designs support non-terminal NAPTR processing; all other ENUM Client developers either have not considered it in their design or discard such NAPTR records. This means that, although there would be expected to be a large number of test vectors to explore non-terminal processing support, these are limited because there are currently very few ENUM Clients that could take advantage of them.

General DNS Client Difficulties − − − − − − − −

Can Client handle receiving an NXDOMAIN response, where no delegation exists for the queried domain? Can Client handle receiving a SERVFAIL response, where there is a delegation but there are no authoritative servers for that delegated domain? (i.e. a Lame Delegation) Can the Client handle receiving a response that is empty (i.e. there are no NAPTRs within the zone)? Can the Client handle a misconfigured delegation, with dotted decimals or CNAMEs as the NS record targets? Can the Client handle a misconfigured delegation, where the destination Name Servers are unreachable? Can the Client handle receiving a SERVFAIL error, where there is a forwarding loop in the DNS configuration? Can the Client handle receiving a failure due to a parent/child mismatch on the NS records? Can the Client handle receiving no response due to the target nodes shown in the NS records not actually providing a DNS service?

Version 1.0

Page 15/30

2005-08-23

ETSI ENUM Plugtests™ Final Report − − −

August 2005

Can the Client handle receiving no NAPTRs, but receiving a TXT record that looks like a NAPTR? Can the Client handle receiving a response with a NAPTR record having very long labels in its generated URI? (e.g. where a valid SIP URI has a set of 63-byte domain labels) Can a Client handle truncated response (i.e. a response generated as a result of a large NAPTR RRset)? (note – the expected behaviour is for the Client to react by retrying the request using TCP or by setting the EDNS0 option in its request)

Basic ENUM Client Difficulties − −

Can the Client process a single NAPTR with a SIP URI (using RFC3761 syntax)? Can Client handle > 1 NAPTR?

Order/Priority Field Difficulties −

Can Client sort NAPTRs and process them in the proper order?

Flags Field Difficulties − −

Does the Client handle a flag character in either case? Does the Client handle duplication of the u flag? Does the Client handle an unknown flag (acting as a terminal and a non-terminal NAPTR)?

Service field difficulties − − − − − − − − − −

Does the Client handle a response with a NAPTR that does NOT include the E2U tag? (i.e. it is not an ENUM NAPTR) Does the Client handle a response with a NAPTR containing E2U but no Enumservice? Does the Client handle receiving a NAPTR with an empty Enumservice token: With the E2U token in RFC2916 syntax? (i.e. at the right of the field)? Does the Client handle a NAPTR in RFC 3761 syntax, but with an empty Enumservice token: Immediately preceding the E2U token? At the right end of the service field? In the middle of the service field? Does the Client handle receiving a NAPTR with an RFC3761 syntax service field, but with an RFC2916-example resolution protocol? Does the Client handle a NAPTR with a compound service field (i.e. holding more than one Enumservice), with the left-most Enumservice being valid and normally handled? Does the Client handle a compound NAPTR service field, with a normally handled Enumservice at the right-most end? Does the Client handle a NAPTR with two Enumservices that differ in the expected URI they output/require, where both are otherwise recognised/supported? Does the Client handle a NAPTR with two Enumservices, where the second Enumservice is a private? Does the Client handle a NAPTR with two Enumservices, where the first Enumservice is private Enumservice?

Version 1.0

Page 16/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

August 2005

−

Does the Client handle a NAPTR with a private Enumservice with a malformed syntax (i.e. it consists only of “X-“)? − Does the Client handle a NAPTR with two copies of the E2U tag in the service field? − Does the Client handle receiving a NAPTR with SIP URI valid according to RFC2916? − Does the Client handle receiving a NAPTR with the voice:sip service proposed in ETSI TS102172? [See also non-matching URI scheme in RegExp field tests]

RegExp field Tests − − − −

Does the Client handle a NAPTR that uses a non-typical delimiter character? Does the Client handle a NAPTR with a non-trivial pattern match (i.e. one that matches against the AUS rather than matching against anything)? Does the Client handle a RegExp field in which there is no URI scheme? (note – these do exist in current published zones, and some Clients “crash” when they process one!) Does the Client handle a NAPTR where the URI scheme generated by the RegExp field does not match that expected from the Enumservice shown in the Service field? (note – again, these do exist; for example, a SIP Enumservice with a tel: URI)

Replacement field Tests This set of vectors tests Client Non-terminal NAPTR processing. − −

−

Does the Client handle an empty flags field (non-terminal NAPTR) at all? (i.e. does it follow the non-terminal reference and query the referenced zone for NAPTRs, or does it instead discard the non-terminal NAPTR?) Does the Client correctly retain the original E.164 number (AUS) when pattern matching NAPTRs within a referenced zone? (note - this is demonstrated by provisioning test zones that: - contain NAPTRs that Pattern Match only with non-terminal query but not for a direct query - contain NAPTRs that do not match with non-terminals - only for direct queries) Does the Client detect a non-existent referenced domain name and recover?

The following test vectors were proposed, but were not implemented for this first ENUM Plugtest, as there was only a single ENUM Client that could perform this kind of processing. It is hoped that, in the future, a wider selection of ENUM Clients will implement this part of the standard, in which case these test vectors can be implemented and used. −

−

Does the Client detect and recover from non-terminal NAPTRs that point to the current domain (i.e. where there is a tight loop)? Does is discard the non-terminal NAPTR and continue with the next one? Does it abort processing and return a failure? Does the Client detect and recover from loops via other zones? (i.e. where a zone has a nonterminal NAPTR that points to another zone, and where that zone includes a non-terminal that has a loop?) If the loop is via another zone entirely, then

Version 1.0

Page 17/30

2005-08-23

ETSI ENUM Plugtests™ Final Report -

-

Version 1.0

August 2005

Does it discard the non-terminal in the third zone and continue with the next NAPTR in that third zone? Does it abort processing of the third zone, discarding the non-terminal in the second zone that referred to it, and continue with the next NAPTR in that second zone? Does it discard the initial non-terminal NAPTR that started the chain of references continue with the next NAPTR in the initial zone? Does it abort processing the ENUM request that detected the loop?

Page 18/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

5

August 2005

Experiences from the first ENUM Plugtest

From experience of running this first ENUM test event, several features were noted. First, it is not feasible to test an ENUM Client remotely in all circumstances and running every test. Whilst ENUM is an Internet protocol and so in principle should work over any Internet connection, there are circumstances in which site-local monitoring of ENUM Client activity at least simplifies inference of its internal behaviour. Secondly, the test vectors were not all exercised. The vast majority of the ENUM Clients tested support SIP, and of these only two supported outbound calls to the PSTN. In addition, only one ENUM Client supported non-terminal NAPTRs. In practice, this meant that all of the Clients could be said to have failed at least some of the tests. However, all of the attendees did work through the tests, and the feedback received from the attendees was that the experience has helped to highlight the work that needs to be done. It does seem, however, that ensuring SIP support works correctly is the biggest aim of most of the groups, rather than supporting all elements of the existing standards. Next, the groups who are testing their ENUM Clients at this stage in ENUM deployment are technically very advanced, and are used to developing and debugging these Clients. As a result, they often have their own monitoring methods and internal logging interfaces, and so can detect behaviour of their Clients with little outside support. It is expected that this will change as ENUM deployment becomes more widespread, but at present it does mean that Plugtest attendees viewed the event more as a way of sharing development experience and assisting one another to debug their systems, rather than as a source of equipment to which they otherwise did not have access. For example, several of the attendees debugged their separate Provisioning and Gateway (ENUM Client) systems during the Plugtest as a result of running through the tests and comparing results. Finally, as mentioned below, most of the tests were run manually. To improve efficiency and simplify the tests, there is a need for a “Test Call Receiver” with public ENUM registrations tied to a number range via which it has a PSTN interface. This allows a considerable degree of automation of the tests and outcomes, and the options for dedicated ENUM test registrations are being raised through TISPAN (and, potentially, the ITU-T).

5.1 Equipment Configuration Experiences In practice, only one of the groups testing systems used the test and instrumentation servers; others used their own machines as needed. The groups also used machines they provided to monitor packet traffic and so decode DNS queries made by their own nodes under test. Only in a few of the broken DNS delegation cases was recourse to the authoritative DNS server logs needed, to confirm the queries that were received by those authoritative servers. Also, although the (deliberately misconfigured) DNS servers and Firewall were available, none was used in this Plugtest. Most of the systems under test were remote, and so such infrastructure was not applicable. Firewall misconfiguration is a common source of problems (such as blocking TCP traffic for DNS, or in some cases discarding DNS responses over a fixed size, regardless of the presence of EDNS0 options). Similarly, certain versions of intermediary DNS Recursive Resolvers can cause issues by discarding referral information from responses, or simply by randomising the order in which NAPTRs are returned to a Client. At this point, the existing ENUM developer community has other priorities. However, it is hoped that in future tests it will be possible to

Version 1.0

Page 19/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

August 2005

exercise these failure modes, and to build experience in the developer community of the symptoms these issues cause. In addition to the SIP telephones provided, most of the groups also used their own SIP Clients (mostly softphones, with in one case two other SIP telephones). Some of these were registered with the test Asterisk gateway, with others being registered remotely and being used to trigger remote ENUM-aware systems to process the test vectors. Availability of a wide range of SIP terminals proved convenient, as it allowed manual monitoring of call placement. In future test events, it is hoped to continue to make SIP telephones available, as they were used extensively, and helped the attendees to run through the tests.

5.2 Actual Test Vector Provisioning It proved impossible in the end to arrange for delegations within the French ENUM Trial for domains associated with telephone numbers from within the block used for the ETSI PSTN interface (and so under the Plugtest group’s control). Instead, arrangements were made (as an exceptional and short-term procedure) to provision the test vectors in domains associated with United Kingdom telephone numbers set aside for drama use, as these are guaranteed to not be assigned to end users and so could not result in interference to third parties. These ENUM domains were delegated to authoritative DNS servers operated as part of the Plugtest infrastructure. Also, logging access was arranged to the UK Tier 1 DNS servers, so that the queries made of these servers could be checked against the tests being run. The delegation of these numbers was handled in a way that allowed the zones to be moved between the Plugtest DNS servers without recourse to the UK Tier 1 registry. This allowed for rapid reconfiguration and the timely introduction of extra failure modes such as a functioning name server becoming unreachable. An added benefit of this approach was that it gave better control over the time-to-live (TTL) values of cached delegation information. Resolving name servers were unlikely to cache stale data for longer than the time needed to carry out a set of the test cases. The initial plan was that call monitoring would just require a “Call Receiver” accept all calls triggered as a result of the tests. However, as the available ENUM registrations were associated with E.164 numbers not assigned to ETSI, this meant that the default behaviour of ENUM-aware Client systems on failure to determine a valid URI (i.e. placing a call over the PSTN to the input E.164 number) would not be picked up by a local PSTN termination. The choice of using the UK drama number range ensured that nobody else would be disturbed by receiving test calls, but it did mean that test vectors that resulted in PSTN call placement from remote units under test were more complex to check. A temporary solution was developed and worked well, but to improve the potential for automation of the tests, this situation should be avoided if possible in future Plugtests. The solution chosen for this Plugtest involved monitoring of the test calls. Fortunately, this was possible for all of the remote nodes under test, as the tests were run manually using SIP phones and the tester simply listened for the call result. In those cases where the individual test failed, it typically resulted in calls to the input E.164 number (i.e. where the node under test had gone to its default behaviour on failure to generate an acceptable URI from its ENUM query and had dropped the call to the PSTN). The tester listened either for the call to be placed to the “Call Receiver” unit, (where the caller was connected to an announcement unit indicating test success), or where the ENUM lookup failed the default PSTN call also failed, as this attempted to place a call to the input number that was guaranteed not to be in service.

Version 1.0

Page 20/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

August 2005

5.3 Other Notes As an aside, it was noted that the remote PSTN connections did not always operate correctly when trying to place calls to the input E.164 numbers (the UK drama numbers). These numbers are not assigned, and so it was expected that such call attempts would be rejected with the cause value “Number Not In Service”. However, it was noted that calls from different Countries sometimes gave a “Number Busy” response, or in one case actually gave “Ringback”, implying that the PSTN routing for these calls is not correct. Such misconfiguration of live PSTN systems reinforces the need for a test Call Receiver so that there is a defined response to call attempts, something that from experience is not always possible in the existing PSTN infrastructure.

Version 1.0

Page 21/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

6

August 2005

Conclusions from the first ENUM Plugtest

There was a little confusion over terminology that needed to be clarified. Some participants used the terms Resolver and ENUM Resolver for the same thing. Others used these terms for different parts of the ENUM system. The general feeling was that Resolver should be applied to what is known in DNS circles as the Stub Resolver: the software usually provided by the Operating System for making DNS lookups and receiving responses from name servers. These are typically found in a shared library, for instance the res_nmkquery() POSIX API. The ENUM Resolver was accepted to be a logically discrete component, even if provided as part of the Operating System. This piece of software would be responsible for processing any NAPTR records returned from the DNS lookup. The ENUM Resolver would handle the Order and Preference values processing, identifying Enumservice fields of interest to the calling application (e.g. sip: or tel: URIs) and take care of any regular expression matching and substitution. The participants agreed to ask TISPAN to consider making this clarification. Concern was also expressed that there was a need to discuss URI and Enumservices naming schemes with the GSM Association. Unless a co-ordinated approach was taken, there was a possibility that ENUM deployment could be fragmented because of ad-hoc arrangements for identifying services and end-points such as MMS or SMS gateways. The IETF has made slow progress in this area, partly because the IETF ENUM and SIP Working Groups do not agree on how to deal with this problem. It was agreed that this issue would be raised with TISPAN who could liaise with the GSM Association. Another example of the potential problems arising from these informal naming schemes is the need for a distinction between sip: and voice:sip URIs which are needed by SIP proxies. The IETF has not defined a voice:sip Enumservice. This is an area where ETSI could develop a standard through TISPAN. Participants tended to prefer the test vectors which showed failures rather than successes. To some extent this was an understandable example of the computing maxim that testing shows the presence of bugs, not their absence. However there was a consensus that a permanent or semi-permanent testbed should be established. This should include ENUM delegations for the test vectors used during the Plugtest along with the corresponding infrastructure of name servers and a SIP server/PSTN gateway. Disappointment was expressed that the infrastructure provided during the Plugtest was to be torn down at the end of the event. The test vectors provided a good platform for developing an extensive and comprehensive set of ENUM test cases. These could include new URI schemas and Enumservice descriptions such as those that might be used for ENUM-capable MMS services. This could become a fully-fledged conformance test suite. That in turn could be used by a suitable standards-making body such as ETSI to provide independent certification of ENUM-aware systems and software. One area where further work needs to be done is the production of Application Programming Interfaces (APIs) for ENUM. Standards in this area would be very useful for developers and could simplify an ENUM Resolver’s workload when processing a NAPTR RRset. It is not clear were this activity could be undertaken since it is out of scope both for ETSI and the IETF. Participants felt that it was important that Registries should not control which NAPTR records are permitted or denied for an ENUM entry. However it would be helpful if a recommended list of useful NAPTR records and Enumservices were compiled. These could provide convenient Version 1.0

Page 22/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

August 2005

templates for end users and service providers. Consideration should be given to an ETSI-provided naming convention for these specimen NAPTR records.

Version 1.0

Page 23/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

August 2005

Appendix 1 – Test Vectors used For the following test vectors, the “Call Receiver” Test System running Asterisk software was configured to respond to incoming PSTN calls on +33492954401 - +33492954404. It was also configured to respond to incoming SIP calls for SIP URIs to sip:[email protected]. to sip:[email protected]. The other available PSTN numbers (and SIP URIs) were used to allow calling to the provided SIP phones for the Plugtest attendees. Note that temporary ENUM registrations were made for domains associated with the number block +441419460900 to +441419460945. These numbers are within the “Drama numbers” range of +441419460000-+441419460999, and so are guaranteed not to be assigned and “in service”.

A.1 - Test Vectors ; ;

Note that for tests 0..10 there are no NAPTRs configured in the zone and for test 10, there is no NAPTR, but a TXT record that LOOKS like a NAPTR

; ;

[0] +441419460900: UNUSED

; ;

[1] +441419460901: 1.0.9.0.6.9.4.1.4.1.4.4.e164.arpa NXDOMAIN response (no domain at all)

; ;

[2] +441419460902: 2.0.9.0.6.9.4.1.4.1.4.4.e164.arpa Lame delegation -- no authoritative servers for the zone

; ;

[3] +441419460903: 3.0.9.0.6.9.4.1.4.1.4.4.e164.arpa NOHOST response (No NAPTR records for domain)

; ;

[4] +441419460904: 4.0.9.0.6.9.4.1.4.1.4.4.e164.arpa Broken delegation -- dotted decimals as NS record targets

; ;

[5] +441419460905: 5.0.9.0.6.9.4.1.4.1.4.4.e164.arpa Broken delegation -- unreachable dotted decimals as NS record targets

; ;

[6] +441419460906: 6.0.9.0.6.9.4.1.4.1.4.4.e164.arpa SERVFAIL error -- forwarding loop

; ;

[7] +441419460907: 7.0.9.0.6.9.4.1.4.1.4.4.e164.arpa Broken delegation -- parent/child mismatch on NS records

; ;

[8] +441419460908: 8.0.9.0.6.9.4.1.4.1.4.4.e164.arpa Broken delegation -- delegated name servers not running DNS

; ;

[9] +441419460909: UNUSED

0.0.9.0.6.9.4.1.4.1.4.4.e164.arpa.

9.0.9.0.6.9.4.1.4.1.4.4.e164.arpa

; [10] +441419460910: 0.1.9.0.6.9.4.1.4.1.4.4.e164.arpa ; NOHOST response -- TXT record resembling a NAPTR record 0.1.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN TXT '100 10 "U" "!^.*$!sip:[email protected]!" .'

Version 1.0

Page 24/30

"E2U+SIP"

2005-08-23

ETSI ENUM Plugtests™ Final Report

August 2005

; ----------------------------------------------------------------------; [11] +4414114960911: 1.1.9.0.6.9.4.1.4.1.4.4.e164.arpa ; Single NAPTR record with very large URI (63-byte labels) 1.1.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 10 3 "U" "E2U+sip" "!^.*$! sip:4526@IsThisAVeryVeryVeryLongLabelAnnoyToTheENUMClientsAndDNSClients.ThisAIsV eryVeryVeryLongLabelToAnnoyTheENUMClientsAndDNSClients.AThisIsVeryVeryVeryLongLa belToAnnoyTheENUMClientsAndDNSClients.1.1.9.0.6.9.4.1.4.1.4.4.e164.arpa.!" . ; Note that this zone has an SRV record, so that clients that can parse the URL can place a SIP call _sip._udp.IsThisAVeryVeryVeryLongLabelAnnoyToTheENUMClientsAndDNSClients.ThisAIs VeryVeryVeryLongLabelToAnnoyTheENUMClientsAndDNSClients.AThisIsVeryVeryVeryLongL abelToAnnoyTheENUMClientsAndDNSClients.1.1.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN 10 10 5060 plugtests.org.

; [12] +441414960912: 2.1.9.0.6.9.4.1.4.1.4.4.e164.arpa ; Large NAPTR RRset -- truncated responses and/or EDNS0 2.1.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 10 0 "U" "E2U+sip" "!^.*$!sip:4527@IsThisAVeryVeryVeryLongLabelAnnoyToTheENUMClientsAndDNSCli ents.ThisAIsVeryVeryVeryLongLabelToAnnoyTheENUMClientsAndDNSClients.AThisIsVeryV eryVeryLongLabelToAnnoyTheENUMClientsAndDNSClients.1.1.9.0.6.9.4.1.4.1.4.4.e164. arpa.!" . 2.1.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 10 1 "U" "E2U+sip" "!^.*$!sip:4528@IsThisAVeryVeryVeryLongLabelAnnoyToTheENUMClientsAndDNSCli ents.ThisAIsVeryVeryVeryLongLabelToAnnoyTheENUMClientsAndDNSClients.AThisIsVeryV eryVeryLongLabelToAnnoyTheENUMClientsAndDNSClients.1.1.9.0.6.9.4.1.4.1.4.4.e164. arpa.!" . 2.1.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 10 2 "U" "E2U+sip" "!^.*$!sip:4529@IsThisAVeryVeryVeryLongLabelAnnoyToTheENUMClientsAndDNSCli ents.ThisAIsVeryVeryVeryLongLabelToAnnoyTheENUMClientsAndDNSClients.AThisIsVeryV eryVeryLongLabelToAnnoyTheENUMClientsAndDNSClients.1.1.9.0.6.9.4.1.4.1.4.4.e164. arpa.!" . 2.1.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 10 3 "U" "E2U+sip" "!^.*$!sip:4530@IsThisAVeryVeryVeryLongLabelAnnoyToTheENUMClientsAndDNSCli ents.ThisAIsVeryVeryVeryLongLabelToAnnoyTheENUMClientsAndDNSClients.AThisIsVeryV eryVeryLongLabelToAnnoyTheENUMClientsAndDNSClients.1.1.9.0.6.9.4.1.4.1.4.4.e164. arpa.!" . 2.1.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 10 4 "U" "E2U+sip" "!^.*$!sip:4531@IsThisAVeryVeryVeryLongLabelAnnoyToTheENUMClientsAndDNSCli ents.ThisAIsVeryVeryVeryLongLabelToAnnoyTheENUMClientsAndDNSClients.AThisIsVeryV eryVeryLongLabelToAnnoyTheENUMClientsAndDNSClients.1.1.9.0.6.9.4.1.4.1.4.4.e164. arpa.!" . 2.1.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 10 5 "U" "E2U+sip" "!^.*$!sip:4532@IsThisAVeryVeryVeryLongLabelAnnoyToTheENUMClientsAndDNSCli ents.ThisAIsVeryVeryVeryLongLabelToAnnoyTheENUMClientsAndDNSClients.AThisIsVeryV eryVeryLongLabelToAnnoyTheENUMClientsAndDNSClients.1.1.9.0.6.9.4.1.4.1.4.4.e164. arpa.!" . 2.1.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 10 6 "U" "E2U+sip" "!^.*$!sip:4533@IsThisAVeryVeryVeryLongLabelAnnoyToTheENUMClientsAndDNSCli ents.ThisAIsVeryVeryVeryLongLabelToAnnoyTheENUMClientsAndDNSClients.AThisIsVeryV eryVeryLongLabelToAnnoyTheENUMClientsAndDNSClients.1.1.9.0.6.9.4.1.4.1.4.4.e164. arpa.!" . 2.1.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 10 7 "U" "E2U+sip" "!^.*$!sip:4534@IsThisAVeryVeryVeryLongLabelAnnoyToTheENUMClientsAndDNSCli ents.ThisAIsVeryVeryVeryLongLabelToAnnoyTheENUMClientsAndDNSClients.AThisIsVeryV eryVeryLongLabelToAnnoyTheENUMClientsAndDNSClients.1.1.9.0.6.9.4.1.4.1.4.4.e164. arpa.!" . 2.1.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 10 8 "U" "E2U+sip" "!^.*$!sip:4535@IsThisAVeryVeryVeryLongLabelAnnoyToTheENUMClientsAndDNSCli ents.ThisAIsVeryVeryVeryLongLabelToAnnoyTheENUMClientsAndDNSClients.AThisIsVeryV eryVeryLongLabelToAnnoyTheENUMClientsAndDNSClients.1.1.9.0.6.9.4.1.4.1.4.4.e164. arpa.!" .

Version 1.0

Page 25/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

August 2005

2.1.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 10 9 "U" "E2U+sip" "!^.*$!sip:4536@IsThisAVeryVeryVeryLongLabelAnnoyToTheENUMClientsAndDNSCli ents.ThisAIsVeryVeryVeryLongLabelToAnnoyTheENUMClientsAndDNSClients.AThisIsVeryV eryVeryLongLabelToAnnoyTheENUMClientsAndDNSClients.1.1.9.0.6.9.4.1.4.1.4.4.e164. arpa.!" . ;---- General ENUM processing ; [13] +441414960913; Standard SIP URL -- no pattern matching 3.1.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "U" "E2U+SIP" "!^.*$!sip:[email protected]!" . ; [14] +441419460914; multiple NAPTRs, response "fits" into minimal DNS packet so no truncation required; will normally take 2nd in response (unless email gwy :) 4.1.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "U" "E2U+email:mailto" "!^.*$!mailto:[email protected]!" . 4.1.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 11 "U" "E2U+SIP" "!^.*[email protected]!" . ;---- Order/Priority fields ; [15] +441419460915; multiple NAPTRs, response "fits" into minimal DNS packet so no truncation required; should take 2nd in response 5.1.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 11 "U" "E2U+SIP" "!^.*[email protected]!" . 5.1.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "U" "E2U+SIP" "!^.*[email protected]!" . ;---- Flag field ; [16] +441414960916; Standard SIP URL -- no pattern matching, lower case flag character 6.1.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "u" "E2U+SIP" "!^.*$!sip:[email protected]!" . ; [17] +441414960917; Duplicate Flag field 7.1.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 "!^.*$!sip:[email protected]!" .

10

"uU"

"E2U+SIP"

; [18] +441414960918; Non-standard Flag field (Terminal NAPTR) 8.1.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "X" "E2U+SIP" "!^.*$!sip:[email protected]!" . ; [19] +441414960919; Non-standard Flag field (non-terminal) 9.1.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "X" "" 3.1.9.0.6.9.4.1.4.1.4.4.e164.arpa. ;---- Service field ; [20] +441414960920; Non-E2U NAPTR 0.2.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR "!^.*$!sip:[email protected]!" .

100

""

10

"U"

"E2F+SIP"

; [21] +441414960921; E2U with no Enumservice 1.2.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "!^.*$!sip:[email protected]!" .

"U"

"E2U"

; [22] +441414960922; Empty Enumservice token (RFC2916 style) 2.2.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "U" "+E2U" "!^.*$!sip:[email protected]!" . ; [23] +441414960923; RFC3761-style SIP NAPTR with an empty Enumservice at the end 3.2.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "U" "E2U+SIP+" "!^.*$!sip:[email protected]!" .

Version 1.0

Page 26/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

August 2005

; [24] +441414960924; RFC3761-style SIP NAPTR with an empty Enumservice in the middle 4.2.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "U" "E2U++SIP" "!^.*$!sip:[email protected]!" . ; [25] +441414960925; Apparently RFC3761-style SIP NAPTR with an empty token at the beginning 5.2.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "U" "+E2U+SIP" "!^.*$!sip:[email protected]!" . ; [26] +441414960926; RFC2916-style Enumservice Field 6.2.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "!^.*$!tel:+33492954401!" .

with

RFC3761

"U"

Service

"E2U+TEL"

; [27] +441414960927; Compound NAPTR (valid - voice first) 7.2.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "U" "E2U+VOICE:TEL+SMS:TEL" "!^.*$!tel:+33492954402!" . ; [28] +441414960928; Compound NAPTR (valid - voice last) 8.2.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "U" "E2U+SMS:TEL+VOICE:TEL" "!^.*$!tel:+33492954403!" . ; [29] +441414960929; Compound NAPTR -- 2 Enumservices with differing URLs (tel: & mailto:) 9.2.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "U" "E2U+VOICE:TEL+X-SMS:MAILTO" "!^.*$!mailto:[email protected]!" . ; [30] +441414960930; Compound NAPTR conflicting URLs (sip: & h323:) 0.3.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR "!^.*$!sip:[email protected]!" .

--

2

Enumservices

100

10

"U"

implying

"E2U+SIP+H323"

; [31] +441414960931; Compound NAPTR -- 2 Enumservices (sip & following private Enumservice) 1.3.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "U" "E2U+SIP+XZIP" "!^.*$!sip:[email protected]!" . ; [32] +441414960932; Compound NAPTR private Enumservice & sip) 2.3.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR ZIP+SIP" "!^.*$!sip:[email protected]!"

-100 .

2

Enumservices 10

"U"

(preceding

"E2U+X-

; [33] +441414960933; Compound NAPTR -- 2 Enumservices (preceding private Enumservice with no string after X- & sip:) 3.3.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "U" "E2U+X-+SIP" "!^.*$!sip:[email protected]!" . ; [34] +441414960934; Compound NAPTR -- 2 E2U Enumservices 4.3.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "U" "E2U+SIP+E2U" "!^.*$!sip:[email protected]!" . ; [35] +441414960934; Standard RFC2916-style SIP NAPTR 5.3.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "U" "!^.*$!sip:[email protected]!" .

"SIP+E2U"

; [36] +441419460939; TISPAN 102172 Trial Enumservice (voice:sip) 6.3.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "U" "E2U+voice:sip" "!^.*$!sip:[email protected]!" . ;---- RegExp field

Version 1.0

Page 27/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

August 2005

; [37] +441414960937; Standard SIP URL -- no pattern matching, BUT uses non typical delim (this uses space char) 7.3.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "u" "E2U+SIP" " ^.*$ sip:[email protected] " . ; [38] +441414960938; SIP NAPTR with pattern matching -- only works if this zone is queried directly (e.g. non-term at 43 will fail) 8.3.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "U" "E2U+SIP" "!^\+44141960939$!sip:[email protected]!" . ; [39] +441414960939; SIP NAPTR with pattern matching -- only works if this zone is queried from a non-terminal NAPTR in an other zone (+441411496944) 9.3.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "U" "E2U+SIP" "!^\+44141960944$!sip:[email protected]!" . ; [40] +441414960940; Bogus URI scheme (wrong URI - should be sip: but is tel:) 0.4.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "U" "E2U+SIP" "!^.*$!tel:+33492954404!" . ; [41] +441419460941; Apparently valid Enumservice, but missing "sip:" URL scheme label (these do exist "in the wild") 1.4.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "U" "E2U+sip" "!^.*[email protected]!" .

the

;---- Replacement field (Non-final NAPTRs) ; [42] +441414960942; Standard non-final NAPTR - refers to a basic SIP NAPTR (should work if non-terminals are supported at all) 2.4.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "" "" "" 3.1.9.0.6.9.4.1.4.1.4.4.e164.arpa. ; [43] +441419460943; SIP NAPTR with pattern matching -- fails when followed as target only works when queried directly. (The AUS will be incorrect) 3.4.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "" "" "" 8.3.9.0.6.9.4.1.4.1.4.4.e164.arpa. ; [44] +441419460944; Non-final//pattern matching test -- succeeds when followed as target only works when queried with this AUS 4.4.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR 100 10 "" "" "" 9.3.9.0.6.9.4.1.4.1.4.4.e164.arpa. ; [45] +441419460945; Non-terminal but yonder 5.4.9.0.6.9.4.1.4.1.4.4.e164.arpa. 5 IN NAPTR nowhere.example.com.

pointing 100

10

into

the

wild

""

""

""

blue

;----

Performing the tests consisted of processing ENUM queries on the input numbers, and determining the call outcome; whether the call was placed to the input number (in which case, that test had failed), or instead it had been made either via SIP or a PSTN call to the Test Call Receiver (in which case, a voice announcement indicated correctness by a Yes or No answer).

Version 1.0

Page 28/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

August 2005

Appendix 2 – List of Attendees Company

Country

AG Projects

NL

Atlas Internet

UK

DNS-MODA

UK

Enum.at

AT

Etisalat

UAE

MCI Inc.

IE

NASK

PL

Nominet UK

UK

Nominum, Inc.

NL

Roke Manor Research Ltd.

UK

SIEMENS AG

DE

T-Systems International GmbH, SSC ENPS Berlin

DE

VeriSign Inc.

Version 1.0

USA

Page 29/30

2005-08-23

ETSI ENUM Plugtests™ Final Report

August 2005

Appendix 3 – Formal Satisfaction Survey Results Hereunder some of the results obtained through the satisfaction survey handed out to the participants during the event and where the answer rate is 100% Satisfaction of the overall organisation

4.3/5

Satisfaction on the test bed provided

4.5/5

Support by IT Co-ordinator

4.6/5

Support by Event Co-ordinator

4.8/5

Facilities and in house services

4.0/5

Usefulness

4.4/5

Global satisfaction

4.3/5

Version 1.0

Page 30/30

2005-08-23