HK1185194B - Sip-based call session server and message-routing method - Google Patents

Description

SIP-based call session server and message routing method

Background

The present invention relates to communication systems. More particularly, but not by way of limitation, the present invention relates to a session initiation protocol (SlP) based call session server and a method of routing messages within the server.

A resiliently distributed and load balanced SIP-based call session server, such as a high capacity IP multimedia subsystem, IMS-CSCF, node, may implement a Call Session Control Function (CSCF). The server is designed to handle many simultaneous one-to-one calls and conference calls while providing its services via only one or a few advertised external interfaces (e.g., SIP standard port 5060 and a few specified IP addresses). The CSCF creates multiple back-to-back user agent (B2BUA) instances on possibly multiple processor elements to handle calls simultaneously and is generally designed to handle not only calls compliant with the standard SIP protocol (RFC3261) but also calls based on variants and/or extensions of the RFC3261 standard, some of which may be proprietary variants and/or extensions. The CSCF may also need to support a combination of a pure RFC3261 call and a number of variants and/or extensions to the RFC 3261-based call at the same time (within the same call session). The CSCF may also control call-related resources using SIP-based protocols. For example, the CSCF acting as a media gateway controller can control media resources in a multimedia gateway/server using SIP based protocols.

When creating multiple B2BUA instances on multiple processor units behind a limited set of external interfaces to handle multiple simultaneous calls, incoming signaling messages from the external nodes must be correlated and routed to the correct B2BUA instance for each call. To accomplish this, the CSCF typically implements a call session aware SIP message routing framework. That is, for each call, the SIP message routing framework must share all call session information (e.g., values of message parameters generated by the B2BUA instance) with the corresponding B2BUA instance.

Existing solutions for SIP message routing in typical implementations of CSCF functionality of call session servers rely on "call ID", "forking", and/or "tagging" parameters in the SIP protocol message headers. RFC3261 requires these parameters to be random and unique in length, space, and time. When a gateway generates these parameters for an outgoing request, the remote/peer gateway involved in the call session is required to respond to them in some form in an incoming response to the call session server.

A typical CSCF generates various SIP message parameters such as call ID, forking, and tagging parameters as arbitrary strings of arbitrary length, making them unique and random in space, time, and across multiple calls. However, due to the nature of the generation process and the randomness of the various parameters, they typically do not have any particular attributes or patterns that can be used by the message routing framework to correlate messages with call sessions and determine the corresponding B2BUA instances within the CSCF to which messages are to be routed. Thus, to assist the routing framework in correlating and routing SIP messages, various parameters generated by its B2BUA instance for each call session are shared with the SIP message routing framework. However, the values of various parameters of a call session may have little or no correlation with one another. In addition, the presence and values of the parameters also depend on the state of the call session in the state machine, which can be call leg specific, and whether the call leg is compliant with pure RFC3261 or a variant/extension thereof. Thus, to efficiently utilize parameter values to correlate and route messages, common substrings are included into parameter values across multiple headers, and call state information is also shared between the B2BUA and the routing layer.

Information sharing between the B2BUA instance and the routing framework is typically accomplished using inter-process communication (IPC) mechanisms and/or distributed databases. In the routing framework, the use of the database also provides resiliency, fault tolerance, and load balancing by parameters of call sessions inserted into call session records and registered into a distributed database that is replicated across all processors in the node (also known as global replication). The routing framework is designed to consist of multiple routing process instances with redundancy distributed across multiple processor units. The B2BUA instance and routing framework store and retrieve call session records from any on-processor database.

The use of common substrings in parameter values and information sharing between the B2BUA instance and the SIP message routing framework presents considerable design problems when attempting to make the routing framework call session aware. The problems fall into three main categories. First, the procedure results in inefficiencies in both the routing framework and the B2BUA layer within the CSCF due to the considerable overhead and complexity of call session information sharing and maintenance between the two layers. Second, because the routing framework is forced to maintain call session information for each call (to achieve resiliency, fault tolerance, and load balancing), if one instance of the routing process crashes, the session information for all affected call sessions must be transferred to another routing process, possibly on another processor unit. This also involves saving and retrieving call session information for the affected calls in a distributed database. However, this introduces considerable overhead and cost in terms of routing process management and database management in the signalling plane. In addition, upon failure in the routing framework, the B2BUA instance of the affected call session must be re-associated with the new routing process instance, and there is additional overhead incurred to manage the association. This wastes processor and memory resources and increases call processing latency, adversely affecting the performance and capacity of the system, while making the overall design of the CSCF complex and therefore expensive.

