Oracle Enterprise Communications Broker Routing

The Oracle Enterprise Communications Broker (OECB) employs a purpose-built SIP routing engine for packet processing. Unlike traditional SIP proxies, application servers, or Session Border Controllers, the OECB may be provisioned with a complete network topology map of all signaling entities, and use this provisioned data to make fully-informed routing decisions on how signaling flows should travel through a SIP network. Beyond choosing a next hop and pushing the signaling message on its way, the OECB will look at the entire path from origin to destination to find the path with the least cost, fewest active sessions, least number of hops, and so forth. The OECB pre-populates the egress signaling message with a specific route set to inform each receiving device on the next element in sequence.

Recursive Routing

Conceptually, the routing engine in the Oracle Enterprise Communications Broker (OECB) is similar to the recursive routing engine in a layer three router. The system provides the route engine with input criteria, including calling number, called number, source agent, and destination agent. The routing engine returns a set of results based on the lookup. The OECB processes each result recursively until complete, with each loop building another hop on the route.

The process of using recursion to create routes consists of identifying individual hops for an end-to-end path beginning with the last hop before the destination. The routing engine selects subsequent elements (agents) to identify the hop that is next after the previously identified hop until it has a full path between itself and the UE. The OECB routing engine performs this process for all possible paths to each agent, creating multiple choices for the system to use as a route set for every individual call.

The following diagram is an example of a rudimentary network topology to illustrate how the OECB uses recursion to identify a route path.

1. The OECB discovers that Agent G is the last stop on the signaling message path.
2. The OECB resolves each way that it can reach Agent G. It finds that it can reach G by way of agents D, E, and F.
3. The OECB looks up how to reach D, E, and F, and the route table yields Agents A and B. Because Agents A and B are directly connected to the OECB, route path identification is complete.

Identifying Contacts and Specifying Routes

Having determined the target for a call, the Oracle Enterprise Communications Broker creates route sets to the target. In addition, the Oracle Enterprise Communications Broker also finds all of a target's contacts and builds route sets for each of them. Depending on deployment and configuration, these contacts are available from multiple sources, both internal and external to the Oracle Enterprise Communications Broker. These sources provide the Oracle Enterprise Communications Broker with the agent of each contact, from which it can build routes to the contacts.

The Oracle Enterprise Communications Broker uses called, calling number and source agent from the source of the call, and the called number and destination agent to create a route. It goes about collecting this detail for target and all contacts using the following procedure:

1. Find the AoR and all associated contacts in the registration cache. Store agent(s) for route creation.
2. Find caller and callee's source context, as presented earlier in this document.
3. Convert user portion of request-URI and From URI to universal number via the dial plan and source context. These become called and calling number.
4. Lookup called and calling number in the user database. Retrieve each number's agent for route creation.
5. If the user database lookup does not produce source and destination agent, request this information via the LDAP database. If necessary, the system converts the universal number so the lookup format is compatible with the LDAP database.
6. If the LDAP lookup does not return source and/or destination agent, the Oracle Enterprise Communications Broker uses the host portions of the Request-URI and FROM URI or inbound agent (agent on which the call was received) as agents.
7. For any AoR returned from LDAP, the Oracle Enterprise Communications Broker performs another lookup in the registration cache and creates routes for the AoR.
8. If the LDAP lookup identifies other contacts, the system passes those contacts through the registration cache to identify its agent and build the route set.
9. All routes are built and, depending on forking configuration, placed in order.

If any of these sources are not configured or operational, the Oracle Enterprise Communications Broker proceeds to the next source. Note that, if agents are found in the user database, the system does not perform an LDAP lookup.

Note:

The procedures associated with an LDAP resource are equivalent to those with an LST resource. These procedures are also exclusive; LST and LDAP resources cannot be used simultaneously for routing.

The system forwards the request based on the route list and the forking configuration. By default, the system performs serial forking to all contacts using route cost to establish the order. The system can also perform parallel forking, if desired.

