Carrier ENUM Resolution User Guide

3333

TNS Carrier ENUM ServicesResolution Service User’s Guide

Type of Guide gistry

TNS Carrier ENUM Data Access User's Guide

2 Transaction Network Services

Copyright © 2010 Transaction Network Services, Inc. All rights reserved.

The information in this document belongs to Transaction Network Services (TNS). It may not be used, reproduced or disclosed without the written approval of TNS.

DISCLAIMER AND LIMITATION OF LIABILITY

Transaction Network Services, Inc. has made efforts to ensure the accuracy and completeness of the

information in this document. However, Transaction Network Services, Inc. makes no warranties of any

kind (whether express, implied or statutory) with respect to the information contained herein.

Transaction Network Services, Inc. assumes no liability to any party for any loss or damage (whether

direct or indirect) caused by any errors, omissions, or statements of any kind contained in this

document. Further, Transaction Network Services, Inc. assumes no liability arising from the application

or use of the product or service described herein and specifically disclaims any representation that the

products or services described herein do not infringe upon any existing or future intellectual property

rights. Nothing herein grants the reader any license to make, use, or sell equipment or products

constructed in accordance with this document. Finally, all rights and privileges related to any intellectual

property right described herein are vested in the patent, trademark, or service mark owner, and no other

person may exercise such rights without express permission, authority, or license secured from the

patent, trademark, or service mark owner. Transaction Network Services Inc. reserves the right to make

changes to any information herein without further notice.

TRADEMARKS

The TNS logo and other trademarks, service marks, and designs are registered or unregistered trademarks of Transaction Network Services, Inc. and its subsidiaries in the United States and in foreign countries. All other trademarks are property of their respective owners.

This document may describe features and/or functionality that are not present in your software or your service agreement. Contact your account representative to learn more about what is available with this TNS product. If you need help using this product, contact customer support.

[email protected]

TNS Carrier ENUM Services

Transaction Network Services 3

Contents

1. TNS Carrier ENUM Service.................................................................. 5

Service Features........................................................................................ 6

Querying TNS Carrier ENUM Services................................................. 7

Service Provider Identification .............................................................. 8

TNS Carrier ENUM Platform ................................................................ 8

Industry Standards ............................................................................. 10

Service Setup and Management.............................................................. 10

Connectivity and Access .................................................................... 11

ENUM Client Software Development Kit ............................................ 11

Help Desk Procedures........................................................................ 12

Maintenance Windows ....................................................................... 13

Redundancy ....................................................................................... 13

2. Service Details ................................................................................... 14

ENUM Data................................................................................... 14

Public ENUM Data Sources .......................................................... 14

Private ENUM Data Sources......................................................... 15

Provisioning Web Portal ..................................................................... 17

3. ENUM Message Structure and Flows................................................. 18

Common Fields in Queries and Responses ....................................... 18

Error Messages............................................................................. 19

ENUM Query ...................................................................................... 20

ENUM Response................................................................................ 20

Resource Record Format.............................................................. 20

Naming Authority Pointer (NAPTR) Resource Record Format ........... 21

Example Messages ................................................................................. 24

Query Example 1................................................................................ 24

Response Example 1 ......................................................................... 24

Query Example 2................................................................................ 24

Response Example 2 (Valid Number) ................................................ 24

Response Example 3 (Invalid Number) .............................................. 27

4. SIP Message Structure and Flows ..................................................... 29

SIP Message Flows............................................................................ 29



SIP Message Formats ........................................................................30

A. Protocol interface changes .................................................................32

B. Glossary..............................................................................................34



1. TNS Carrier ENUM Service

Communication services become more valuable when calls and messages can be received from and sent to users of other service providers’ networks. TNS Carrier ENUM is a carrier-of-record registry that provides accurate information to service providers that is critical for successful routing of communication services including MMS, SMS, and VoIP. Lookups to the TNS Carrier ENUM result in the return of carrier-of-record information including Service Provider Identifier (SPID), Location Routing Number (LRN), and when available, the Uniform Resource Locator (URL) associated with the service provider.

Currently, the industry faces a challenge stemming from applications using Internet protocols to communicate with consumer devices that are addressed by telephone numbers. The application must have the ability to identify the carrier-of-record for the destined telephone number to enable successful message delivery. Number portability complicates carrier-of-record identification. Subscribers porting telephone numbers to other carriers results in an application’s inability to determine, at any given time, the carrier through which the device is reachable.

The ideal solution to this problem is a domain name system (DNS) populated with line information sourced from industry and regulatory number management systems and directly from the authoritative entity (carrier or reseller). This permits the application to discover the carrier-of-record of a given telephone number by simply performing a number lookup in the form of an ENUM query. For example, the carrier-of-record information for telephone number 1-650-555-1234 can be retrieved through a lookup of the fully-qualified domain name 4.3.2.1.5.5.5.0.5.6.1.nrd.tnsi.com

TNS operates an intelligent infrastructure that facilitates this critical functionality.

TNS Carrier ENUM is a comprehensive registry that provides accurate and timely carrier-of-record information accessible through ENUM or through SIP interfaces. The registry contains essential information for ported, non-ported, and pooled telephone numbers. Registry information is derived from industry sources and, in some cases, directly from the authoritative entity (carrier or reseller). When queried, the registry returns carrier-of-record information including; (a) the Service Provider Identifier of the carrier or reseller, (b) if the number has been ported, the Location Routing Number that is necessary to route telephone calls to the carrier of the ported telephone number, and (c) when available, service routing information in the form a Uniform Resource Locator such as a “mailto:” URI.

Optionally, TNS Carrier ENUM can also be used as a central repository for other subscriber information or metadata for data providers, which their trading partners can query to retrieve data critical to a particular service fulfillment.



