1. User's Guide
  2. Oracle Enterprise Communications Broker Overview
  3. Packet Processing by the Oracle Enterprise Communications Broker

Packet Processing by the Oracle Enterprise Communications Broker

The following diagrams describe, at a high level, the processing performed by the elements of the Oracle Enterprise Communications Broker (OECB) to all traffic that it handles. Understanding this processing provides insight into configuration and troubleshooting tasks. The following diagram provides an example of the interactions of elements in a call flow between SIP agents.

This diagram shows the life of packet as it traverses the ECB from SIP agent to SIP agent. The ECB applies ingress and egress policies as the packet passes through.

The following image displays OECB processing of different signaling messages, including:

  • INVITE—Pass through the INVITE handling processes, which includes number normalization, route optimization, and multi-contact support.
  • REGISTER—When configured as a SIP Registrar, registration traffic passes into the registrar for authorization, authentication, and caching. There are multiple means of performing authorization and authentication.
  • Other—All other signaling traffic is proxied, based on RFC 3261 standards, including the insertion of VIA and Route Record headers to keep the OECB in the path of each applicable dialog's traffic.

This diagram shows how the ECB processes signalling traffic from SIP endpoint to SIP endpoint. The diagram shows the ID method for ingress processing, the elements of the ECB, and packet assembly for egress processing.

The following diagram displays the key processing elements handling an INVITE, including number normalization, based on context, end station lookup, and recursive route set creation.

This diagram displays the key processing elements handling an INVITE, including number normalization based on context, end station lookup, and recursive route set creation.

The following diagram details the elements the system examines to perform user lookup. The OECB queries each of the objects shown in the diagram to identify the destination agent. After identifying the applicable agent, the user lookup hands everything the routing engine needs to recursively specify hop-by-hop routing through agents to reach the target.

Note that utilization of LST versus LDAP resources are independent and exclusive of each other. Either the LST or the LDAP resources perform the functions needed after registration cache procedures. The OECB allows you to configure either LST or LDAP resources.

This diagram shows the details for user lookup.

Ingress INVITE Processing

When an packet arrives at a Oracle Enterprise Communications Broker ingress interface, standard link and network layer processing occurs to prepare the data for processing within the device. Subsequently, the Oracle Enterprise Communications Broker performs admission and overload control procedures to ensure it is both appropriate and possible to proceed with further processing. As discussed, ensuing processing is based on traffic type, of which INVITE processing is key to the overall purpose of the Oracle Enterprise Communications Broker.The sections below describe further INVITE processing.

Identifying Source Context

When receiving an inbound SIP message, the Oracle Enterprise Communications Broker first determines the source context of the calling party. This allows the Oracle Enterprise Communications Broker to interpret the dialed digits appropriately.

For example, a user dialing 911 in the United States has different expectations than a user dialing extension 911 in a European office.

The system performs four steps sequentially to identify the source context. If a step identifies a source context, the system skips the next steps and provides the information to the dial plan engine for subsequent processing. These steps include:
  1. The system searches the FROM address in the signaling for a source context (SC) parameter. This parameter, if present, identifies the UA's source context.
  2. If the number presented in the RURI begins with a "+" sign, assume the RURI is an e.164 number and bypass the source context identification.
  3. The system treats the digits received in the userinfo portion of the From header as a universal address and checks to see if the calling party is in its User database.
    1. If there is a match and the user has a source context configured, the system uses that as the call's source context.
    2. If the user has no source context configured, the system check the user's home agent for a source context and, if configured, uses that as the call's source context.
  4. The system looks for a Source Context value in the configuration for the Agent from which the message was received.
  5. If the above fail, the system uses the default Source Context, as configured in the SIP Interface settings.

Dial Plan Processing

The dial plan receives the dialed digits and the source context of that signaling message, and uses the rules associated with the identified context to prepare the universal address from the digits that were dialed. As described in the section on the dial plan engine, this may involve stripping routing digits out of the dial sequence, adding addressing digits into the sequence, or both.

The result of the dial plan processing yields the universal address that the system passes into the routing engine.

Route Engine Processing

The route engine receives the information from the dial plan lookup and builds a search key based on the calling number, called number, source agent, and destination agent for that call. As described in the section on Oracle Enterprise Communications Broker Routing, it recursively processes each route lookup result to construct full route sets.

Egress Processing

Now that the Oracle Enterprise Communications Broker has a fully qualified universal address, a route or set of routes to use for processing that call, it will prepare the universal address to suit the formatting requirements of the destination. It does this by looking for the Number Translation Mode of the destination agent (not any intermediate agents) and applying the transformation identified within that agent's configuration.

Lastly, the message is sent on its way based on the most preferred route. If that route fails, the Oracle Enterprise Communications Broker will try all subsequent route sets that it learned via the routing engine, in order from least cost to highest cost. This may also involve re-writing the universal address to suit the new "last hop".

Call Handling Example

The following illustration and call flow steps describe call handling through the Oracle Enterprise Communications Broker (OECB).This example assumes no registration cache and no LDAP configuration.

The following diagram shows a simple, intra-organization call passing through the OECB.

This diagram illustrates the list of processing steps that follows this diagram.

A user within the organization calls another within the organization residing on a different PBX. The call proceeds through the components of the OECB using the following steps:

  1. Call Received by Ingress Processing.
  2. Ingress Processing hands FROM and Request-URI to Dial Plan.
  3. System runs 5-step process to ID source context.
  4. Dial Plan normalizes Source and Destination Numbers.
  5. FROM handed to Routing Engine as Source.
  6. Dial Plan hands Request-URI to User DB to ID Home Agent.
  7. User DB hands Request-URI to Routing Engine.
  8. Routing Engine uses FROM and Agent1 CFG to create new Source.
  9. Routing Engine builds Route.
  10. Routing Engine hands Request-URI to Agent 2 configuration.
  11. Agent 2 configuration translates Request-URI into format compatible with Agent 2.
  12. Agent 2 configuration hands Request-URI to Egress processing.
  13. Egress processing builds INVITE.
  14. Egress processing sends new INVITE to Agent2.