SIP Call

The Oracle Communications Unified Session Manager evaluates all IFC logic to determine that messages with matching characteristics are sent to the proper AS specified in the iFC evaluation using the IP Multimedia Service Control (ISC) interface. In this INVITE, the Oracle Communications Unified Session Manager adds two Route headers. The first (top) route header contains the target AS’s URI. The second Route parameter is built using the IP address of the egress SIP interface and contains the ODI as a parameter. For example:

INVITE SIP:test@service.com
...
Route:2.2.2.2;lr
Route:1.1.1.1:5060;lr;smx_odi=1

If the AS routes the call back to the Oracle Communications Unified Session Manager, it is expected to include the ODI parameter that it received from the Oracle Communications Unified Session Manager, unchanged. The presence of the ODI parameter indicates that IFC evaluation needs to continue from where it left off for this call. If this continuation of IFC evaluation results in another AS URI, the Oracle Communications Unified Session Manager initiates a request towards that AS this time with a new ODI. In this way, the ODI is a state-signifier of Service Point Triggers.

The process continues until IFC evaluation is completed. Below is an example of an IFC evaluation completing after two iterations.

This image depicts the OCUSM or OCCSM proceeding with iFC evaluation during a SIP call.

The iFC continues to be evaluated completely which may result in the INVITE being forwarded to additional ASs. At the conclusion of evaluating the iFC, the Oracle Communications Unified Session Manager checks if the target of the initial request is registered to itself, or not. If the UA is not registered locally the Oracle Communications Unified Session Manager forwards the request by regular means into the network. If the target UA is registered locally, the Oracle Communications Unified Session Manager proceeds to obtain iFCs for the target and begin iFC evaluation for the terminating side of the call.