ENUM Failover and Query Distribution

ENUM Query Distribution

The Oracle® Enterprise Session Border Controller can intelligently distribute ENUM queries among all configured ENUM servers. By setting the enum config’s query method parameter to round robin, the Oracle® Enterprise Session Border Controller will cycle ENUM queries, sequentially, among all configured ENUM servers. For example, query 1 will be directed to server 1, query 2 will be directed to server 2, query 3 will be directed to server 3, and so on.

The default query method, hunt, directs all ENUM queries toward the first configured ENUM server. If the first server is unreachable, the Oracle® Enterprise Session Border Controller directs all ENUM queries toward the next configured ENUM server, and so on.

Failover to New enum-config

When an enum-config’s configured servers are unreachable via the network, i.e., no response is received on a query, the Oracle® Enterprise Session Border Controller can failover to a defined ENUM config that contains different enum servers to query. This failover behavior works when all servers in an enum config are unreachable, rather than when the Oracle® Enterprise Session Border Controller receives not-found type responses.

The Oracle® Enterprise Session Border Controller queries each ENUM server once before trying the next configured server, and then ultimately trying the servers listed in the failover-to enum config. If the failover-to servers also are unreachable, the Oracle® Enterprise Session Border Controller fails the call; the failover-to behavior does not recurse among enum-configs, it only checks the first, linked enum-config.

ENUM Server Operation States

After 5 consecutive failed attempts, an ENUM server is considered Out of Service (OOS). All subsequent queries which would be directed to the OOS servers are immediately directed to the first non-OOS server. ENUM servers return to in-service after 600 seconds. If all configured ENUM servers are OOS, the Oracle® Enterprise Session Border Controller fails the call.

After the first failed attempt to reach an ENUM server, it is placed in a Time Out state, which it stays in for 30 seconds. Within this 30 seconds it will not be contacted when an ENUM query is made. After the 30 seconds pass, the ENUM server goes back to an in-service state.

Server Availability Monitoring

The Oracle® Enterprise Session Border Controller can probe an ENUM server’s health by sending it a standard ENUM NAPTR query and receiving a valid answer. The query is for the phone number defined in the health query number parameter, which should be one that the ENUM servers can positively resolve. As long as the query succeeds, that ENUM server maintains its in-service state and is available for ENUM queries. Any lack of response, whether network based (time-outs), or application based (DNS error or not found response) is considered a query failure and the server is set to OOS and unavailable for ENUM queries.

The Oracle® Enterprise Session Border Controller continuously checks the health of all configured ENUM servers to determine their current state and monitor for failed servers’ return to service. All servers are checked for availability at the health query interval parameter, as defined in seconds.

Note:

When ENUM server availability monitoring is enabled, ENUM servers can only exist in an in-service or out-of-service states; Without the health query interval defined, server availability monitoring is disabled, and ENUM servers exist in three service states.

ENUM Server IP Address and Port

You can configure an IP address and port for each enum server listed in the enum-servers parameter. IP address and port are specified in XXX.XXX.XXX.XXX:YYYY format with a port value range of 1024-65535. If the port number is not specified, 53 is assumed.

The Oracle® Enterprise Session Border Controller supports IPv6 ENUM configurations in IPv6 realms. The enumservers parameter in the enum-config configuration parameter can be configured IPv6 addresses in addition to IPv4 addresses. When IPv6 Addresses are used, the realm configured in the realm-id parameter must be an IPv6 realm.

Caching ENUM Responses

As DNS responses often lead to further DNS queries, a DNS server can send additional multiple records in a response to attempt to anticipate the need for additional queries. The Oracle® Enterprise Session Border Controller can locally cache additional NAPRT, SRV, and A records returned from an ENUM query to eliminate the need for unnecessary external DNS requests by enabling the cache addl records parameter. These cached records can then be accessed by internal ENUM and DNS agents.

The unprompted NAPTR, SRV, or A record returned to the Oracle® Enterprise Session Border Controller must include complete information to resolve a call to be added to the local DNS/ENUM cache, otherwise the Oracle® Enterprise Session Border Controller will preform an external query to fine the address it is looking to resolve.

