General System Information

System Identification

Global system identification is used primarily by the Oracle® Enterprise Session Border Controller to identify itself to other systems and for general identification purposes.

Connection Timeouts

It is important to set administrative session timeouts on the Oracle® Enterprise Session Border Controller for security purposes. If you leave an active configuration session unattended, reconfiguration access is left open to anyone. By setting a connection timeout, only a short amount of time needs to elapse before the password is required for Oracle® Enterprise Session Border Controller access.

Timeouts determine the specified time period that must pass before an administrative connection is terminated. Any subsequent configuration activity can only be performed after logging in again to the Oracle® Enterprise Session Border Controller. The timeout parameter can be individually specified for SSH sessions and for console port sessions.

After the SSH timeout passes, the SSH session is disconnected. You must use your SSH program to log in to the Oracle® Enterprise Session Border Controller once again to perform any further configuration activity.

After the console timeout passes, the console session is disconnected. The current session ends and you are returned to the login prompt on the console connection into the Oracle® Enterprise Session Border Controller.

Cluster Member Graceful Shutdown

When it becomes necessary to temporarily remove an Oracle Communications Session Border Controller (OCSBC) from active service, and make it available only for administrative purposes, the user issues a set-system-state offline ACLI command. The OCSBC begins a graceful shutdown. The shutdown is graceful in that active calls and registrations are not affected, but new calls and registrations are rejected except as discussed below. When the user issues the command, the OCSBC goes into becoming offline mode. Once there are no active SIP sessions and no active SIP registrations in the system, the OCSBC transitions to offline mode. If the OCSBC is a member of a cluster, the offline status is communicated when the user issues the set-system-state offline command, and the OCSBC excludes the offline OCSBC in future endpoint (re)balancing algorithms.

The graceful shutdown procedure is limited only to SIP calls and registrations.

Detailed Description of Graceful Shutdowns with Active SIP Calls or Registrations

This is the procedure when active SIP calls or registrations are on an OCSBC.

When the system receives the set-system-state offline command, it transitions to becoming offline mode. It begins checking the number of SIP-INVITE-based sessions and the number of SIP registrations, and continues to check them when sessions complete or registrations expire while it is in becoming offline mode. When both counts reach zero, the system transitions to offline mode. If the system is a member of a Oracle Communications Subscriber-Aware Load Balancer (OCSLB) Cluster, the OCSLB client on the OCSBC changes its cluster status to the shutdown state, and informs the OCSLB that it is offline. The OCSLB ceases to forward new end-points to the OCSBC and lists the OCSBC in a shutdown state on the OCSLB. The OCSBC continues to send heartbeat updates to the OCSLB as before.

Active calls continue normally when the OCSBC is in becoming offline mode. If SIP refresh registrations arrive for endpoints that have active calls, they are accepted. However, the expiry of these endpoints is reduced to the configurable retry-after-upon-offline timer value (in seconds) defined under sip-config on the OCSBC. This timer should be configured to be a much lower time interval than originally requested by the refresh registrations, so that endpoints refresh sooner and thus the registrations expire as closely as possible to when the active call ends. If the new timer value configured in retry-after-upon-offline is greater than the existing registration requested refresh value, or if its value is ‘0’ (unconfigured), the original registration refresh request is honored.

Refresh registrations for endpoints that do not have any active calls are rejected with a configurable response code defined in the sip-config reg-reject-response-upon-offline parameter. The default for this parameter is the 503 Service Unavailable message. It includes a Retry-After header with a configurable timer set in retry-after-upon-offline. If the value of the configuration is 0 (unconfigured), the header is not included in the rejection message. Once these refreshes are rejected, OCSBC immediately removes such endpoints from its registration cache. It is a force remove. De-registrations are forwarded to the core. There is no local response. Removals are communicated to the OCSLB.

Any new calls that arrive for endpoints that currently have registration entries are not rejected. The same retry-after-upon-offline action is performed.

Any other SIP methods (like SUBSCRIBE or MESSAGE) intended for this endpoint is handled normally and are not rejected. Priority calls are processed as usual by the OCSBC, regardless of whether an active registration is present in the OCSBC as long as the OCSBC is in becoming offline state. When the OCSBC transitions to the offline state, even priority calls are rejected. If the priority calls cannot be forwarded to the endpoint, a 380 Alternative Service response may be sent, depending on the OCSBC's configuration. However, when the OCSBC achieves offline mode, even priority calls are rejected. New non-priority calls coming for endpoints that are not currently registered are rejected with the 503 Service Unavailable error message, as has always been done.

The OCSBC sends the endpoint removal requests to the OCSLB so that the OCSLB removes them from its endpoint table. If a REGISTER message comes in with multiple contacts, it’s possible that one of the contacts has an active call while others do not. In that scenario, the contact without active call has the Expires value in the Contact header changed to 0 and is forwarded to the core. When the response arrives from the core, the Contact with active call has its Expires parameter modified to the retry-after-upon-offline value or the UA expires value, whichever is lower. Any contact with no active calls is removed from the cache.

Eventually, all SIP calls end, and all registrations expire. The OCSBC transitions to the offline system state. The OCSBC continues to send heartbeat updates to the OCSLB.

At any time after the issuance of the set-system-state offline command, a set-system-state online command may be issued. If the OCSBC is in becoming offline mode, the process is aborted and the OCSBC again becomes online. The OCSBC state is forwarded to the OCSLB, and the OCSBC once again participates in the OCSLB's (re)balancing process.

High-level Procedure for Graceful OCSBC Shutdown

This section describes the graceful shutdown procedure. Details and exceptions to this procedure when there are active calls or registrations are discussed in later paragraphs. The first six actions are performed regardless of whether or not the OCSBC is part of an Oracle Communications Subscriber-Aware Load Balancer (OCSLB) Cluster

The OCSBC receives the set-system-state offline command.
The OCSBC transitions to becoming offline mode.
The OCSBC accepts calls and subscribes from registered endpoints.
The OCSBC rejects calls from non-registered endpoints.
The OCSBC rejects new registrations with a 503 Service Unavailable error message.
The OCSBC checks the number SIP INVITE based sessions and number of SIP registrations. When both counts are 0, the OCSBC transitions to the offline state.

Note:

Previous versions only looked at active SIP sessions (calls), without monitoring active SIP registrations.

If the OCSBC is part of an OCSLB Cluster:

The OCSLB client on the OCSBC changes its cluster status to shutdown state.
The OCSBC informs the OCSLB that it is offline.
The OCSLB ceases to forward new end-points to the OCSBC and puts the OCSBC in a shutdown state.
OCSLB continues to forward all messages for existing registered endpoints to the offline OCSBC.
The OCSBC continues to send heartbeat updates the OCSLB as before.