Contents

1   Introduction

IPWorks E.164 telephone Number Mapping (ENUM) server supports ENUM protocol at the interface with ENUM clients. This document describes the interface between the IPWorks ENUM Server and the ENUM Clients.

Scope

The scope of this document includes the standard ENUM protocol specified in RFC 3761, Reference [25], Number Portability extensions specified in RFC 4694, Reference [29] and RFC 4769, Reference [30].

The use of the DNS protocol described in this document only to the extent that the IPWorks ENUM Server uses it in ENUM queries and responses. IPWorks as a whole supports more general DNS functionality using an implementation of the Internet Systems Consortium’s BIND 9 DNS Server, which is outside the scope of this document.

This document covers the following topics:

• Interface Overview
• Interface Role
• Services
• Encapsulation and Addressing
• Procedures
• Information Model
• Related Standards

Target Groups

This document is intended for personnel needing to understand the logical entity, including interfaces and protocols, of the IPWorks.

1.1   Prerequisites

N/A

1.1.1   Documents

N/A

1.2   Related Information

Trademark information, typographic conventions, definition and explanation of acronyms and terminology can be found in the following documents:

• Trademark Information, Reference [1]
• Glossary of Terms and Acronyms, Reference [2]
• Typographic Conventions, Reference [3]

The standard, related to the interface, can be found in the section References.

2   Interface Overview

Figure 1 is the overview of the interface between the IPWorks ENUM Server and ENUM Clients.

2.1   Introduction

ENUM is an application that uses DNS to query Naming Authority Pointer (NAPTR) resource records.

The ENUM application describes a way to map telephone numbers into domain names for the use in queries to a DNS server. The ENUM application is defined in RFC 3761, Reference [25].

DNS is described in various IETF RFCs – see the standards in Section Reference. The ENUM Server provides the external DNS/ENUM interface between IPWorks and its clients.

In order to support the number portability feature, a set of logic has been developed in the IPWorks ENUM server to handle the ENUM query which might trigger the number portability query towards external SS7 database or CUDB.

IPWorks ENUM server supports the standard "Tel" URI defined in RFC 4694, Reference [29] and RFC 4769, Reference [30].

2.2   Syntax Notation

N/A

2.3   Interface Role

Enum implements how DNS can be used for identifying available services connected to one E.164 number.

2.4   Services

This section describes the services the ENUM Client Interface offers.

Table 1    Offered Services

Offered Service	Description
Available services connected to one E.164 number.	ENUM provides ENUM translation to SIP URI based on a multi-server based hierarchy. This service is common to all call servers and management systems that wish to obtain a translation of URI to/from E.164 numbers, and to determine the Call Server domain name for the call server that owns the user data.

2.5   Encapsulation and Addressing

This section describes what lower level protocol the ENUM Client Interface is using.

• UDP/IP

3   Procedures

This section describes the procedures used in connection with the offered and used interfaces of IPWorks.

3.1   ENUM query and reply

The ENUM protocol is a specific usage of the DNS protocol. The DNS protocol is carried over UDP/IP. The ENUM Server listens for requests on port 53 by default, but can be configured to use a different port if required.

ENUM protocol builds upon the Dynamic Delegation Discovery System (DDDS) described in RFC 3401, Reference [21], RFC 3402, Reference [22], RFC 3403, Reference [23] and RFC 3404, Reference [24].

IPWorks ENUM server only implements the functions of server part.

A standard ENUM query, as specified in RFC 3761, Reference [25], generates a domain name as follows:

0.9.6.9.8.0.2.2.1.2.6.8.e164.arpa.

In response to a query with this domain name, the ENUM Server provides the identity of one or more possible destinations that can deal with the call.

The destinations are identified by Uniform Resource Identifiers (URIs) contained within NAPTR resource records in the ENUM response.

In IPWorks, ENUM server supports "Tel" URI besides the "SIP" URI supported in previous version for the response. A ENUM reply utilizing the "Tel" URI is presented like the following information:

NAPTR 10 100 “u” “E2U+pstn: tel” “!^.*$!tel:+86-212-208-9690;npdi;rn=+86-212-208-9691!”

3.2   Response timer for ENUM query involved in number portability query

It takes time for IPWorks to perform number portability query dip into external SS7 database or CUDB. A configurable timer through IPWorks Control Panel is provided. The waiting time range is from 0.1 to 30 seconds, with 0.1-second increments, and a default value of 3 seconds.

