Using the Local Route Table (LRT) for Routing

The LRT allows the Oracle® Enterprise Session Border Controller to determine next hops and map E.164 to SIP URIs locally for routing flexibility.

The LRT uses a local route cache that is populated by a local XML file on the Oracle® Enterprise Session Border Controller. Each local cache is populated from one defined XML file. For routing, the local route cache operates in a way similar to the ENUM model where a local policy next hop specifies the local route table that the Oracle® Enterprise Session Border Controller references. For example, you can configure one next hop to use one table, and another next hop to use a different table.

Similar to the ENUM model, the Oracle® Enterprise Session Border Controller typically performs a local route table lookup using the telephone number (TN) of the SIP Request-URI. This is the user portion of the URI, and the Oracle® Enterprise Session Border Controller ignores user parameters or non-digit characters. The local route table XML file defines the matching number and the resulting regular expression replacement value such as ENUM NAPTR entries do. The Oracle® Enterprise Session Border Controller uses the resulting regular expression to replace the Request-URI, and it uses the hostname or IP address portion to determine the next hop. If the hostname or IP address matches a configured session agent, the request is sent to that session agent. If the Oracle® Enterprise Session Border Controller does not find a matching session agent for the hostname/IP address, the Oracle® Enterprise Session Border Controller either performs a DNS query on the hostname to determine its IP address or sends the request directly to the IP address.

Note:

RFC3261 explicitly excludes the use of the _ [underscore] character in a URI. Do not configure LRT entries with a URI that includes an underscore character.

When the next hop is defined as a user-parameter lookup key, such as a routing number (RN) or carrier identification code (CIC), the defined key is used for the local route table lookup.

The Oracle® Enterprise Session Border Controller can attempt up to 10 next hops per LRT entry in the order in which they appear in the XML file. If the next hop is unsuccessful, the Oracle® Enterprise Session Border Controller tires the next hop on list. An unsuccessful hop may occur when an out-of-service session agent or the next hop responds with a failure response.

Note:

Entering XML comments on the same line as LRT XML data is not supported.

The Oracle® Enterprise Session Border Controller can perform local route table lookups for SIP requests and communicate the results to the SIP task. The new task processes the new local routing configuration objects.

When a SIP call is routed, the Oracle® Enterprise Session Border Controller uses local policy attributes to determine if a local route table lookup is required. If a lookup is needed, the Oracle® Enterprise Session Border Controller selects the local routing configuration to use. Successful local route table lookups result in URIs that can be used to continue routing and redirecting calls.

Multi-Tiered LRT Route Selection

When routing though an LRT, the ESBC normally attempts to reach next-hops using LRT entries in the order that they appear in the XML file. If a next-hop is unsuccessful, the ESBC tries the next-hop on the list. You can, however, configure entries in LRTs that cause the ESBC to gradually increase traffic for specific routes and control the distribution, while also monitoring usage. You can specify priorities and weights to favor route entries and use a preferred route instead of following the list order.

To establish the use of priority and weight, use the route tag syntax <route format="weighted"> for a route entry in the LRT. Each next-hop entry can then include the following fields:

prio—Specifies the relative preference in which the ESBC uses this next-hop entry. You configure priority with zero as the highest priority, using the range from 0 to 65535.
weight—Specifies the frequency of use for a given next-hop entry in a set of next-hop entries with the same priority; an entry with a higher weight is returned more frequently. You configure weight in multiples of 10 using the range of 0 to 65535.

A route set in an LRT file, without a specified priority or weight, uses the route tag syntax <route>. The ESBC selects next-hop entries for these routes using the list order only. Using the <route format="weighted"> tag syntax allows you to have active routes with specified priority and weight in the same table as routes that do not.

When the route tag contains the format="weighted" attribute, the maximum number of next-hops allowed per route with the same priority value is 10. There is no next-hop limit when there is no format attribute specified.

The ESBC treats any next-hop entry with weight=”0” as disabled. The ESBC does not use these entries for routing and does not display them in show lrt commands. The ESBC also treats invalid route-sets, which do not have any valid next-hop entries under a particular route-entry, as if they are disabled.