Route Selection

After constructing routes to use for a call, the Oracle Enterprise Communications Broker (OECB) often can choose from multiple routes. Cost calculations for each route identify the route that the system uses.

In the network example in "Recursive Routing," the OECB determined the three following potential routes for an inbound message sent to Agent G:

• A to D to G
• B to E to G
• B to F to G

Each route between agents in the OECB routing table may be assigned a cost that represents the desirability of that route. The OECB sums up the total cost for each route and orders them from lowest to highest cost. It then selects the lowest cost route and forwards the message.

Forking

Forking is a routing option that the Oracle Enterprise Communications Broker (OECB) uses to direct an INVITE to multiple targets. Several types of forking control the operations of the function, such as timing and target lists. The OECB performs serial forking to all targets by default. You can enable the OECB to perform parallel forking, which directs the INVITE to all targets for an Address of Record (AOR) simultaneously. When any target responds, the OECB issues a CANCEL to the other targets and ignores any responses from them. Should the OECB receive error messages from all contacts, it provides the lowest number message back to the caller.

The OECB detects a user's multiple contacts from:

• A configured LDAP server
• The local registration cache
• The User Database

The system can fork to multiple contacts that come from the following locations:

• Registration cache (the minimum requirement)
• Registration cache + LDAP
• Registration cache + User Database

When the system finds the contact used in the RURI in the User Database, it uses that contact and then LDAP queries only on the user in the "From:" header.

When the User Database does not contain the number in the RURI, LDAP performs the lookup on the RURI and the system forks the call based on the result.

You cannot configure forking to:

• LDAP directly
• User Database directly
• Registration cache + LDAP + User Database

When the OECB detects multiple routes to a contact, the system uses cost configuration to determine the preferred route. The system uses backup routes only when the primary routes do not respond.

You can enable parallel forking in the SIP Interface configuration.

Fork Groups

Fork-groups on the Oracle Enterprise Communications Broker are sets of one or more contacts that the system attempts to reach simultaneously. The system uses fork group order to specify when it tries to reach each fork group's contacts. This results in a hybrid of serial and parallel forking operation. The user can configure fork groups on agents, the registration cache and within the LDAP database. The user can also configure a global fork group timer with a value from 0 to 32 seconds on the sip-interface. If the system does not receive a response from any contact within that time, it tries the next fork group. Parallel forking must be enabled.

By default, the Oracle Enterprise Communications Broker assigns all contacts to fork group 1 and attempts to contact them serially, using the order in which it learns them. If desired, the user can enable parallel forking. By itself, parallel forking causes the system to attempt to reach all contacts simultaneously. Fork groups refine parallel forking, allowing the system to try all contacts in a group, and then move on to the next group.

The user names fork groups using decimal numbers between 1 and 100. This naming defines fork group order, with the system using fork group 1 first. The user configures objects with fork group numbers, based on a forking plan they devise.

The user can also configure a lookup query to LDAP databases to retrieve individual contacts' fork groups. The user must have previously modified the LDAP database to include a custom fork group field in contact records.

A use case for this feature could include the system attempting to reach a user's BYOD and desk phone simultaneously, then forwarding to an enterprise-preferred voicemail server if neither answers. For this to work, the BYOD and desk phone would be in the same fork group. The voicemail server would be a member of a higher numbered fork group. To ensure this order, the system assigns lower numbered fork groups with a higher precedence.

After establishing a session, other contacts may respond to try and start the session themselves. The Oracle Enterprise Communications Broker replies to these messages with a CANCEL.

Fork group operation does not exclude the use of primary and backup routes. The Oracle Enterprise Communications Broker still creates route sets for all contacts. If a contact fails via a primary route, the system attempts to reach the contact using all backup routes, based on cost.

If the Oracle Enterprise Communications Broker receives a redirect from an endpoint, the system adds the redirect target to the current fork-group and tries to contact it before attempting the next fork-group. If the global fork group timer expires before the system receives a redirect, however, the system proceeds to the next fork group.