Third, SIP message header parameters such as call ID, forking and tagging cannot always be relied upon to achieve uniqueness and randomness, while also carrying special attributes in the substring portion to identify the call session. This is because if a substring of the random parameter value string is used as a common substring and mixed with other random strings of SIP header parameters, the overall entropy of the SIP header parameter string is destroyed, resulting in a higher probability of collision at the routing framework. This leads to erroneous routing of messages, especially at high call volumes, since the probability of collisions rises with the number of messages. Thus, using a common string of SIP message header parameters in a manner that makes SIP header values susceptible to collisions violates the randomness requirements of RFC 3261. Furthermore, such a scheme may not work at all when variants/extensions to RFC3261 are to be supported, in particular also signaling based on pure RFC3261 within the same call session. Variants and extensions of the SIP standard can place additional constraints on various parameter values, or can modify existing constraints (according to RFC3261), or can use parameter values to achieve completely non-standard objectives.

European patent application EP1480407a1 discloses a load balancer that routes an incoming message and a destination identifier to one of a plurality of back-end servers indicated by the destination identifier. If the message does not have a destination identifier, the load balancer selects a back-end server using a load balancing algorithm, adds a tag identifying the selected back-end server, and routes the message to the selected back-end server.

Disclosure of Invention

The present invention sets forth a novel scheme for SIP-based message routing within a SIP-based call session server, such as an IMS-CSCF node, that implements a Call Session Control Function (CSCF). The present invention eliminates the need for the message routing framework to have call session awareness in the CSCF in order to properly route SIP messages to and from the nodes. By using this approach, the routing framework can be designed to be algorithmic and thus efficient, resilient, fault tolerant, and highly suitable for deployment in distributed and load balanced node architectures.

The invention has the following features:

1. the need for call session awareness in the SIP call session message routing framework of a SIP based call session server/IMS-CSCF is eliminated.

2. Algorithmic SIP message correlation and routing based on a randomly generated session identifier, hereinafter referred to as a "routing key" in the remainder of this application.

3. Session identifiers (routing keys) that are randomly generated based on factors such as call ID, source tag, and destination tag (also ensuring that their values are unique in time, space, and across multiple call sessions) are used in order to generate parameter values in a manner that does not destroy their entropy. The call ID, origin label and destination label headers are the most common headers present in SIP messages according to the SIP standard and its variants and extensions and are therefore the basis for generating routing keys.

4. The call session information is only maintained within the session control layer (CSCF/B2 BUA instance) and need not be explicitly shared with the message routing framework.

5. Persistent caching of call session information in the database at the routing framework is not required to achieve fault tolerant and resilient repeatable logic.

6. Location independent (i.e., processor element and routing process independent) SIP message correlation and routing results in a highly optimized, load balanced and scalable routing solution. There is no dedicated routing process instance for the call session.

In one embodiment, the present invention is directed to a method of routing SIP messages within a SIP-based call session server, the SIP messages being associated with a call session. The method comprises the following steps: receiving, by the SIP server, an incoming SIP message from the originating node; determining, by the SIP server, a routing key based on at least one header field in the incoming SIP message; identifying, by the SIP server, a back-to-back user agent (B2BUA) instance responsible for the call session using the routing key; sending the incoming SIP message to the identified B2BUA instance; creating an outgoing SIP message by a B2BUA instance, wherein the B2BUA instance generates a header field in the outgoing SIP message by using a routing key; and sending the outgoing SIP message from the SIP server to the terminating node.

