Authentication Proxy The Authentication Proxy is a SIP application that upon

16-14 Oracle WebLogic Communications Server Administration Guide Presence server is collocated with a User Dispatcher each such callback would be within the same JVM.

16.3.3.2.2 Presence Application Broadcast Another solution is to have the Presence

servers guarantee that a user only exists on one Presence node at any given time. This can be done by having the Presence application broadcast a message to all its neighbors when it receives a PUBLISH or SUBSCRIBE for a new presentity a presentity that it does not already have a state for. If any other Presence node that receives this broadcast message already has active subscriptions for this presentity, that server must terminate that subscription so that the client can establish a new subscription with the new server. With this functionality in the Presence application, the User Dispatcher would not have to perform additional steps to migrate a user from one live node to another.

16.3.3.3 Standby Server Pool

Another approach is to have a standby pool of servers that are idling ready to take over traffic from a failing node. When an active node fails the User Dispatcher will redistribute all its traffic to one server from the standby pool. This node will now become active and when the failing node eventually is repaired it will be added to the standby pool. This will eliminate the need for migrating users “back” from a live node when a failing node resumes. This approach requires more hardware and the utilization of hardware resources will not be optimal.

16.3.3.4 Failure Types

There are several types of failures that can occur in a Presence server and different types of failures may require different actions from the User Dispatcher.

16.3.3.4.1 Fatal Failures If the failure is fatal all state information is lost and established

sessions will fail. However, depending on the failure response, subscriptions presence subscribe sessions can survive using a new SIP dialog. If the response code is a 481 the presence client must according to RFC 3265 establish a new SUBSCRIBE dialog and this is not considered to be a failure from a presence perspective. All other failure responses may depending on the client implementation be handled as an error by the client and should therefore be considered a failure. After a fatal failure the server does not have any dialog states from the time before the failure, which means that all subsequent requests that arrive at this point will receive a 481 response back. During the failure period all transactions both initial and subsequent will be terminated with a non-481 error code, most likely a 500 or an internal 503 or 408 depending on if there is a proxy in the route path or not, and what the nature of the failure is. Typically a fatal failure will result in the server process or the entire machine being restarted.

16.3.3.4.2 Temporary Failures A temporary failure is one where none or little data is lost

so that after the failure session states will remain in the server. This means that a subsequent request that arrives after the server has recovered from the failure will be processed with the same result, as it would have been before the failure. All requests that arrive during the failure period will be responded with a non-481 failure response, such as 503.