The timer shall be configured properly to synchronize with the DNS client query retransmission timer. Information below shall be useful for ENUM clients to adjust its configuration regarding the number portability related ENUM queries:

The response timer will be started once ENUM server receives an ENUM query which is to perform number portability dip into external SS7 database or CUDB.

The timer for the ENUM query will be canceled when ENUM server gets the response from external SS7 database or CUDB.

Before the timer expires or is canceled, any further ENUM queries with the same query name (QName field in DNS query) from the same client will not perform number portability dip into external SS7 database or CUDB.

If ENUM server gets response before the timer expires, all the ENUM queries will be replied using information got in the number portability dip which is raised by the first ENUM query.

If the timer expires, all the ENUM queries will be replied with NXDOMAIN.

4   Information Model

This section describes the information model including mandatory and optional parameters of each service operation.

4.1   General

The presence of an information element is defined in the "P" column as follows:

M		Mandatory
C		Conditional
O		Optional

4.2   ENUM Query Message

An ENUM query message is sent from a client to the ENUM Server.

An ENUM query message is a DNS message as defined in RFC 1035, Reference [7]. In a standard ENUM query, the domain name – that is, the value of the QNAME field – follows the convention defined in RFC 3761, Reference [25].

The following elements of the header of an ENUM query are significant:

Table 2    ENUM Query Message

Element	Type	P	Comment
OPCODE	Integer	M	Operation Code. See 5.3.
QNAME	Sequence of labels	M	Domain Name, with optional extensions as described above. See 5.6.
QTYPE	Integer	M	Query Type. See 5.7.

The ENUM query message should contain only one question – that is, the value of the QDCOUNT field should be 1.

The ENUM query message may include an Options (OPT) pseudo resource record (see Section 4.2.1).

4.2.1   Options (OPT) Resource Record

An ENUM query message may optionally contain an Options (OPT) pseudo resource record, as defined in RFC 2671, Reference [17], identifying the maximum size of UDP payload that the client will accept in the response message.

The ENUM Server honors the request by omitting elements from the ENUM response message if necessary, as described in Section 4.3.

4.3   ENUM Response Message

The ENUM Server sends an ENUM response message to a client in response to each ENUM query message from the client.

The ENUM Server sets the Authoritative Answer (AA) bit to 1 in the header of the ENUM response message.

The ENUM Server sets the value of the Response Code (RCODE) field to zero to indicate a successful request or a non-zero value to indicate an error. See Section 66 for a list of error codes.

If the ENUM query message specifies a domain name within an equipped ENUM zone and the ENUM Server recognizes the destination telephone number, then the ENUM response message contains the following resource records:

• Zero or more Naming Pointer (NAPTR) resource records (see Section 4.3.1).

If the ENUM response message exceeds the maximum size of payload specified in the request (see Section 4.2.1) , the ENUM Server brings the actual payload size within the limit by discarding elements in the following order:

• NAPTR resource records list in order from the lowest priority to the highest priority (as determined by the values of the Order and Preference fields).

In the case of ENUM response for query which has performed number portability dip into external SS7 database or CUDB, the ENUM reply will contain only one NAPTR record.

4.3.1   Naming Pointer (NAPTR) Resource Record

The ENUM response message returned by the ENUM Server includes zero or more Naming Pointer (NAPTR) resource records, as defined in RFC 3403, Reference [23].

The NAPTR resource records are to be interpreted as for standard ENUM.

Each NAPTR resource record contains the following elements:

Table 3    NAPTR resource record

Element	Type	P	Comment
ORDER	Integer	M	The order in which the client must process the records. See Section 5.4.
PREFERENCE	Integer	M	The order in which the client should process records with the same Order. See Section 5.5.
FLAGS	String	O	Indicates the interpretation of the REGEXP field. See Section 5.2.
SERVICES	String	M	Service parameters. See Section 5.10.
REGEXP	String	C	Normally the destination URI. See Section 5.8.
REPLACEMENT	String	C	Mutually exclusive with REGEXP element. See Section 5.9.

5   Information Elements

5.1   Data Definitions

The encoding of character strings and labels is defined in RFC 1035, Reference [7].

5.2   Flags

Table 4    Flags

Type	Text string
Size (octets)	2 octets
Identity	FLAGS
Description	For ENUM responses, this is either the single-character string "U" (or equivalently "u"), or empty. "U" means that the value of REGEXP is a terminal symbol (normally a URI); empty means that the value of REGEXP or REPLACEMENT is a non-terminal symbol to be used in formulating a further query.

5.3   Operation Code

Table 5    Operation Code

Type	Unsigned integer
Size (octets)	4 bits
Identity	OPCODE
Description	The operation code that identifies the type of a DNS query. The codes and the corresponding denotations are defined by RFC 1035, Reference [7] or as indicated below for other RFC. The ENUM Server behavior for each OPCODE is as follows: 0 – Standard query. The ENUM Server processes the query if the domain name belongs to a configured ENUM zone. Otherwise it forwards the query to the DNS Server. 1- Inverse query (obsoleted by RFC 3245, Reference [20]. The ENUM Server forwards the query to the DNS Server. 2- Status request. The ENUM Server responds with RCODE = 0 ("No error") or 2 ("Server failure"). 3 - Reserved. The ENUM Server responds with RCODE = 4 ("Not implemented"). 4 - Notify (defined in RFC 1996, Reference [13]). The ENUM Server responds with RCODE = 4 ("Not implemented"). 5 - Update (defined in RFC 2136, Reference [14]). The ENUM Server forwards the query to the DNS Server. 6 - 15, The Enum Server responds with RCODE = 4 ("Not implemented").

5.4   Order

Table 6    Order

Type	Unsigned integer
Size (octets)	2 octets
Identity	ORDER
Description	The order that the client must follow to process the records. Lower values take precedence over higher values. The database administrator is responsible for provisioning the value to be returned in the NaptrOrder field of the EnumDnSched table. The administrator should normally provision the same value for all NAPTR resource records for a given directory number, but the ENUM Server does not enforce this. For the response dynamically created based on the information got from number portability query towards some SS7 database or CUDB, the values for the order field of the NAPTR record will always be set to: Order = 10

5.5   Preference

Table 7    Preference

Type	Unsigned integer
Size (octets)	2 octets
Identity	PREFERENCE
Description	The order in which the client should process NAPTR records that have the same value of Order. Lower values take precedence over higher values. The value range is only limited by the element size. For the response dynamically created based on the information got in number portability query towards some SS7 database or CUDB, the values for the preference field of the NAPTR record will always be set to: preference = 100

5.6   Query Name

Table 8    Query Name

Type	Sequence of labels (as defined in RFC 1035)
Size (octets)	Up to 256 octets
Identity	QNAME
Description	The name of the domain that the query relates to, represented as a sequence of labels, where each label consists of a length octet followed by that number of octets. The final label is a zero length octet representing the root of the domain tree. The labels in an ENUM query are formed as described in Section 4.2.

5.7   Query Type

Table 9    Query Type

Type	Enumeration
Size (octets)	2 octets
Identity	QTYPE
Description	The type of query that identifies the type of resource records to be returned. For all queries to be processed by the ENUM Server. The value should be set to 255 (meaning all types of resource record). Note: The ENUM Server currently ignores QTYPE and returns the full set of resource records, described in Section 4.3, regardless of the setting of QTYPE. This behavior is not guaranteed for future releases and client call servers should not rely on it.

5.8   Regular Expression

Table 10    Regular Expression

Type	Text string
Size (octets)	Up to 256 octets
Identity	REGEXP
Description	A regular expression that represents the result of the query. The ENUM Server derives the value from the value of the NaptrFlags field or NAPTR record in ENUM Server for any ENUM query which could find an entry in the IPWorks ENUM Server database or fit into some number series wildcard configuration. For ENUM queries that don’t have an entry in ENUM Server database nor fit into some number series wildcard configuration, but have performed number portability dip into some external SS7 database or CUDB outside of IPWorks, the following rules apply for regular expression field: RegExp Parameter of the NAPTR record in the ENUM reply for queries forwarded to SS7 nodes to perform SS7 query will be formatted according to NAPTR record service parameter value and the format is compliant with RFC 4694 and RFC 4769.

5.9   Replacement

Table 11    Replacement

Type	Text string
Size (octets)	Up to 256 octets
Identity	REPLACEMENT
Description	This field is used when the regular expression is a simple replacement operation. Any value in this field must be a fully qualified domain name. Name compression is not used in this field. This field and the REGEXP field together make up the Substitution Expression in the DDDS Algorithm. The field is mutually exclusive with REGEXP field.

5.10   Services

Table 12    Services

Type	Text string
Size (octets)	8 octets
Identity	SERVICES
Description	The applicable service parameters. This should normally be "E2U+sip" for an ENUM query. IPWorks ENUM Server provides no restriction on the value of Service element for ordinary ENUM query except the size of the element. All currently registered ENUM Service could be found in http://www.iana.org/assignments/enum-services. For the ENUM replies which are composed based on information got from external SS7 database or CUDB via number portability query, the value of the service parameter of the NAPTR record shall be set according to RFC4769. Both "E2U+pstn:tel" and "E2U+pstn:sip" are valid, "E2U+pstn:tel" is the default value. It can be configured in IPWorks at number series level.

6   Error handling

The ENUM Server detects errors in queries sent by clients. It responds with the following response codes as defined in RFC 1035, Reference [7], RFC 2136, Reference [14] and RFC 2671, Reference [17].

Table 13    Error handling

RCODE	Circumstance
1 Format Error	The ENUM Server cannot interpret the query.
2 Server Failure	The ENUM Server cannot service requests at this time.
3 Name Error	The query is below an equipped ENUM zone, but the domain name specified in the query has not been configured in the database or the query to external SS7 database or CUDB has failed in number portability case.
4 Not Implemented	All non-supported OPCODEs.
5 Refused	The ENUM Server does not generate this response code.
6 YXDomain	Only relevant to dynamic updates. The ENUM Server does not generate this response code.
7 YXRRset	Only relevant to dynamic updates. The ENUM Server does not generate this response code.
8 NXRRSet	Only relevant to dynamic updates. The ENUM Server does not generate this response code.
9 NotAuth	Only relevant to dynamic updates. The ENUM Server does not generate this response code.
10 NotZone	Only relevant to dynamic updates. The ENUM Server does not generate this response code.
16 BADVERS	The ENUM Server returns this response code if the query contains an OPT resource record with a non-zero Version.
All other RCODEs	The ENUM Server does not generate these response codes.

7   Formal Syntax

This section refers to specification where the formal syntax notation is defined. It also describes any deviations from the specification, if applicable.

For information about the formal syntax notation, see the following specification:

• Implementation and specification - RFC 1035 Implementation and specification - RFC 1035, Reference [7]

8   Related Standards

The ENUM Server complies with the RFCs listed in Reference to the extent to support the ENUM protocol, as described in the preceding sections of this document. As to SOC, refer to Reference [4] and Reference [5].

Reference List

IPWorks Library Documents
[1] Trademark Information.
[2] Glossary of Terms and Acronyms.
[3] Typographic Conventions.

PCAT and Other Ericsson Document
[4] SOC to RFC 4694, 7/174 02-CSH 109 019/2
[5] SOC to RFC 4769, 5/174 02-CSH 109 019/2

Standards
[6] Domain names - concepts and facilities - RFC 1034.
[7] Domain names - implementation and specification - RFC 1035.
[8] DNS encoding of network names and other types - RFC 1101.
[9] Requirements for Internet Hosts – Application and Support - RFC 1123.
[10] New DNS RR definitions - RFC 1183.
[11] Serial number arithmetic - RFC 1982.
[12] Incremental zone transfers in DNS - RFC 1995.
[13] A mechanism for prompt notification of zone changes - RFC 1996.
[14] Dynamic updates in the Domain Name System - RFC 2136.
[15] Clarifications to the DNS specification - RFC 2181.
[16] Negative Caching of DNS Queries (DNS NCACHE) - RFC2308.
[17] Extension mechanisms for DNS (EDNS0) - RFC 2671.
[18] Non-terminal DNS name redirection - RFC 2672.
[19] A DNS RR for specifying the location of services (DNS SRV) - RFC 2782.
[20] Obsoleting IQUERY - RFC 3245.
[21] Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS - RFC 3401.
[22] Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm - RFC 3402.
[23] Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database - RFC 3403.
[24] Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application - RFC 3404.
[25] The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) - RFC 3761.
[26] DNS Security Introduction and Requirements - RFC 4033.
[27] Resource Records for the DNS Security Extensions - RFC 4034.
[28] Protocol Modifications for the DNS Security Extensions - RFC 4035.
[29] Number Portability Parameters for the "tel" URI - RFC 4694.
[30] IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information - RFC 4769.