Operational Examples

The following table displays one route set using format, priority, and weight, and in contrast, one route set that uses none.

<?xml  version="1.0" encoding="UTF-8"?>
<localRoutes>
<route format=”weighted”>
      <user type="E164">370</user>
      <next prio="0" weight="40" type="regex">!^.*$!sip:\0@SAG-CarrierA!</next>
      <next prio="0" weight="30" type="regex">!^.*$!sip:\0@SAG-CarrierB!</next>
      <next prio="0" weight="20" type="regex">!^.*$!sip:\0@SAG-CarrierC!</next>
      <next prio="1" weight="10" type="regex">!^.*$!sip:\0@SAG-CarrierD!</next>
      <next prio="2" weight="10" type="regex">!^.*$!sip:\0@SAG-CarrierE!</next>
</route>
<route>        
      <user type="E164">371</user>        
      <next type="regex">!^.*$!sip:\0@SAG-NoPrio1</next>
      <next type="regex">!^.*$!sip:\0@SAG-NoPrio2</next>
</route>
</localRoutes>

Consider the next hops with priority 0 and weights of 40, 30 and 20. In this case, the ESBC distributes calls between these 3 entries using a ratio of 4:3:2. This means that, for 10 calls to example user “370”, the ESBC distributes the first 9 calls using a 4:3:2 ratio:

4 calls will be routed to SAG-CarrierA
3 calls to SAG-CarrierB
2 calls to SAG-CarrierC

The ESBC attempts to reach next-hops with higher prio values (lower priority, such as prio=1) in this example only if the next-hop with lower prio values (higher priority), such as prio=0, is in Out of service. Note that the weighted algorithm distributes calls randomly in the given ratios.

Consider the above example ,whenever a call attempts to route to SAG-CarrierA of prio=0, and if it is Out of Service,the call routes to SAG-CarrierD, which is from next priority prio=1.The same is the case for SAG-CarrierB, SAG-CarrierC from prio=0, if they are in Out of service, it routes the next priority prio=1.

The ESBC ignores the weight value if a given next-hop is the only entry with that priority in a route set. In the example , the ESBC ignores the weight values for the prio="1" and prio="2" entries as they are the only entries with those priority values. Furthermore:

If we need 4 next-hops in ratio of 2:3:5:7, then we can configure the weight values as either:
- 20,30,50,70
- 200,300,500,700, or
- 2000,3000,5000,7000
If we configure weights as 10, 100, 1000, 10000, the ESBC routes calls using the ratio 1:10:100:1000.

Configuration Dependencies

Recursion allows the call to break out of a SAG route and continue to the next route in the LRT. Continuing with the example above, assume the following:

SAG-CarrierA contains 2 SAs, SA_M1 and SA_M2 and has sag-recursion=disabled
SAG-CarrierB contains 2 SAs, SA_B1 and SA_B2 and has sag-recursion=enabled
SAG-CarrierC contains 2 SAs, SA_T1 and SA_T2 and has sag-recursion=enabled

The route proceeds as SA_M1 overflows to SA_B1 on to SA_B2, and then on to SA_T1 and SA_T2. Notice SA_M2 was not attempted because sag recursion was disabled within that route.

If you have enabled sag-recursion for SAGs configured under a single route-entry, and each SAG has multiple SAs, the ESBC tries to reach every SA in every SAG until it gets a response for its request. However, you can skip recursion between multiple SAs under one SAG by either configuring stop-sag-recurse with valid response values or by configuring a sip-recursion-policy on the SAG.

If you configure stop-sag-recurse with valid response codes and the condition gets a hit, then the ESBC terminates the call by sending the response code to UAC. In this case, the ESBC does not try the next SAGs in the list.
If you want the ESBC to recurse through multiple SAG’s in the list, even after receiving error response codes from one of the SA in SAG, you can configure a sip-recursion-policy at two levels; one at the SAG level and other at the sip-interface level.

Note:

SIP recursion between different route entries in LRT file works in same way with SAGs and SAs. This feature does not affect any SIP recursion behavior.

Creating XML Files