Extending the multi-tenant TNS Carrier ENUM system, data providers can allow trading partners’ data-sharing capabilities, featuring safeguards designed to uphold the data provider’s sharing policies.

For example, a data provider such as a mobile operator can register subscription status (active, inactive) and rate plan information (post-paid or prepaid) for each mobile telephone number. Using the self-administration capabilities of the TNS Carrier ENUM, the mobile operator is able to selectively publish information, in whole or part, to its trading partners. Trading partners can choose to selectively accept the information provided by data providers.

TNS Carrier ENUM enhances the service delivery functions of telecommunication applications by:

Identifying the service provider associated with a telephone number for routing calls and messages

Summarizing multiple instances of carrier identifiers to enable efficient management of carrier data (OCN and SPID roll ups)

Storage of service provider specific information and selectively sharing the information with trading partners.

Optionally mapping a telephone number to the Universal Resource Identifier (URI) to identify the system hosting the end user's service subscription.

Optionally mapping carrier identifiers to customer-specific identifiers (pseudo-SPIDs)

Optionally mapping a telephone number to other subscriber information or metadata such as subscription status (active/non-active), network type (GSM/CDMA), and rate plan information (pre-paid/post-paid).

Service providers can send DNS queries (optionally using the TNS ENUM Java SDK), or SIP queries to query the TNS Carrier ENUM Services.

Service Features TNS Carrier ENUM features include:

SPID Discovery

Using metadata from both industry and authoritative sources, ENUM queries return the overall service provider identifier, or SPID, associated with a telephone number. Public data originates from industry sources, including number portability databases. Authoritative data is sourced directly from the carrier-of-record and selectively published to users of the TNS Carrier ENUM. The primary value of sourcing private data is to compensate for when industry data does not exist, as in the case of mobile virtual network operators and privately leased ranges.



LRN Discovery

If the queried telephone number has been ported or pooled, TNS Carrier ENUM returns the Location Routing Number (LRN) that provides current service provider routing (local office) information. The LRN is regularly sourced from the North American Portability Administration Centers (NPACs), and is available real-time.

URL Discovery

TNS maintains tables within the ENUM database that map the identified SPID (and optionally LRN) to an associated URL. For example, a queried mobile directory number may respond with the “mailto:” URL associated with the mobile operator’s mobile message service.

Service Provider Data Management

Service providers can upload their numbering information and associated routing information to TNS Carrier ENUM registry. Once uploaded, a service provider can selectively share this data with its trading partners, thereby controlling how trading partners send traffic to the service provider. Changes made on the portal are exposed to trading partners immediately, thereby influencing the routing decisions made trading partners.

Access and Administration

The TNS Carrier ENUM is accessed through secure VPN connectivity. SIP and ENUM protocols are supported for querying data, and a Java API is provided by TNS. A secure Web portal provides customers with the capability to self manage customer specific routing information as needed. Web portal also provides access to a rich set of reports to TNS customers with information regarding the usage of TNS Carrier ENUM service. Web Services API is also available for service providers to provision their service data into TNS Carrier ENUM.

Querying TNS Carrier ENUM Services TNS Carrier ENUM services can be accessed using industry standard ENUM protocol or Session Initiation Protocol (SIP).

When employing ENUM interface to query TNS Carrier ENUM service, multiple NAPTR records may be returned for a queried number:

A NAPTR record containing an LRN if the number is ported, the applicable SPID for the E.164 number, and

(Optionally, if provisioned), multiple NAPTR records containing a "mailto" URI with a host name that corresponds to the operator currently serving the queried MDN.

+ Note As per DNS/ENUM protocols, the ordering of the NAPTR responses and ordering of the parameters within each NAPTR is not guaranteed to always occur in



the same order as above. Instead, the recipient of the response should process all the NAPTRs and select the one with the highest order returned and/or setup a local selection policy to determine which of the returned NAPTRs it should utilize for further processing.

When employing SIP interface to query TNS Carrier ENUM service, results are returned as SIP redirect responses (302 “Temporarily Moved”), with the information about carrier-of-record. Contact header in the SIP redirect response is used to return the service provider information. LRN, SPID, service provider name and number portability dip indicator are returned as parameters to Contact header in the SIP redirect response.

Service Provider Identification The TNS Carrier ENUM determines ownership of an E.164 formatted telephone number (up to 15 digits) by associating the number with a unique service provider identifier. Service Provider Identifier is a 4-character identifier that uniquely identifies a telecom service provider. The identifier can be a globally unique service provider identifier (SPID) or Operating Company Name (OCN) assigned by regulatory bodies or a pseudo-service provider identifier (pseudo-SPID) assigned by TNS.

If a service provider does not have a SPID assigned by industry sources (in the case of MVNOs and international carriers, for example), then TNS assigns a pseudo-SPID for use. A pseudo-SPID is only valid within the context of the TNS Carrier ENUM service and is not an industry-approved or -published SPID.

Multiple SPIDs or OCNs belonging to same carrier can be rolled up within TNS Carrier ENUM, thereby allowing users of TNS Carrier ENUM service to easily identify the carrier. TNS Carrier ENUM Web Portal allows users to perform SPID rollups themselves by grouping multiple SPIDs or OCNs and rolling them up to a single SPID.

TNS Carrier ENUM Platform The following diagram shows the components of the TNS Carrier ENUM service and their interrelationships.

TNS supports two deployment options for its customers based on customer requirements – a central replica model and a local replica model. With the central replica model, resolution servers are located in TNS data center. A local replica model allows resolution servers to be co-located with customer equipments thereby minimizing network latency and increasing throughput. Both central replica and local replica receive real-time updates from the TNS registry.



TNS Carrier ENUMRegistry

Number Portability AdministrationCenter (NPAC)

National NumberingDatabases

Authoritative data & Carrier private data

TNS Hosted ENUMCentral‐Replica

Master Database

In‐memory Database

Internet

