Abstract:
Disclosed are methods, systems, and computer program products for notifying a Session Initiation Protocol (SIP) entity of a fast switchover event. According to one method a first SIP entity having an active host and a standby host is provided. At the active host a SUBSCRIBE message is received from a second SIP entity for subscribing to a fast switchover notification service. The standby host is switched to an active mode. In response to switching the standby host to active mode, a NOTIFY message is sent to the second SIP entity for notifying the second SIP entity that the standby host is operating in active mode.

Description:
TECHNICAL FIELD 
     The subject matter described herein relates to session initiation protocol (SIP) service in a communications network. More particularly, the subject matter described herein relates to methods, systems, and computer program products for a subscription-based SIP fast switchover. 
     BACKGROUND ART 
     Telecommunications systems have historically provided redundant load carrying capacity by maintaining multiple units at certain points within the network system. These multiple units have often been configured such that one unit operates as an active unit and the second unit operates as an active standby unit. The active unit and the active standby unit (hereinafter, standby unit) have traditionally been provisioned identically. The active unit traditionally carries the primary load and the standby unit becomes available to carry the load in the event the active unit fails or is taken off line for any reason. 
     The transition of the load from the active unit to the standby unit has historically created many problems with a loss of active calls. There is also a large amount of overhead associated with a load switch from the active to the standby unit. This overhead is in the form of inter-unit and intra-system messaging and communication. In order to minimize the impact of a load transition, the active unit periodically forwards updates of primary active load information to the standby unit. In this way, the standby unit is maintained in a ready state, prepared to carry the load of the active unit at any moment with minimal load loss. 
     For example, as shown in  FIG. 1 , a telecommunications subsystem  100  is shown. Within telecommunications subsystem  100  is a SIP entity  101  having an active SIP host  102  and standby SIP host  104 . Active SIP host  102  and standby SIP host  104  are connected to each other through Internet protocol (IP) network  106 . Also connected to IP network  106  are media gateway/media gateway controller (MG/MGC)  108  and MG/MGC  110 . 
     Each MG/MGC  108  and MG/MGC  110  may maintain state information for SIP dialogs for calls in progress or being initiated to or from subscriber terminals  112  and  114  that are connected to each MG/MGC. According to IETF RFC 3261, a SIP dialog represents a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog facilitates sequencing of messages between the user agents and proper routing of requests between both of them. The dialog represents a context in which to interpret SIP messages. Since each MG/MGC may maintain many dialogs, for example, thousands or tens of thousands of dialogs, switching from an active host to a standby host may require multiple messages to be sent to peer SIP entities. 
     In one implementation, if active SIP host  102  were to fail and standby SIP host  104  were to attempt to transition the load from active SIP host  102 , the following message sequence for each dialog maintained by each SIP peer would be required. In order for each dialog maintained by MG/MGC  108  to have the proper IP address of the standby SIP host  104  associated with it, the standby SIP host  104  would need to send an INVITE message  116  to MG/MGC  108  for each dialog associated between MG/MGC  108  and active SIP host  102 . For each INVITE message, MG/MGC  108  would send a 200 OK message  118  to standby SIP host  104 . Standby SIP host  104  would then respond with an acknowledgement (ACK) message  120  for each SIP dialog. 
     As discussed above, each MGC may maintain thousands of dialogs. With the above described message sequence of INVITE message  116 , 200 OK message  118  and ACK message  120 , this correlates to thousands of messages for each MGC for every switchover event from active SIP host  102  to standby host  104 . This overhead may result in lost calls due to the time required to send this many messages while attempting to transition all of the dialogs to the IP address of the new standby SIP host  104 . 
     Accordingly, in light of these difficulties and performance problems associated with transitioning between active and standby SIP hosts, there exists a need for improved methods, systems, and computer program products for managing a switchover event. 
     SUMMARY 
     According to one aspect, the subject matter described herein comprises methods, systems, and computer program products for notifying a Session Initiation Protocol (SIP) entity of a fast switchover event. One method includes providing a first SIP entity having an active host and a standby host, receiving at the active host a SUBSCRIBE message from a second SIP entity for subscribing to a fast switchover notification service, switching the standby host to an active mode, and in response to switching the standby host to active mode, sending a NOTIFY message to the second SIP entity for notifying the second SIP entity that the standby host is operating in active mode. 
     The subject matter described herein providing SIP fast switchover may be implemented using a computer program product comprising computer executable instructions embodied in a computer readable medium. Exemplary computer readable media suitable for implementing the subject matter described herein includes disk memory devices, programmable logic devices, and application specific integrated circuits. In addition, a computer readable medium that implements the subject matter described herein may be distributed across multiple physical devices and/or computing platforms. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Preferred embodiments of the subject matter described herein will now be explained with reference to the accompanying drawings, of which: 
         FIG. 1  is a block diagram of an exemplary telecommunications subsystem; 
         FIG. 2  is a block diagram of a system for subscription-based switchover between active and standby SIP hosts according to an embodiment of the subject matter described herein; 
         FIG. 3A  is a flow chart of an active host entity subscription process according to an embodiment of the subject matter described herein; 
         FIG. 3B  is a flow chart of an active host entity notification process according to an embodiment of the subject matter described herein; 
         FIG. 4A  is a flow chart of an MGC subscription process according to an embodiment of the subject matter described herein; and 
         FIG. 4B  is a flow chart of an MGC notification process according to an embodiment of the subject matter described herein. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       FIG. 2  shows an exemplary telecommunications subsystem  200 . Within telecommunications subsystem  200  is IP network  106 , a SIP entity  201  having an active SIP host  202  and a standby SIP host  204 , media gateway controllers  208  and  209 , media gateways  210  and  211 , and subscriber terminals  112  and  114 . Active SIP host  202  and standby SIP host  204  may implement a SIP protocol function. For example, active SIP host  202  and standby SIP host  204  may each implement a SIP proxy server, redirect server, user agent, or other SIP protocol function. 
     Media gateway controllers  208  and  209  may also include SIP functionality. For example, media gateway controllers  208  and  209  may implement SIP proxy server, redirect server, and/or user agent functionality. Media gateways  210  and  211  may control media stream connections to and from subscriber terminals  112  and  114 . An exemplary commercially available media gateway/media gateway controller architecture suitable for implementing components  208  through  211  illustrated in  FIG. 2  is the T9000 architecture available from Tekelec of Morrisville, N.C. An exemplary commercially available system on which active and standby SIP host  202  and  204  may be implemented is the T3000 platform also available from Tekelec of Morrisville, N.C. 
     Media gateway controllers  208  and  209  are each capable of subscribing to a notification mechanism by which active SIP host  202  and standby SIP host  204  provide notification to MGCs  208  and  209  in the event of a switchover from active SIP host  202  to standby SIP host  204 . 
     One exemplary SIP fast switchover (SIP FS) notification process of telecommunications subsystem  200  may be initiated by MGC  208  sending a SUBSCRIBE message  212  to active SIP host  202 . SUBSCRIBE message  212  includes information identifying MGC  208 , including the internet protocol (IP) address of MGC  208 , so that MGC  208  can be notified in the event of a switchover from active SIP host  202  to standby SIP host  204 . Active SIP host  202  responds to the SUBSCRIBE message  212  with an acknowledgement (200 OK)  214  message to MGC  208 . Alternatively, active SIP host  202  could respond to SUBSCRIBE message  212  with a reject message or a 503 (not allowed) message. These are not depicted in  FIG. 2 . 
     Active SIP host  202  and standby SIP host  204  may have a storage medium  216  for storing information related to subscribed MGCs. This information includes the IP address of subscribed MGCs. Upon receipt of SUBSCRIBE message  212 , active SIP host  202  may create an entry using the information included within SUBSCRIBE message  212  in storage medium  216 . This entry can be used to identify MGC  208  as being subscribed to a SIP FS notification mechanism. Active SIP host  202  may then send SUBSCRIBE message  212  to standby SIP host  204  as SUBSCRIBE message  218 . Though not depicted in the drawing, standby SIP host  204  can respond to SUBSCRIBE message  218  with a 200 OK message or can respond by some other mechanism available for verifying proper delivery of the message. 
     Upon receipt of SUBSCRIBE message  218  at standby SIP host  204 , standby SIP host  204  can create an entry in its storage medium  216  with the information included in the message that is related to and identifies MGC  208  as an entity subscribed to the SIP FS notification mechanism. 
     The SIP FS notification mechanism may activate in response to a switchover from an active SIP host  202  to a standby SIP host  204 . A switchover event  220  may occur for a variety of reasons, for example, failure of active SIP host  202 , maintenance of active SIP host  202 , updated provisioning for active SIP host  202  or a variety of other reasons. Switchover, as disclosed herein, may also be used for many other purposes, for example, load balancing where dialogs that are active on one host may be moved to another host to balance the load between the hosts. Accordingly, all such other purposes are considered within the scope of this disclosure. 
     A switchover event  220  may be triggered in a variety of ways. For example, in relation to any possible switchover event performed for reasons other than a failure of an active SIP host, some of which were discussed above, an internal message from active SIP host  202  to standby SIP host  204  may be used to activate standby SIP host  204 . Other mechanisms for activating standby SIP host  204  are possible, such as, for example, a power fail interrupt or other alert mechanism that may notify a standby SIP host that an active SIP host has failed. Accordingly, all such mechanisms for activating a standby SIP host are considered within the scope of this disclosure. 
     Further, security measures may be used to prevent a host from switching over to either a valid or an invalid standby host. For example, encryption of an internal message, such as the internal message discussed above, may be used to validate that a switchover event is genuine. Many other security measures are possible to avoid an unintended switchover by an active SIP host to either a valid or an invalid standby host and all are considered within the scope of this disclosure. 
     When a standby SIP host  204  becomes an active SIP host by entering an active mode, it can associate with a new standby SIP host (not shown in  FIG. 2 ). As will be described in more detail below, standby SIP host  204  can then send a NOTIFY message  222  to each MGC  208  that is subscribed to the SIP FS notification mechanism. SIP host  204  can also send a SUBSCRIBE message  218  to the new standby SIP host for each subscribed MGC as described above. In this way, subscription information can be propagated from activated standby SIP hosts to new standby SIP hosts over time without a need for MGCs to re-subscribe to the notification process. In an alternative embodiment, SIP host  204  could send a single bulk SUBSCRIBE message including information associated with all subscribed MGCs to the new standby SIP host. A bulk SUBSCRIBE messaging scheme for updating a new standby SIP host would further reduce network traffic for a switchover event. For non-failure related switchover events where active SIP host  202  may perform messaging activities, either or both of SIP host  202  and standby SIP host  204  may be configured to send NOTIFY message  222 . 
     NOTIFY message  222  may include information identifying a new active SIP host (e.g., the standby SIP host  204  which has now switched to an active mode), a new standby SIP host (not shown in  FIG. 2 ) within the network, and the Internet protocol (IP) address of both the new active SIP host and the IP address of the new standby SIP host. MGC  208  can then update its local records with the information included in NOTIFY message  222 . MGC  208  may also then update all of its dialog records with the IP address of standby SIP host  204  to indicate that it is now the active SIP host. 
     Upon update of each dialog within MGC  208  with the IP address for standby SIP host  204 , all dialogs associated with MGC  208  can then operate without a need for standby SIP host  204  to individually invite each dialog to transition to standby SIP host  204 . This can quickly and efficiently be done within MGC  208  without a need for further network traffic or the latency associated with such traffic. 
     It is believed that this method will greatly reduce network traffic associated with a switchover event and provide better call retention than previous methods. For example, rather than requiring an INVITE message to be sent to a SIP peer for each dialog, a SUBSCRIBE message, a NOTIFY message and assorted 200 OK messages can be used to update all dialogs maintained by the SIP peer. It is believed that this reduction in network message overhead can reduce and prevent dropped calls by removing the message latency associated with individual notification to each dialog. By allowing a quicker transition to standby SIP host  204 , dialogs that would otherwise not have been able to communicate with any SIP host during a switchover period may now communicate sooner and have a higher probability of remaining active. 
     Beyond the network message latency reductions, there are also many approaches to quickly update the information within MGC  208  that can allow for a very rapid update of active host information associated with the dialogs. All should be considered within the spirit and scope of this specification. For example, direct memory access (DMA), register pointer based accessing whereby all dialogs read the same memory location for the IP address of the active host and whereby transitions to new register-based data can occur in as little as a single clock cycle, and many other approaches can be used to allow rapid updating of the active host information for all active dialogs. Those skilled in the art will recognize many other suitable memory updating schemes and all are considered within the scope and spirit of this specification. 
       FIGS. 3A and 3B  represent portions of an exemplary SIP FS process  300  resident on active SIP host  202  and standby SIP host  204 . This process is divided into two flow charts for ease of description. The process begins in  FIG. 3A  at  302  where a SIP host will wait for a SUBSCRIBE message from an MGC  208  that includes identifying information for MGC  208 . If a SUBSCRIBE message is received, the process transitions to  304 . At  304 , process  300  can store the identifying information, for example the IP address, of the MGC that is attempting to subscribe to the notification mechanism. A transition can be made to  306  where an acknowledgment message (200 OK) is formed and sent to the subscribing MGC. The SUBSCRIBE message can also be forwarded at  308  to the current standby SIP host with the information identifying the subscribing MGC. A transition can then be made to  302  to await future events. 
       FIG. 3B  shows a portion of SIP FS process  300  related to handling a switchover event. This portion of SIP FS process  300  begins at  310  where the process waits for a switchover event. If a switchover event occurs, a transition can be made to  312  where the process determines whether any MGCs are currently subscribed to the notification mechanism. If there are no MGCs currently subscribed, process  300  transitions to  310  to await another switchover event. However, if there are any MGCs currently subscribed to the notification mechanism, a transition can be made to  314  where process  300  can associate with a new standby SIP server as discussed above and a NOTIFY message can be formed. 
     The NOTIFY message can include information indicating the new active server, new standby server, and the IP addresses of both. This NOTIFY message can then be sent to all subscribed MGCs. A transition can then be made to  316  where the process checks for 200 OK responses from all subscribed MGCs. If any MGC has not responded after a defined timeout period, a transition can be made to  318  to resend the NOTIFY message to the remaining MGCs. This continues until either all have responded or a sufficient time passes such that error handling should be invoked. The error handling is not discussed herein, but a variety of mechanisms can be used to handle errors of this sort, any of which are considered to be within the scope and spirit of this disclosure. In order to simplify this discussion, a reliable messaging mechanism is considered such that all MGCs respond and a transition can then be made back to  310  to process future events. 
       FIGS. 4A and 4B  show the MGC side of an exemplary SIP FS process  400 . This process is divided into two flow charts for ease of description. SIP FS process  400  begins in  FIG. 4A  at  402  where the MGC determines whether a subscription message needs to be sent to an active SIP host. This determination could occur based upon a variety of circumstances, some of which are detailed herein. For example, a new subscription may be required upon a boot of an MGC with new code or during any provisioning event for the MGC, when a new active SIP host is provisioned or comes back online after maintenance that results in a break in the subscription forwarding discussed above, and upon any other system event that could require a new SUBSCRIBE message to be sent. 
     Another example of a situation where a new SUBSCRIBE message may need to be sent is for a case where a new feature is deployed in an active SIP host and a standby SIP host, and the NOTIFY message instructs the MGC to perform a function or forward additional information related to the subscription mechanism. In this way, the subscription process can be modified without a need for extensive outage of the MGC. Many mechanisms exist for the deployment of new services and features within communications networks. These are not detailed herein, but all are considered within the scope and spirit of this disclosure. 
     If a new SUBSCRIBE is needed, process  400  transitions to  404 . At  404 , MGC  208  sends a SUBSCRIBE message to its presently active SIP host. A transition is then made to  406  where the MGC awaits an acknowledgement (200 OK) message from the active SIP host. If the active SIP host does not acknowledge the SUBSCRIBE request within a defined timeout period, a transition is made back to  404  where a new SUBSCRIBE message is sent, and a transition is made back to  406  to await an acknowledgment (200 OK) from the active SIP host. 
     The re-sending of the SUBSCRIBE message may continue until either the active SIP host has responded or a sufficient time passes such that error handling should be invoked. The error handling is not discussed herein, but a variety of mechanisms can be used to handle errors of this sort, any of which are considered to be within the scope and spirit of this disclosure. In order to simplify this discussion, a reliable messaging mechanism is considered such that the active SIP host can respond and a transition can then be made back to  402  to determine whether any new SUBSCRIBE messages need to be sent as discussed above. 
       FIG. 4B  shows a portion of SIP FS process  400  related to handling a NOTIFY message. This portion of SIP FS process  400  begins at  408  where the process waits for a NOTIFY message from a newly activated standby SIP host that is to become the new active SIP host. A NOTIFY message will contain information related to updating dialogs that are associated with the MGC to associate the dialogs with the new active SIP host. This information can include the name and IP address of the new active SIP host and a new standby SIP host. 
     When a NOTIFY message is received, a transition can be made to  410  where the NOTIFY message is parsed to extract the information, which can include the name and IP address for a new active host and a new standby host. The IP address of the new active host can be updated for each existing dialog presently associated with the MGC as discussed above. At  412 , the new standby host name and IP address can be updated and a transition can be made back to  408  to wait for a NOTIFY message. 
     The steps described above that include waiting for a message can be implemented using any of a variety of mechanisms. For example, an interrupt mechanism, a polling mechanism and many other mechanisms are available. Accordingly, all are considered within the scope and spirit of this disclosure. 
     It will be understood that various details of the invention may be changed without departing from the scope of the invention. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the subject matter described herein is defined by the claims as set forth hereinafter.