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 SLB 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 SLB. 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.