Methods, systems and computer readable media for providing a failover measure using watcher information (WINFO) architecture

Methods, systems, and computer readable media system for collecting and distributing session initiation protocol (SIP) event watcher entity subscription information in a communications network are disclosed. According to one aspect, the method includes receiving, at a first notifier server from a watcher entity client, a first subscription request for SIP event information associated with one or more watched entity clients. The method also includes receiving, at a watcher information (WINFO) entity, SIP event subscription information that includes an identifier indicating that the first notifier server serves the watcher entity client, storing the SIP event subscription information in the WINFO entity, detecting the unavailability of the first notifier server. The method further includes sending an instruction message, based on the identifier in the stored SIP event subscription information, to direct the watcher entity to generate a second subscription request associated for the SIP event information.

TECHNICAL FIELD

The subject matter described herein relates to session initiation protocol (SIP) event subscription and notification. More particularly, the subject matter described herein relates to systems, methods, and computer readable media for providing a failover measure using watcher information (WINFO) architecture.

BACKGROUND

A session initiation protocol (SIP) event notification system as disclosed in Request for Comments (RFC) 3265 includes a network architecture that permits SIP nodes to request notifications from remote nodes which indicate whether certain events (e.g., change in state information) have occurred in a given end node. Namely, SIP entities may subscribe to the state of a resource associated with a remote node (e.g., a watched subscriber or resource entity), and a notifier node/server associated with the remote node can send a notification if a state change occurs. For example, a SIP entity may send a SIP SUBSCRIBE message to request a SIP event subscription (e.g., a presence state subscription) to a notifier node that services the end node. A notifier node associated with the end node may then be configured to return the current state information (e.g., presence state information) of the node (and updates to the state information) up until the subscription expires. Notably, the SIP events model is a “soft state” model where subscriptions are not permanent and are configured to expire after a predefined amount of time and must be renewed by subsequent subscription (e.g., SIP SUBSCRIBE) messages.

In addition to providing SIP event information associated with watched subscribers or resources, a notifier node/server can also be adapted to provide watcher information (WINFO) to the watched subscriber or resource entity. Problems arise, however, in scenarios where multiple SIP event servers (e.g., presence state servers) are deployed to handle subscription request transactions related to a watched subscriber entity. Namely, responding to watcher information requests become difficult because there isn't a single SIP event server (e.g., a presence server) that has a complete view of all watcher entities that are subscribed to a particular watched entity. In short, multiple SIP event servers may be handling the subscription request transactions related to a single watched subscriber entity. This is particularly problematic because current specifications typically do not allow a watched subscriber entity to discover and contact the full set of servicing SIP event servers in order to acquire all of the watcher subscriber information associated with that requesting watched subscriber entity.

Due to the SIP event notification system's soft state model, other problems may arise in the event a notifier server fails. Any watcher subscriber serviced by the failed notifier server will not know that the notifier server is unavailable and therefore will be unable to receive any SIP event updates (e.g., presence state updates) until the watcher subscriber's SIP event subscription expires. This problematic situation is difficult to detect, especially if it is not unusual for the watcher subscriber to not receive SIP event update messages because the watched entity's status typically does not change. Thus, the problem may continue undetected by the watcher entity for the length of the SIP event subscription. Moreover, even if the watcher subscriber detects the problem and refreshes the subscription, a re-subscribe message may be needlessly sent to the failed notifier server.

Accordingly, there exists a need for improved methods, systems, and computer readable media for providing a failover measure using watcher information (WINFO) architecture.

SUMMARY

According to one aspect, the subject matter described herein includes a system for providing a failover measure using watcher information

(WINFO) architecture. In one embodiment, the method includes receiving, at a first notifier server from a watcher entity client, a first subscription request for SIP event information associated with one or more watched entity clients. The method also includes receiving, at a watcher information (WINFO) entity, SIP event subscription information that includes an identifier indicating that the first notifier server serves the watcher entity client, storing the SIP event subscription information in the WINFO entity, detecting the unavailability of the first notifier server. The method further includes sending an instruction message, based on the identifier in the stored SIP event subscription information, to direct the watcher entity to generate a second subscription request associated for the SIP event information.

