Hitless application upgrade for SIP server architecture

• US 8,171,466 B2
• Filed: 05/15/2007
• Issued: 05/01/2012
• Est. Priority Date: 05/16/2006
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: Oracle International Corporation (Oracle Corporation)
• Inventors: Langen, Anno R., Khan, Rao Nasir, Wilkiewicz, Jaroslaw
• Primary Examiner(s): Dao, Thuy
• Assistant Examiner(s): Luu, Cuong V
• Application Number:
  US11/748,767
• Publication Number:
  US 20080091837A1
• Time in Patent Office: 1,813 Days
• Field of Search: None
• US Class Current: 717/170
• CPC Class Codes: H04L 65/1045 Proxies, e.g. for session initiation protocol [SIP]
• CPC Class Codes: H04L 65/1104 Session initiation protocol [SIP]
• CPC Class Codes: H04L 65/40 Support for services or applications
• CPC Class Codes: H04L 67/1001 for accessing one among a plurality of replicated servers
• CPC Class Codes: H04L 67/1014 based on the content of a request
• CPC Class Codes: H04L 67/1027 Persistence of sessions during load balancing
• CPC Class Codes: H04L 67/1029 using data related to the state of servers by a load balancer

Abstract

The Session Initiation Protocol (SIP) server can be comprised of an engine tier and a state tier distributed on a cluster network environment. The engine tier can send, receive and process various messages. The state tier can maintain in-memory state data associated with various SIP sessions. Various applications can be running on the engine tier. A new version of an application can be deployed alongside the old version, simultaneously running on the SIP server. Incoming messages for new calls can be directed by the SIP server to the new version of the application. Incoming messages for previously established calls can be directed to the old version of the application. Once the old version is finished processing calls, it can be undeployed.

Claims

1. A computer implemented method for upgrading an application, comprising:

maintaining a session initiation protocol (SIP) server running on an engine node, wherein the SIP server includes a SIP servlet container adapted to host applications;

deploying a first application to the SIP server container having an application name, wherein the application name specifies a version string associated with the first application, and wherein the SIP server strips the version string of the first application when the first application is deployed;

processing incoming messages by the first application deployed on the SIP server;

deploying a second application to the SIP server container while maintaining processing by the first application, wherein the second application includes the application name and version string, and wherein the version string of the second application is stripped when the second application is deployed;

receiving incoming messages by the engine node, wherein when the incoming messages are received by the engine node, the engine node

detects which application the incoming messages are directed based on the application name included in the incoming messages,

determines whether the incoming messages are associated with a new call or an established call,

directs the incoming messages for new calls to the second application; and

directs the incoming messages for previously established calls to the first application.

2. The method of claim 1 wherein directing incoming messages further includes:

receiving a message by an engine node in a cluster network from a load balancer;

determining by the SIP server on the engine node whether the message is associated with a new call or an established call; and

assigning the message to the first application if the message is associated with the established call, otherwise assigning the message to the second application.

3. The method of claim 1 further comprising:

maintaining a count of active calls being processed by the first application.

4. The method of claim 3 further comprising:

undeploying the first application when the count of active calls processed by the first application reaches zero.

5. The method of claim 1 further comprising:

determining that the second application is not functioning as intended; and

undeploying the second application and directing the incoming messages for new calls back to the first application.

6. The method of claim 1 wherein deploying the second application further includes:

activating the second application to process incoming messages.

7. The method of claim 1 wherein the previously established call is an SIP session established between the first application and a SIP client.

8. The method of claim 1, further comprising:

maintaining version information by the SIP server in order to differentiate between the first application and the second application wherein the second application is a newer version of the first application.

9. The method of claim 1 further comprising:

appending a version identifier string to the second application in order to distinguish the second application from the first application by the SIP server.

10. The method of claim 1 wherein directing the incoming messages further includes:

changing the servlet mappings by the SIP server such that incoming messages for new calls are routed to the second application and the incoming messages for old calls are routed to the first application.

11. A system for upgrading an application, said system comprising at least one central processing unit (CPU) that executes a set of instructions to implement:

a session initiation protocol (SIP) server running on an engine node, wherein the SIP server includes a SIP servlet container adapted to host applications;

a first application deployed to the SIP server container for processing incoming messages, wherein the first application includes an application name that specifies a version string associated with the first application, and wherein the SIP server strips the version string of the first application when the first application is deployed;

a second application deployed to the SIP server container, wherein the second application is deployed while maintaining processing by the first application, and wherein the second application includes the application name and version string, and wherein the version string of the second application is stripped when the second application is deployed; and

wherein when incoming messages are received by the engine node, the engine node

detects which application the incoming messages are directed based on the application name included in the incoming messages,

determines whether the incoming messages are associated with a new call or an established call,

directs the incoming messages for new calls to the second application; and

directs the incoming messages for previously established calls to the first application.

12. The system of claim 11, further comprising:

a load balancer for receiving an incoming message and directing the message to an engine node in the cluster network wherein the SIP server running on the engine node determines whether the message is associated with a new call or an established call and assigns the message to the first version application if the message is associated with the established call, otherwise assigns the message to the second application.

13. The system of claim 11, further comprising:

a count of active calls being processed by the first application that is decremented as the first application finishes processing the messages for established calls.

14. The system of claim 13 wherein the first application is undeployed when the count of active calls processed by the first application reaches zero.

15. The system of claim 11 wherein the second version application is undeployed upon determining that the second version application is not functioning as intended and wherein the messages for new calls are directed to back to the first version application.

16. The system of claim 11 wherein a previously established call is an SIP session established between the first version application and a SIP client.

17. The system of claim 11 wherein the first version application and the second version application are simultaneously executing on the SIP server for a period of time.

18. The system of claim 11 further comprising:

a version identifier string appended to the second version application in order to distinguish the second version application from the first version application by the SIP server.

19. A non-transitory computer readable storage medium storing a set of instructions, said instructions when executed by one or more processors causing the one or more processors to:

maintain a session initiation protocol (SIP) server running on an engine node, wherein the SIP server includes a SIP servlet container adapted to host applications;

deploy a first application to the SIP server container having an application name, wherein the application name specifies a version string associated with the first application, and wherein the SIP server strips the version string of the first application when the first application is deployed;

process incoming messages by the first application deployed on the SIP server;

deploy a second application to the SIP server container while maintaining processing by the first application, wherein the second application includes the application name and version string, and wherein the version string of the second application is stripped when the second application is deployed;

receive incoming messages by the engine node, wherein when the incoming messages are received by the engine node, the engine node

detects which application the incoming messages are directed based on the application name included in the incoming messages,

determines whether the incoming messages are associated with a new call or an established call,

directs the incoming messages for new calls to the second application; and

directs the incoming messages for previously established calls to the first application.