In another embodiment, the present invention is directed to a method of routing a SIP message within a SIP-based call session server. The method comprises the following steps: receiving an incoming SIP message from an originating node in the network and transport layers; and forwarding, by the network and transport layer, the incoming SIP message to one of a plurality of SIP message routing process instances in a call session unaware algorithmic SIP message routing framework, wherein the network and transport layer load balances the incoming SIP message across the plurality of SIP message routing process instances on a per message basis. A receiving SIP message routing process instance determines a routing key based on at least one header field in an incoming SIP message. The SIP message routing framework then forwards the incoming SIP message to a selection instance of the plurality of B2BUA instances in the call session control framework based on the routing keyword, wherein the SIP message routing framework load balances the incoming SIP message across the plurality of B2BUA instances on a per call session basis. The method also includes: creating an outgoing SIP message from the selected B2BUA instance, wherein the B2BUA instance generates a header field in the incoming SIP message that depends on the type of the outgoing SIP message using the routing key; forwarding the outgoing SIP message to the network and transport layer via the SIP message routing framework; and sending the outgoing SIP message from the SIP server to the terminating node.

In another embodiment, the present invention is directed to a SIP-based call session server for routing SIP messages. The SEP server comprises: a network and transport layer for receiving incoming SIP messages from an originating node and for sending outgoing SIP messages to a terminating node; an algorithmic SIP message routing framework in communication with the network and transport layers, the SIP message routing framework comprising a plurality of SIP message routing process instances; and a call session control framework in communication with the SIP message routing framework, the call session control framework including a plurality of back-to-back user agent (B2BUA) instances. The network and transport layer forwards the incoming SIP message to one of a plurality of SIP message routing process instances in a SIP message routing framework, wherein the network and transport layer load balances the incoming SIP message across the plurality of SIP message routing process instances on a per-message basis. The receiving SIP message routing process instance determines a routing key based on at least one header field in the incoming SIP message, and forwards the incoming SIP message to a select instance of a plurality of B2BUA instances in a call session control framework based on the routing key, wherein the SIP message routing framework load balances the incoming SIP message across the plurality of B2BUA instances on a per call session basis. The selected B2BUA instance creates an outgoing SIP message using the routing key to generate a header field in the outgoing SIP message that depends on the type of the outgoing SIP message, and forwards the outgoing SIP message to the network and transport layers via the SIP message routing framework. The network and transport layers send outgoing SIP messages to the terminating node.

Taken together, the process of the present invention reduces call processing latency and reduces CPU overhead, thereby improving capacity. The routing framework easily supports load balancing, resiliency and fault tolerance. Any messages for any call session can be handled by any routing procedure but still be routed correctly to the correct B2BUA instance. All routing processes algorithmically execute the same logic without caching or storing/retrieving any information, making the routing framework fault tolerant. The present invention also easily handles SIP extensions and variants since the parameter values are based on the call ID, source tag and destination tag headers used together.

Drawings

In the following sections, the invention will be described with reference to the exemplary embodiments shown in the figures, in which:

FIG. 1 is a flow chart showing the steps of an exemplary embodiment of process 1;

FIG. 2 is a flow chart showing the steps of an exemplary embodiment of process 2;

FIG. 3 is a flow chart showing the steps of an exemplary embodiment of process 3; and

fig. 4 is a simplified block diagram of a SIP call session server/IMS-CSCF node illustrating exemplary message routing for two call sessions in an embodiment of the present invention.

Detailed Description

In an exemplary embodiment, the message routing method of the present invention includes three processes:

process 1: an overall process for algorithmic dependent and stateless routing of SIP messages within a SIP server. This involves generating or retrieving a session identifier called a "routing key" from the incoming SIP message (according to procedure 2); identifying a correct B2BUA responsible for a call session to which the SIP message belongs; and sending the incoming SIP message and the routing key together to the identified B2BUA instance; and generating appropriate parameters for the outgoing SIP message based on the routing key (according to procedure 3).

And (2) a process: a process for generating or retrieving a routing key based on parameters of an incoming SIP message.

And 3, process: a process for generating certain specific SIP message parameter values using routing keys.

