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

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 (Subscriber-Aware Load Balancer) Cluster, the Subscriber-Aware Load Balancer client on the SBC changes its cluster status to the shutdown state, and informs the SLB that it is offline. The Subscriber-Aware Load Balancer ceases to forward new end-points to the SBC and lists the SBC in a shutdown state on the SLB. The SBC continues to send heartbeat updates to the Subscriber-Aware Load Balancer as before.

Active calls continue normally when the SBC 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 SBC. 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, SBC 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 Subscriber-Aware Load Balancer.

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 SBC, regardless of whether an active registration is present in the SBC as long as the SBC is in becoming offline state. When the SBC 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 SBC's configuration. However, when the SBC 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 SBC sends the endpoint removal requests to the Subscriber-Aware Load Balancer so that the Subscriber-Aware Load Balancer 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 SBC transitions to the offline system state. The SBC continues to send heartbeat updates to the Subscriber-Aware Load Balancer.

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