When you enable the local policy session agent matching option in your global SIP configuration, you change the way local policies match session agents. Normally, the Oracle Communications Session Border Controller looks up and stores matched session agents configured as next hops so it does not need to perform the lookup while processing requests. In this type of matching, the Oracle Communications Session Border Controller does take the realm set in the local policy attributes into consideration. When the Oracle Communications Session Border Controller performs its regular matching method and you have enabled overlapping IP addresses for session agents, the Oracle Communications Session Border Controller might match session agents to different realms than the ones you intended when creating your configuration.

Local policy session agent matching provides a way to match session agents differently, taking realms and nested realms into consideration during the matching process. This difference is key to deployments with multiple peering partners that use the overlapping IP address feature, and have multiple local policies routing to the same IP address in different realms where some target next hops require session constraints but others do not. In the cases where no session constraints are required, session agents are not needed. But session agents still match the local policy, applying their constraints, because they match the next hop IP address.

In addition to modifying this behavior, this feature also affects the use of realms and nested realms. It triggers the use not only of realms, but of all the realms nested however deeply—thereby improving matching efficiency.

You can set the local policy session agent matching option with values that define how the Oracle Communications Session Border Controller performs session agent matching:

• any—The Oracle Communications Session Border Controller looks up and stores matched session agents configured as next hops so it does not need to perform the lookup while processing requests, without regard to realms.

  This behavior is the default when the SIP configuration does not have the local policy session agent matching option set.

• realm—The Oracle Communications Session Border Controllerselects session agents in the realm that the local policy attribute indicates; this provides an exact match, rather than not taking the realm into consideration during session agent selection.

  For example, the session agent is a match if the session agent realm-id and the local policy attribute realm parameters are an exact match.

• sub-realm—Session agents in the same realm or the same realm lineage—where session agents and realms are related to one another via realm parent-child relationships no matter the depth of realm nesting configured

  For example, the session agent is a match if the local policy attribute realm is a sub-realm of the realm specified in the session agent realm-id parameter.

• interface—Session agents in the same realm or same realm lineage via the realm set in the local policy attribute, and whose realm uses the same signaling interface as the realm set in the local policy attribute

  For example, the session agent is a match if the session agent realm-id is a sub-realm of the local policy attribute realm, and both referenced realms use the same SIP signaling interface.

• network—Session agents whose realm is in the realm lineage for the same realm set in the local policy attributes, and whose realm is associated with the same network interface as the realm set in the local policy attributes

  For example, the session agent is a match if the session agent realm-id is a sub-realm of the local policy attribute realm, and realm reference by both use the same network interface.

If it cannot find a match, the Oracle Communications Session Border Controller will use the IP address as the next hop. Further, requests matching local policy attributes will not be associated with session agents, and so their constraints will not be applied.

The Oracle Communications Session Border Controller stores session agent information that it looks up when performing local policing session agent matching. To perform the lookup, it uses the session agent hostname as a key. When the hostname is an FQDN and there is a configured IP address in the ip-address parameter, the Oracle Communications Session Border Controller uses the ip-address value as a secondary key. Given this implementation, the following are true when selecting session agents:

• If multiple session agents share the same IP address, the one with an IP address in the hostname parameter takes precedence.
• If all session agents with the same IP address have an FQDN as their hostname, the one whose name is alphabetically lower will take precedence, where alphabetically lower means earlier in the alphabet (closer to A than to Z).
• For non-global session agents (whose realms are configured but not wildcarded) with an IP address, the Oracle Communications Session Border Controller uses a key that is a combination of the IP address and the realm in the form <address>:<realm>.
• For a session agent whose realm has a parent realm, the Oracle Communications Session Border Controller uses a combination of the IP address, realm, and realm-path (or lineage for the realm) in the form <address>:<realm-path>. For example, the realm path for a realm core3 with a parent core2, which in turn has a parent core would be core:core2:core3.

When it looks up a session agent with a realm, the Oracle Communications Session Border Controller first searches for an exact match for the IP address and realm combination. If this fails, it performs a second search if the desired realm has parents or children. The Oracle Communications Session Border Controller locates an entry in its repository of session agent information that is greater than or equal to the IP address with the base realm, which is the ancestor of the desired realm without a parent. Having gathered this set of candidates, the Oracle Communications Session Border Controller narrows down the search for a match by comparing sub-realms and determines there is a match if either:

• The desired realm path is a sub-string of the entry’s realm path, or
• The entry’s realm path is a substring of the desired realm path (i.e., the desired realm is a sub-realm of the entry’s realm)

Then the Oracle Communications Session Border Controller orders the candidates by depth of the entry’s realm-path, or number of levels from the base realm relative to the depth of the desired realm. By searching the ordered set until the entry’s realm depth equals the desired realm’s depth, the Oracle Communications Session Border Controller determines a parent candidate, all subsequent entries being sub-realms of the desired realm. The Oracle Communications Session Border Controller only considers entries at the first level deeper than the desired realm. If at this point there is only one entry, the Oracle Communications Session Border Controller deems it a match. Otherwise, it selects the parent candidate as the matching entry. In the event the search does not yield a matching realm, the Oracle Communications Session Border Controller uses the global session agent for the IP address, if there is one.

The following diagram shows the realm tree, where the clouds are realms and squares are session agents, representing a group of session agents sharing the IP address 1.2.3.4. The Oracle Communications Session Border Controller searches for the session agents lower in the tree along the session agent realm-path and the desired realm.

For each realm in the table above, the search results for each realm would look like this:

enforcement-profile
        name                              rulefour
        allowed-methods
        sdp-address-check                 disabled
        subscribe-event
                 event-type                      *
                 max-subscriptions               1
        subscribe-event
                 event-type                      xyz
                 max-subscriptions               0
        last-modified-by                  admin@console
        last-modified-date                2008-11-11 12:49:27