Fig. 1 is a flow chart illustrating the steps of an exemplary embodiment of the overall process 1. The messages are shown in a SIP transaction between a User Agent Client (UAC)11, a SIP server 12 and a User Agent Server (UAS) 13. The UAC creates a SIP request message 14 and sends it to the SIP server. At step 15 the SIP server receives the incoming message using the facilities provided by the node on which the server resides. At step 16, the server retrieves or generates routing keys using the process of process 2. The server identifies the B2BUA instance responsible for the call session using the routing key, step 17. In step 18 the server sends the incoming message and the routing key to the identified B2BUA instance 19, which generates an outgoing SIP message. In step 20, the server generates outgoing SIP message header fields using the procedures of procedure 3. At step 21, the server sends the outgoing SIP message to the UAS13 using the facilities provided by the node where the server resides. The same procedure is performed when the UAS13 generates a SIP response message 22 that is routed through the server to the UAC 11. The same procedure is also performed when UAS13 generates a SIP request message 23 that is routed through a server to UAC11 and UAC11 generates a SIP message response 24 that is routed through a server to UAS 13.

Fig. 2 is a flow chart illustrating the steps of an exemplary embodiment of process 2. In this process, the SIP server 12 generates or retrieves routing keys based on the parameters of the incoming SIP message. The process starts at step 30 and passes to step 31 where the SIP server receives an incoming message using the facilities provided by the node where the server resides. At step 32, it is determined whether the incoming message is a request 14 (or 23) or a response 22 (or 24). If the message is a request, the process passes To step 33 where it is determined whether a destination Tag (To-Tag) is present. If a destination tag is present, the process passes to step 34 where the server utilizes a retrieval algorithm F, described below_RetrieveThe routing key is retrieved with the destination tag as input. The process then ends at step 37. If, however, the destination tag does not exist, the process passes to step 35 where the server generates a globally unique alphanumeric string called a routing key in accordance with the random nature of the tag, according to section 19.3 of RFC 3261. In one embodiment, algorithm F is utilized, as described below_RouteThe routing key is generated with the call ID or the source Tag (From-Tag) or both as inputs. The process then ends at step 37.

However, if it is determined in step 32 that the incoming message is a response, the process passes to step 36, in which the server utilizes a retrieval algorithm F, described below_RetrieveThe routing key is retrieved with the source tag as input. The process then ends at step 37.

Fig. 3 is a flow chart illustrating the steps of an exemplary embodiment of process 3. In this process, the SIP server 12 uses the routing key to generate certain specific SIP message parameter values for the outgoing SIP message. The process starts at step 40 and proceeds to step 41 where the server determines whether the outgoing message is a request or a response. If the message is a request, the process passes to step 42, where a generation algorithm F is used, as described below_genA source tag is generated based on the routing key. The process then ends at step 44. However, if it is determined at step 41 that the outgoing message is a response, the process passes to step 43, where the server uses a generating algorithm F, as described below_genA destination label is generated based on the routing key. The process then ends at step 44.

In one embodiment, F_genAnd F_RetrieveThe method is an algorithm and/or a pair of algorithms that are mathematically reciprocal. In the following F_genAnd F_RetrieveIn the example of (1):

F_Genthe output of the algorithm will be either a source tag or a destination tag.

F_RetrieveThe output of the algorithm will be the retrieved routing key.

Algorithm F used in procedures 2 and 3_RetrieveAnd F_GenExamples of (2):

example 1:

F_Gencan be: AES encryption (routing key, p), where p is the passphrase used for encryption.

F_RetrieveMust be: AES decrypt (T, p), where T is the source tag or destination tag, and p is the passphrase used for decryption.

Examples of the invention2：

F_GenCan be: assuming that the routing key is of length N, a random alphanumeric character string is generated and the routing key is appended to the character string such that the result has the routing key as the first N characters.

F_RetrieveMust be: the first N characters of the source tag or the destination tag are collected.

Example 3:

F_Gencan be: an arbitrary alphanumeric character string of length equal to the routing key is generated and the routing key is then interleaved into the string such that the even-numbered position characters of the resulting string are those of the routing key.

F_RetrieveMust be: all even-numbered position characters are collected from the source or destination tags, and the collected characters are concatenated.

Algorithm F used in method 2_RouteExamples of (2):

in the following example, F of the Call ID and/or Source tag of an incoming SIP request message is used_RouteThe output of the algorithm is the generated routing key.

Example (c):

F_Routecan be: the call ID or source tag is used as is.