DETAILED DESCRIPTION

FIG. 1depicts an exemplary communications network100that facilitates the failover of SIP notifier servers using a watcher information

(WINFO) architecture. In one embodiment, communications network100may include watcher entity clients101-102, watched entity clients103-105, a plurality of notifier servers (e.g., resource list servers107-109), a watcher information (WINFO) server110, and a plurality of SIP event servers111-117. In general, watcher information (WINFO) server110is configured to collect SIP event subscription information from the plurality of notifier servers, such as resource list servers107-109. Similarly, each of RLS servers107-109may be configured to interface with a common event server or a pool of event servers, such as SIP event servers111-117. In one embodiment as shown inFIG. 1, SIP event servers111-117may be presence state service servers, which are responsible for receiving and maintaining presence state information associated with watched entities clients103-105. Although the present subject matter primarily uses presence service as an exemplary SIP event service, other SIP event services may be handled in a similar fashion by communications network100without departing from the scope of the present subject matter. Other SIP event subscription services may include presence subscription service, dialog subscription service, voice mail subscription information, automatic callback subscription service, PSTN and Internet Internetworking (PINT) subscription service, conference state information, cryptographic certificates, pending consent information, http resource information, keypad markup language information, push-to-talk settings, registration state information, REFER operation progress information, policy documents, intelligent networking (IN) detection point information, user agent profile information, media statistics information, XCAP document change information, or any other event packages as that term is defined by RFC3625and its successor documents (if any).