Real‐time data replication to

Local‐replicas over VPN

Real‐time data replication to

Central replicas

Customer Application

In‐memory Database

ENUM Client

Optional Local‐Replica

VPNTNSCustomer

Customer Data Center

TNS Carrier ENUM Architecture Diagram



Industry Standards TNS Carrier ENUM is consistent with industry standards, including the following standards as amended periodically:

Interoperable Interface Specification for Number Portability Administration Center Service Management System [IIS-NPAC-SMS], from North American Number Council (NANC)

Functional Requirements Specifications for Number Portability Administration Center Service Management System [FRS-NPAC-SMS], from NANC

Customers should be familiar with the following information from the Internet Engineering Task Force (IETF), the organization that establishes protocol standards for the operation of the Internet. These documents refer specifically to the ENUM standard and the Domain Name System:

RFC 1035 , "Domain names - Implementation and Specification", November 1987: http://www.ietf.org/rfc/rfc1035.txt

RFC 3403, "Dynamic Delegation Discovery System Part Three: The Domain Name System (DNS) Database", October 2002: http://www.ietf.org/rfc/rfc3403.txt

RFC 3761, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) ", April 2004: http://www.ietf.org/rfc/rfc3761.txt

RFC 4694, “Number Portability Parameters for the "tel" URI,” October 2006: http://www.ietf.org/rfc/rfc4694.txt

RFC 3261, “SIP: Session Initiation Protocol”, June 2002, http://www.ietf.org/rfc/rfc3261.txt

Service Setup and Management Setup for the TNS Carrier ENUM service involves the following basic steps, managed and coordinated by Service Deployment:

Execute required Service Agreement

Exchange primary contact information and any high-level customer network connectivity documentation available

Provide customer with TNS ENUM Java SDK and related documentation

Participate on a service kick-off call during which setup forms are reviewed and customer-specific environment elements are discussed

Complete and submit setup forms



Establish connection to the TNS operational test and evaluation service, if required

Establish connections to the production service

- ENUM account/profile setup

- VPN Connectivity (secure IP connectivity)

- Provide ENUM Web portal access

Complete customer NOC training for Direct Service (online ticketing)

Provide welcome package to customer

Connectivity and Access Customers access the TNS ENUM service using the interface specified in “Service Details ” on page 13. Customers must connect to the TNS network over a secure Virtual Private Network (VPN). Data queries can be sent using the DNS protocol or the Session Initiation Protocol (SIP). IP address and VPN rule information is exchanged by setup forms during implementation. The customer is responsible for its own network expenses incurred in connecting with all such interfaces.

TNS ENUM Java SDK ENUM clients can choose to query ENUM data hosted by the TNS Carrier ENUM Services using the Java resolution API supplied by TNS. TNS makes the API available as a software development kit (SDK) which includes sample code, configuration files, and documentation.

The TNS ENUM Java SDK employs ENUM protocol to query TNS Carrier ENUM services. ENUM SDK is based on JSR-161, JAIN ENUM API Specification. In addition to performing queries on behalf of the client applications, ENUM SDK also performs health monitoring, failover and grouping of requests to enhance application throughput. ENUM SDK supports multiple threading models to allow easy integration with applications that utilize different threading models.

The SDK is delivered once you have signed the contract for the service.



Help Desk Procedures

TNS Customer Support tracks all operational elements of the TNS Carrier ENUM service. Customers can manage fault reporting and status by opening trouble tickets using the Direct Service application. To set up a Direct Service account, contact Customer Support by:

E-mail: [email protected]

Phone: 1-800-416-3882, Option 4

The Direct Service application is the preferred method for contacting Customer Support. Using Direct Service, the customer immediately receives a Service Request (SR) number and the issue is automatically placed into the appropriate workgroup for review and resolution.

TNS support personnel may also initiate tickets based on the monitoring and alarms in place for the TNS Carrier ENUM service. The customer receives e-mail notifications from TNS during service-impacting events. TNS tracks day-to-day operations, usage, and system performance internally using logs and traps configured for the system.

Tickets should be opened to report service outages, detriments to service, or inconsistent service. To ensure the quickest path to resolution is followed, the first point of contact for TNS service and support should always be Customer Support.

Customer Support is available 24 hours-a-day, 365 days-a-year.

When calling Customer Support, customers should provide the following information, as applicable, at the time of the call:

Customer name

Contact name and callback number

Problem description (for example, messages not delivered, service returned error message, carrier-of-record returned is incorrect)

Date and time problem was detected

Source IP address and/or Destination IP address

E.164 telephone number queried

Query results

Error messages



Maintenance Windows Maintenance for any TNS-managed component is conducted during the standard scheduled maintenance window:

Sunday 12:00 a.m. to 6:00 a.m. Eastern Standard Time.

Standard scheduled maintenance notifications are sent to customers at least 5 days in advance of maintenance activities, and include information about the nature of the maintenance, the approximate time needed to complete the work, and impacts to customer traffic, if any. In the event TNS must conduct emergency maintenance, commercially reasonable efforts will be made to provide advance notice to customers. For every maintenance conducted, TNS compiles internal plans for backing out the changes imposed by the maintenance, including steps, owners, go/no go decision points, and total timeframes for completing the back-out.

TNS endeavors to schedule maintenance to coincide with Number Portability Administration Center (NPAC) maintenance windows standard for the industry. The NPAC may change or add maintenance windows as required, outside of the control of TNS. In this event, customers will be notified of the window accordingly.

Redundancy In support of maintenances, changes, and unforeseen disasters, TNS takes every precaution to deploy its service in a completely redundant manner. The service has been deployed to multiple sites using multiple components for the resolution systems as well as the provisioning systems. Routers, switches, VPNs, and Internet Service Providers used to support the applications are also deployed in a redundant manner. TNS conducts failover verification testing periodically during maintenance windows to ensure the availability of the service. Additionally, TNS works with customers to ensure their networks are configured to take advantage of the TNS-deployed redundant components.