Refer to the following guidelines as you set up your multi-tiered LRT deployment:

Format Attribute (XML file):
- Specifying the wrong value to format attribute, format=”weids” for example , causes the ESBC to treat the entire route as invalid, not load any of the route entries under this route, and not display them in the show lrt stats output. However, by specifying the format attribute name incorrectly, form=”weighted” for example, you can ensure the ESBC treats routes as “route without format attribute”, expecting next-hop entries to be present without any prio and weight attributes. If any <next> entries under this route have prio, weight or both, then the ESBC treats the <next> entry as invalid. If all of the <next> entries under the <route> are invalid, then the <route> is invalid.
- The format attribute in the xml file under route entry specifies that all the next-hop entries under this route entry should have both priority and weight fields defined. Any next-hop entry without both is considered invalid.
- The ESBC allows configuration of partial values for the format attribute. All partial strings matching the original string (“weighted” ) are treated as valid. Valid examples include “w”, “we”, “wei”… “weighted”.
- The ESBC default behavior supports XML files without the format=”weighted” attribute in the route tag. The ESBC considers any route entry without format attribute and with next-hop entry contains either prio, weight, as invalid entries.
Prio and Weight Attributes:
- The ESBC requires the Prio and weight attributes to contain numerical values, treating entries with alphanumeric, empty values or any other values are treated as invalid. The ESBC refers to the "format" attribute, using the value "weighted” to differentiate between weighted entries and normal entries.
- You can specify the prio, weight and type attributes in any order in a next-hop.
- The maximum number of next-hop entries used under one route set with same priority value is 10, when the attribute format=”weighted” is in the route tag. The ESBC considers only the first 10 <next> entries as valid. In addition, routes with more than 10 <next> entries are valid, with entries after the tenth being ignored.

Monitoring Multi-Tiered LRT Operation

You can monitor LRT activity using the show lrt command to display priority and weight fields if they are part of the route entry output. The ESBC always displays weight values in the output of show lrt commands. Applicable syntax includes:

show lrt route-table <lrt-config-name>
show lrt route-entry <lrt-config-name> <user>

The examples below assume an LRT table named LRT1 that contains one route and one user named 370.


<?xml version="1.0" encoding="UTF-8"?>
<localRoutes>
<route format="weighted">
      <user type="E164">370</user>
      <next prio="0" weight="40" type="regex">!^.*$!sip:\0@SA1!</next>
      <next prio="1" weight="10" type="regex">!^.*$!sip:\0@SA2!</next>
</route>
</localRoutes>

Example output when using the route-table argument is shown below.

ORACLESBC# show lrt route-table LRT1
UserName <370>
    Entry Type = E164
      Priority = 0
        Weight = 40
       NextHop = !^.*$!sip:\0@SA1!
  NextHop Type = regexp
      Priority = 1
        Weight = 10
       NextHop = !^.*$!sip:\0@SA2!
  NextHop Type = regexp

----------------------------------
Total: 1 routes
----------------------------------

When you add the user argument, the ESBC changes the output as shown below.

ORACLESBC# show lrt route-entry LRT1 370
UserName <370>
    Entry Type = E164
      Priority = 0
        Weight = 40
       NextHop = !^.*$!sip:\0@SA1!
  NextHop Type = regexp
      Priority = 1
        Weight = 10
       NextHop = !^.*$!sip:\0@SA2!
  NextHop Type = regexp

Local Route Table (LRT) Performance

Capabilities

Loads approximately 500 LRT tables during boot time
Loads 100,000 entries per LRT file
Loads 2,000,000 LRT entries total per system

Constraints

You cannot configure the Oracle® Enterprise Session Border Controller with 500 LRT files each with 100,000 entries.
Actual performance that affects the interaction among the three performance attributes varies with system memory and configuration.

Local Routing Configuration

This section shows you how to:

Set up local route configuration
Specify that a set of local policy attributes needs to use local routing

Configure Local Routing

The local routing configuration is an element in the ACLI session-router path, where you configure a name for the local route table, the filename of the database corresponding to this table, and the prefix length (significant digits/bits) to be used for lookup.