In one embodiment, each of watcher entity client101and a watcher entity client102may comprise a computer, mobile device, or similar client machine configured to run a user agent or client software program, function, or module for accessing network servers. In one embodiment, watcher entity client101is associated with a watcher subscriber entity (e.g., watcher subscriber entity D) and is configured to create and send SIP SUBSCRIBE requests to a notifier server entity (e.g., a resource list server or a SIP event server, depending on the embodiment). The SIP SUBSCRIBE requests are subscription messages that request a SIP event subscription for change in state notifications related to one or more watched entities. In one embodiment, the SIP event subscriptions may include presence state service subscriptions (e.g., a SIP request to add a watched subscriber entity to a watcher subscriber entity's “buddy list”). In a SIP event notification architecture, these subscription requests require approval from watched entity clients. As shown inFIG. 1, a watcher entity client (e.g., client101) may have a direct association or connection to a SIP event server (e.g., event server113). It should also be noted that network100may include watcher clients that are subscribed to RLSs and SIP event servers, concurrently.

Similarly, each of watched entity client103, watched entity client104, and watched entity client105may comprise a computer, mobile device, or similar client machine configured to run a user agent or client software program, function, or module for accessing network servers. In one embodiment, watched entity client103is associated with a watched subscriber entity (e.g., watched subscriber A) and is configured to provide SIP event information (e.g., presence state information and updates) to a designated SIP event server113(e.g., presence server). Although not explicitly shown inFIG. 1, watched entity client103may be configured to send to a notifier server (e.g., RLS107) SIP messages that request watcher entity information associated with watched entity A (e.g., watched entity client103requests a list of watcher entities that are either receiving the presence state information related to watched entity A or have requested to subscribe to watched entity A's presence information).

FIG. 1also depicts a plurality of SIP event servers111-117. As shown inFIG. 1, each of SIP event servers111-117may be communicatively coupled to an RLS server. In one embodiment, a SIP event server may be a presence server that is configured to collect and manage the presence state information of a watched subscriber entity and provide current presence state information and present state updates to one or more RLSs. In an alternate embodiment, communications network100may not employ RLSs107-109. In such a case, SIP event servers111-117may function as notifier servers and directly communicate with watcher and watched entities. SIP event servers111-117may also be configured to provide watcher entity subscription information to WINFO server110when RLS servers are not employed in network100.

In one embodiment, SIP event servers111-117collect SIP event state data from a plurality of watched subscriber or resource entities (e.g., watched entities103-105). In one embodiment, a SIP event server may be a presence server that receives presence state information from one or more watched entities. For example, watched entity103may provide presence state information by publishing its current presence state using a status string and providing this information to SIP event server113(which in this case is a presence service server). In response to receiving the presence state information, SIP event server113may serve a “presence state document” to presence subscribers (i.e., watcher entities) of watched subscriber entity103or to RLSs. Presence server103is also configured to receive XML based presence rules from watched subscriber entity A. In one embodiment, SIP event server113maintains a set of presence rules for each subscription to each resource device. For example, the presence rules associated with watched subscriber entity103may be modified such that a unique set of presence rules may exist for each of the watcher entities of watched subscriber entity A. For example, subscription refresh rules and/or the type of presence state information provided to one watcher entity client may differ from what is provided to a second watcher entity client. Moreover, a presence server may also be configured to receive publication information from different presence sources associated with the same watched subscriber entity. For example, presence server113may receive presence state updates related to watched subscriber A's client devices in the form of GPS location data, a text string, or a Web server connected to a calendar.

In one embodiment, a SIP event server such as a presence server may be configured to detect the failure of any other presence server in network100. For example, referring briefly toFIG. 9(more details below), a first presence server701and presence server703may be designated mates that communicate ping messages or are connected by a proprietary bus to periodically monitor the availability of the other presence server. Upon detecting the failure (e.g., failed presence server is congested, unreachable, taken out of service, etc.) of presence server703, presence server701may transmit a message to a WINFO server that requests the active subscription information for presence server703. The active subscription information includes SIP event state subscriptions that were previously serviced by presence server703. The WINFO server may respond to the request from presence server701by sending a message containing the necessary SIP event subscription state information that was managed by failed presence server703. After receiving the requested SIP event subscription state information, presence server701contacts the watcher entity subscribers (e.g., watcher client102) that were being served by presence server703by sending an instruction message causing these former presence server703subscribers to re-subscribe. In one embodiment, the instruction message includes a SIP terminate presence subscription message that lists the watched subscribers for which a new SIP event subscription needs to be sent. The contacted watcher entity clients (e.g., watcher client102) then contacts a DNS server to obtain the serving presence server address information. The DNS server then points the watcher subscribers to a designated RLS server. In one embodiment, when the watcher entity client wishes to contact a SIP entity using its DNS name, the watcher entity client performs a three step/level lookup (i.e., a first step for DNS NAPTER records, a second step for DNS SRV records, and a third step for DNS A or AAAA records). The result obtained in the second step includes a list of servers which enables the watcher entity client to contact the presence servers in a particular order until a connection is made. Thus, presence server701may be contacted despite the failed state of presence server703. In yet another embodiment, the re-subscription attempt may traverse a proxy. The proxy may have up-to-date information regarding which SIP event servers are currently online so that the proxy is capable of directing the subscription to an appropriate (online) event server according to its own internal logic. Please note that although depicted as such inFIG. 9, the presence server that detects the failed presence server is not required to be the designated failover presence server.

FIG. 1also depicts a plurality of resource list servers (RLSs)107-109that function as notifier server entities in communications network100. Although only three RLSs are depicted inFIG. 1, any number of RLSs may be employed without departing from the scope of the present subject matter. In an alternate embodiment, network100may also utilize zero RLS entities and instead only employ presence servers. In one embodiment, RLS107functions as a notifier server in communications network100that receives SIP SUBSCRIBE requests sent by one or more watcher entity clients, e.g., watcher client101. Similarly, RLS107may also generate SIP NOTIFY messages for the purpose of informing watcher entity client101or any other watcher subscriber or resource entity of the state (or change in state) of a watched resource (e.g., the current presence state of a watched subscriber entity).

Typically, a resource list server (RLS) is used to store a list of watched subscriber or resource entities in which a watcher entity is interested in knowing “change in state” information. For example, an associated watcher entity client may create a resource list (e.g., a buddy list) of watched entities that is stored in an RLS. The watcher entity client may then subscribe to the list in order to obtain SIP event information (e.g., presence state information) and updates regarding the watched subscribers on the list. Upon receiving the resource list from the watcher client, the RLS attempts to acquire the SIP event information by communicating with the SIP event servers that maintain the requested SIP event information. After obtaining the SIP event information, the RLS sends a SIP NOTIFY message to the watcher entities with the current SIP event states of the different watched entities. Also, prior to the SIP event subscription expiring, an RLS may also be configured to send SIP event state updates to the watcher entities after the RLS receives the updates from the event servers. In the present subject matter, however, an RLS may be used to provide SIP event subscription information to WINFO server110. The RLS creates the SIP event subscription information from receiving subscription requests from watcher entities requesting a subscription to change in state information pertaining to one or more watched entities. An RLS server may also be configured to request watcher entity subscription information on behalf of a requesting watched entity. For example, RLS107may receive a request for watcher information from a watched entity client103associated with a watched subscriber A. RLS107may then subsequently forward that request to WINFO server110.

In one embodiment, an RLS may be configured to detect the failure of any other RLS in network100. For example, referring briefly toFIG. 5(more details below), RLS107and RLS109may be designated mates that communicate ping messages or are connected by a proprietary bus to periodically monitor the availability of the other RLS. Upon detecting the failure (e.g., failed RLS is congested, unreachable, taken out of service, etc.) of RLS109, RLS107may transmit a message to a WINFO server that requests the active subscription information for RLS109. The active subscription information includes SIP event state subscriptions that were previously serviced by RLS109. The WINFO server may respond to the request from RLS107by sending a message containing the necessary SIP event subscription state information that was managed by failed RLS109. After receiving the requested SIP event subscription state information, RLS107contacts the watcher entity subscribers (e.g., watcher client102) that were being served by RLS109by sending an instruction message causing these former RLS109subscribers to re-subscribe. In one embodiment, the instruction message includes a SIP terminate presence subscription message that lists the watched subscribers for which a new SIP event subscription needs to be sent. The contacted watcher entity clients (e.g., watcher client102) then contacts a DNS server to obtain the serving RLS address information. The DNS server then points the watcher subscribers to a designated RLS server. In yet another embodiment, the re-subscription attempt may traverse a proxy. The proxy may have up-to-date information regarding which SIP event servers are currently online so that the proxy is capable of directing the subscription to an appropriate (online) event server according to its own internal logic. Please note that although depicted as such inFIG. 5, the presence server that detects the failed presence server is not required to be the designated failover presence server.

In one embodiment, watcher information (WINFO) server110is a designated server, network element, or node that is configured to receive SIP event subscription information from notifier servers, such as an RLS or SIP event server depending on the embodiment. Notably, the SIP event subscription information is generated by an RLS or SIP event server and may include which watcher entities are subscribed to, or have requested a subscription to, the SIP event information and updates pertaining to one or more watched entities. In one embodiment, the SIP event subscription information communicated to WINFO server110includes watcher entity identifiers, watched subscriber entity identifiers, subscription details, and other information that identifies the sending notifier server. Upon receipt, WINFO server110provisions a database118with the communicated SIP event subscription information.

WINFO server110may also be configured to manage and distribute a specific portion of the SIP event subscription information (as watcher entity subscription information) to requesting watched entities. Specifically, after being provisioned with the SIP event subscription information, WINFO server110may receive requests for watcher entity identification information from watched entities via an RLS server. For example, RLS server107receives requests for watcher information from a watched subscriber entity. RLS server107then forwards the watcher entity information request from the watched subscriber entity to WINFO server110(which is authoritative for the requesting subscriber).

In one embodiment, watcher information (WINFO) server110may be configured to handle WINFO SIP metadata event packages. A WINFO event package allows a watched entity client (e.g., watched entity client103) associated with a watched subscriber (e.g., watched subscriber A) to subscribe and obtain watcher entity subscription information that identifies one or more watcher entities that are subscribed to receive (or have made a request to receive) the watched subscriber's presence information. Notably, a WINFO event package or “WINFO document” is created and sent to the requesting watched entity client so as to notify the associated watched subscriber of the watcher entities that are subscribed to the presence state information related to the watched subscriber entity or attempting to add that watched subscriber entity to a buddy list. In one embodiment, the WINFO document includes a list of subscribed watcher entities and further indicates 1) which watcher entities are presently “online” and/or have associated watcher entity clients running, 2) a list of watcher entities that have issued a subscription request to the watched subscriber entity's presence information, 3) the amount of time remaining for all outstanding presence state subscriptions, 4) and a list of all SIP event subscriptions that are currently in a pending state (i.e., not approved).

