Browse Prior Art Database

Optimization of geographical DRP for a SIP/SIMPLE presence application. Disclosure Number: IPCOM000174211D
Original Publication Date: 2008-Sep-01
Included in the Prior Art Database: 2008-Sep-01
Document File: 2 page(s) / 71K

Publishing Venue



SIP/SIMPLE presence application are based on a SIP request contains a SUBSCRIBE message, once the SIP dialog is created a SIP session is used to manage the subscription state. In geographical DRP (Disaster Recovery Plan) environment duplicating the SIP sessions for a failover is complicated and resource consuming therefore some application defines the DRP as service continually w/o the hot failover meaning the subscription will be recreated. In such environment, the SIP sessions is recreated on the local server however the remote party is not aware of the change and still maintains the old previous SIP session! This introduces a resource problem in the remote party. In the presence domain most of the subscriptions are mutual, meaning if instance A subscribes to B (A -> B) then instance B will be subscribed to A (B-> A). Based on this fact, the patent idea is to include in the new subscribe message (the SIP message originating in the DRP site after the failure in primary site) an additional flag that indicates that this SIP message is originating in the DRP site and it might replace an existing SIP session. The remote party (that will be aware of the DRP procedure) thus will be able to identify that the new SIP message is coming from the DRP site and will act accordingly

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Optimization of geographical DRP for a SIP /SIMPLE presence application.

SIP/SIMPLE presence applications use SIP session to manage the subscriptions, when user A subscribes on user B the presence server / SIP application and user A client each maintain a SIP session. Since the subscription is a long living object the client may not be aware of a failure on the server side. High availability of SIP services such as of the presence server are usually based on a replication of the valid SIP sessions. This is a valid and maybe a recommended solution for local cluster deployment, but this technique will not provide a valid solution for the geographical DRP (Disaster Recovery Plan). The explanation is that in the geographical distributed environment the WAN connectivity between the sites of the geographical DRP will not allow to replicate the SIP session in an efficient way.

Let's describe the problem and the proposed solution using the following example: Bob is an employee of Company A and is connected with his SIP collaboration software to Company A's cluster. Alice is employee of Company B and is connected with her SIP software client to Company B's SIP server. The SIP servers of Company A and the SIP servers of Company B are connected. On the Company A side there are two servers that are geographically distributed in order to provide an answer in case of Disaster. Bob and Alice add each other to their buddy lists; this will result in 2 subscriptions on each server. Each server will maintain inbound subscription (red arrow) that represents the subscription from the remote user and outbound subscription (blue arrow) that represents the subscription from the local user. Upon failure in Company A primary site (New York) the user will reconnect to the secondary site (Los Angeles). Then the outbound subscription will be recreated (gray arrow) , Since the company B server is not aware of the failure in the Company A primary site the original subscription ( red arrow ) is still exist although now it can be considered as obsolete. Moreover, the original Alice's subscription on Bob does no longer exist on Company A primary server. This subscription exists only on the Company B server therefore Alice will not be aware of the right status of Bob.

The problems as we describe above are:
(1) Upon failure of the Company A server, the remote server (Company B) will manage duplicate subscriptions which will consume twice the amount of memory and may affect badly the Company B servers availability.
(2) Upon failure of the Company A server the remote user (Alice) will not have proper awareness of...