WO2007134338A2 - Mise à niveau d'application sans à-coups pour architecture de serveur sip - Google Patents

Mise à niveau d'application sans à-coups pour architecture de serveur sip Download PDF

Info

Publication number
WO2007134338A2
WO2007134338A2 PCT/US2007/069021 US2007069021W WO2007134338A2 WO 2007134338 A2 WO2007134338 A2 WO 2007134338A2 US 2007069021 W US2007069021 W US 2007069021W WO 2007134338 A2 WO2007134338 A2 WO 2007134338A2
Authority
WO
WIPO (PCT)
Prior art keywords
application
server
version
sip
calls
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2007/069021
Other languages
English (en)
Other versions
WO2007134338A3 (fr
Inventor
Anno R. Langen
Rao Nasir Khan
Jaroslaw Wilkiewicz
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
BEA Systems Inc
Original Assignee
BEA Systems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US11/748,767 external-priority patent/US8171466B2/en
Priority claimed from US11/748,791 external-priority patent/US8112525B2/en
Application filed by BEA Systems Inc filed Critical BEA Systems Inc
Publication of WO2007134338A2 publication Critical patent/WO2007134338A2/fr
Publication of WO2007134338A3 publication Critical patent/WO2007134338A3/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1063—Application servers providing network services
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/656—Updates while running
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/42—Circuit arrangements for indirect selecting controlled by common circuits, e.g. register controller, marker
    • H04Q3/54—Circuit arrangements for indirect selecting controlled by common circuits, e.g. register controller, marker in which the logic circuitry controlling the exchange is centralised
    • H04Q3/545—Circuit arrangements for indirect selecting controlled by common circuits, e.g. register controller, marker in which the logic circuitry controlling the exchange is centralised using a stored program
    • H04Q3/54508—Configuration, initialisation
    • H04Q3/54516—Initialization, software or data downloading
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/42—Circuit arrangements for indirect selecting controlled by common circuits, e.g. register controller, marker
    • H04Q3/54—Circuit arrangements for indirect selecting controlled by common circuits, e.g. register controller, marker in which the logic circuitry controlling the exchange is centralised
    • H04Q3/545—Circuit arrangements for indirect selecting controlled by common circuits, e.g. register controller, marker in which the logic circuitry controlling the exchange is centralised using a stored program
    • H04Q3/54541—Circuit arrangements for indirect selecting controlled by common circuits, e.g. register controller, marker in which the logic circuitry controlling the exchange is centralised using a stored program using multi-processor systems
    • H04Q3/54558—Redundancy, stand-by

Definitions

  • the current invention relates generally to managing telecommunications and more particularly to upgrading applications within a network environment.
  • PSTN Public Switched Telephone 5 Networks
  • VoIP Voice Over Internet Protocol
  • FIGURE IA is an exemplar ⁇ ' i! lustration of a functional system layers in various embodiments.
  • FIGURE IB is another exemplary illustration of functional system layers in a 25 communications platform embodiment.
  • FIGURE ' 1 C is an exemplary illustration of a SIP server deployed in a production environment, in accordance with various embodiments,
  • FIGURE 2 is an exemplary illustration of the SlP server cluster architecture in accordance with various embodiments of the invention.
  • FIGURE 3 is an exemplary illustration of a near cache in the SIP server cluster architecture in accordance with various embodiments of the invention.
  • FIGURE 4A is an exemplary flow diagram of the hitless application upgrade, in accordance with various embodiments
  • FIGURE 4B is another exemplary flow diagram of the hitless application upgrade, in accordance with various embodiments.
  • FIGURE 4C is an exemplary flow diagram of rollback functionality of the hitless application upgrade, in accordance with various embodiments
  • FIGURE 5 is an exemplary illustration of a call flow in a typical SlP communication session, in accordance with various embodiments.
  • references to embodiments in this disclosure are not necessarily to the same embodiment, and such references mean at least one. While specific implementations are discussed, it is 15 understood that this is done for illustrative purposes only. A person skilled in the relevant ait will recognize that other components and configurations may be used without departing from the scope and spirit of the invention.
  • a SiP server can be comprised of an ensine tier and a state tier distributed on a cluster network environment
  • the en ⁇ me tier can include a set of engine nodes that send, receise and process various messages
  • the state tier can include a set of state tici replica nuclei that maintain in-memory state data associated with various SlP sessions Applications can be deployed and executed on the 5 engine tier
  • These applications can be adapted to process telecommunication sessions, data and calls such as ⁇ ia the SlP protocol Iu certain embodiments, an application ma ⁇ need to be upgraded or modified such as by re-compiling and re-deploj ing the application onto the engine tier in one embodiment, a new version of an application can be deplo>ed alongside an
  • FIGURE IA is an exemplary illustration of functional system layers in accordance with various embodiments Although this diagiam depicts components as logically separate, such depiction is merely for illustrative purposes It will be apparent to those skilled in the art that the components portrayed iu this figure can be arbitrarily combined
  • a Session Initiation Protocol (SIP) Server 102 and a Network Gatekeeper 104 can comprise a portfolio of products that coliectisely make up the Communications Piatfoim 100
  • the SIP Server 102 provides the Communications Platform 100 with a subsystem in which application components, that interact with S IP-based networks may be deployed
  • the Network Gatekeeper 104 pros ides a policy-driven telecommunications Web services
  • a variety of shared and re-usable software and service infrastructure components comprise the Communications Platform 100.
  • an Application Ser ⁇ er such as the WebLogicTM Application Server by BEA Systems, inc. of San Jose, California This Application Server may be augmented and adapted for deployment in telecommunications 5 networks, while providing many features and functionality of the WebLogic Server counterpart widely deployed in enterprise computing environments
  • Application Server embodiments for use in the telecommunications applications can ⁇ ro ⁇ ide a variety of additional features and functionality, such as without limitation;
  • HW/OS Generalized for wide range of target platforms
  • communications platform embodiments can provide a variety of additional features and functionality, sucli as without limitation.
  • Optimized for Telecom HW /OS /HAM W platforms support (SAF, ATCA, HA M 20 /W, etc.)
  • FIGURE I B is another exemplary illustration of functional system layers in a communications platform embodiment
  • this diagram depicts components as logically separate, such depiction is merely for illustrative purposes. It will be apparent to those skilled in the art that the components portrayed in this figure can be arbitrarily combined or divided into separate software, firmware and/or hardware. Furthermore, it will be apparent to those skilled in the art that the components portrayed in this figure can be arbitrarily combined or divided into separate software, firmware and/or hardware. Furthermore, it
  • Communications platform 100 comprises a SlP Server (WLSS) 102 and a Network Gatekeeper (WLNG) S 04.
  • Tools for interacting with Web Services such as a Web 5 Service - Universal Description Discovery Interface (WS/UDDI) 1 10, a Web Service - Business Process Execution Language (WS/BPEL) 112 may be coupled to the SIP Server 102 and the Network Gatekeeper 104 in embodiments.
  • a log/trace and database 1 14 can assist with troubleshooting.
  • the Communications Platform 100 can interface with an OSS/BSS system 120 via resource adapters 122. Such interfaces can be any interfaces.
  • a policy engine 128 can control the activities of the above-described components which can be implemented in a scalable cluster environment (SCE) 130
  • a Communications Platform embodiment can provide an open, high performance,
  • the Communications Platform is suitable k ⁇ use by £or Network Infrastructure Vendor, Network Operators and Communications Service Providers in multiple deployment scenarios ranging from fully IMS oriented network
  • 25 Providers an execution environment in which to host applications (such as the WebLogic Network Gatekeeper), components and standard service enablers.
  • applications such as the WebLogic Network Gatekeeper
  • components such as the WebLogic Network Gatekeeper
  • standard service enablers such as the WebLogic Network Gatekeeper
  • FIGURE IC is an exemplary illustration of a SlP server deployed in a production environment, in accordance, with various embodiments. Although this diagram depicts components as logically separate, such depiction is merely for illustrative purposes, it will
  • the SlP server 102 can be used as a back-to-back user agent 5 (B2BLJ A) 150 in a typical telecommunications environment.
  • B2BUA can take the place of an intermediary between communications between user agents 160, 16.2, including various cellular phones, wireless devices, laptops, computers, applications, and other components capable of communicating with one another electronically.
  • the B2BUA 150 can provide multiple advantages, including controlling the flow of communication
  • ⁇ 0 between user agents enabling different user agents to communicate with one another (e.g. a web application can communicate with a cellular phone), as well as various security advantages.
  • the user agents can transmit to the SIP server instead of communicating directly to each other and thus malicious users can be prevented from sending spam and viruses, hacking into other user agent devices, and otherwise
  • the SIP server 102 can be implemented as & Java Enterprise Edition application server that has been extended with support for the session initiation protocol (SIP) as well as other operational enhancements that allow it to meet tlie demanding requirements of the next generation protocol-based communication networks.
  • SIP session initiation protocol
  • SlP session initiation protocol
  • server 102 can include an Enterprise Java Beans (EJB) container 144, a Hyper Text Transfer Protocol (HTTP) servlet container 142, an SiP servlet container 140, various Java 2 Enterprise Edition (J2EE) services 146, and SlP 150 and HT TP 148 components.
  • EJB Enterprise Java Beans
  • HTTP Hyper Text Transfer Protocol
  • SiP SiP
  • J2EE Java 2 Enterprise Edition
  • SlP 150 and HT TP 148 components can be fully integrated into the SIP servlet container 140 and can offer much greater ease of use than a traditional protocol stack.
  • API Programming Interface
  • S ⁇ P serv ⁇ et API can define a higher layer of abstraction than simple protocol stacks provide and can thereby can free up the developer from concern about the mechanics of the S ⁇ P protocol itself. For example, the developer can be shielded from syntactic validation of received requests, handling of
  • the container is a server software that hosts applications (i e contains them), in the case of a SIP container, it hosts SiP applications.
  • the container can 5 perform a number of SIP functions as specified by the protocol thereby taking the burden off the applications.
  • the SlP container can expose the application to SIP protocol messages (via the SIP Servlet API) on which applications can perforin various actions Different applications can thus be coded and deployed to the container that provides various telecommunication and multimedia services,
  • FIGURE 2 is an exemplary illustration of the SIP server cluster architecture in accordance with various embodiments of the invention.
  • this diagram depicts components as logically separate, such depiction is merely for illustrative purposes. It will be apparent to those skilled iu the an that the components portrayed in this figure can be arbitrarily combined or divided into separate software, firm ware and/or hardware.
  • FIGURE 2 shows Host A implementing both an engine node and a data node, this should not be
  • FIGURH 2 illustrates two host machines, it is possible and even advantageous to implement many more such hosts in order to take advantage of distribution, load balancing and failover that such a system can provide
  • a message such as a phone call request or some other transfer of data associated with SIP
  • a message can come into the cluster from the internet (such as over VoIP), phone, or some other type of network 200
  • This message can be received and handled by a load balancer 202 which can be responsible distributing message traffic across the engines ⁇ such as engine node 1 216 and engine node 2 208) in the cluster.
  • the load balancer can be
  • the load balancer can be implemented as software that distributes the messages to the various engines.
  • the primary goal of the load balancer 202 can be to provide a single public address that distributes 5 incoming SIP requests to available servers in the SIP server engine tier 210. Such distribution of requests can ensure that the SIP server engines are fully utilized.
  • the load balancer 202 can also be used for performing maintenance activities such as upgrading individual servers or applications without disrupting existing SIP clients.
  • the SIP server can provide a two-tier cluster architecture
  • a stateless engine tier 210 can process all signaling traffic and can also replicate transaction and session state to the state tier 212 and its partitions 222.
  • Each partition 222 can consist of any number of nodes (replicas) 218, 214 distributed across any number of hosts such as host 1 220 and host 2 204 which can be implemented as computers linked in a cluster type network
  • the state tier 212 can be an n ⁇ vvay peer-replicated Random Access Memory (RAM) store that maintains various data objects which can be accessed by the engine nodes in the engine tier.
  • RAM Random Access Memory
  • the state tier can also function as a lock manager where call state access follows a simple library book model (i.e. a call state can be checked out by one SlP engine at a time).
  • the engine tier 210 can be implemented as a cluster of S ⁇ P server instances that hosts the SfP servlets which provide various features to SIP clients.
  • SfP servlets which provide various features to SIP clients.
  • the engine tier 2 iO is stateless, meaning that most SIP session state information is not persisted in the engine tier, but is obtained by querying the state tier 212 which can in turn provide replication and fail over services for S ⁇ P session data.
  • the engine tier can have state maintained in a local near cache for improving latency.
  • the primary goal of the engine tier 210 can be to provide maximum throughput
  • the STP serv lets can be deplo) ed uniformly to ail server instances b> targeting the cluster itself and the load balance? need not maintain affimt ⁇ between SIP clients, and individual servers in the engine tier
  • the state tier 212 can be implemented as a cluster of SIP serv er instances that provides a high-performance, highly -available, in-memon store for maintaining and retrieving session state data for SIP servlets
  • This session data may be required by SlP applications in the SIP server engine tier 210 in order to process incoming messages
  • session data can be managed in one or more partitions
  • each partition manager a fixed portion of ⁇ he concurrent call state
  • the first partition could manage one half of the concurrent call state (e H A-M) and the second partition can manage the other half (e g Nf-/)
  • each can manage a third of the call state and so on Additional partitions can be added as needed to manage large numfaei of concurrent calls
  • each partition 222 multiple servers can be added to provide redundancy and iai lover should the olhct servers in the partition fail
  • those servers can be referred to as replicas because each server maintains a duplicate copy of the partition's call state l*or example, nodes 21 S and 214 of the partition 222 can be implemented as replicas
  • the data can be split evenly across a set of partitions, as prev iously discussed.
  • the number of ieplicas in the partition can be called the replication factor, since it determines the lc ⁇ cl of redundancy and strength of failov er that it provides For example, if one node goes down oi becomes disconnected from the network, any available replica can automatically provide call state
  • Replicas 214, 2 S 8 can join and leav e the partition 222 and each replica can serv e as exactly one partition at a time
  • the total available call state storage capaeif) of the cluster is a summation of ⁇ he capacities of each partition 222 hi one embodiment, each partition 222 can pccr-replicated, meaning that clients
  • I l architecture wherein one store acts as a primary and the other nodes serve as secondaries. Latency is reduced because there is no wait for the second hop of primary-secondary systems.
  • the peer-replicated scheme can provide better fai lover characteristics as well, since there does not need to be change propagation delay,
  • the engine nodes 208, 216 can he responsible for executing the call processing.
  • Each cai! can have a call state associated with it.
  • This call state can. contain various information associated with the call, such as the ids of the cailer/eallee, where the caller is, what application is running on the callee, any tinier objects that may need to fire in order to process the call flow (as discussed below), as well as any other data
  • ⁇ 0 that may correlate to a call or a message.
  • the state for each call can be contained in the state tier 212.
  • the engine tier 210 could be stateless in order to achieve the maximum performance. In alternative embodiments, however, the engine tier can have certain amounts of state data stored thereon at various times.
  • a typical message processing flow can involve locking/getting
  • the operations supported by the replicas for normal operations can include:
  • the engine tier can maintain mainly short lived objects and any long lived objects which may be needed for message processing can be stored on the state tier. This can provide improvements in latency during garbage collection.
  • the Java Virtual Machine (JVM) garbage collector can safely and quickly remove the short lived objects from memory without interfering with the execution of
  • JVM Java Virtual Machine
  • Short lived objects are not as easily removed by the garbage collector (since they may be referenced and depended on by various entities) and thus in some cases, the JVM garbage collector may need to stop processing all threads in order to safely perform its garbage collection. This is due in part to the scoping of the short lived and long lived objects. Short
  • the engine tier can maintain mostlv short lived objects in eases where longer li ⁇ ed objects are needed b ⁇ the engine tie ⁇ , the> can be
  • the state tier 212 can maintain call state in ⁇ arious data objects residing in the random access memory (RAM) of a computer This can provide ⁇ O significant access speed advantages to the engine tier 210 over the use of a database
  • call state can be maintained in a database or some other form of persistent store, which can be accessed ⁇ albeit slower)
  • the engine tier State of various applications running on the SIP server can also be maintained on the state tier Developers can be provided an API to allow their applications to access the state tier 15 and to store v arious data thereon for later access by vadous applications
  • application state may be stoted in a database
  • the SlP server can deploy and host a multitude of applications that provide ⁇ arious serv ices to SlP clients Fo? example, a webl ⁇ x application can be deployed on the SIP 20 server and provide web conferencing and video conferencing features to numerous customers Other such applications can also be running on the SlP server at v arious times
  • the hitless application upgrade can enable the SlP server to upgrade a deployed SlP application to a newer v ersion without losing the existing calls being processed by the
  • This type of upgrade can be accomplished by deploying a newer application version alongside the older version which is already running on the engine tier
  • the SiP server can (hen automatically manage the calls and messages such that new calls are routed to the new version of the application, while the old established calls continue to be 5 processed by the older version. Once all established calls are completed, the older version of the application can be undepJoyed
  • the hilless application upgrade can also enable the user to commit or roll back the changes caused by the new versions of the applications. Jn this manner, a smoother and more dynamic transition is provided for upgrading the various services of a corporation.
  • FIGURES 3A-3B are exemplary illustrations of the hill ess application upgrade functionality, in accordance with various embodiments of the invention. Although each of these diagrams depicts components as logically separate, such depiction is merely for illustrative purposes it will be apparent to those skilled in the art that the components portrayed in these figures can be arbitrarily combined or divided into separate software,
  • a SiP server including a SIP servlet container 308.
  • a load balancer 300 can be receiving incoming SlP message traffic and distributing that traffic to the various engine nodes 304, 306 for processing in the engine tier 302. Some (or all) of the messages and requests received by the engine nodes, can then be directed to be handled by the SIP App v l 3 12..
  • a system administrator of the SiP server may wish to upgrade or substitute a new version of SlP App Vl 312 without disrupting the existing calls being handled thereby
  • the hitiess application upgrade can take enable such features, as illustrated in FIGURE 3B.
  • SIP App v2 a new version of the SIP application, such as SIP App v2
  • (version two) 316 can be deployed on the engine node A 304 alongside the old version SlP App vl 312
  • the SiP server can then manage the SIP serviet mapping such that new
  • Version information can be assigned to each updated application in order to distinguish it from the older application versions. For example, whenever a SlP application is deployed, a version number can be associated therewith. Alternatively, only
  • ⁇ O new updated applications may be assigned a version number and other applications that are already deployed may be assumed to be older versions by the SIP server.
  • the application name can be replaced with calls to a helper method that obtains the base application name.
  • the SiP server can provide SipApplicatkmRuniimeMBeau methods for obtaining the base application name and version identifiers as well as for determining whether the current application version is active or retiring.
  • the S ⁇ P server can use a version identifier such as a string value appended to the application name in order to distinguish between multiple versions of a given application
  • the version can be appended to the context root or to the archive name when the application is packaged for deployment.
  • the SIP server can subsequently strip the version string specified from the application's deployment name so that it can recognize when several versions of the same application are deployed. If two versions are indeed deployed, the server can begin routing new requests to the most recently-deployed
  • the server can allow the other deployed application to complete in-flight calls while directing no new calls to it. This process can be referred to as retiring because eventually, the older version will process no S ⁇ P messages.
  • the server can also distinguish between a deployment that has no version identifier and a subsequent version that does specify a version identifier. This can enable upgrades of applications that were packaged
  • the original deployment SIP ⁇ pp v l 3 !2 can then process messages only for established or in-flight calls (e g calls that were initiated with the original deployment) After these in-flight calls 5 are completed, the original deployment version can be removed as no longer being necessary
  • an active session count can be obtained from the application's runtime bean instance or a script prepared by a system administrator When the count of active sessions for that ⁇ ersion of the application reaches zero, the hitiess application upgrade can be graceful Iy
  • a method ' ' gctActivcVersionState ⁇ )' ⁇ can return an integer value that describes the state of a selected application version
  • a returned value of zero can indicate that the particular ⁇ crsio ⁇ of the application is inactive, meaning that the application is being retired Alternatively, it can mean that this version has not yet been activated
  • Kach host or engine node can be httlcssly upgraded one at a time, in order to test the performance of the new application version without disrupting the entire system Alternativ ely, all engine nodes can be upgraded in parallel, sequentially or some rna> be left with older application versions Furthermore, rollback functionality can also be
  • the SlP server can restore the previous sen let mappings, as previously discussed
  • a configured load balances 300 can be used to peifomi a hve upgrade of the SIP server software or a deployed SIP application on a production installation When updating the SIP server or when upgrading a SlP sen let where the
  • a new engine tier can be created in order to host newly-upgraded engine tier instances or new versions of SIP sen lets Subsequently, servers in the engine tier can be shut down, upgraded and then restarted in the new target cluster In some cases, it may be preferable to shut down each 5 server one at a time so as to maintain current ca!! processing Similarly, it ma ⁇ be preferable to target all deployed SIP serslets to the engine tier duster, rather than to indiv idual managed server instances within the cluster After all servers have been upgraded, the older cluster can be removed and no longer used When the engine tier cluster is finished upgrading, servers in the state tier can be upgraded similarly one at a
  • FIGURE 4 ⁇ is an exemplary flow diagram of the hitless application upgrade, in accordance with various embodiments Although this figure depicts functional steps in a particular sequence for purposes of illustration, the process is not necessarily limited to this particular order or steps One skilled in the art will appreciate that the various steps
  • a SiP .server can he distributed ovei a cluster type network in order to pros ide services to various SIP clients ⁇ n application deploy ed on the SlP server can process incoming message traffic from the SIP clients, as illustrated in step 402,
  • a new version of the application can be deployed on the SIP server, alongside the existing version of the application, in step 406
  • the new ⁇ crsion can be activated in oidei to begin processing calls, as illustrated m step 408
  • the SLP server or the SIP sen let container therein
  • the container can direct the incoming messages for new calls to the new version of the application
  • the container can
  • 2S direct incoming messages for previously established calls to the old version of the application T hus, for at least some period of tune, the two versions can be running simultaneously
  • FIGURE 4B is another exemplary flow diagram of the hitless application upgrade, in accordance with various embodiments Although this figure depicts functional steps in a
  • an incoming message can be received from a SlP client by a load balancer of the cluster network.
  • the load balancer can then distribute 5 the message to a SIP server having two versions of the application running, as previously discussed
  • the container can then determine whether the message is for an already established SlP session or whether the message is a request that would establish a new SiP session between the client and the SlP server.
  • the SlP server can route messages for previously iO established S ⁇ P sessions to the old version of the application that is executing alongside the new version on the SiP server.
  • the messages for new S ⁇ P sessions can be routed to the new version, as illustrated in step 428. This can be achieved by the SIP server replacing the existing servlet mappings for the application being upgraded with new servlet mappings specified in the SIP deployment descriptor of the new version, upon
  • an active session count can be maintained, such as by the SIP server itself or via scripts Implemented by a system administrator. The count is likely to decrement as existing calls (that are being handled by the old version of the application) are ended by various SIP clients. Whenever this active session count reaches zero, the new
  • 20 version deployment can be gracefully committed, as illustrated in step 432, by undeployi ⁇ g the old version of the application. AH incoming traffic is then directed to the new version of the application. In this manner, no interruption in calls need be experienced by the S ⁇ P server.
  • FIGURE 4C is an exemplary flow diagram of rollback functionality of the hitless
  • a new version is deployed in the SlP server for processing incoming messages as previously discussed. New messages which are associated with new calls can be directed to this newly deployed version, as illustrated in
  • step 444 the new version of the application may not be functioning as previously expected.
  • new functionality added to the new version may cause an increase in latency or simply way not process messages as intended.
  • a rollback can be performed.
  • the rollback can be initiated by ⁇ ndeploying the new version of the application. Subsequently, the incoming messages for all calls, established and new, can be routed back to the old version of the application, as illustrated in step 448. This can be achieved by restoring the previous servlet mappings that were changed by the SiP server. Furthermore, since the deployment and undepioyment of the new version can be initiated by ⁇ ndeploying the new version of the application. Subsequently, the incoming messages for all calls, established and new, can be routed back to the old version of the application, as illustrated in step 448. This can be achieved by restoring the previous servlet mappings that were changed by the SiP server. Furthermore, since the deployment and undepioyment of the new version can be initiated by ⁇ ndeploying the new version of the application. Subsequently, the incoming messages for all calls, established and new, can be routed back to the old version of the application, as illustrated in step 448. This can be achieved by restoring the previous servlet mappings
  • FIGURE 5 is an exemplary illustration of a simplified call flow in a typical SlP
  • a back to back user agent (B2BUA) 500 having a ⁇ inning SlP server thereon can take the place of being an intermediary between the communications sent between various users. This can be done for purposes of controlling the call and message flow between user agent !. 502 and user agent 2 504 and in order to prevent any unwanted behavior and messages (e.g. spamrai ⁇ g, hacking, viruses, etc.) from being sent
  • B2BUA back to back user agent
  • ⁇ t should be noted that although user agent 1 502 and user agent 2 504 are illustrated as telephones in FIGURE 5, the SlP messages can come from various other sources as well.
  • the user agent can also be a cell phone, a wireless device, a laptop, an application or any other component that can initiate a S ⁇ P type of communication.
  • FIGURE 5 illustrates communications between two user
  • 30 agents there can be more such user agents taking part of a single communication session. For example, during a conference call, there may be 20 or 30 user
  • a telephone call can be set up between user agent 1 502 and user agent 2 504 sla the use of the SIP serv er
  • the fust message sent from user 5 agent I 502 to the SlP server on the B2BU ⁇ 500 can be an invite message, requesting to set up a telephone call with use* agent 2 504
  • the invite message can be received by the load balancer 202 of the SlF server and it can be directed to an engine in the engine tier 210 for processing
  • the engine tier (e g an application executing thereon) can
  • pci form logic far determining various factors associated with the call, such as determining whether user agent 1 502 is allowed to make the type of call attempted to be initiated, determining whether the callee that will be contacted is properly identified, as ⁇ ve!i as any othef logic that the serv er may need to calculate before attempting to set up a telephone call
  • the engine can then generate state aioimd the fact that a call is being set
  • the engine can also determine how to find the target of the call (i e user agent 2 504) and the right path to route the message to the callee
  • user agent I is an originator (as well as the terminator) of the call and user agent 2 is referred to as the callee
  • the SiP server can send a " 100 tr> ing" message back to usci agent 1 *>02. indicating that it has received the invite message and that it is in the process of handling it
  • the "100 trying" message is part of the SlP protocol definition and can be used by a server in order to stop the user agent from re-transmitting the invite request
  • the user agent may have interference which might
  • SIP protocol defines various re-transmission schemes in oidei to handle such ni obi lit) and interruptions Messages such as "' ! OC) trying, " "' 180 ringing. "1 and "200 OK " ate just some of the examples of messages defined in SlP for handling communication
  • the SlP server can then send an invite message to
  • user agent 2 504 can then send a "200 ok" message to the SIP server, the server can transmit that message to user agent 1 502
  • the user agent i 502 can send a.n acknowledgement ("Ack" message) to lhe SIP server which can be transmitted along to user agent 2 504 and at this point a sound transfer conversation 5 can be set up between the two user agents.
  • This sound transfer can be implemented via real transfer protocol (RTP) on a media server.
  • RTP real transfer protocol
  • either user agent can choose to terminate the call by sending a "Bye" message, In this illustration, user agent 1 502 terminates the call by sending a ' "Bye” message to the SIP server which sends it off to user agent 2 504.
  • RTP real transfer protocol
  • the SlP server can transmit that message to user agent 1 and the conversation can be truly ended.
  • the vertical lines such as those extending downward from the user agents 502, 504 and the B2BUA 500 can each illustrate and be referred to as a single call leg.
  • the call flow for each call leg may be time sensitive as some messages
  • the user agent A 502 may continue to re-transmit the initial invite message until it receives a " 100 trying" message from the B2BUA 500. As such, in some cases certain messages may need to be processed synchronously while others may be allowed to process in parallel.
  • 25 transmitting steps may be added, changed, interrupted or rearranged in case of interference or failure of various components.
  • sequences can be controlled by various timer objects residing on the S ⁇ P server.
  • the SIP server after receiving the invite message from one user agent, the SIP server will typically forward that invite to another user agent and wait for a
  • tiieu the in ⁇ te message may need to be retransmitted to the second user agent because it mav be assumed that the ⁇ sei agent did not receive the first message Thit> type of re-transmission can be controlled by the protocol timer objects which may be 5 residing in the state tier
  • the protocol timer objects which may be 5 residing in the state tier
  • an initial Tl timer value of 500 milliseconds can control the retransmission Interval for the invite request and responses and can also set the value of various other timers
  • time* objects which can be executing on the le ⁇ ei of the entire call For example, if after a specified period of lime, nothing i_,
  • the entire call may be purged from the system This specified period of time can also be controlled by firing a rimer object
  • a ⁇ engine tier servers add new call state data to the state tier, state tie ⁇ instances queue and maintain a complete list of SlP protocol timers and application timers associated with each call F,ngine tier servers can periodically poll the
  • the processing of the timer objects can be executed by the engine server as determined by the state tier serve* I 1
  • the state tier can
  • the state data may not need to be pushed onto the engine server since that data ma> alread) be available in the cache
  • the timers can be fetched from the state tier, however upon the timer firing, the engine can fetch the call state using the cache
  • system server clocks Io a common time source (e.g within a few milliseconds) in order achieve maximum performance.
  • a.n engine tier server with a system clock that is significantly faster than other servers may process more expired timers than the other engine tier 5 servers. In some situations this may cause retransmits to begin before their allotted time and thus care may need to be taken to ensure against it,
  • the SlF Servlet API can provide a timer service to be used by applications.
  • the TimerService can define a
  • SipAppUcationSession can be implicitly associated with the timer.
  • an application defined Tiiner ⁇ stener is invoked and ServietTimer object passed up, through which the SipAppUcationSession can be retrieved which presides the right context of the
  • the engine tier servers continual Iy access the state tier replicas in order to retrieve and write call state data.
  • the engine tier nodes can also detect when a state tier server has failed or become disconnected. For example, in one
  • the engine when an engine cannot access or write call state data for some reason ⁇ e.g. the state tier node has failed or become disconnected) then the engine can connect to another replica in the partition and retrieve or write data to that replica.
  • the engine can also report that failed replica as being offline. This can be achieved by updating the view of the partition and data tier such that other engines can. also be notified about the offline
  • Additional failover can also be provided by use of an echo server running on the same machine as the state tier server.
  • the engines can periodically send heartbeat messages to the echo server, which can continually send responses to each heartbeat request. If the echo server fails to respond for a specified period of time, the engines can 30 assume that the state tier server has become disabled and report that state server as previously described. In this manner, even quicker failover detection is provided, since the
  • Failover can also be provided for the engine tier nodes.
  • the engine tier nodes can periodically poll the stale tier nodes in order to determine which
  • the state tier nodes can notice whenever the engine tier node has failed to poll Jf a specified period of lime elapses and the engine tier has not polled the state tier, the state server can then report that engine as unavailable ⁇ e.g. having failed or disconnected from the network). In this manner, failover can be implemented for both the state tier and the engine tier, thereby providing a more reliable
  • the invention encompasses in some embodiments, computer apparatus, computing systems and machine-readable media configured to carry out the foregoing methods.
  • the present invention may be conveniently 15 implemented using a conventional general purpose or a specialized digital computer or microprocessor programmed according to the teachings of the present disclosure, as will be apparent to those skilled in the computer art.
  • the invention may also be implemented by the preparation of application specific integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be readily apparent to those skilled in the art.
  • the present invention includes a computer program product which is a storage medium (media) having instructions stored thereon/in which can be used to program a
  • the storage medium can include, but is not limited to, any type of rotating media including floppy disks, optical discs, DVD, CD-ROMs, rnicrodrive, and magneto-optical disks, and magnetic or optical cards, nanosy stems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data.
  • the present invention includes software for controlling both the hardware of the general purpose/specialized computer or microprocessor, and for enabling the computer or microprocessor to interact
  • Such softwaje may include, but is uot limited to, device dmers, operating s ⁇ stems, and user applications
  • Embodiments can provide, by way of example and without limitation, services such as
  • VoIP services including, without limitation the following features
  • Call logs The ability to view calls made over a given period of time online, ability to associate names with phone numbers, integrate call log information to other applications such as IM
  • Locate me This is adx anced call forwarding Rather than have all calls forwarded to a single location (e g , voice mail) when the caller is busy. Locate me can try multiple
  • a unci raa ⁇ have two office locations a mobile, and a pager, and it may make sense to forward a call to both office locations first.
  • Personal conferencing ⁇ user could use an existing application (e g , Wi client) to schedule a Web/audio conference to start at a certain time Since the IM client already has 5 personal profile information, the conferencing system sends out the Web conference link information either thsough IM and/or email to the participants The phone contact information in the profile is used to automatically ring the participants at the time of the conference
  • Lifetime number This is the facility where a single ⁇ irtual number can travel with iO a customer wherever they live Even if they move, the old number continues to work, and reaches them at their new location This is really the analog of static IP addresses in a phone network
  • Speed dial I his is the ability to drarnaticall) expand the list of numbers that can be dialed through short -ke) and accelerator combinations This is another example of a 15 converged application, since It's ⁇ ery likely that w hen a user will set up this information. when they work through the call logs on the operator user portal, and the updated information needs to be propagated to Die network side in real-time
  • Media delivery services including, without limitation the following features Depending on the service les ⁇ l agreement users are willing to sign up to, the 20 quality of media delivered (e g number of frames per second) will vary
  • the policy engine enables segmenting the customer base by revenue potential, and to maximize return on investment made in the network
  • Context-sensitive applications including, without limitation the following features
  • a typical example here is the need for applications that have ⁇ short lifetime, 2 ⁇ extremely high usage peaks within their lifetime, and immediacy For example, voting on
  • Integrated applications including, without limitation the following features
  • the final class of applications is one that combines wireline and wireless terminal 30 usage strigiios ⁇ n example of an Integrated application i.s the following a mobile terminal user is on a conference call on their way to work When he reaches his office, he enters a special key sequence to transfer the phone call to his office phone The transfer
  • a computer progiam product vvhieh is a storage 5 medium (medial having instructions stored thereon/in which can be used to program a general purpose or specialized computing processor(sVde ⁇ ice(s) to perform any of the features presented herein
  • I he storage medium can include, but is not limited to, one or more of the following any type of phy sical media including floppy disks, optica! discs, DVDs, CD-ROMs, microdmes, magneto-optical disks, holographic storage, ROMs,
  • SO RAMs SO RAMs, PRAMS, F.PROMs, ELPROMs. DRAMs, VRAVb, flash memory devices, magnetic or optical cards, nanosystems (including molecular memon ICs). paper or paper- based media, and any ts pe of media or device suitable for storing instructions and/ or information
  • Various embodiments include a computer program product that can be transmitted in whole or in parts and over one or more public and/or prh ate networks
  • the transmission includes instructions which can be used by one or mo ⁇ e processors to perform any of the features * presented herein
  • the transmission includes instructions which can be used by one or mo ⁇ e processors to perform any of the features * presented herein
  • the transmission ma> Include a plurality of sepaiate transmi.ssio ⁇ s
  • the present disclosure includes software for controlling both the hardware of general
  • Such software may include, but h not limited to, dc ⁇ ice drivers, operating systems, execution ernironrnernyeontainers, user interfaces and applications

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Le serveur SIP peut être constitué d'une couche moteur et d'une couche état distribué sur un environnement de réseau en grappe. La couche moteur peut envoyer, recevoir et traiter divers messages. La couche état peut conserver en mémoire des données d'état associées à diverses sessions SIP. Diverses applications peuvent être exécutées sur la couche moteur. Une nouvelle version d'une application peut être déployée en même temps que l'ancienne version, simultanément exécutée sur le serveur SIP. Des messages entrants de nouveaux appels peuvent être dirigés par le serveur SIP vers la nouvelle version de l'application. Des messages entrants d'appels précédemment établis peuvent être dirigés vers l'ancienne version de l'application. Une fois que l'ancienne version a fini de traiter les appels, elle peut être supprimée.
PCT/US2007/069021 2006-05-16 2007-05-16 Mise à niveau d'application sans à-coups pour architecture de serveur sip Ceased WO2007134338A2 (fr)

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
US80108306P 2006-05-16 2006-05-16
US80094306P 2006-05-16 2006-05-16
US80109106P 2006-05-16 2006-05-16
US60/801,083 2006-05-16
US60/801,091 2006-05-16
US60/800,943 2006-05-16
US11/748,767 2007-05-15
US11/748,767 US8171466B2 (en) 2006-05-16 2007-05-15 Hitless application upgrade for SIP server architecture
US11/748,791 2007-05-15
US11/748,791 US8112525B2 (en) 2006-05-16 2007-05-15 Engine near cache for reducing latency in a telecommunications environment

Publications (2)

Publication Number Publication Date
WO2007134338A2 true WO2007134338A2 (fr) 2007-11-22
WO2007134338A3 WO2007134338A3 (fr) 2008-10-09

Family

ID=38694788

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2007/069021 Ceased WO2007134338A2 (fr) 2006-05-16 2007-05-16 Mise à niveau d'application sans à-coups pour architecture de serveur sip

Country Status (1)

Country Link
WO (1) WO2007134338A2 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009152703A1 (fr) * 2008-06-17 2009-12-23 华为技术有限公司 Procédé et appareil de mise à niveau pour serveur de protocole d'initiation de session
CN111026430A (zh) * 2013-05-20 2020-04-17 派克赛泽有限责任公司 本地或分布式计算机系统上的柔性节点组成的方法和系统
CN116400935A (zh) * 2023-06-09 2023-07-07 贵州爱信诺航天信息有限公司 基于国产化平台的跨平台部署系统及方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6704933B1 (en) * 1999-02-03 2004-03-09 Masushita Electric Industrial Co., Ltd. Program configuration management apparatus
US6747970B1 (en) * 1999-04-29 2004-06-08 Christopher H. Lamb Methods and apparatus for providing communications services between connectionless and connection-oriented networks

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009152703A1 (fr) * 2008-06-17 2009-12-23 华为技术有限公司 Procédé et appareil de mise à niveau pour serveur de protocole d'initiation de session
CN111026430A (zh) * 2013-05-20 2020-04-17 派克赛泽有限责任公司 本地或分布式计算机系统上的柔性节点组成的方法和系统
CN111026430B (zh) * 2013-05-20 2023-10-13 派克赛泽有限责任公司 本地或分布式计算机系统上的柔性节点组成的方法和系统
CN116400935A (zh) * 2023-06-09 2023-07-07 贵州爱信诺航天信息有限公司 基于国产化平台的跨平台部署系统及方法
CN116400935B (zh) * 2023-06-09 2023-08-18 贵州爱信诺航天信息有限公司 一种应用安装系统及方法

Also Published As

Publication number Publication date
WO2007134338A3 (fr) 2008-10-09

Similar Documents

Publication Publication Date Title
US8171466B2 (en) Hitless application upgrade for SIP server architecture
US8219697B2 (en) Diameter protocol and SH interface support for SIP server architecture
US8001250B2 (en) SIP and HTTP convergence in network computing environments
US7661027B2 (en) SIP server architecture fault tolerance and failover
US8112525B2 (en) Engine near cache for reducing latency in a telecommunications environment
US20080086567A1 (en) SIP server architecture for improving latency in message processing
US7844851B2 (en) System and method for protecting against failure through geo-redundancy in a SIP server
US9667430B2 (en) System and method for a SIP server with offline charging
US7895475B2 (en) System and method for providing an instrumentation service using dye injection and filtering in a SIP application server environment
US9723048B2 (en) System and method for providing timer affinity through notifications within a session-based server deployment
US20080147551A1 (en) System and Method for a SIP Server with Online Charging
US8078737B2 (en) System and method for efficient storage of long-lived session state in a SIP server
US7870265B2 (en) System and method for managing communications sessions in a network
US8179912B2 (en) System and method for providing timer affinity through engine polling within a session-based server deployment
US20080205622A1 (en) Distributed Session-Based Data
WO2008080849A1 (fr) Système, produit-programme informatique et procédé de communication avec des sessions d'application de protocole d'initiation de session (sip) au moyen d'un système de serveur de messages
WO2007134338A2 (fr) Mise à niveau d'application sans à-coups pour architecture de serveur sip
US8498302B2 (en) System and method for exposing third party call functions of the intelligent network application part (INAP) as a web service interface
WO2007134339A2 (fr) Cache proche du moteur pour réduire le temps d'attente dans un environnement de télécommunications
US9479606B2 (en) System and method for enhanced media brokering in VoIP network
Van Den Bossche et al. ISE01-2: J2EE-based Middleware for Low Latency Service Enabling Platforms
Kim On SIP Server Clusters and the Migration to Cloud Computing Platforms
WO2025083709A1 (fr) Système et procédé de gestion d'appels sur la base d'une affinité de fil
WO2025094201A2 (fr) Système et procédé de gestion de demandes de service dans un réseau
CN117158017A (zh) 用于实现合法拦截管理集成的系统和方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07797496

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07797496

Country of ref document: EP

Kind code of ref document: A2