In one embodiment, the WINFO server is configured to receive messages from a notifier server (e.g., an RLS or SIP event server) that requests active SIP event subscription information for a detected failed notifier server. The WINFO server may be similarly configured to access its database in order to obtain the active SIP event subscription information of the failed notifier server and subsequently provide the SIP event subscription information to the requesting notifier server in a SIP based response message. In one embodiment, the WINFO server may be configured to detect the failure of a notifier server in network100, rather than a notifier server that has been previously designated as a mate to the failed notifier server. As such, the WINFO server may also be configured (instead of the designated failover notifier server) to send a terminate presence subscription message to the identified watcher subscribers formerly serviced by the failed notifier server.

The advantage of using a WINFO server in a communications network is that subscription permissions may be eased. Furthermore, the use of different overload queuing techniques may be employed since the amount of subscription traffic at the WINFO server is considerably smaller as compared to a SIP event server (e.g., only the watched entity will be subscribing to a WINFO server for watcher information that is associated with the requesting watched subscriber). Furthermore, the logic associated with accepting and enforcing subscriptions may be generated and supported with greater ease. AlthoughFIG. 1only depicts a single WINFO server110that is authoritative of watched entities103-105, additional WINFO servers authoritative of additional watched entities may be utilized in communications network100without departing from the scope of the present subject matter.

