ENUM Support

ENUM Dip Indicator

Telephone Number Mapping (ENUM) transforms the telephone number into a universal identifier recognized across different devices and applications (voice, fax, mobile, e-mail, text messaging, location-based services and the Internet). ENUM can also be used to implement a variety of services like number portability, call forwarding etc. It uses a DNS NAPTR record to translate a telephone number into a Uniform Resource Identifier or IP address that can be used in Internet communications.

Since a call may span multiple network elements, to avoid redundant ENUM queries, the SBC Core supports (when configured) processing the enumdi parameter received on ingress INVITE. Similarly, if ERE/PSX performs an ENUM dip, the SBC sends this parameter in egress INVITE to the next network element identifying that an ENUM query has already been made for the TEL URI, thus preventing redundant queries further down the network.

The SBC also supports sending ENUM queries and receive responses, using the Signaling Interface. The user can configure the Signaling Interface for sending ENUM queries and receive responses, using the packet interface port 988. The packets from the Signaling Interface are prioritized over the packets from the Management Interface.

The Feature Control Profile flag to enable processing of the enumdi parameter is processEnumdi. For example,

% set profiles featureControlProfile <profile name> processEnumdi enable

ENUM NAPTR Queries

The SBC performs ENUM queries to an external DNS to map E.164 telephone numbers to SIP trunk URIs, and then performs SIP routing based on the service URIs. ENUM translation requires an ENUM NAPTR (Naming Authority Pointer) query to resolve a telephone number to an FQDN, and then requires DNS queries to resolve the FQDN to an IP address and port number.

The result of a successful ENUM NAPTR query is a SIP URI telephone number received in the Request-URI resolved to a SIP URI. To perform an ENUM NAPTR query, the SBC reverses the order of the SIP URI telephone number digits, adds a dot in between each digit, adds the domain name, and finally performs the DNS NAPTR query.

By default, the SBC sends ENUM NAPTR queries to the default public domain (.e164.arpa). If the ENUM database resides in a private domain, specify the private domain on the DNS-ENUM Service Definition screen.

For example, an ENUM query to an external DNS for the ENUM NAPTR record for the SIP URI sip:+1-212-555-5678@1.2.3.4 is sent using the format 8.7.6.5.5.5.5.2.1.2.1.e164.arpa. The SBC then uses the FQDN from the returned record to perform DNS queries which attempt to map the FQDN to an IP address and port number. The SBC returns the IP address and port number in a Request-URI in the policy response.

• If the DNS cannot match a SIP URI telephone number with a SIP URI in the database, the DNS returns no record for that telephone number. The SBC then attempts to route the call through standard routing.
• If the ENUM NAPTR query succeeds, but a trigger for performing a DNS query has not been provisioned on the SBC, the SBC uses the FQDN from the returned ENUM NAPTR record to attempt to perform Username routing.

When the SBC queries an ENUM server and the NAPTR response contains two or more matches, the SBC orders the records in the response according to the “order” and “preference” fields. The SBC uses the first valid record which has the highest (numerically lowest) order and highest (numerically lowest) preference. The rest of the records are not used.

In a NAPTR response to ENUM query, any one of the following strings are recognized as indicating that a SIP address-of-record appears in the URI field:

• E2U+sip
• sip+E2U
• E2U+SIP
• SIP+E2U

In the following example, five records were received; the record with the rrk2 address is used because it has the highest order (100) and highest preference (10).

Provisioned records for (44) 1793601415:

5.1.4.1.0.6.3.9.7.1.4.4.e164.arpa. IN NAPTR 300 10 "u" "E2U+sip" "!^.*$!sip:rrk1@sonusnet.com!"

5.1.4.1.0.6.3.9.7.1.4.4.e164.arpa. IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:rrk2@sonusnet.com!"

5.1.4.1.0.6.3.9.7.1.4.4.e164.arpa. IN NAPTR 200 10 "u" "E2U+sip" "!^.*$!sip:rrk3@sonusnet.com!"

5.1.4.1.0.6.3.9.7.1.4.4.e164.arpa. IN NAPTR 100 20 "u" "E2U+sip" "!^.*$!sip:rrk4@sonusnet.com!"

5.1.4.1.0.6.3.9.7.1.4.4.e164.arpa. IN NAPTR 400 10 "u" "E2U+sip" "!^.*$!sip:rrk5@sonusnet.com!"

ENUM NAPTR Flags

The NAPTR Resource Record (RR) uses the following format:

Domain TTL Class Type Order Preference Flags Service Regexp Replacement

"Flags" is a <character-string> containing flags to control aspects of the rewriting and interpretation of the fields in the record. Flags are single characters from the set [A-Z0-9]. The case of the alphabetic characters is not significant.

At this time only four flags, "S", "A", "U", and "P", are defined.

The "S", "A" and "U" flags denote a terminal lookup. This means that this NAPTR record is the last one and that the flag determines what the next stage should be.

For details refer to the IETF RFC at https://tools.ietf.org/html/rfc2915.

ENUM LNP

ENUM LNP enables number portability lookups in the IP network without the need to consult an external element in the SS7 network, thus simplifying call routing and networking operations.

The Routing Number must use one of the following formats:

• Globalized number:  +1-555-614-8166 (specified in RFC4769)
• National Number: 555-614-8166

To provision ENUM LNP, enter ported numbers into the SBC database via the NPA-NXX entity (or optionally Number Translation Criteria), and then provision the Enum Domain and Enum Service.

When a Routing Request triggers an ENUM LNP lookup, the SBC uses the dialed number to form a domain name and puts it in an ENUM LNP query to the ENUM database. When the ENUM returns NAPTR resource records, the SBC selects the record with a particular service type, extracts the translated number and domain name from the NAPTR record, and uses them to perform routing. If the query returns no NAPTR record with a translated number, the SBC routes the call using the original dialed number.

ENUM CNAM

ENUM CNAM enables calling name lookups on the IP network without having to consult an external element in the SS7 network, thus simplifying call routing and network operations.

To provision ENUM CNAM, specify the trigger criteria in the Number Translation Criteria entity and specify the ENUM CNAM as the lookup type. ENUM CNAM, provisioned through the DNS-ENUM Service Definition screen, uses the same triggering and escape criteria as SCP-based CNAM. When a Routing Request triggers an ENUM CNAM lookup, the SBC uses the calling number to form a domain name and puts it in an ENUM CNAM query to the ENUM database. When the ENUM returns NAPTR resource records, the SBC adds the caller name.

The ERE platform supports number translations based on the host part (contains a fully-qualified domain name) of the SIP headers. As the IP address format is not supported for host part lookup, it is recommended to use the fully-qualified domain name. The SBC retrieves the destination domain from the various SIP headers and sends it to the ERE as part of the policy request. The domain name lookup is case insensitive and partial matches are supported, while first priority is always for the full match.

The supported destination domain SIP headers are:

• INVITE Message, R-URI Header
• INVITE Message, TO Header
• 3XX Message, Contact Header

CalledUri and toHeader element types are used to support call processing. Configure any of these element types to trigger number translations. The domain names configured in number translations are converted to upper case and stored in ERE as uppercase.

Service Interaction

The following are configured based on service priority:

1. ENUM SIP AoR
2. ENUM CNAM

The ERE after executing the SIP AoR service, receives the domain name from the NAPTR RR SIP-URI and the system continues to trigger the next service ENUM CNAM in the priority list. In general, ERE uses the domain name received from SIP AoR service for routing. The ERE updates the CalledUri with the information received from SIP AoR and then performs any other number translations as required.

To facilitate this service interaction ENUM SIP AoR service must be provisioned with a higher priority than ENUM CNAM service. ENUM CNAM service must be provisioned with element type as calledUri.

ENUM Services

The mandatory parameter priority is used to set the priority of this ENUM service. The ENUM service cannot be created if priority  is not set. This parameter is used to prioritize the order of the ENUM service execution. Priority of the  ENUM server hold the values in range (0..255). Multiple ENUM services can be created with the same service type, such as sipAor, lnp, and cnam.

The ENUM service is triggered based on the trigger criteria created. The flag skipFurtherNumberTranslations skips further ENUM service execution and goes directly to routing. The default value is disable.

Userinfo Parameters in ENUM Response

SBC Core supports transparently passing userinfo parameters received in the ENUM Naming Authority Pointer Response (NAPTR) response in the outgoing INVITE Request Uniform Resource Identifier (R-URI). The SBC transparently sends custom and standard userinfo parameters such as tgrp, trunk-context, cic and rn received in ENUM response. The SBC sends these parameters in the R-URI of the egress INVITE.

This behavior is controlled by enabling the IP Signaling Profile flag “includeEnumParameters”. The default value is "disable". When enabled, the SBCeither adds ENUM response parameters to the R-URI or overwrites egress INVITE R-URI parameter value with the ENUM response parameter value (egress INVITE parameters are determined based on the existing SBC process logic and transparency mechanism).

% set profiles signaling ipSignalingProfile <profile name> egressIpAttributes flags includeEnumParameters < enable | disable > 

Load Balancing Support Across ENUM Servers

The SBC supports load balancing across ENUM servers for individual ENUM zones. ENUM client routes the query to ENUM servers based on the load balancing scheme configured for that zone. ENUM client uses the following load balancing scheme to route the requests to ENUM servers:

• Sequential—This is an existing load balancing type supported by the SBC. Whenever a new INVITE comes to the SBC and if it matches with the ENUM trigger criteria, then the SBC selects an ENUM server with highest priority (lowest forwardersData priority value) over other configured servers in the particular domain/zone and then triggers an ENUM query towards that server. In case, if the selected ENUM server does not respond to the ENUM query sent, then the SBC selects the alternate ENUM server, which has second highest priority configured in the particular domain and triggers an ENUM query towards that server.
  
  
• Round Robin—Whenever a new INVITE comes to the SBC and if it matches with the ENUM trigger criteria, then the SBCselects the ENUM server based on the configured round robin type. For example, when three Server IPs are configured in a particular order, the client uses the first IP address in the list for the first call, and second IP address in the list for the second call and so on. In case of failure, the client fall back to the next IP address in the list.
  
  
• Proportional—The ENUM client routes the requests to the ENUM servers based on the proportion (percentage of distribution) configured against each server (IP) for a zone.