2. Service Details

The TNS Carrier ENUM service architecture consists of two key elements - the ENUM Server and the ENUM Client. The ENUM Server securely maintains and regulates access to the E.164 telephone address and the associated service provider identity. It can also host the policy for mapping the E.164 address or SPID/Pseudo-SPID to a URI that is resolvable by DNS or SIP. The ENUM Client is typically co-located with the customer's voice, messaging, or content application. Through callouts to the ENUM Server, the ENUM Client identifies the owner of the E.164 address, and then applies relevant service logic. For example, an inter-carrier messaging application uses ENUM query results (SPID and optionally URI) as input to its interoperability and routing service logic to accurately broker the exchange of messaging between mobile networks.

ENUM Data

In its simplest form, ENUM data securely stored on the ENUM Server includes a list of E.164 numbers and/or blocks of numbers, the associated SPID, and optionally, the policy for mapping the E.164 address or SPID/Pseudo-SPID to a URL or the mailto address.

The ENUM server maintains two types of ENUM data:

Public -- global in scope and viewable by all ENUM clients

Private -- restricted in scope and viewable only by the associated ENUM client or the ENUM clients to which the principal ENUM client has granted access.

Both public and private ENUM data contain sub-types which are assigned an order of precedence based on the source and intent of the data.

For example, when determining the ownership of a number using public ENUM Data, Local Number Portability (LNP) data has precedence over data derived from the North American Numbering Plan Administration (NANPA)

Public ENUM Data Sources

The ENUM server populates the public ENUM data from industry sources. This data has a lower precedence than private ENUM data.

Public ENUM data sub-types include, in descending order of precedence:

1. Local Number Portability (LNP) Data. This data sub-type provides network service provider ownership for ported and pooled telephone numbers. The LNP SPID takes precedence over the North American Numbering Plan Administrator’s Operating Company Number (OCN).



2. North American Numbering Plan Administration (NANPA): The NANPA data identifies the service provider owner (OCN) of the number blocks within the North American Numbering Plan.

3. International Carrier Data: This data is sourced from various international carriers and regulatory bodies. A unique VSPID is created by TNS that identifies each international carrier.

Private ENUM Data Sources

Private ENUM data sourced from the ENUM client characterizes the client’s interpretation (URI mapping) of public ENUM data and provides the opportunity to either override or augment public ENUM data with authoritative data.

Authoritative Lists: An authoritative entity, such as a network operator or virtual network operator, can choose to directly provide the ENUM client with a complete list of its E.164 numbers or line ranges. If the authoritative entity chooses to use the authoritative source for their E.164 addresses it then supersedes industry sources. The SPID/Pseudo-SPID (and optional URI) from the Authoritative List supersedes the information for the E.164 number from public ENUM data sources. Authoritative List data is restricted and is not published to all ENUM clients unless permission is granted. Distribution for public access or other use is prohibited.

White Lists: An ENUM client can create a White List of E.164 addresses and an optional SPID/Pseudo-SPID-to-URI mapping policy visible only to the specific ENUM Clients identified by the White List owner. White List data has the highest precedence of all ENUM data.

SPID/Pseudo-SPID-to-URI Mapping Policy: This feature allows the ENUM Client to define a set of viewable E.164 addresses. All Public ENUM Data is viewable by the ENUM Client by default. The ENUM Client can populate an inclusive policy or filter identifying which SPID/Pseudo-SPID should be returned in a query result.

Private ENUM data sub-types are listed here in descending order of precedence:

The White List is a set of telephone numbers that returns the pre-programmed service provider identifier (SPID/Pseudo-SPID) and/or mapped URI if queried by the ENUM Client or specified partners.

- White Lists can be used when two or more entities agree to perform some preliminary interoperability or service evaluation testing. Rather than simply including all E.164 addresses associated with a service provider, a subset or test suite of numbers is provisioned against the White List and associated with a Pseudo-SPID, confining the evaluation to a limited number of subscribers/devices.

Authoritative Lists - Sent to TNS by one or many authoritative entities through the ENUM Client using an electronic data transfer mechanized over a VPN or secure session. These are complete lists of all telephone numbers allocated to the



authoritative entity. The ENUM Client’s Authoritative List is a composite of all authoritative lists received by the ENUM Client.

Examples of business needs for authoritative lists include:

Mobile Virtual Network Operators (MVNOs) for which subscriber numbers are identified within industry data sources as belonging to the MNO, but for whom they'd like to be identified as the authoritative entity (Pseudo-SPID).

Resellers for which subscriber numbers are identified within industry data sources as belonging to either an MNO or wireline Service Provider, but for whom they would like to be identified as the authoritative entity (pseudo-SPID).

MNOs/MVNOs which prefer to supersede industry data with a more precise representation of active numbers to override industry sources (leased ranges)



Provisioning Web Portal TNS Carrier ENUM provides a Web portal that allows customers to perform various provisioning activities like creation of white lists, SPID rollups, and establishment of SPID/Pseudo-SPID-to-URI mapping policies etc. The portal also has a rich set of reports that provide details on the provisioned data, usage and system availability.

Data can be provisioned on TNS Carrier ENUM using direct user input, bulk file upload, or through the Web Services API. All data provisioned on the TNS Carrier ENUM portal is immediately made available to the customers and their trading partners based on the peering relationship established on the portal.

The Service Deployment team provides login information, the User Guide, and an initial training session.

See the Service Provider Users' Guide for the Network Routing Directory Provisioning System, available from your account manager, for more information.



3. ENUM Message Structure and Flows

This section outlines the message formats used by the TNS Carrier ENUM when using ENUM as the access protocol. All ENUM transactions are stateless query/response volleys. (The service does not perform recursive queries or give referral responses.) ENUM gives a valid response if it has the data requested, or an error in all other cases.