FIG. 2is a flow chart illustrating an exemplary method200for providing a failover measure in a communications network that includes a plurality of notifier servers according to an embodiment of the subject matter described herein. In block202, event servers are provisioned with SIP event status information from one or more clients associated with watched entities. In one embodiment, the SIP event servers may include presence service servers, each of which is provisioned with presence status information from the plurality of watched subscriber entities over a period of time. In one embodiment, a presence server receives presence information when the client of a watched subscriber entity publishes its current state with a status string.

In block204, a subscription request for SIP event information associated with one or more watched entities is received at a notifier server, such as an RLS, or alternatively, a presence server if an RLS is not utilized in the network. In one embodiment, an RLS server may receive a presence service subscription request message from a client associated with a watcher entity. For example,FIG. 3depicts a signaling diagram in which watcher entity client101sends a presence service subscription request message (i.e., a SUBSCRIBE message) to RLS107. Namely, the presence service subscription request message sent to RLS107indicates that watcher entity client101wants to subscribe to presence status information for watched entities A and C. In one embodiment, the SUBSCRIBE message includes a list of identifiers associated with watched entities A and C. Similarly,FIG. 3also depicts a watcher entity client102that sends, to RLS109, a presence service subscription request message (i.e., a SUBSCRIBE message) for subscribing to presence status information for watched entities A and B.FIG. 3also shows RLS107replying to the SUBSCRIBE message with a NOTIFY message, which indicates the presence status of watched entities A and C. RLS107may send the NOTIFY message to watcher entity client101if RLS107already has the current present state information for watched entities A and C stored locally. Otherwise, RLS107may either obtain the presence state information from the appropriate presence servers (e.g., by issuing backend presence service subscription requests) or may collect derive the presence data in the same manner as a presence server.