F_RouteCan be: a tandem call ID and a source tag.

F_RouteCan be: MD5 (call ID).

F_RouteCan be: SHA-1 (Call ID + destination header), where "+" indicates concatenation.

F_RouteCan be: MD5 (Source tag + R-URI), where "+" denotes a cascade。

F_RouteCan be: SHA-1 (Source tag + R-URI + Branch parameter), where "+" indicates concatenation.

F_RouteCan be: TwoFish (origin marker).

F_RouteCan be: SHA-1 (whole SIP message) because the SIP message already contains the call ID and the origination label.

F_RouteCan be: AES (call ID + random string + timestamp), where "+" indicates concatenation.

F_RouteCan be: TripleDES (call ID + random string + node name), where "+" indicates concatenation.

F_RouteCan be: (Call ID + node IP address of the removal point), where "+" indicates concatenation.

F_RouteCan be: (Call ID + timestamp + hardware MAC address of board that received SIP message), where "+" indicates concatenation.

Procedures 1, 2 and 3 are described below using a generalized architecture for a SIP call session server/IMSCSCF node implementation, which is based on the SIP message routing method of the present invention.

Fig. 4 is a simplified block diagram of a SIP call session server/IMS-CSCF node 50 illustrating exemplary message routing for two call sessions in an embodiment of the present invention. The sessions are labeled a and B. The node includes three layers: a call session control framework 51, a SIP message routing framework 52, and a network and transport layer 53.

The call session control framework 51 includes a pool of CSCF/B2BUA instances 54a-54n, one for each call session. The call session control framework is responsible for processing and generating SIP messages according to RFC3261 or variants and extensions thereof. The call session control framework is also responsible for generating specific unique SIP message header fields for outgoing messages based on the incoming initial call setup message. The header fields for the outgoing message are generated in such a way that when those header fields are echoed in the incoming SIP message by a remote point SIP-based node 55 or any co-location or remote resource management node 57 (e.g., media gateway server) that provides its services using a SIP-based signaling protocol, the routing process instances 56a-56n in the SIP message routing framework 52 are able to algorithmically route the incoming message to the correct CSCF/B2BUA instance 54.

The SIP message routing framework 52 includes a pool of resilient SIP message routing process instances 56a-56 n. Each routing process instance is responsible for per-call session load balancing of incoming SIP messages across the pool of CSCF/B2BUA process instances 54a-54 n. The routing process instances are not specific to each call, but rather route incoming SIP messages based on the contents of the message's header fields. Any SIP message can be routed algorithmically by any routing process. The SIP message routing framework is also responsible for forwarding outgoing messages to the network and transport layer 53. The SIP message routing framework has SIP-based protocol awareness, but no call session awareness.

The network and transport layer 53 includes a resilient IP/TCP/UDP/SCTP protocol termination endpoint 58. The network and transport layers are responsible for per-message load balancing of incoming traffic across the pool of SIP message routing process instances 56a-56n in the SIP message routing framework 52. The network and transport layers are also responsible for routing outgoing traffic to the correct destination node 55 or 57.

In the above manner, the present invention utilizes algorithmic routing of SIP messages at the routing layer, which is made possible by the process for generating message parameters. These processes together eliminate:

● the need to explicitly share any call session information between the B2BUA layer and the routing framework layer;

● the distributed database registers any call session records to fulfill the need for resiliency and fault tolerance at the routing framework level;

● overhead in managing resources (processors, memory, and/or databases) to enable information sharing at the B2BUA layer and the routing framework; and

● design the B2BUA and routing framework to achieve fault tolerance complexities (re-associating B2BUA instances and routing procedures; passing affected call sessions from one routing procedure to another in the event of a failure; maintaining call session records using a database and maintaining global copies of the records across various processor units in the node).

As will be recognized by those skilled in the art, the innovative concepts described in the present application can be modified and varied over a wide range of applications. Accordingly, the scope of patented subject matter should not be limited to any of the specific exemplary teachings discussed above, but is instead defined only by the following claims.

Claims (14)

1. A method of routing Session Initiation Protocol (SIP) messages within a SIP-based call session server (12), the SIP messages being associated with a call session, and wherein the SIP server receives incoming SIP messages (14, 24, 22, 23) from an originating node (11, 13) and sends outgoing SIP messages to a terminating node (13, 11), the method being characterized by the steps of:

generating (16), by an algorithmic SIP message routing framework (52) in the SIP server (12), a session identifier, referred to as a routing key, based on at least one header field in the incoming SIP message;

identifying (17), by the SIP server, a back-to-back user agent B2BUA instance (19) responsible for the call session using the routing key;

-sending the incoming SIP message to the identified B2BUA instance (19); and

creating (20) the outgoing SIP message by the B2BUA instance, wherein the B2BUA instance generates a header field in the outgoing SIP message using the routing key;

wherein the SIP message routing framework (52) is free of call session awareness.

2. The method according to claim 1, wherein the step of generating (16) a routing key comprises the steps of:

determining (32) whether the incoming SIP message is a request message or a response message;

retrieving (34) the routing key with the destination tag of the incoming SIP message when the incoming SIP message is a request message and the destination tag is present;

generating (35) the routing key as a globally unique alphanumeric string in a manner that conforms to the random nature of the tag, according to RFC3261, using the call ID of the incoming SIP request message, the source tag of the incoming SIP request message, or both, when the incoming SIP message is a request message and the destination tag is not present; and

when the incoming SIP message is a response message, the routing key is retrieved (36) using the origin tag of the incoming SIP message.

3. The method as claimed in claim 2, wherein the step of retrieving the routing key using a destination tag of an incoming request message or a source tag of an incoming response message comprises retrieving the routing key using a retrieval algorithm, which is an algorithm and/or mathematical inverse of a generation algorithm used by the SIP server to generate the source tag or the destination tag in an outgoing SIP message.

4. The method of claim 3, wherein the generation algorithm is defined as:

AES encryption (routing key, p), where p is the passphrase used for encryption, and the retrieval algorithm is defined as:

AES decrypt (T, p), where T is the source tag or the destination tag, and p is the passphrase used for decryption.

5. The method of claim 3, wherein the generation algorithm is defined as:

generating a random alphanumeric character string assuming the routing key length is N, and appending the routing key to the character string such that the result has the routing key as the first N characters;

and the retrieval algorithm is defined as:

collecting the first N characters of the source mark or the destination mark.

6. The method of claim 3, wherein the generation algorithm is defined as:

generating an arbitrary alphanumeric character string of length equal to the routing key and then interleaving the routing key into the character string such that the even-numbered position characters of the resulting character string are those of the routing key;

and the retrieval algorithm is defined as:

all even-numbered position characters are collected from the source tag or the destination tag, and the collected characters are concatenated.

7. The method according to claim 1, wherein the step of creating (20) the outgoing SIP message comprises the steps of:

determining (41) whether the outgoing SIP message is a request message or a response message;

generating (42) the origin tag in the outgoing SIP message based on the routing key when the outgoing message is a request message; and

-generating (43) the destination tag in the outgoing SIP message based on the routing key when the outgoing message is a response message.

8. The method of claim 7, wherein the step of generating a source tag for a request message or a destination tag for a response message comprises generating the source tag or the destination tag using a generation algorithm that is an algorithm and/or mathematical inverse of a retrieval algorithm used by the SIP server to retrieve the routing key from a source tag or a destination tag in an incoming SIP message.

9. The method of claim 1, wherein:

-the SIP server receiving the incoming SIP message (14, 24, 22, 23) in a network and transport layer (53);

the network and transport layer (53) forwarding the incoming SIP message to one of a plurality of SIP message routing process instances (56a-56n) in an algorithmic SIP message routing framework (52) that is not call session aware, wherein the network and transport layer (53) load balances incoming SIP messages across the plurality of SIP message routing process instances (56a-56n) on a per message basis;

the receiving SIP message routing process instance (56) generating the routing key based on at least one header field in the incoming SIP message;

based on the routing key, the SIP message routing framework (52) sending the incoming SIP message to the identified B2BUA instance (19) in a call session control framework (51), wherein the SIP message routing framework (52) load balances incoming SIP messages across the plurality of B2BUA instances (54a-54n) on a per call session basis;