The flexibility inherent in fork group operation requires the user to carefully plan forking prior to configuration. For each call, the system creates an ordered contact list, based on fork group configuration. Because the fork group assignment may affect multiple contacts, such as agent configuration, the user must be careful not to configure a sequence that would adversely affect calls to different end stations behind that agent.

Fork Group Assignment

You configure fork groups to specify call attempt order for a given call. The Oracle Enterprise Communications Broker (OECB) creates call attempt lists based on each contact's fork group assignment.

Upon configuration, the system assigns fork groups to target endpoints, as follows:

• User database—Each user database entry is assigned to the home-agent's fork-group.
• Registration cache—Each registration cache entry is assigned to the SIP registrar's fork-group.
• LDAP server—Each contact retrieved from an LDAP server is assigned to the a fork-group specified in the server's user record. If no fork-group is configured for the user in the Active Directory, the system assigns the target endpoint to the fork-group of the user's home-agent, as configured on the LDAP server.

The OECB uses the following contact source order:

1. Registration cache contacts
2. User database contact
3. LDAP contacts
4. LDAP AORs generating subsequent contact dips for additional registration cache contacts

By default, the OECB collects contacts from these sources and creates a contact list that follows the order in which the system learns them. This behavior is in accordance with default fork group operation, where all contacts are in fork group 1 and the mode is to fork serially only. As soon as the system finds differentiation between contact fork groups, it arranges contact lists using the fork group order.

Additional Targets

You may want to include forking targets to stations that are not resolved as original call targets. Examples of these scenarios include directing calls to a preferred enterprise voice mail server, if they are not picked up. The Oracle Enterprise Communications Broker (OECB) provides for this using Additional target configurations. You manually configure these devices within Additional target groups, which includes one or more end stations. Agent and registrar configuration allows you to select these groups as additional forking targets for all calls that use that agent or registrar's entries.

An additional target group is a list of agents or end stations that the OECB uses as candidates for either parallel or serial forking. You configure these groups with fork group numbers, which the system then uses to define fork group order. The system adds additional target contacts to the forking sequence the same way it adds contacts for other objects with fork group configurations.

Fork Groups Configuration Considerations

Fork Group configuration requires that you establish a clear plan prior to any configuration. Configurations established by this planning may include:

• Identify or create new agents as fork group targets.
• Identify usage and precedence policy for forking via the Registrar.
• A adjust fork group identification and precedence based on preferred LDAP lookup scenarios.

Coordinating the use of these sources and configuring the applicable objects establishes and refines fork group configuration. Applicable configuration objects include:

• Agent—Create new agents specifically for use in a fork group, or uses existing agents. Configures an agent with a single fork group number, which the system applies to every call using that agent as a route.
• Additional targets—Create sets of targets to manually establish forking targets.
• Registrar—Set the registrar to a single fork group, which the system applies to every contact in the registrar.
• LDAP—Ddefine a lookup query that pulls the pre-configured fork group assignment defined for the queried contact. The query must pull this fork group assignment from a custom attribute established on the LDAP database.

Configure Fork Groups on Agents

1. Access the Agent configuration object.
   Configuration tab, Service Provisioning section, Agents, Session Agent.
2. Click either Add to create a new agent or Edit to add the agent to a fork group.
3. On the Agents page, do the following:

   Additional Target Group	Select a target group from the drop down list.
   Fork Group	Enter a digit to specify this agent's fork group priority in a target list. Range: 0-100.

4. Click OK.
5. Save the configuration.

Configure Additional Target Groups

Additional targets are agents or end stations that are not contacts already targeted by a given call. You assign additional target groups on a per-agent and a per-registrar basis.

Configure target groups.

To configure additional target groups:

1. Access the Agent configuration object.
   Configuration tab, Service Provisioning section, Agents, Additional Target Group.