Returning toFIG. 2, in block206, SIP event subscription information associated with the subscription request is received at a WINFO server. In one embodiment, a WINFO server110receives presence subscription information associated with a subscription request previously sent to RLS107. For example,FIG. 4depicts RLS107communicating presence subscription information to WINFO server110, which may be authoritative for watcher entity A. AlthoughFIG. 4depicts an RLS107sending a SIP PUBLISH message to communicate the presence subscription information, it should be understood that any other similar mechanism or message may be utilized without departing from the scope of the present subject matter. Specifically,FIG. 4illustrates that the presence subscription information received by WINFO server110includes a watcher entity identifier (for watcher entity D), a watched entity identifier (for watched subscriber A), and subscription details. In one embodiment, the subscription details may include the SIP subscription dialog information (e.g., To and From header field values including tags, Call-ID, remote and local CSeq values, remote and local Contact values, and route-set), the current subscription status, the most recent event affecting the subscription status, and the remaining subscription duration. Similarly,FIG. 4also depicts RLS109communicating a SIP PUBLISH message that includes a second set of presence subscription information to WINFO server110. Specifically, the presence subscription information from RLS109is shown to include a watcher entity identifier (for watcher entity E), watched entity identifier (for watched entity A), and subscription details. Notably,FIG. 4shows that WINFO server110may receive presence service subscription information related to watched subscriber entity A from more than one notifier server source (e.g., an RLS or SIP event server).

Returning toFIG. 2, in block208, the SIP event subscription information is stored in a WINFO server. In one embodiment, the presence service subscription information received by WINFO server110is stored in a database118(as shown inFIG. 1). For example, an exemplary database118may include a column that contains watched entity identifiers (i.e., watched subscriber identifiers), a column that includes watcher entity identifiers (i.e., watcher subscriber identifiers), and a column includes identifiers corresponding to the RLSs serving the respective watcher entities. Although only three columns are described, additional columns may be included in database118without departing from the scope of the present subject matter. Notably, the SIP event subscription information stored in the WINFO server includes sufficient information to know what SIP event subscriptions a notifier server is serving, but not enough information for a failover notifier server to resume the session. For example, the stored information is established at the beginning of the subscription, and is invariant for the duration of the subscription. Thus, this information only needs to be sent once (at the beginning of the subscription), and removed once at the end of the session. The information necessary to resume a session would require data replication for every SIP message that is sent or received for that subscription. Thus, the volume of replication data to accomplish this is not feasible. However, by maintaining the amount of information proposed by the present subject matter, the WINFO server is permitted to send subscription termination messages.

Returning toFIG. 2, in block210, the unavailability of a first notifier server is detected. In one embodiment, a first notifier becomes unavailable (e.g., by failing, becomes congested, becomes unreachable, or taken out of service). The unavailability condition is subsequently detected by another notifier server (e.g., a designated notifier server mate) or a WINFO server in network100. For example, inFIG. 5, RLS109fails and becomes unavailable to communicate with any other network element. RLS107(or any other RLS that may be designated as a notifier server mate) subsequently detects the unavailability of RLS109. RLS107may be configured to detect RLS109as being unavailable by any manner, such as a failed ping messages, a notification message sent by WINFO server110to RLS107, or via a proprietary bus connecting the RLSs. In an alternate embodiment, WINFO server110may be configured to detect the failure of an RLS (such as RLS109) as shown inFIG. 6. In one embodiment, a detection module may be configured to detect the unavailability of the first notifier server. The detection module may reside in or be co-located with a second notifier server (e.g., an RLS or presence server). In another embodiment, the detection module may be a stand-alone network entity or element.