Cached entries are per ENUM config. That means if one ENUM config has a number of cached entries, and an ENUM request is directed through a different ENUM config, the second configuration is not privy to what the first configuration has cached.

The Oracle® Enterprise Session Border Controller uses the shorter lifetime of the DNS response’s TTL or the server dns attribute’s transaction-timeout to determine when to purge a DNS record from the local cache.

Source URI Information in ENUM Requests

ENUM queries can be configured to include the source URI which caused the ENUM request by enabling the include source info parameter. The Oracle® Enterprise Session Border Controller can add the P-Asserted-ID URI (only if not in an INVITE) or the From URI into an OPT-RR Additional Record to be sent to the ENUM server. It can be useful to specify the originating SIP or TEL URI from a SIP request which triggered the ENUM query, so the ENUM server can provide a customized response based on the caller.

This feature implements the functionality described in the Internet Draft, DNS Extension for ENUM Source-URI, draft-kaplan-enum-source-uri-00.

When a P-Asserted-ID is blocked or removed before the ENUM query is made, the Oracle® Enterprise Session Border Controller only sends the URI in the From header.

Note that to support this feature, according to the Internet draft, ENUM clients must support 1220 bytes in UDP responses. Therefore, if this feature is enabled, and the max response size parameter is not set i.e., with a 512 byte default, the Oracle® Enterprise Session Border Controller will set the size to 1200 on the OPT-RR records sent.

Operation Modes

There are four modes of ENUM operation that are selected on a global basis:

stateless proxy
transaction stateful proxy
session stateful proxy
B2BUA with or without media

Stateless Proxy Mode

The stateless proxy mode is the most basic form of SIP operation. The stateless proxy mode:

Has the least number of messages per call. No record route header is added and there are no 100 Trying or BYEs.
Does not keep transaction state (timers and retransmission). There are no session counters and no session stop time. No session stop time means no RADIUS STOP records.
Has no limits on session state.
Can restrict functionality by specification. This can mean no media management, limited potential for RADIUS accounting, and no CALEA (no Release/BYE messages for CDC).
Acts primarily as a routing device, with local policy routing and ENUM routing.

Transaction Stateful Proxy

In the transaction stateful proxy mode:

Adds state to the proxy (not dialogs).
Has lower number of messages per call. No Record Route header added and no BYES.
Keeps transaction state (timers and retransmissions.
Enforces session restrictions (32k) because of state management. These restrictions can be increased.
Can restrict functionality by specification. This can mean no media management, limited potential for RADIUS accounting, and no CALEA (no Release/BYE message for CDC).
Acts as routing device with transaction timers, with local policy routing and ENUM routing.
Can off-load some transactions across unreliable links.

Session Stateful Proxy

The session stateful proxy mode:

Maintains dialog state as a proxy.
Includes BYES (though cannot be inserted)
Keeps transaction state (timers and retransmission)
Provides per-session information such as session counters per session agent, RADIUS STOP accounting record generation, CALEA CDC generation.
Enforces session restrictions (32k) because of state management.
Does not provide media management. There is no CALEA CCC.
Routes full sessions with transaction timers with local policy routing and ENUM routing.

B2BUA

The B2BUA mode:

Acts as UAS and UAC within call flow.
Includes BYES (can be inserted).
Keeps transaction state (timers and retransmissions)
Provides per-session information such as session counters per session agent, RADIUS STOP accounting record generation, CALEA CDC generation.
Enforces session restrictions (32k) because of state management.
Can provide media management, including media routing through a single IP address with topology masking, CALEA CCC, media watchdogs for state management.
Routes full sessions with topology masking. Includes rewriting Via, Route, Contact headers, full NATing with SIP NAT or header manipulation, direct bridging, local policy routing, and ENUM routing.

Example ENUM Stateless Proxy

The following diagram shows the Oracle® Enterprise Session Border Controller using ENUM to query a local subscriber database. The Oracle® Enterprise Session Border Controller serves as the inbound and outbound routing hub and performs media management. Calls are routed throughout the MSO network using ENUM lookup results.

The ENUM Stateless Proxy diagram is described below.

ENUM Configuration

This section shows you how to configure ENUM on your Oracle® Enterprise Session Border Controller.

To configure ENUM:

In Superuser mode, type configure terminal and press Enter.
```
ORACLE# configure terminal
```
Type session-router and press Enter to access the signaling-level configuration elements.
```
ORACLE(configure)# session-router
ORACLE(session-router)#
```
Type enum-config and press Enter. The system prompt changes to let you know that you can begin configuring individual parameters.
```
ORACLE(session-router)# enum-config
ORACLE(enum-config)#
```
name—Enter a string that uniquely identifies this ENUM configuration. You use this name in other areas of the Oracle® Enterprise Session Border Controller configuration to refer to this ENUM configuration. For example, in the local policy attributes.
top-level-domain—Enter the domain extension to be used when querying the ENUM servers for this configuration. For example, e164.arpa. The query name is a concatenation of the number and the domain.

For example the number is +17813334444 and the domain is e164.arpa, the query name would be 4.4.4.4.3.3.3.1.8.7.1.e164.arpa.com.
realm-id—Enter the realm where the ENUM servers can be reached. The realm ID is used to determine on which network interface to issue the ENUM query.
enum-servers—Enter the list of ENUM servers (an ENUM server and corresponding redundant servers) to be queried. Separate each server address with a space and enclose list within parentheses.

The first server on this list is the first one to be queried. If the query times out (including retransmissions) without getting a response, the next server on the list is queried and so on.
service-type—Enter the ENUM service types you want supported in this ENUM configuration. Possible entries are E2U+sip and sip+E2U (the default), and the types outlines in RFCs 2916 and 3721.
This parameter defaults to the following service types: E2U+sip and sip+E2U.

You can enter multiple services types in the same entry, as in this example:
```
ORACLE(enum-config)# service-type E2U+sip,sip+E2U,E2U+voicemsg
```
query-method—Set the strategy the Oracle® Enterprise Session Border Controller uses to contact ENUM servers. Valid values are:
- hunt—Directs all ENUM queries toward the first configured ENUM server. If the first server is unreachable, the Oracle® Enterprise Session Border Controller directs all ENUM queries toward the next configured ENUM server, and so on.
- round-robin—Cycles all ENUM queries, sequentially, among all configured in-service ENUM servers. Query 1 will be directed to server 1, query 2 will be directed to server 2, query 3 will be directed to server 3.
timeout—Enter the total time in seconds that should elapse before a query sent to a server (and its retransmissions) will timeout. If the first query times out, the next server is queried and the same timeout is applied. This process continues until all the servers in the list have timed out or until one of the servers responds.

The retransmission of ENUM queries is controlled by three timers. These timers are derived from this timeout value and from underlying logic that the minimum allowed retransmission interval should be 250 milliseconds; and that the Oracle® Enterprise Session Border Controller should retransmit 3 times before timing out to give the server a chance to respond. The valid values are:
- Init-timer—Is the initial retransmission interval. If a response to a query is not received within this interval, the query is retransmitted. To safeguard from performance degradation, the minimum value allowed for this timer is 250 milliseconds.
- Max-timer—Is the maximum retransmission interval. The interval is doubled after every retransmission. If the resulting retransmission interval is greater than the value of max-timer, it is set to the max-timer value.
- Expire-timer—Is the query expiration timer. If a response is not received for a query and its retransmissions within this interval, the server will be considered non-responsive and the next server in the list will be tried.
  
  The following examples show different timeout values and the corresponding timers derived from them.
  
  timeout >= 3 seconds
```
Init-timer = Timeout/11
Max-Timer = 4 * Init-timer
Expire-Timer = Timeout
```
  timeout = 1 second
```
Init-Timer = 250 ms
Max-Timer = 250 ms
Expire-Timer = 1 sec
```
  timeout = 2 seconds
```
Init-Timer = 250 ms
Max-Timer = 650 ms
Expire-Timer = 2sec
```
cache-inactivity-timer—Enter the time interval in seconds after which you want cache entries created by ENUM requests deleted, if inactive for this interval. If the cache entry gets a hit, the timer restarts and the algorithm is continued until the cache entry reaches its actual time to live.

Setting this value to zero disables caching. For optimal performance, set this to one hour. Rarely used cache entries are purged and frequently used entries are retained. The default value is 3600. The valid range is:
- Minimum—0
- Maximum—999999999
lookup-length—Specify the length of the ENUM query, starting from the most significant digit. The default is 0. The valid range is:
- Minimum—1
- Maximum—255
max-response-size—Enter the maximum size in bytes for UDP datagrams in DNS NAPTR responses. This parameter takes values from 512 (default) to 65535. Although the maximum value you can set is 65535, Oracle recommends configuring values that do not exceed 4096 bytes.
health-query-number—Set this parameter to a standard ENUM NAPTR query that will consistently return a positive response from the ENUM server.
health-query-interval—Set this parameter to the number of seconds to perpetually probe ENUM servers for health.
failover-to—Set this parameter to the name of another ENUM-config which to failover to under appropriate conditions.
cache-addl-records—Set this parameter to enabled for the Oracle® Enterprise Session Border Controller to add additional records received in an ENUM query to the local DNS cache.
include-source-info—Set this parameter to enabled for the Oracle® Enterprise Session Border Controller to send source URI information to the ENUM server with any ENUM queries.
Save your work.

Example

The following example shows an ENUM configuration called enumconfig.

enum-config
        name                           enumconfig
        top-level-domain
        realm-id                       public
        enum-servers                   10.10.10.10:3456
                                       10.10.10.11
        service-type                   E2U+sip,sip+E2U
        query-method                   hunt
        timeout                        11
        cacheInactivityTimer           3600
        max-response-size              512
        health-query-number            +17813245678
        health-query-interval          0
        failover-to                    enumconfig2
        cache-addl-records             enabled
        include-source-info            disabled

Configuring the Local Policy Attribute

You can specify that an ENUM query needs to be done for the routing of SIP calls. You do so by configuring the local policy’s next-hop attribute with the name of a specific ENUM configuration, prefixed with the enum: tag. For example: enum:test

You can configure multiple next-hops with different ENUM servers or server groups (possibly with different top-level-domains). If the first ENUM server group you enter as the next hop is not available, one of the others can be used.

Note:

A new parameter called action has replaced the policy attribute’s replace-uri parameter available prior to build 211p19.

To configure local policy:

In Superuser mode, type configure terminal and press Enter.
```
ORACLE# configure terminal
```
Type session-router and press Enter.
```
ORACLE(configure)# session-router
```
Type local-policy and press Enter. The system prompt changes to let you know that you can begin configuring individual parameters.
```
ORACLE(session-router)# local-policy
ORACLE(local-policy)#
```
next-hop—Enter the name of the ENUM configuration with the prefix enum:. For example, enum:test.
action—Set to redirect if you want to send a REDIRECT message back to the calling party with the information returned by ENUM in the Contact. The calling party then needs to send a REDIRECT using that information. The default value is none. Valid values are:
- none—No specific actions requested.
- replace-uri—To replace the next Request-URI with the next hop.
- redirect—To send a redirect response with this next hop as contact.
Save and activate your configuration.

Local Policy Example

The following example shows one local policy with the next-hop configured to use enum:test and a second with the next-hope configured to use enum:test_alternate.

local-policy
     from-address           *
     to-address             *
     source-realm           public
     activate-time          N/A
     deactivate-time        N/A
     state                  enabled
     last-modified-date     2006-03-09 09:18:43
     policy-attribute
       next-hop               enum:test
       realm                  public
       action                 none
       terminate-recursion    disabled
       carrier
       start-time             0000
       end-time               2400
       days-of-week           U-S
       cost                   1
       app-protocol           SIP
       state                  enabled
       media-profiles
     policy-attribute
       next-hop               enum:test_alternate
       realm                  public
       action                 none
       terminate-recursion    disabled
       carrier
       start-time             0000
       end-time               2400
       days-of-week           U-S
       cost                   2
       app-protocol           SIP
       state                  enabled