2. On the Additional Target page, click the Add icon.
3. On the Add Additional Target page, enter a enter a name for this target. Use this name to assign this group to an agent or the registrar.
4. Under Additional Target, click Add.
   The system displays the Additional Target Group / Additional Target page.
5. On the Additional Target Group / Additional Target page, do the following:

   Additional Session Agent	Select an existing target group from the drop down list, or enter an IP address of a target station.
   Fork Group	Enter a digit to specify this agent's fork group priority. The lower the digit, the higher the priority. Default: 1. Range: 1-100.

6. Click OK.
7. Click OK.
8. Save the configuration.

Assign the Additional Target Groups to the appropriate agent or the registrar.

Configure Fork Groups on a Registrar

1. Access the SIP Registrar configuration object.
   Configuration tab, System Administration section, SIP Registrar.
2. On the Add SIP Registrar page, do the following:

   Additional target Group	Select an existing target group from the drop down list.
   Fork Group	Enter a digit to specify the fork group for every contact in the SIP Registrar end points. Default: 1. Range: 0-100.

3. Click OK.
4. Save the configuration.

Configure LDAP for Fork Groups

• Configure the LDAP server that you want to use for fork groups.
• Define and populate the custom LDAP attribute for specifying a fork group.

1. Access the LDAP Configuration object.
   Configuration tab, System Administration section, LDAP, LDAP Config.
2. Click on the Action button for an existing LDAP configuration.
3. Click Edit.
4. Scroll to Routing, Lookup Queries, and click Add .
   The system displays the Add LDAP Config / Routing / Lookup Query dialog.
5. In the Fork Group Attribute field, enter the name of the custom attribute in the LDAP database that includes fork group assignments.
6. Click OK.
7. Click OK.
8. Save the configuration.

Configure the Global Fork Group Timer

The global fork group timer specifies the amount of time the system waits for responses from a fork group before it tries contacting the next fork group.

After this timeout, the system drops responses received from contacts in the expired fork group.

1. Access the SIP Interface configuration object.
   Configuration tab, System Administration section, SIP Interface, SIP Config.
2. On the SIP Config page, for the Fork Group Timeout parameter, enter a time in seconds. Default: 0. When set to the default, the system waits for the standard SIP INVITE transaction timeout to expire before proceeding with the next group. Range: 0-32.
3. Click OK.
4. Save the configuration.

Routing and ENUM

The ENUM functionality lets the Oracle Enterprise Communications Broker make an ENUM query for a SIP request. The ENUM lookup capability lets the Oracle Enterprise Communications Broker transform E.164 numbers to URIs during the process of routing (or redirecting) a call. During the routing of a SIP call, the Oracle Enterprise Communications Broker determines if an ENUM query is required and if so which ENUM server(s) need to be queried. A successful ENUM query results in a URI that is used to continue routing or redirecting the call.

Refer to the chapters on Agent and Route configuration for instructions on the related fields.

Route Types and Precedence

There are three types of routes used by the Oracle Enterprise Communications Broker. These include configured, default and implicit. The Oracle Enterprise Communications Broker uses these types, in conjunction with route cost, to determine route order. You create both configured and default routes in your route table. A default route is simply a route configured with wildcards for called number, calling number, source agent and destination agents. The system installs implicit routes dynamically when there are no explicitly configured routes to an agent. The system assumes the agent is to be a directly connected next-hop, and subsequently relies on the network infrastructure to reach that agent when needed.

The system orders routes by cost first, with the lowest cost being preferred. If costs are equal, the system orders by type, with the preference given to configured, then implicit and then default. If route cost and type are all equal, the system orders routes according to hop count, with the lowest number of hops being preferred.

Refer to the chapter on Route configuration for instructions on the related fields.

Active Directory and Oracle ECB Routing

A large percentage of Enterprises use call servers with Active Directory (Domain Controller) such as Media Servers, Exchange Servers, Lync Servers, and so on. For Enterprises that integrate these servers in parallel to their existing communications infrastructure, or transition from their legacy Private Branch Exchange (PBX) to these types of servers, Active Directory becomes a more efficient and cost-effective way of routing the incoming calls within the core Enterprise network.