Returning toFIG. 2, in block212, SIP event subscription information associated with an unavailable first notifier server is sent to a designated failover notifier server. The designated failover notifier server may be the notifier server designated as the detecting server or any other RLS server in network100. As shown inFIG. 5, RLS107obtains SIP event subscription information from WINFO server110for the subscriptions that were previously serviced by failed RLS109. In one embodiment, RLS107initiates contact with WINFO server110and requests the SIP event subscription information associated with failed RLS109. WINFO server110may respond to the request from RLS107with the necessary SIP event state information. In this embodiment, the SIP event subscription information includes presence subscription state information that was managed by RLS109. For example, WINFO server110may access database118(as shown inFIG. 1) to locate stored watcher entity subscription information that was handled by RLS109. WINFO server110may then query database118in order to obtain an identifier for each of the watcher entities that were serviced by unavailable RLS109. Notably, block212is an optional step (i.e., not necessary) if WINFO server110is instead configured to send a terminate subscription message directly to the watcher entity.

Returning toFIG. 2, in block214, instructions are sent to watcher entities associated with the unavailable first notifier server. The sent instructions direct the watcher entities to send a new subscription request to a failover notifier server. In one embodiment, as shown inFIG. 5, WINFO110contacts the watcher entity clients that were formerly serviced by RLS109, such as watcher entity client102. For example, RLS107sends a message (e.g., a SIP-based terminate presence subscription message) that instructs watcher entity client102to terminate current presence subscriptions formerly serviced by RLS109(e.g., watched subscribers A and B) and to send a new subscription message in order to re-subscribe for presence information associated with watched subscriber entities A and B. When the watcher entities contact a DNS server to obtain the serving RLS address information, the DNS server points the watcher entities to a new RLS, e.g., RLS107. Please note that althoughFIG. 5shows that RLS107detected the unavailability of RLS109as well as being designated as the new serving (i.e., failover) RLS, this is not required and is only one exemplary illustration of the present subject matter. For example, RLS108could have been designated as the RLS responsible for detecting the unavailability of RLS109with RLS107still being the designated failover notifier server (and vice versa). In one embodiment, the detector module may be configured to send the instructions to direct the watcher entities to send a new subscription request to a failover notifier server. As mentioned above, the detector module may reside in or be co-located with a second notifier server (e.g., an RLS or presence server). In another embodiment, the detector module may be a stand-alone network entity or element.

In an alternate embodiment, the detection of failed RLS109(block210) and the sending of instruction messages to watcher entity client102(block214) may be performed by WINFO server110itself instead of the failover RLS107. For example,FIG. 6depicts RLS109failing and thereby becoming unavailable to communicate with any other network element. WINFO server110subsequently detects the unavailability of RLS109. WINFO server110may be configured to detect RLS109as being unavailable by any manner, such as a failed ping messages or via a proprietary bus connecting the RLS with the WINFO server. WINFO110then determines and contacts the watcher entity clients that were formerly serviced by RLS109, such as watcher entity client102, by accessing database118. For example, WINFO110subsequently sends a message (e.g., a SIP-based terminate presence subscription message) that instructs watcher entity client102to terminate its current presence subscriptions formerly serviced by RLS109(e.g., watched subscribers A and B) and to send a new subscription message in order to re-subscribe for presence information associated with watched subscriber entities A and B. When watcher entity client102contacts a DNS server in order to obtain the serving RLS address information, the DNS server points the watcher entity client102to a new failover RLS, e.g., RLS107. Please note that althoughFIG. 6shows that RLS107detected the unavailability of RLS109as well as being designated as the new serving (i.e., failover) RLS, this is not required and is only one exemplary illustration of the present subject matter. For example, RLS108could have been designated as the RLS responsible for detecting the unavailability of RLS109with RLS107still being the designated failover notifier server (and vice versa).

