Multistage Local Policy Routing
Multistage local policy routing enables the Oracle Communications Session Border Controller to perform multiple stages of route lookups where the result from one stage is used as the lookup key for the next routing stage.
Routing Stages
A routing stage signifies a re-evaluation of local policy based on the results of a local policy lookup. In the simplest, single stage case, the Oracle Communications Session Border Controller performs a local policy lookup on a SIP message’s Request URI. The result of that local policy lookup is a next hop FQDN, IP address, ENUM lookup, or LRT lookup; that result is where the Oracle Communications Session Border Controller forwards the message. In the multistage routing model, that resultant next hop is used as the lookup key for a second local policy lookup.
The results of each stage do not erase the results of the previous stage. Thus, previous results are also possible routes to use for recursion, but the next stage results are tried first.
Note:
Setting a next hop to a SAG in a multistage scenario constitutes an error.Multi-stage Routing Source Realm
By default, the Oracle Communications Session Border Controller uses the realm within which a message was received as the source realm through all stages of a multistage local policy routing lookup. You can change this by setting the multi-stage-src-realm-override parameter in the session router config to enabled. Enabling this setting causes the Oracle Communications Session Border Controller to use the next-hop realm from the current local policy stage as the source realm for the next stage of the lookup. This source realm selection process also repeats for each stage of a multistage routing scenario.
Network Applications
The following are typical applications of multistage routing:
- An operator might need to query an ENUM server for a destination number. Based on the NAPTR result of the ENUM query, the Oracle Communications Session Border Controller performs a local policy lookup to decide how to route the request, perhaps based on a LRT table lookup.
- An operator might need to query one ENUM server for a number portability lookup, then based on the routing number perform a second ENUM query to a different server to learn which carrier to use for the routing number. Then, then based on the identified carrier perform a LRT lookup for what next-hop(s) to use for that carrier.
- An operator might query an LRT table to confirm the allowed source number. Then, based on the result, query an ENUM server for destination routing.
Multistage Routing Conceptual Example
Multistage routing is enabled by setting a policy attribute’s lookup parameter to multi. Instead of replacing the SIP message’s request URI with the policy attribute’s next hop address or response from an ENUM or LRT lookup, the system uses that next hop or ENUM or LRT lookup response to reconstruct the SIP message. The reconstructed SIP message is fed again through all configured local policy configuration elements (and policy attribute sub elements). Each time the Oracle Communications Session Border Controller re-evaluates a SIP message against local policies, it is considered an additional routing stage. When multiple records are returned from an ENUM or LRT lookup, the Oracle Communications Session Border Controller evaluates the first response against all applicable local policies. If unsuccessful, the Oracle Communications Session Border Controller evaluates all additional responses, in turn, against all applicable local policies.
For example:
Multistage Routing Example 2
The following three local policy configuration elements are configured in the Oracle Communications Session Border Controller:
Local Policy 1- from-address=*
- to-address=159
- source-realm=private
- policy-attribute
- next-hop=lrt:default-lrt
- lookup=multi
- policy-attribute
- next-hop=192.168.200.50
- lookup=single
- from-address=*
- to-address=192.168.1.49
- source-realm=private
- policy-attribute
- next-hop=lrt:carrier-lrt
- lookup=multi
- policy-attribute
- next-hop=lrt:emergency
- lookup=single
- from-address=*
- to-address=215680000002
- source-realm=private
- policy-attribute
- next-hop=192.168.200.98
- lookup=single
- policy-attribute
- next-hop=192.168.200.97
- lookup=single
- policy-attribute
- next-hop=192.168.200.44
- lookup=multi
<route>
<user type="E164">159</user>
<next type="regex">!^.*$!sip:11568000000@192.168.200.47!</next>
<next type="regex">!^.*$!sip:215680000002@192.168.200.99!</next>
<next type="regex">!^.*$!sip:11578000000@192.168.200.44!</next>
</route>
INVITE sip:159@192.168.1.49:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.48:5060
From: sipp <sip:sipp@192.168.1.48:5060>;tag=1
To:sut<sip:159@192.168.1.49:5060>
Call-ID: 1-4576@192.168.1.48
CSeq: 1 INVITE
Contact: sip:sipp@192.168.1.48:5060
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: 135The local route table in default-lrt appears as follows:
<route>
<user type="E164">159</user>
<next type="regex">!^.*$!sip:11568000000@192.168.200.47!</next>
<next type="regex">!^.*$!sip:215680000002@192.168.200.99!</next>
<next type="regex">!^.*$!sip:11578000000@192.168.200.44!</next>
</route>Customizing Lookup Keys
When the next hop parameter points to perform an ENUM or LRT lookup, it can be provisioned with a "key=" attribute in order to specify a parameter other than the username to perform the lookup on. The following table lists the header, key value, and corresponding syntax to configure the Oracle Communications Session Border Controller with.
| Username from Header: | Key Value | Example |
|---|---|---|
| To-URI | $TO | key=$TO |
| From-URI | $FROM | key=$FROM |
| P-Asserted-Identity | $PAI | key=$PAI |
For a subsequent stage in multistage local policy routing, the lookup key to use for the next stage can be explicitly specified by configuring the next key parameter. By default, multistage lookups use the modified Request-URI returned from the ENUM/LRT response as the to-address key for the next local policy lookup. When the next key parameter is configured, its value will be used for the to-address key in the subsequent local policy lookup regardless if an ENUM or LRT lookup is configured for that policy attribute. The key syntax is for this parameter is the same as with the Routing-based RN and CIC feature.
Multistage Routing Lookup Termination
It is important for the Oracle Communications Session Border Controller to have a mechanism to stop performing additional stages of route lookups and limit the number of attempts and results to be tried. Routing termination can be performed at in the non-multistage way or at the global session router level.
Global Local Policy Termination
The Oracle Communications Session Border Controller can be configured to limit local policy lookups based several aspects of the route lookup process:
- Limiting the number of stages per message lookup—The Oracle Communications Session Border Controller can limit to the number of additional local policy lookup stages it will perform received message to a maximum of 5. This is configured with the additional lp lookups parameter. Leaving this parameter at its default value of 0 essentially disables multistaged local policy lookups.
- Limiting the number of routes per Local Policy lookup—The Oracle Communications Session Border Controller can limit the number of route results to use as returned for each Local-Policy lookup. This is configured with the max lp lookups routes per lookup parameter. Leaving this parameter at its default value of 0 places no limit on the number of returned routes the Oracle Communications Session Border Controller can try.
- Limiting the total number of routes for all local policy lookups per message request—The Oracle Communications Session Border Controller can limit the number of route returned in total across all lookups for a given request, including additional stages. This is configured with the total lp routes parameter. Leaving this parameter at its default value of 0 places no limit on the number of returned routes the Oracle Communications Session Border Controllercan try. This parameter overrides any configured options.
Additionally, the Oracle Communications Session Border Controller monitors for local policy lookup loops which could cause a significant deterioration in performance. If a loop is found, the Oracle Communications Session Border Controller stops trying the looping route list and proceeds to try any remaining routes..
Multistage Local Policy Routing Configuration
To set up your local policy attributes for routing using the TO header:
Maintenance and Troubleshooting
The show sipd policy command includes four additional counters that refer to single and multistage local policy lookups. All counters are reported for the recent period, and lifetime total and lifetime period maximum. These counters are:
- Local Policy Inits—Number of times the Oracle Communications Session Border Controller makes an initial local policy lookup.
- Local Policy Results Max—Number of times the Oracle Communications Session Border Controller truncated the number of routes returned for a local policy lookup because the maximum number of routes per local policy lookup (max lp lookups routes per lookup) threshold was reached.
- Local Policy Exceeded—Number of times the Oracle Communications Session Border Controller truncated the number of routes returned for a local policy lookup because the maximum number of routes per message request (total lp routes) threshold was reached.
- Local Policy Loops—Number of times the Oracle Communications Session Border Controller detected a loop while performing a multistage local policy lookup.
Traps
An SNMP trap is generated to notify that the limit on the additional lp lookups threshold has been reached during the recent window period. This trap occurs a maximum of once during a window period.
apSysMgmtLPLookupExceededTrap NOTIFICATION-TYPE
STATUS current
DESCRIPTION
" The trap will be generated the first time the additional Local Policy Lookups limit is reached is in the recent window period. The trap will only occur once during a window period."
::= { apSystemManagementMonitors 65}