Preserving an Original Dialog Indicator
As the Oracle Communications Unified Session Manager (OCUSM) works through dialogs with Application Servers (AS), it saves and uses the Original Dialog Indicator (ODI) parameter to manage a call's service subscription sequence. By default, the OCUSM deletes the in-memory Service Profile, including the ODI, on receiving a final response to a transaction with an AS. If you enable the preserve-odi parameter in the sip-config however, the OCUSM maintains the in-memory service profiles, and each associated ODI, until it receives the BYE from the AS that ends the dialog between them. This is a global configuration, causing the OCUSM to maintain all ODIs for the duration of the dialog.
If the OCUSM discards the ODI when it receives the transaction's final message, it may experience problems, for example, with AS processes that are in B2BUA mode. In this mode, the AS may send a 200OK response to the request originator before forwarding the INVITE to the terminating side. If the OCUSM receives a message from the AS using a discarded ODI, the OCUSM restarts and repeats the entire iFC evaluation process for the call. Configuring ODI preservation provides value in applicable environments by avoiding this extraneous processing.
Enabling ODI preservation uses system resources to store this information. Balance this impact on resources with the value of deploying this behavior in your environment.
Key OCUSM behavioral detail with respect to the preserve-odi configuration includes:
- Upon receipt of an ODI, the OCUSM continues with iFC evaluation from the point where it left off for this ODI, using the same trigger-set and route-set as used within the initial iFC evaluation.
- If the originating user cancels a call, each AS also generates CANCEL message for each INVITE. The OCUSM clears ODIs from its memory when it processes the CANCEL for each original INVITE.
- If the HSS updates the user's service profile during iFC evaluation for a particular request message, for example, if the HSS sends a PPR to the OCUSM with a modified iFC, the OCUSM continues the current call with the existing in-memory Service Profile and uses the updated user-profile for subsequent calls.
- if an AS tries to send multiple request messages re-using an ODI, the OCUSM rejects those request messages and send 403 Forbidden response to the AS. The OCUSM only accepts the first request message from the AS using the same ODI.
- If the OCUSM does not receive the BYE, it retains the ODI until the session timers expire.
- An active OCUSM provides the service profile for each call, including all associated ODIs to its standby, enabling further service modification on a per-ODI basis despite a failover. This backup process requires a final message, a 200 OK received from the AS. If a failover happens before the 200 OK, the standby does not save the ODI.
The diagram below illustrates the OCUSM iFC evaluation behavior when you enable this parameter. By default, the OCUSM removes the ODI after the transaction between the OCUSM and AS1 is complete. With the preserve-odi parameter enabled, however, the OCUSM retains the ODI until it receives the BYE from AS1, which terminates the dialog between the OCUSM and AS1. If there are ODIs tracking service with other AS servers, shown below as AS2, the OCUSM retains those until the dialogs between itself and those servers terminates.