Refer to the following references listed for details on query and response formats:

RFC 1035 , "Domain names - Implementation and Specification", November 1987: http://www.ietf.org/rfcs/rfc1035.txt

RFC 3761, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) ", April 2004 http://www.ietf.org/rfc/rfc3761.txt

RFC 3403, "Dynamic Delegation Discovery System Part Three: The Domain Name System (DNS) Database", October 2002: http://www.ietf.org/rfc/rfc3403.txt

Refer to Appendix-A for any TNS Carrier ENUM Service version specific protocol interface changes.

Common Fields in Queries and Responses This section outlines the fields of the DNS message relevant to ENUM and common to DNS queries and responses. Later sections discuss the fields specific to queries and responses. (Refer to Section 4.1.1 of RFC 1035) for more information about these fields.)



The following table describes the common fields.

Field Description

ID A 16-bit identifier for the ENUM query

QR The Query bit (QR) is cleared (set to 0) for the ENUM query.

OPCODE This field is set to QUERY (0) for the ENUM query.

AA The Authoritative Answer (AA) bit is set by all non-error responses sent by ENUM SDK, and cleared in all error responses. The SDK logs a message if this field is set to 0 for responses

TC The Truncation (TC) bit is set in all responses sent by ENUM SDK that would be larger than the limits set by RFC 1035. The SDK logs a message if this field is non-zero for responses.

RD Number Identity Registry ignores the Recursion Desired (RD) bit and reflects its value in the responses it sends.

RA ENUM always clears the Recursion Available (RA) bit in responses, because ENUM SDK performs no recursive queries on behalf of the client. This field is set to 0 in queries and ignored in responses.

Z The "reserved for future use" field is always set to 0 for Number Identity Registry responses/errors, and must be set to 0 for ENUM queries.

RCODE This field is set to 0 for ENUM query. This is set by the server to NO ERROR (0) for successful lookups (where the number queried has a record in the database).

QDCOUNT Queries to Number Identity Registry will have only 1 question.

ANCOUNT This field is set to 0 for ENUM query. This is set by the ENUM server as the number of NAPTR resource record contained in responses, or 0 in error conditions.

NSCOUNT This field is set to 0 for ENUM query. ENUM SDK does not expect the server returning authority records.

ARCOUNT This field is set to 0 for ENUM query. ENUM SDK does not expect the server returning additional records.

Error Messages

Errors are returned in the RCODE parameter of response messages. Refer to the IETF document (RFC1035 - section 4.1.1) for the most up to date information.

RCODE Description

0 No error condition

1 Format error - The name server was unable to interpret the query

2 Server failure - The name server was unable to process this query due to a problem with the name server

3 Name Error - Meaningful only for responses from an authoritative name server, this code signifies that the domain name referenced in the query does not exist

4 Not Implemented - The name server does not support the requested kind of query



5 Refused - The name server refuses to perform the specified operation for policy reasons For example, a name server may not wish to provide the information to the particular requester, or a name server may not wish to perform a particular operation (for example, zone transfer) for particular data

6-15 Reserved for future use

ENUM Query ENUM SDK sends queries that follow the syntax specified in Section 4.1.2 of RFC 1035. In addition to the fields specified in the previous section, these fields have significance in ENUM queries.

The following table describes the fields

Field Description

QNAME The domain name must be within the configured top-level domain for ENUM SDK (by default, "nrd.tnsi.com"). In addition, the remaining labels of the domain name must conform to the syntax defined in Section 2, step 6 of RFC 2916.

QTYPE The ENUM SDK sets this field to NAPTR (35).

QCLASS The ENUM SDK sets this field to IN (1).

ENUM Response The ENUM SDK receives responses in the format specified in RFC 3403. The ENUM responses could contain one or more answer NAPTR resource records. However the SDK does not expect any Authority or Additional resource records.

Resource Record Format

ENUM returns the following fields in the resource records. Refer to Section 4.1.3 of RFC 1035 for more information about the resource record format:



The following table describes the fields.

Field Description

NAME ENUM server returns the name of the resource record.

TYPE SDK expects only NAPTR RRs (35); for other values it ignores the record.

CLASS SDK expects only IN (1); for other values it ignores the record

TTL Time-to-live value for the NAPTR RR.

RDLENGTH Length of the NAPTR RR data. SDK ignores the record if the field value is 0

RDATA This field contains the NAPTR data. The syntax of this field is described in a subsequent section.

Naming Authority Pointer (NAPTR) Resource Record Format This section describes in depth the syntax of NAPTR RR data, as defined in Section 4.1 of RFC 3403.



The following table describes the fields.

Field Description

ORDER The order for the NAPTR RR.

PREFERENCE The preference for the NAPTR RR.

FLAGS The SDK expects the value "u" as per RFC 2916 and RFC 3403. This flag means "URI", and indicates a terminating record. If the field length is 0, the SDK ignores the record returned. If the field value is not "u", the SDK logs a message and returns an error.

SERVICE This field is set by the ENUM server depending on the type of URI in the NAPTR RR, e.g. "E2U+tel" or "E2U+mms" etc. If the field length is 0, the SDK ignores the record returned.

REGEXP According to RFC 3403 this is the regular expression to apply to the original query (in this case, phone number). The elements are delimited by the '!' character. If the field length is 0, the SDK ignores the record returned.

REPLACEMENT The replacement field is not used by ENUM SDK.

The following additional information is provided by the TNS Carrier ENUM service and aids in routing of the calls to the appropriate switch/VoIP gateway. These are provided as additional parameters to the "sip" URI NAPTR returned in the form of "tag[=value]" data, that are separated by ";"

Location Routing Number (LRN): This is the address of the telephone switch that services a given telephone number. If the number is not ported or pooled, the OCN of the code holder as derived from the North American Numbering Plan Administration is returned in the response. If there is no information at all, an NXDOMAIN error is returned. If the number has been ported, this is the address of the current switch on which the number resides. TNS Carrier ENUM generates one "sip" URI NAPTR RR containing the LRN of the ported number. This parameter is provided only if the number is ported. For non-ported numbers, it will not be present.



Example: "rn=+19735599999"

Service Provider Identifier (SPID): This is a 4-character alphanumeric identifier for a telecom service provider for ported numbers. This value can map to a name in the LNP database (maintained by the NPAC), and optionally maps to a domain. In case of non-ported numbers, this parameter can contain the OCN (Operating Company Name) derived from NANPA database, or it can be customized per ENUM client to map to a SPID or a VSPID. This parameter is always present for queries that are returned with a positive response.

Example : "spid=1234"

Number Portability Dip Indicator (NPDI): The presence of the NPDI parameter in the URI indicates that the NP database lookup has been done. This parameter is always present for queries that are returned with a positive response.

Example: "npdi" (Note that this has only a tag name, no value attached to it.)

So, one example of a complete NAPTR regular expression with all the above fields populated would look like:

"!^.*$!sip:+15555559999;rn=+19735559999;spid=1234;npdi!"

The following additional information can be provided by the TNS Carrier ENUM service in the form of an additional NAPTR and aids in routing of the calls to the appropriate SMSC/MMSC:

Mailto URI: This URI can be returned back in responses from the TNS Carrier ENUM service – depending upon if the querying client has set up a SPID<-> mailto for the SPID being returned.

Example: mailto:[email protected] So, one example of a complete NAPTR regular expression for the mailto URI would look like:

"!^.*$!mailto:[email protected]!"

The SDK provided by TNS provides API calls that parse the NAPTR returned by the server and extract the above LRN, SPID, and NPDI information.



Example Messages This section gives a detailed description of an example DNS ENUM transaction, with an emphasis on message format. It provides a hex dump of each message (query and response), along with a field-by-field breakdown of each message. All examples contain fictitious data.

Query Example 1 To create a domain name for a given phone number, apply the algorithm described in section 2 of RFC 3761. Once the domain name is generated, a DNS query can be sent to the ENUM server. A simple way to send DNS queries is with the command-line utility dig (provided with ISC bind).

For example, suppose you want to query the portability status of a US phone number, 510-996-4321. The resultant domain name for this number would be "1.2.3.4.6.9.9.0.1.5.1.nrd.tnsi.com" Assuming that the name of the ENUM server is "bart12," the syntax for the dig command would appear as following:

Domain Name System (query)

Transaction ID: 0xa2ac

Flags: 0x0100 (Standard query)

0... .... .... .... = Response: Message is a query

.000 0... .... .... = Opcode: Standard query (0)

.... ..0. .... .... = Truncated: Message is not truncated

.... ...1 .... .... = Recursion desired: Do query recursively

.... .... .0.. .... = Z: reserved (0)

.... .... ...0 .... = Non-authenticated data OK: Non-authenticated

data is unacceptable

Questions: 1

Answer RRs: 0

Authority RRs: 0

Additional RRs: 0

Queries

1.2.3.4.7.6.6.3.0.7.1.nrd.tnsi.com: type NAPTR, class IN

Name: 1.2.3.4.7.6.6.3.0.7.1.nrd.tnsi.com

Type: NAPTR (Naming authority pointer)

Class: IN (0x0001)

Response Example 1 (Valid Number)



The ENUM DNS server returns a successful response if the number was a valid North American Numbering Plan (NANP) number. It contains at least one NAPTR resource record in the answer section, which contains the PSTN signaling data of the phone number in a tel: URI. Depending on whether a MMS domain name existed for the service provider associated with the phone number, there may be another NAPTR resource record providing the MMS address for the phone number.

Continuing the example query in the previous section, here is the output of the dig command for the example response:

Domain Name System (response)

Transaction ID: 0xa2ac

Flags: 0x8400 (Standard query response, No error)

1... .... .... .... = Response: Message is a response


.... .1.. .... .... = Authoritative: Server is an authority for

domain


.... ...0 .... .... = Recursion desired: Don't do query recursively

.... .... 0... .... = Recursion available: Server can't do recursive

queries

.... .... .0.. .... = Z: reserved (0)

.... .... ..0. .... = Answer authenticated: Answer/authority portion

was not authenticated by the server

.... .... .... 0000 = Reply code: No error (0)

Questions: 1

Answer RRs: 2

Authority RRs: 0

Additional RRs: 0

Queries


Name: 1.2.3.4.7.6.6.3.0.7.1.nrd.tnsi.com


Class: IN (0x0001)

Answers

1.2.3.4.7.6.6.3.0.7.1.nrd.tnsi.com: type NAPTR, class IN, order 10,

preference 11, flags u

Name: 1.2.3.4.7.6.6.3.0.7.1.nrd.tnsi.com


Class: IN (0x0001)

Time to live: 5 minutes

Data length: 88

Order: 10

Preference: 11



Flags length: 1

Flags: "u"

Service length: 25

Service: "E2U+mms:mailto+sms:mailto"

Regex length: 54

Regex: "!^.*$!mailto:[email protected]!"

Replacement length: 1

Replacement: .

1.2.3.4.7.6.6.3.0.7.1.nrd.tnsi.com: type NAPTR, class IN, order 10,

preference 11, flags u

Name: 1.2.3.4.7.6.6.3.0.7.1.nrd.tnsi.com


Class: IN (0x0001)

Time to live: 5 minutes

Data length: 70

Order: 10

Preference: 11

Flags length: 1

Flags: "u"

Service length: 12

Service: "E2U+pstn:tel"

Regex length: 49