To configure local routing:

In Superuser mode, type configure terminal, and press Enter.
```
ORACLE# configure terminal
```
Type session-router, and press Enter.
```
ORACLE(configure)# session-router
```

Type local-routing-config,and press Enter.

ORACLE(session-router)# local-routing-config
ORACLE(local-routing-config)#

name—Enter the name (a unique identifier) for the local route table; this name is used for reference in the local policy attributes when to specify that local routing should be used. There is no default for this parameter, and it is required.
file-name—Enter the name for the file from which the database corresponding to this local route table will be created. You should use the .gz format, and the file should be placed in the /code/lrt/ directory. There is no default for this parameter and it is required.
prefix-length—Enter the number of significant digits/bits to used for lookup and cache storage. The default value is 0. The valid range is:
- Minimum—0
- Maximum—999999999

Save and activate your configuration.

The following example displays a typical local routing configuration.

local-routing-config
        name                           lookup
        file-name                      abc.xml.gz
        prefix-length                  3

Applying the Local Routing Configuration

Apply the local routing configuration by calling it to use in the local policy attributes. You do this by setting a flag in the next-hop parameter along with the name of the local routing configuration that you want to use.

To apply the local routing configuration:

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.

ORACLE(session-router)# local-policy
ORACLE(local-policy)#

Type policy-attributes, and press Enter.

ORACLE(local-policy)# policy-attributes
ORACLE(local-policy-attributes)#

next-hop—In the next-hop parameter, type in lrt: followed directly by the name of the local routing configuration to be used. The lrt: tag tells the Oracle® Enterprise Session Border Controller that a local route table will be used.
```
ACMEPACKET(local-policy-attributes)# next-hop lrt:lookup
```
Save and activate the configuration.

Local Route Table Support for H.323 and IWF

Local Route Table (LRT) support for H.323 and IWF is compatible with that currently offered for SIP. LRT and ENUM provide the Oracle® Enterprise Session Border Controller with the ability to perform routing based on ENUM queries to a DNS server or local to an onboard database.

For the LRT feature, this means that entries in the local routing table now include those prefixed with the h323: URI scheme, indicating that H.323 is the next hop protocol.

IWF Considerations

When the system performs a local policy lookup for an incoming SIP or H.323 call and determines an ENUM/LRT server is the next hop, it queries that ENUM/LRT server. The response will include the URI scheme, indicating the next hop protocol and the hostname/IP address representing the next hop. For cases where the incoming call signaling protocol and the URI scheme of the ENUM/LRT response are the same, the call requires no interworking. The Oracle® Enterprise Session Border Controller can simply route the egress call leg to the specified next hop.

Interworking is required when the incoming signaling protocol and the URI scheme of the ENUM/LRT response do not match. When the responses do not match, the Oracle® Enterprise Session Border Controller interworks between SIP and H.323 to route the call to the appropriate next hop.

The Oracle® Enterprise Session Border Controller also compares the URI scheme returned in the ENUM/LRT response to the application protocol specified in the policy attributes. If the URI scheme is SIP, but the policy attributes indicate H.323, the route is deemed invalid. The same is true for an H.323 URI scheme and SIP route.

ENUM LRT Responses

No special configuration is required for LRT to work for H.323 and IWF calls. You can configure the system to match ENUM/LRT responses against session agent groups, and then use those SAGs for routing.

To enable matching ENUM/LRT responses for H.323 SAG routing:

In Superuser mode, type configure terminal, and press Enter.
```
ORACLE# configure terminal
ORACLE(configure)#
```

Type session-router, and press Enter.

ORACLE(configure)# session-router
ORACLE(session-router)#

Type h323-config, and press Enter.

ORACLE(session-router)# h323-config
ORACLE(h323-config)#

enum-sag-match—Set this parameter to enabled if you want the Oracle® Enterprise Session Border Controller to perform matching against the hostnames in ENUM/LRT lookup responses and session agent groups. If there is a match, the Oracle® Enterprise Session Border Controller uses the matching SAG for routing. If no match is found, normal ENUM/LRT routing proceeds.