-the identified B2BUA instance creating (20) an outgoing SIP message using the routing key to generate a header field in the outgoing SIP message that depends on the type of the outgoing SIP message; and

the identified B2BUA instance forwards the outgoing SIP message to the network and transport layer (53) via the SIP message routing framework (52) for sending to the terminating node.

10. The method of claim 9, wherein the step of generating the routing key comprises the steps of:

retrieving the routing key using a retrieval algorithm with a destination tag as input when the incoming SIP message is a request message; and

when the incoming SIP message is a response message, the routing key is retrieved using a retrieval algorithm with the origin tag as input.

11. The method of claim 9, wherein said step of creating an outgoing SIP message comprises the steps of:

when the outgoing SIP message is a request message, generating a source tag in the outgoing SIP message based on the routing keyword; and

when the outgoing SIP message is a response message, a destination tag is generated in the outgoing SIP message based on the routing key.

12. A Session Initiation Protocol (SIP) based call session server (50) for routing SIP messages, wherein the SIP server includes a network and transport layer (53) for receiving incoming SIP messages from an originating node and for sending outgoing SIP messages to a terminating node, the SIP server characterized by:

an algorithmic SIP message routing framework (52) in communication with the network and transport layers (53), wherein the SIP message routing framework is call session unaware and comprises a plurality of SIP message routing process instances (56a-56 n); and

a call session control framework (51) in communication with the SIP message routing framework (52), the call session control framework comprising a plurality of back-to-back user agent B2BUA instances (54a-54 n);

wherein the network and transport layer (53) is configured to forward the incoming SIP message to one of the plurality of SIP message routing process instances (56) in the SIP message routing framework (52), wherein the network and transport layer load balances incoming SIP messages across the plurality of SIP message routing process instances (56a-56n) on a per-message basis;

wherein the receiving SIP message routing process (56) instance is configured to generate a session identifier, referred to as a routing key, based on at least one header field in the incoming SIP message, and to forward the incoming SIP message to a selected B2BUA instance of the plurality of B2BUA instances (54) in the call session control framework (51) based on the routing key, wherein the SIP message routing framework load balances the incoming SIP message across the plurality of B2BUA instances (54a-54n) on a per call session basis;

wherein the selected B2BUA instance (54) is configured to create an outgoing SIP message by generating a header field in the outgoing SIP message that depends on the type of the outgoing SIP message using the routing key;

wherein the selected B2BUA instance forwards the outgoing SIP message to the network and transport layer (53) via the SIP message routing framework (52) for sending the outgoing SIP message to the terminating node.

13. The SIP server of claim 12, wherein the received SIP message routing process instance comprises a processor unit programmed to:

retrieving the routing key using a retrieval algorithm if the destination tag is present when the incoming SIP message is a request message, wherein the retrieval algorithm is an algorithm and/or mathematical inverse of an algorithm used by the SIP server to generate the source tag in an outgoing SIP request message or the destination tag in an outgoing SIP response message; and

generating the routing key as a globally unique alphanumeric string in a manner consistent with the random nature of the tag, according to RFC3261, using the call ID of the incoming SIP request message, the source tag of the incoming SIP request message, or both, if the destination tag is not present in the incoming SIP request message; and

when the incoming SIP message is a response message, the routing key is retrieved using a retrieval algorithm that is an algorithmic and/or mathematical inverse of the algorithm used by the SIP server to generate the destination tag in an outgoing SIP response message or the origin tag in an outgoing SIP request message, taking the origin tag as an input.

14. The SIP server of claim 12, wherein the selected B2BUA instance comprises a processor unit programmed to:

generating a source tag in the outgoing SIP message based on the routing key using a generation algorithm when the outgoing SIP message is a request message, wherein the generation algorithm is an algorithm and/or mathematical inverse of a retrieval algorithm used by the SIP server to retrieve the routing key from the destination tag when the destination tag in the incoming SIP request message is present; and

when the outgoing SIP message is a response message, a destination tag is generated in the outgoing SIP message based on the routing key using a generation algorithm, wherein the generation algorithm is an algorithm and/or mathematical inverse of a retrieval algorithm used by the SIP server to retrieve the routing key from the source tag in the incoming SIP response message.