Regex: "!^.*$!tel:+17036674321;rn=+15717669999;spid=1234!"

Replacement length: 1

Replacement: .

Note that the data for the telephone number is contained in the first NAPTR resource record's Regular expression field. The following pieces of data are contained as URI parameters, which are delimited with semicolons (";"):

LRN:rn=+15717669999

SPID:spid=1234

Finally, the "npdi" URI parameter indicates that a number portability dip has been performed on the number in the tel: URI. The LNP platform will append this parameter to all tel URIs it generates.



Example 2 (Invalid Number) If the number queried was not a valid NANP-assigned number, the ENUM server would return a NXDOMAIN error, because no number information exists for it.

Here is the dig output for an example response returned for a non-ported number 571-667-4321:

Domain Name System (query)

Transaction ID: 0x65cf

Flags: 0x0100 (Standard query)

0... .... .... .... = Response: Message is a query



.... ...1 .... .... = Recursion desired: Do query recursively

.... .... .0.. .... = Z: reserved (0)

.... .... ...0 .... = Non-authenticated data OK: Non-authenticated

data is unacceptable

Questions: 1

Answer RRs: 0

Authority RRs: 0

Additional RRs: 0

Queries


Name: 1.2.3.4.7.6.6.1.7.5.1.nrd.tnsi.com


Class: IN (0x0001)

Domain Name System (response)

Transaction ID: 0x65cf

Flags: 0x8403 (Standard query response, No such name)

1... .... .... .... = Response: Message is a response


.... .1.. .... .... = Authoritative: Server is an authority for

domain


.... ...0 .... .... = Recursion desired: Don't do query recursively

.... .... 0... .... = Recursion available: Server can't do recursive

queries

.... .... .0.. .... = Z: reserved (0)

.... .... ..0. .... = Answer authenticated: Answer/authority portion

was not authenticated by the server

.... .... .... 0011 = Reply code: No such name (3)

Questions: 1



Answer RRs: 0

Authority RRs: 0

Additional RRs: 0

Queries


Name: 1.2.3.4.7.6.6.1.7.5.1.nrd.tnsi.com


Class: IN (0x0001)



4. SIP Message Structure and Flows

TNS Carrier ENUM supports Session Initiation Protocol (SIP) to query ENUM. This section provides details of the messages formats and transaction flows when using SIP as the data access protocol. The SIP interface to ENUM is provided through a SIP-to-ENUM interworking function built into the TNS Carrier ENUM product. This allows SIP network devices to perform enhanced number portability lookups against ENUM.

Refer to the following references for details on query and response formats:

RFC 3261 “SIP: Session Initiation Protocol”, June 2002, http://www.ietf.org/rfc/rfc3261.txt

Refer to Appendix-A for any TNS Carrier ENUM Service version specific protocol interface changes.

SIP Message Flows This section describes the message flows when using SIP for ENUM lookups. To perform SIP-based ENUM lookup, a SIP INVITE message is sent to TNS ENUM resolution server, which responds back with a SIP Redirect response ( 302 “Temporarily moved”), with number portability information in the Contact header.

SIP UAC TNS Carrier ENUM SIP UAS INVITE

302 moved w/LNP

info

ACK

INVITE wLNP info

200 OK



SIP Message Formats SIP message formats used for querying ENUM are illustrated in this section. When a SIP network node receives a call setup request that requires a number lookup, the node will send a SIP INVITE to ENUM.

Format of a sample SIP invite message is shown below:

ENUM responds with a “302 Moved Temporarily” response with LNP information in the Contact header.

Number portability information is made available in the SIP Contact header to aide in identifying the carrier-of-record and routing a VoIP call successfully. Following additional parameters will be present in the SIP Contact header in the form “tag[=value]” data, separated by semi-colon (“;”).

o Location Routing Number(LRN): The address of the telephone switch that services a given telephone number. LRN is present only if the number is ported. LRN of a non-ported telephone number will be same as the telephone number itself. When a number gets ported, LRN will identify the switch that now servers the ported telephone number.

Example: “rn=+17036671111”

INVITE sip:[email protected];user=phone SIP/2.0 Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice <sip:[email protected];user=phone>;tag=9fxced76sl To: Bob <sip:[email protected];user=phone> Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:[email protected];transport=udp> Content-Type: application/sdp Content-Length: 154 v=0 o=alice 2890844526 2890844526 IN IP4 client.a.example.com s=- c=IN IP4 client.a.example.com t=0 0

SIP/2.0 302 Moved TemporarilyVia: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9;received=192.0.2.101 From: Alice <sip:[email protected];user=phone>;tag=9fxced76sl To: Bob <sip:[email protected];user=phone> Contact: <sip:+17036671111;rn=+19725559999;spid=999F;[email protected]> Call-ID: [email protected] CSeq: 1 INVITE Content-Length: 0



o Service Provider Identifier (SPID): Service provider that currently is the carrier-of-record for the requested telephone number. SPID is always retuned in the results when query results in a positive response.

Example: “spid=999F”

o Number Portability Dip Indicator (NPDI): Presence of the NPDI parameter in the URI indicates that number portability database lookup has been performed. This parameter indicates to subsequent network nodes that portability corrected information is available and no further portability database lookup is required to route call correctly. This parameter is always present in for queries that are returned with a positive response.

Example: “npdi” (Note: there is no value associated with this parameter)



A. Protocol Interface Changes

The following table describes the changes in the response sent by NRD 5.0 over the SIP and ENUM protocol interfaces.

Change Examples

Example-1: ENUM NAPTRs returned by NRD