Clients using Microsoft servers such as a Lync Server deploy their own URI. Therefore, a user in a network with both a desk phone and a Lync client may have an IP PBX extension/URI for the desk phone, and a different URI for the Lync client. Currently, all PSTN traffic is sent by default to a legacy PBX in the core network. If the PBX does not recognize the extension/URI, the PBX forwards it to the Lync client. Sending traffic to the PBX first and then to the Lync Server can be costly in terms of computing resources and licensing fees. Routing all incoming sessions from a SIP trunk to the Lync Server first and then to a PBX can be costly.

As a solution, the Oracle Enterprise Communications Broker (OECB) initiates a query to the Active Directory to determine how to route the call. The data fetched is the agent of the targets pre-configured in the database.

The OECB stores the data used to facilitate the routing decision of the call (performed by Lightweight Directory Access Protocol (LDAP) and routes the call the first time to the applicable destination (PBX or Lync Server).

In scenarios where a user has multiple contacts such as both a Lync phone and a legacy PBX phone, calls destined for the Lync phone number can be routed to the PBX phone number, or calls destined for the PBX phone number can be routed to the Lync phone number. The destination is dependant on the current OECB configuration. The OECB uses the information stored in the Enterprise’s Active Directory, compares it to the OECB configuration and then determines which phone number to utilize.

Note:

The Active Directory-based call routing feature supports confidential and secure LDAP traffic support by using SSL TLS (LDAPS).

Active Directory-based call routing is a feature of the OECB that facilitates the routing of incoming calls to the appropriate destinations within the Enterprise core network. The OECB LDAP query to the Active Directory yields the agent of the phone number.

The following diagram shows incoming call flow with Active Directory and the OECB in the network. The IP PBX extension (4392) is the primary telephone number (+1.781.555.4392). The secondary transition number (+1.781.430.7069) is assigned to Lync.

1. When the OECB receives an inbound SIP INVITE over a SIP Trunk, it checks the current LDAP configuration in the OECB.
2. Depending on the configuration, the OECB accesses the Enterprise’s Active Directory to search for the applicable number being called by way of an LDAP query.
3. When the LDAP query finds the agent of the called number, the OECB builds a route set for the call and routes the call, per the routing engine, directly to the call server client ( 3a) or to the IP PBX phone ( 3b ) and ( 3c).

The Enterprise is responsible for migrating phone numbers from the legacy PBX to the call server by making the necessary updates in their Active Directory so the OECB can route the call properly. In the illustration above,

LDAP and Oracle ECB Routing

The Oracle Enterprise Communications Broker (OECB) uses Lightweight Directory Access Protocol (LDAP) to perform queries to the Enterprise’s Active Directory (AD) to determine where to route incoming calls to the call server or the IP PBX in the Enterprise network. Session requests and responses are sent and received based on the OECB’s LDAP routing configuration. LDAP determines the destination, to a call server user or a non-call server user, and forwards the call accordingly.

The OECB, using LDAP, performs the following on an inbound call:

• Creates an LDAP search filter based on the dialed number and the configured LDAP attributes
• Sends an LDAP search query to the configured LDAP Server
• Creates a route list based on the query responses received from the LDAP Server and the applicable attributes it already has (caller number, callee number, caller agent)
• Routes calls based on the route list and routing order. The routing order is dependent on the LDAP attribute configuration and whether there was an exact match for the dialed phone number in the Enterprise’s Active Directory.
• If configured, searches for additional AoR matches in Active Directory so that it can create additional routes to target users that have contacts stored in separate records.

To use AD as a source for home agent names, you create lookup queries from the LDAP routing configuration dialogs. The OECB uses LDAP to retrieve that information and create routes. If the system cannot derive a home agent name from the query results, it routes the call to the configured default home agent.

Note:

You must ensure that phone numbers in the LDAP database are unique. If the OECB encounters multiple records with the same number, it cannot process the lookup.

The OECB keeps a permanent LDAP session open to all configured call servers. It sends an LDAP bind request on all established connections to those servers. The first call server is considered the primary LDAP Server, and all others are secondary LDAP servers. If a query request sent to the primary server is unsuccessful, the OECB sends the request to the next configured LDAP Server until the request successfully in gets a response. If the OECB receives no response and cannot find another route successfully, it sends a busy to the caller.

LDAP performs call routing based on LDAP attributes configured on the OECB. The route-mode attribute setting determines how LDAP handles the called number when accessing the Enterprise’s Active Directory. You can set routing modes to any of the following:

• Match-only (default)
• Attribute-order
• Match-first

Match-only

When you set the LDAP route-mode attribute to match-only, the OECB performs as follows.

When the OECB receives an incoming call to the Enterprise network, LDAP queries the Active Directory to find the number that matches the incoming number exactly. If the number is found, the OECB retrieves the entry's agent and builds a route list for the call. The following steps describe the match-only call flow in the following diagram.

1. A call comes into the Enterprise network (+1.781.555.4413).
2. Using the configured route-mode of match-only, LDAP queries the exact matching number in the Enterprise’s Active Directory.
3. The Active Directory finds the matching number and includes that number's agent in the response to the LDAP query.
4. The OECB creates a route set for the call and forwards the call towards the destination phone number (same number as the number that initially called into the Enterprise in Step 1 (+1.781.555.4413)).

Attribute-order

When you set the LDAP route-mode attribute-order, the OECB performs as follows.

The order in which you configure the LDAP attributes on the OECB determines the priority of each route. If an incoming call is destined for the IP-PBX, but the attribute name for a Lync client is configured first, the OECB uses the corresponding agent (Lync Server) to create the first route in the route list.

An entry in an LDAP search response must have at least one attribute that it matches in the Active Directory.

For example, suppose the incoming phone number is +1.781.555.4392 (which matches the IP-PBX phone number), and the attribute name msRTCSIP-Line (Lync attribute) in the response is+1.781.430.7069 (Lync phone number). The OECB creates a route for the Lync phone number, even though the incoming phone number matches the IP-PBX phone number because the msRTCSIP-Line attribute was configured first. The OECB forwards the call to the Lync destination.

If an Enterprise uses the same phone number for both Lync and IP-PBX phones, and the attribute-name msRTCSIP-Line is configured first (a Lync attribute), the OECB uses the corresponding agent (Lync Server) to create the first route in the route list. The following steps describe the attribute-order call flow in the following diagram.

1. A call comes into the Enterprise network (+1.781.555.4392).
2. Using the configured route-mode of attribute-order, LDAP queries the Active Directory for the agent of the matching number.
3. The Active Directory responds with the agent associated with the first configured LDAP attribute (+1.781.430.7069). In the diagram, the number is associated with a Lync Client (msRTCSIP-Line) that was configured first in the LDAP configuration.
4. The OECB forwards the call to the applicable destination phone number's agent from the Active Directory response. (+1.781.430.7069).

When you configure the attribute name msRTCSIP-Line first, the Oracle Enterprise Communications Broker uses the corresponding next hop (Lync Server) to create the second highest priority route in the route list. For example, the dialed telephone number could be +1.781.555.4392 (IP-PBX phone number), and the attribute-name msRTCSIP-Line in the response could be +1.781.430.7069 (Lync phone number). A route is created for the Lync phone number, even though the dialed telephone number is the PBX phone number.

Match-first

When you set the LDAP route-mode attribute to match-first, the OECB performs as follows.

When the LDAP query is sent to the Active Directory, the first exact match of the incoming phone number that the LDAP query finds in the Directory is the number whose corresponding route gets the highest priority in the route list. For all other routes configured on the OECB, the ordering of LDAP attributes in the LDAP configuration determines the priority for each route.

For example, if the incoming number is +1.405.565.1212, and the Active Directory includes a configured mobile number first (+1.201.444.5555), a home number second (+1.405.333.6666) , and a work number third (+1.405.565.1212), the LDAP query searches the mobile number first, then the home number, then finds the exact match on the work phone number. The Active Directory responds with the agent information for the work phone number and the OECB creates a route list with this exact phone number and forwards the call accordingly. The following steps describe the match-first call flow in the following diagram.

1. A call comes into the Enterprise network (+1.405.565.1212).
2. Using the configured route-mode of match-first, LDAP queries the Active Directory for the agent of the matching number.
3. The LDAP query searches throughout the Active Directory until it finds the first exact match on the number. Active Directory responds with the exact phone number associated with the incoming number (+1.405.565.1212). In the diagram, the number was associated with the work phone.
4. The OECB forwards the call to the agent of the applicable destination phone number from the Active Directory response. (+1.405.565.1212).

LDAP Messages

If LDAP message logging is enabled in the Active Directory, the Oracle Enterprise Communications Broker sends LDAP messages to a message log called log.sipd. This log records all received and sent LDAP messages. Messages are in ASCII encoded binary format.

Additionally, when LDAP is invoked for routing, the LDAP messages display in the GUI under the Monitor and Trace tab.

Note:

The Oracle Enterprise Communications Broker also supports transmitting LDAP messages using the IPFIX Protocol for the Palladion Mediation Engine.

LDAP Failure Events

If an incoming registration to a primary phone number in Lync fails, the phone number is routed to the IP PBX. If failures occur during LDAP queries for all LDAP Servers, the Oracle Enterprise Communications Broker logs the failure to the log.sipd, and proceeds with normal configured routing policies, if available.

Note:

The Oracle Enterprise Communications Broker always establishes the TCP/TLS connection towards the configured LDAP server(s). If a TCP connection fails, the Oracle Enterprise Communications Broker continues to attempt to re-establish the connection.

An LDAP connection failure can be due to any one of the following events:

• Oracle Enterprise Communications Broker receives a CANCEL message (LDAP connection termination). The Oracle Enterprise Communications Broker detects this if it receives or issues an 'unbind' operation. The session is then closed down at TCP/TLS.
• Oracle Enterprise Communications Broker receives a call failure message from Lync (TCP/TLS socket termination). If either side receives a finish message (FIN) or reset message (RST), the TCP socket closes per standard behavior, which triggers the LDAP layer to detect connection failure. The Oracle Enterprise Communications Broker fails over to a secondary LDAP Server, if configured; otherwise it periodically attempts to reconnect to the Primary LDAP Server.
• Oracle Enterprise Communications Broker is unreachable and SIP session towards Lync times out. User is enabled for Lync but the Lync Server is unreachable by the Oracle Enterprise Communications Broker so a timeout occurs. When consecutive LDAP queries timeout, the Oracle Enterprise Communications Broker concludes that the LDAP session has failed, and then proceeds to terminate the TCP/TLS connection.

The number of consecutive queries that timeout before a connection is considered failed, and the number of successive query timeouts for each LDAP Server can be set via configuration.

Oracle ECB Limitations using LDAP

The Oracle Enterprise Communications Broker uses LDAP in the Active Directory when determining the destination of incoming calls. However, the Oracle Enterprise Communications Broker has the following limitations when using LDAP:

• Supports LDAP sessions over the Oracle Enterprise Communications Broker media interfaces only (i.e., not on wancom0).
• Supports LDAPv3 only.
• Establishes a session over the following connections only:

  LDAP over TCP - default

  LDAP over TLS (LDAPS)

Configuring LDAP for Routing

LDAP is the Protocol that the Active Directory uses for general interaction between and LDAP client and an LDAP server. You can configure the LDAP Server(s) in your network, and set the filters and the local policy that the LDAP Server uses when handling inbound Lync and PBX calls in the Enterprise core network.

You can use the following objects in the Web GUI to configure LDAP:

• LDAP Config—Configures the LDAP functionality on the Oracle Enterprise Communications Broker (i.e., name, state, LDAP servers, realm, authentication mode, username, password, LDAP search filters, timeout limits, request timeouts, TCP keepalive, LDAP security type, LDAP TLS profile, and LDAP transactions).
• Routing—Configures Active Directory attribute names, attribute format and regex extractions for routing SIP requests to the target's home agent. You configure this object for LDAP search queries in the Active Directory.
• Address of Record—Configures Active Directory attribute names, attribute format and regex extractions for identifying other addresses of record for the request URI and from. The Oracle Enterprise Communications Broker uses any AoR information provided by these queries to generate additional routes for the session, using the same process it used for the original request URI and from.

Source Routing

The OECB supports source routing based on agent hostname. You configure these routes by adding the hostname to the source agent portion of your route. When the OECB sees this hostname in the FROM URI, it uses your source route to direct the traffic. You can also configure the OECB to perform source routing on calling numbers that have a FROM header with a R-URI that contains an IP address or an FQDN. For this, the OECB attempts to determine the hostname by searching for the address or FQDN in the UserDB. If it finds the entry, the OECB inserts the hostname into the FROM and performs a route lookup. You enable source routing using the Source Based Routing parameter in the SIP configuration.

If the FROM of the INVITE has an IP address or FQDN instead of a hostname, the OECB does not perform source routing by default. You enable the OECB process that can resolve an IP address or FQDN to an agent's hostname, thereby allowing source routing on this signaling. To accomplish this, the OECB matches the configured session agent hostname with the host portion of the From-URI in incoming INVITE. If there is an IP address in the From-URI, the OECB performs a session-agent IP/FQDN match with the From- URI host.

Assuming you have enabled it, the OECB performs routing using a sequence of configuration checks with source routing being the last. For this sequence, the OECB:

1. Performs a lookup in the Dial-plan for the calling number.
2. Checks for a UserDB entry for the calling number.
3. If LDAP is enabled, performs an LDAP look-up on the host portion of the FROM URI.
4. Checks to match the host portion of the FROM URI with a configured session agent host.
5. Attempts to perform source routing using the host portion of the From-URI as the source agent.

After determining that source routing is required, the OECB:

1. Checks the userDB for an entry that matches the calling number. If the calling number is present in the userDB, the OECB fetches the source agent from userDB entry.
2. If Step (1) doesn't result in any entry, the OECB performs an LDAP lookup for a matching entry. If the OECB finds an entry, it fetches the source agent from that entry.
3. If Step (2) doesn't find an applicable entry, the OECB checks the host portion of the From-URI for an IP address match.
4. If the received IP address doesn't match any of the configured hostnames, the call fails.
5. The OECB performs a routing look up after IP address resolution.

This flexibility with the source agent parameter of a route also allows you to configure source routes using session agent groups (SAGs). In this case, the OECB matches sessions coming from any of the agents included in the group, even if the calling number from the SAG is not in the UserDB.

Oracle recommends that you do not configure overlapping IP addresses to multiple Session Agents when using source routing. The OECB allows you to configure the same IP address for multiple session agents. But if there is overlapping agent addressing, the OECB only uses the first configured SA it finds for setting the source agent, which may not be the intent of you configuration.

Configuring Source Routing

You enable or disable Source based routing using the Source Based Routing checkbox in the SIP configuration. Navigate to this setting using Configuration, System Administration, SIP Interface, Sip-Config. If this checkbox is disabled, the OECB does not use source IP address/FQDN matches for any incoming calls.

If you configure a routing source routing entry with a destination agent that is not set to * , the OECB cannot match the destination agent with the request-uri IP address. Set source route entries with a destination agent of *.

You can also support SAG based source routing by configuring an applicable manipulation-string to your Session-Agent configuration to replace the configured string with the user-portion of the From URI. The manipulation-string configuration only applies if you have configured HMR.