As mentioned above with regard to at least one embodiment, communications network100may employ notifier servers that include presence servers instead of utilizing RLSs. For example,FIG. 7depicts a signaling diagram in which watcher entity client101sends a presence service subscription request message (i.e., a SUBSCRIBE message) to presence server701. Namely, the presence service subscription request message sent to presence server701indicates that watcher entity client101wants to subscribe to presence status information for watched entity A. In one embodiment, the SUBSCRIBE message includes an identifier associated with watched entity A. Similarly,FIG. 7also depicts a watcher entity client102that sends, to RLS703, a presence service subscription request message (i.e., a SUBSCRIBE message) for subscribing to presence status information for watched entity A.FIG. 7also shows presence server701replying to the SUBSCRIBE message using a NOTIFY message, which indicates the presence status of watched entity A.

FIG. 8depicts presence server701communicating presence subscription information to WINFO server110, which may be authoritative for watched entity A. AlthoughFIG. 8depicts presence server701sending a SIP PUBLISH message to communicate the presence subscription information, it should be understood that any other similar mechanism or message may be utilized without departing from the scope of the present subject matter. Specifically,FIG. 8illustrates that the presence subscription information received by WINFO server110includes a watcher entity identifier (for watcher entity D), a watched entity identifier (for watched subscriber A), and subscription details. Similarly,FIG. 8also depicts presence server703communicating a SIP PUBLISH message that includes second set of presence subscription information to WINFO server110. Specifically, the presence subscription information from presence server703is shown to include a watcher entity identifier (for watcher entity E), watched entity identifier (for watched entity A), and subscription details. Notably,FIG. 8depicts that WINFO server110may receive presence service subscription information related to watched subscriber entity A from more than one notifier server source (e.g., a presence server).

FIG. 9depicts presence server701obtains SIP event subscription information from WINFO server110for the subscriptions that were previously serviced by failed presence server703. In one embodiment, presence server701initiates contact with WINFO server110and requests the presence state subscription information associated with failed presence server703. WINFO server110may respond to the request from presence server701with the necessary presence state information. In this embodiment, the presence state subscription information was managed by presence server703. For example, WINFO server110may access database118(as shown inFIG. 1) to locate stored watcher entity subscription information that was handled by presence server703. WINFO server110may then query database118in order to obtain an identifier for each of the watcher entities that were serviced by unavailable presence server703.

In an alternate embodiment, the detection of failed presence server703(block210) and the sending of instruction messages to watcher entity client102(block214) may be performed by WINFO server110itself instead of the failover presence server701. For example,FIG. 6depicts presence server703failing and thereby becoming unavailable to communicate with any other network element. WINFO server110subsequently detects the unavailability of presence server703. WINFO server110may be configured to detect presence server703as being unavailable by any manner, such as a failed ping messages or via a proprietary bus connecting the presence server with the WINFO server. WINFO110then determines and contacts the watcher entity clients that were formerly serviced by presence server703, such as watcher entity client102, by accessing database118. For example, WINFO110subsequently sends a message (e.g., a SIP-based terminate presence subscription message) that instructs watcher entity client102to terminate its current presence subscriptions formerly serviced by presence server703(e.g., watched subscriber A) and to send a new subscription message in order to re-subscribe for presence information associated with watched subscriber entity A. When watcher entity client102contacts a DNS server in order to obtain the serving presence server address information, the DNS server points the watcher entity client102to a new failover presence server, e.g., presence server701. Please note that althoughFIG. 9shows that presence server701detected the unavailability of presence server703as well as being designated as the new serving (i.e., failover) presence server, this is not required and is only one exemplary illustration of the present subject matter. For example, presence server702could have been designated as the presence server responsible for detecting the unavailability of presence server703with presence server701still being the designated failover notifier server (and vice versa).

It will be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation.