The Session Initiation Protocol (SIP) is a standardized signaling protocol for controlling communication sessions over a network. It enables sessions with one or more participants to be created, modified and/or terminated and it is widely used to control multimedia communications over Internet Protocol (IP) networks. For example, it can be used to control Voice over IP (VoIP) communications, instant messaging, chat, games and video communications between multiple entities, supporting both unicast and multicast sessions. It is also used as a signaling protocol in 3rd Generation Partnership Project (3GPP) standards such as the IP Multimedia Subsystem (IMS) architecture.
SIP is an application layer protocol and as such is designed to be used independently of underlying transport protocols. Its syntax is text-based and is modeled on that of HyperText Transfer Protocol (HTTP). One or more SIP services are typically provided by a SIP server instance. A SIP server instance is used herein to refer to an entity that receives and processing SIP messages so as to provide a SIP service. A SIP server instance is typically implemented using computer program code that is loaded from a storage medium into one or more portions of memory so as to be processed by one or more processors. The computing platform that provides said one or more processors and/or memory is referred to herein as a SIP server node. Examples of SIP server instances comprise OpenSIPS for Linux platforms, Microsoft Lync Server provided by Microsoft Corporation, and those provided by the DC-SIP toolkit provided by Data Connection Limited. An exemplary SIP server node may comprise a SPARC server platform such as those supplied by Oracle Corporation. In some implementations the SIP server instance and the SIP server node may be tightly coupled in an integrated “black-box” device (“a SIP server”), wherein some aspects of the SIP server instance may be implemented using dedicated hardware of the SIP server node. In other implementations, the SIP server instance and the SIP server node may be separable. The combination of one or more SIP server instances and a SIP server node is generally referred to herein as a SIP server.
SIP messages comprise either a request or a response. A SIP transaction comprises a request that is sent to a SIP server node over a communications channel and that invokes a particular method or function on the SIP server instance. This method or function then results in a response which is sent by the SIP server node over a communications channel in reply to the request. SIP server instances may provide a number of different SIP services. For example, amongst others, provide a logical end-point, provide proxy services, provide redirect services, provide registration services, and/or provide gateway services. As such, the combination of one or more SIP server instances and a SIP server node may implement physical devices such as proxy servers, redirect servers, registration servers, media gateways and session border controllers.
User agents create and/or receive SIP messages. User agents may be software-based, for example a so-called “softphone” operating on a personal computer, or may comprise an embedded system forming part of a hardware device such as an IP phone. Proxy servers are typically used to route SIP requests from a first user agent to, for example, a second user agent. Redirect and registration servers support user mobility. Session border controllers control signaling between two networks. SIP servers may be coupled to a Plain Old Telephone Service (POTS) using a media gateway.
SIP messages may comprise headers and values, all specified as strings. The body of a SIP message may contain a description of a session, for example using a format specified by the Session Description Protocol (SDP). Encryption may also be used, which is referred to as SIPS.
A large scale communications system may manage thousands, if not millions, of communication sessions, for example VoIP calls, multimedia conversations or gaming sessions. Each of these sessions may comprise one or more SIP transactions or SIP “dialogs”, e.g. an on-going exchange of messages between two devices registered to two corresponding users. To cope with this level of SIP traffic a plurality of SIP server instances and/or SIP server nodes are typically required. A SIP server instance has a limitation on the number of SIP messages it can process per time period. This is typically based on underlying physical limitations of a SIP server node that is implementing the SIP server instance. To avoid overloading any one particular SIP server instance and/or SIP server node a load balancer is required. A load balancer has the function of distributing a processing load associated with the SIP traffic across a plurality of SIP server instances. If a first SIP server instance is near capacity, a load balancer can assign new SIP transactions or dialogs to a second SIP server instance with more capacity. SIP load balancers are thus used to provide SIP clients, such as user agents, with a centralized point of access for a scalable network of server instances supporting SIP services, known in the art as a cluster. A SIP load balancer may provide mechanisms to dynamically distribute SIP messages across SIP server instances in order to optimize the collective traffic handling capabilities of the cluster. In some cases they may additionally provide for improved availability of the SIP services provided by the SIP server instances.
SIP server instances, such as SIP proxy instances, may be “stateful” or “stateless”. In these cases the “state” may relate to a transaction, a dialog or a call. A transaction, a dialog or a call can be thought of as a SIP process, i.e. any process that uses the SIP protocol. Stateless systems do not maintain a record of the state of a transaction, dialog or call when processing the transaction, dialog or call. For example, a stateless SIP proxy instance would create no SIP transaction state data when forwarding a request. This results in retransmitted requests being indistinguishable from new requests and thus processed again to produce identical results to a first set of request processing. In comparison, stateful systems maintain, or keep track of, the state of a transaction, dialog or call. For example, a call-stateful SIP proxy instance may store or otherwise remember successful SIP INVITE messages relating to a call, keeping track of any dialogs that are created until the call and any dialogs are terminated with a SIP BYE message. Transaction-stateful proxy instances may generate state information while handling each SIP request, waiting for responses, and handling the responses that arrive so as to, amongst other tasks, recognize transmissions or failure conditions. The Internet Engineering Task Force (IETF) standards document RFC3261 sets out details of stateful SIP systems.
Most SIP load balancers are designed to operate in a generic environment with little or no knowledge of the proxy instances they are distributing traffic to. While these load balancers are suited to distribute SIP traffic to stateless SIP server instances, they can lead to a number of problems when there is a requirement to distribute traffic to stateful SIP server instances. For example, when distributing traffic to stateful SIP server instances, it is necessary to ensure that all messages for a SIP process are routed to the same SIP server node, and the same SIP server instance operating on that SIP server node, for processing. This is because the SIP server instance maintains state information relating to the process; if SIP messages were sent to another SIP server instance it would not have the required state information to suitably process the messages.
One solution to ensure that all messages for a SIP process are routed to the same SIP server instance is to store routing information at the SIP load balancer that correlates a SIP process with a serving SIP server instance. In certain examples, this is achieved using a mapping between a SIP process identifier, such as a call or transaction identifier, and the serving SIP server instance, for example a (virtual) IP address assigned to a SIP server node implementing the SIP server instance. For example, one known system provides a number of node servers that include a storage portion for storing node-session information that associates a SIP or HTTP session ID and a server node. However, if routing information is used then the SIP load balancer must maintain data associated with this information.
In many SIP server cluster arrangements it is typically found that the SIP load balancer becomes the limiting factor with regard to scalability. For example, additional SIP server instances and/or SIP server nodes can be added to increase capacity, but additional SIP load balancers cannot be added without losing the benefits of a centralized point of access. There is thus a problem of increasing scalability for high volume SIP services, such as those provided by cluster architectures. This is compounded when using stateful SIP server instances as a requirement to maintain state information adds processing overheads.