Before: 1.1.1.1.7.6.6.3.0.7.1.nrd.tnsi.com. 3600 IN NAPTR 10 10 "u" "E2U+pstn:tel" "!^.*$!sip:17036671111;spid=999F;spname=Carriername;[email protected]!" . 1.1.1.1.7.6.6.3.0.7.1.nrd.tnsi.com. 3600 IN NAPTR 10 10 "u" "E2U+mms:mailto" "!^.*$!mailto:[email protected]!" . After: 1.1.1.1.7.6.6.3.0.7.1.nrd.tnsi.com. 3600 IN NAPTR 10 10 "u" "E2U+pstn:tel" "!^.*$!sip:+17036671111;spid=999F;[email protected]!" . 1.1.1.1.7.6.6.3.0.7.1.nrd.tnsi.com. 3600 IN NAPTR 10 10 "u" "E2U+mms:mailto" "!^.*$!mailto:[email protected]!" .

Changes for All Call Query (ACQ) account model

1) NRD will not return the Service Provider name as URI parameter “spname” in the NRD response

2) NRD will add leading ‘+’ in the user part of the URI if no dialplan is applied

Example-2: SIP Contacts returned by NRD

Before: Contact: <sip:17036671111;spid=999F;spname=Carriername;[email protected]> Contact: <mailto:[email protected]> After: Contact: <sip:+17036671111;spid=999F;[email protected]> Contact: <mailto:[email protected]>

Change for ENUM Data Service (EDS) account model

1) NRD will not return the Service Provider name as URI parameter “spname” in the NRD response

2) NRD will not return “/PLMN” in the mailto URI

Note: The EDS account model will be phased out after

Example-1: ENUM NAPTRs returned by NRD

Before: 1.1.1.1.7.6.6.3.0.7.1.nrd.tnsi.com. 3600 IN NAPTR 10 10 "u" "E2U+pstn:tel" "!^.*$!tel:+17036671111;spid=999F;spname=Carriername;npdi!" .

1.1.1.1.7.6.6.3.0.7.1.nrd.tnsi.com. 3600 IN NAPTR 10 10 "u" "E2U+mms:mailto" "!^.*$!mailto:+17036671111/[email protected]!" .

After: 1.1.1.1.7.6.6.3.0.7.1.nrd.tnsi.com. 3600 IN NAPTR 10 10 "u" "E2U+pstn:tel" "!^.*$!tel:+17036671111;spid=999F;npdi!" .

1.1.1.1.7.6.6.3.0.7.1.nrd.tnsi.com. 3600 IN NAPTR 10 10 "u" "E2U+mms:mailto" "!^.*$!mailto:[email protected]!" .



NRD5.0 deployment Example-2: SIP Contacts returned by NRD

Before: Contact: <tel:+17036671111;spid=999F;spname=Carriername;npdi>

Contact: <mailto:+17036671111/[email protected]>

After: Contact: <tel:+17036671111;spid=999F;npdi>

Contact: <mailto:[email protected]>

For more information about All Call Query or ENUM Data Service account models, refer to the Network Routing Directory Service Provider’s User Guide, available from your account manager or Customer Support.



B. Glossary

The following table describes terms and acronyms used throughout this guide.

Term Description

CLASS Two octets containing one the RR CLASS codes which appears in resource records. For example, 1 = INTERNET; 3 = CHAOS

DNS Domain Name System. A mechanism used in the Internet and on private intranets for translating names of host computers into IP addresses via a distributed database system.

E.164 The international public telecommunication numbering plan. An E.164 number uniquely identifies a public network termination point and typically consists of three fields, CC (country code), NDC (national destination code), and SN (subscriber number), up to 15 digits in total.

ENUM Electronic Numbering. A proposal to map all phone numbers to IP addresses. A proposed standard, from the Internet Engineering Task Force (IETF) for a DNS-based mechanism for translating a telephone number to a Universal Recourse Identifier (URI) and, ultimately to an IP address.

LRN Location Routing Number. A 10-digit number in which the first 6 digits are in the form of NPA-NXX. An LRN is used to uniquely identify a switch capable of portability and is used to route calls to ported numbers resident in that designated switch.

MMS Multi-Media Messaging Service. A service that allows mobile phone users to send pictures, news clips, and other graphic materials from one mobile phone to another. MMS messages can also be sent to email addresses.

NANP North American Numbering Plan. The numbering plan used in the United States, Canada, Bermuda, Puerto Rico, and certain Caribbean Islands. The NANP format is a 10-digit number that consists of a 3-digit NPA code (Area Code), 3-digit NXX code (Exchange), and 4-digit code (Line).

NPAC Number Portability Administration Center. Regional, third party, administrator of number portability information including LRN and GTT information for all ported numbers within a given region.

NAPTR RR Naming Authority Pointer Resource Record

NPA-NXX A code that represents the first 6-digits of a telephone number.

NPANXX-X A code that represents a pooled block of a thousand telephone numbers.

OCN Operating Company Number. A four-character code assigned by the National Exchange Carrier Association (NECA) to any telecommunications provider. Specifically used to identify CLEC and Reseller usage data. Also known as Company Code. Used in TNS Carrier ENUM to identify the owner of a non-ported number.

PUI Public User Identity. In TNS Carrier ENUM it is represented as (<telephone number>@<shortname>).



Query A customer inquiry for telephone number routing information formatted in accordance with the User Guide.

Service Provider An entity that provides telecommunications services.

SPID Service Provider Identifier. A 4-character string assigned by the NPAC to identify service providers. Used in TNS Carrier ENUM to identify the carrier-of-record.

URI Uniform Resource Identifier. A simply formatted string which identifies – via name, location or any other characteristic – a resource on the Internet.

Virtual SPID A Service Provider Identifier that is assigned by TNS for the purposes of interaction with the Carrier ENUM service. Used by customers who are not traditional owners of telephone numbers. It is not an industry -assigned SPID. Also called a “pseudo- SPID.”

VPN Virtual Private Network.

Carrier ENUM Resolution User Guide

Documents

transaction

uniform resource

session initiation

local replica

naming authority

uniform resource

central replica

telecom service