(19)
(11)EP 2 491 702 B1

(12)EUROPEAN PATENT SPECIFICATION

(45)Mention of the grant of the patent:
23.03.2016 Bulletin 2016/12

(21)Application number: 09748074.3

(22)Date of filing:  21.10.2009
(51)International Patent Classification (IPC): 
H04L 29/12(2006.01)
H04L 29/08(2006.01)
H04W 60/00(2009.01)
H04L 29/06(2006.01)
H04L 29/14(2006.01)
(86)International application number:
PCT/EP2009/063815
(87)International publication number:
WO 2011/047720 (28.04.2011 Gazette  2011/17)

(54)

METHOD AND SYSTEM OF TRANSFERRING A MESSAGE IN A SESSION INITIATION PROTOCOL BASED COMMUNICATIONS NETWORK

VERFAHREN UND SYSTEM ZUR ÜBERTRAGUNG EINER NACHRICHT IN EINEM KOMMUNIKATIONSNETZ AUF SITZUNGSEINLEITUNGSPROTOKOLLBASIS

PROCÉDÉ ET SYSTÈME DE TRANSMISSION D'UN MESSAGE DANS UN RÉSEAU DE TÉLÉCOMMUNICATION DE TYPE SIP (SESSION INITIATION PROTOCOL)


(84)Designated Contracting States:
AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

(43)Date of publication of application:
29.08.2012 Bulletin 2012/35

(73)Proprietor: Telefonaktiebolaget LM Ericsson (publ)
164 83 Stockholm (SE)

(72)Inventor:
  • NOLDUS, Rogier August Caspar Joseph
    NL-5052 BM Goirle (NL)

(74)Representative: V.O. 
P.O. Box 87930
2508 DH Den Haag
2508 DH Den Haag (NL)


(56)References cited: : 
US-A1- 2005 159 156
US-A1- 2009 031 032
  
  • ROSENBERG DYNAMICSOFT H SCHULZRINNE COLUMBIA U J: "Session Initiation Protocol (SIP): Locating SIP Servers; rfc3263.txt" IETF STANDARD, INTERNET ENGINEERING TASK FORCE, IETF, CH, 1 June 2002 (2002-06-01), XP015009041 ISSN: 0000-0003
  
Note: Within nine months from the publication of the mention of the grant of the European patent, any person may give notice to the European Patent Office of opposition to the European patent granted. Notice of opposition shall be filed in a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art. 99(1) European Patent Convention).


Description

TECHNICAL FIELD



[0001] The invention relates to Methods of transferring a message in a Session Initiation Protocol (SIP) based communications network in general. More in particular the invention relates to an Internet Protocol (IP) Multimedia Subsystem (IMS) network.

BACKGROUND



[0002] Voice Over Internet Protocol (VOIP) networks, notably Internet Protocol (IP) Multimedia Subsystem (IMS) networks as defined by the 3rd Generation Partnership Project (3GPP), are designed around a set of functional entities, within this document also referred to as nodes, each performing particular tasks.

[0003] Most of the nodes in a VOIP network, such as an IMS network, are deployed in redundant or geographically distributed method, as is common in telecommunication networks. Reasons include: load sharing (e.g. due to the number of subscribers in the network or due to the call density), geographic distribution (e.g. because of the size of the geographical area to cover) and reliability (e.g. switching over to another node in the case of temporary node outage / link failure or in the case of node maintenance). E.g. when a Serving Call Session Control Function (S-CSCF) entity is temporarily not operational, due to failure or due to planned maintenance, subscribers may be registered in another S-CSCF which will take over the tasks of the inoperational S-CSCF. Likewise, when a P-CSCF is temporarily not operational, the subscriber would have to register with another P-CSCF.

[0004] In one known embodiment, the Home Subscriber Server HSS accepts a request for subscription data from one S-CSCF, whilst the HSS has marked the subscriber as currently being registered with another S-CSCF.

[0005] In another known embodiment, frequent re-registrations are applied. Re-registrations are needed to keep a binding between a public user identity and a contact address (or simply 'binding') in S-CSCF alive. When a Session Initiation Protocol User Agent (SIP-UA) performs re-registration, the registration-related data in the IMS network is (re-)synchronized at that moment. If due to network problems the subscriber's registration had to be moved to another S-CSCF, then resulting from the re-registration, the SIP-UA, P-CSCF, S-CSCF and HSS are again synchronized. By configuring the S-CSCF to instruct a SIP-UA to apply very frequent re-registrations, the time that a subscriber would be non-contactable due to node outage is minimized, at the expense of increased network signalling, which, in commercial IMS deployments, amounts to a large percentage of the total SIP signalling.

[0006] When a P-CSCF becomes inoperational, (regular) re-registration by a SIP-UA would not resolve the problem. The SIP-UA will attempt to register with the same P-CSCF as 'discovered' prior to initial registration.

SUMMARY



[0007] The inventor realised that the known VOIP networks, in particular the IMS networks, may be improved. More in general, it is an object of the invention to provide an improved method of transmitting a message in a SIP based network.

[0008] According to the invention is provided a method according to claim 1 a system according to claims 12 and 15 and an apparatus according to claim 13.

[0009] Thus, the first node is not obliged to send the message to the third node via one predetermined second node, but the first node may derive, e.g. select, one of a plurality of second nodes.

[0010] It is noted that "Session Initiation Protocol (SIP): Locating SIP Servers", by J. Rosenberg, and H. Schulzrinne, Network Working Group RFC 3263, June 2002, relates to a method for transferring a message in a SIP based communications network from a first node to a third node via a second node. Also US 2005/159156 and US 2009/0031032 relate to such method. None of these three documents, however, relates to within a single session or transaction deriving, by the first node, on the basis of the group identifier a network address corresponding to another second node of the plurality of second nodes and transmitting a second message to the third node via the other second node.The present invention may result in improved network robustness. Specifically, it may remove the necessity for a SIP subscriber to remain registered with a particular Proxy Call Session Control Function (P-CSCF) entity as second node and/or with a particular Serving Call Session Control Function (S-CSCF) entity as second node. Node failure in a P-CSCF entity or S-CSCF entity will be handled by another P-CSCF entity or S-CSCF entity taking over responsibility for new SIP sessions, for new SIP transactions or for SIP response messages. Shared user data within a group of P-CSCF entities and within a group of S-CSCF entities may facilitate above-referred taking over.

[0011] Thereto, it is possible that the method comprises synchronising among the plurality of second nodes, data relating to the first and/or third node, e.g. data relating to a relationship between the first and the second node and/or between the third and the second node, such as user data. Thus, each second node of the plurality of second nodes possesses up-to-date data while forwarding the message received from the first node towards the third node. When a second node commences the processing of a message, all second nodes within the group may have up-to-date data. When the processing of the message results in change of data, then the data could be synchronised with, e.g. transmitted to, the other second nodes prior to forwarding the message.

[0012] It is possible that the step of deriving comprises performing a Domain Name Server (DNS) query on the basis of the group identifier. The DNS may for example return a list of Internet Protocol (IP) addresses corresponding to the second nodes of the plurality of second nodes. The first node may then select one of the IP addresses.

[0013] It is possible that the message contains the group identifier, and the method further comprising the steps of deriving, by the third node, on the basis of the group identifier a network address corresponding to one second node of the plurality of second nodes, and transmitting, in response to receiving the message, a response from the third node to the first node via a second node selected by the third node. The first node or the second node may enter the group identifier in the message, e.g. in a header of the message. Thus, the group identifier may be distributed from the first node or second node to the third node. It will be appreciated that the response may be transmitted via a different second node than the message.

[0014] It is possible that the plurality of second nodes is a plurality of user-to-network proxy entities. The plurality of second nodes may be a plurality of Proxy Call Session Control Function (P-CSCF) entities. The group identifier may then be stored in a repository associated with a user equipment, for instance a Session Initiation Protocol User Agent (SIP-UA). The SIP-UA may then transmit the message to e.g. a Serving Call Session Control Function (S-CSCF) entity via one of the plurality of P-CSCF entities. It will be appreciated that herein the user equipment is also referred to as a node.

[0015] It is possible that the plurality of second nodes is a plurality of registrars or service nodes. The plurality of second nodes may be a plurality of S-CSCF entities. The group identifier may then e.g. be stored in a repository associated with a user-to-network proxy, such as a P-CSCF entity or in a repository associated with the SIP-UA). The P-CSCF entity may then transmit the message to a recipient via one of the plurality of S-CSCF entities.

[0016] The invention also relates to a method of performing a Session Initiation Protocol (SIP) session in an Internet Protocol Multimedia Subsystem (IMS) communications network, between a User Agent (UA) and a node, via a selected Proxy Call Session Control Function (P-CSCF) entity and a selected Serving Call Session Control Function (S-CSCF) entity, comprising the steps of storing, in a repository associated with the User agent (UA), a first group identifier associated with a plurality of Proxy Call Session Control Function (P-CSCF) entities, and selecting on the basis of the first group identifier a network address corresponding to one P-CSCF entity of the plurality of P-CSCF entities, and/or storing in a repository associated with the User agent (UA) or the selected P-CSCF entity, a second group identifier associated with a plurality of Serving Call Session Control Function (S-CSCF) entities, and selecting on the basis of the second group identifier a network address corresponding to one S-CSCF entity of the plurality of S-CSCF entities, and transmitting a message to the node via the selected P-CSCF entity and the selected S-CSCF entity. Thus, the message may be transmitted from the User Agent to the node via any one of the P-CSCF entities of the plurality of P-CSCF entities, and/or via any one of the S-CSCF entities of the plurality of S-CSCF entities.

[0017] It is possible that a P-CSCF entity is selected per transaction within the SIP session. It is also possible that a S-CSCF entity is selected per transaction within the SIP session. It is also possible that a P-CSCF entity is selected per message within a single transaction within the SIP session. It is also possible that a S-CSCF entity is selected per message within a single transaction within the SIP session.

[0018] It is possible that the selected P-CSCF entity of the plurality of P-CSCF entities synchronises subscriber data stored in a repository associated with that selected P-CSCF entity to the remaining P-CSCF entities of the plurality of P-CSCF entities, and/or the selected S-CSCF entity of the plurality of S-CSCF entities synchronises subscriber data stored in a repository associated with that selected S-CSCF entity to the remaining S-CSCF entities of the plurality of S-CSCF entities.

[0019] It will be appreciated that if the selected P-CSCF entity of the plurality of P-CSCF entities is selected for a shorter duration, e.g. per transaction, the frequency of synchronisation may increase, but the sensitivity to node failure decreases.

[0020] It is possible that the message comprises the first group identifier and/or the second group identifier, for instance in a Via header and/or a Record-route header.

[0021] In an embodiment, a response to the message, within the context of a single transaction, is transmitted from the node to the User Agent, via a selected Proxy Call Session Control Function (P-CSCF) entity and a selected Serving Call Session Control Function (S-CSCF) entity, wherein the method further comprises selecting, e.g. by the node, on the basis of the first group identifier a network address corresponding to one P-CSCF entity of the plurality of P-CSCF entities, and/or selecting, e.g. by the node or by the P-CSCF entity, on the basis of the second group identifier a network address corresponding to one S-CSCF entity of the plurality of S-CSCF entities. Hence, the response may also be transmitted via any one of the P-CSCF entities of the plurality of P-CSCF entities, and/or via any one of the S-CSCF entities of the plurality of S-CSCF entities.

[0022] The invention also relates to a SIP based communications network, comprising a first node, a second node and a third node, wherein the first node has a repository associated therewith, the repository comprising a group identifier associated with a plurality of second nodes, wherein the first node is arranged for deriving, on the basis of the group identifier, a network address corresponding to one second node of the plurality of second nodes, and wherein the network is arranged for transmitting a message to the third node via the selected second node.

[0023] In the event that the SIP based communications network is an Internet Protocol Multimedia Subsystem (IMS) communications network, the first node may for instance be a User Agent. Then the third node may be a recipient node. Also, the plurality of second nodes may be a plurality of P-CSCF entities or a plurality of S-CSCF entities. It is also possible that the plurality of second nodes comprises two or more groups of second nodes, such as a plurality of P-CSCF entities and a plurality of S-CSCF entities, wherein the message may be transmitted from the first node to a second node of one group, then to a second node of another group, and then to the third node.

[0024] The invention also relates to an Internet Protocol Multimedia Subsystem (IMS) communications network comprising a User Agent (UA), a selected Proxy Call Session Control Function (P-CSCF) entity, a selected Serving Call Session Control Function (S-CSCF) entity and a recipient node, wherein the User Agent has a repository associated therewith, storing a first group identifier associated with a plurality of Proxy Call Session Control Function (P-CSCF) entities, and/or a second group identifier associated with a plurality of Serving Call Session Control Function (S-CSCF) entities, wherein the User Agent is arranged for selecting on the basis of the first group identifier a network address associated with one P-CSCF entity of the plurality of P-CSCF entities, and/or wherein the User Agent or the selected P-CSCF entity is arranged for selecting on the basis of the second group identifier a network address associated with one S-CSCF entity of the plurality of S-CSCF entities, and wherein the network is arranged for transmitting a message to the recipient node via the selected P-CSCF entity and the selected S-CSCF entity.

[0025] Optionally, the plurality of P-CSCF entities is arranged for synchronising subscriber data among the plurality of P-CSCF entities. It is also possible that the plurality of S-CSCF entities is arranged for synchronising subscriber data among the plurality of S-CSCF entities.

[0026] The invention also relates to a network node for transmitting a message to a recipient node via an intermediate node in a Session Initiation Protocol, SIP, based communications network, wherein the node has a repository associated therewith arranged for comprising a group identifier associated with a plurality of intermediate nodes, wherein the node is arranged for deriving, e.g. selecting, on the basis of the group identifier, a network address corresponding to one intermediate node of the plurality of intermediate nodes; and wherein the node is arranged for transmitting a message to the recipient node via the intermediate node derived by the node. Such network node may for instance be a User Agent, e.g. a user equipment, or a P-CSCF entity.

[0027] The invention also relates to a network node for receiving a message from a transmitting node and forwarding the message to a recipient node in a Session Initiation Protocol, SIP, based communications network, wherein the node has a repository associated therewith arranged for comprising a group identifier associated with a plurality of such nodes, wherein the node is arranged for synchronising subscriber data among the plurality of intermediate nodes. Such node may for instance be a P-CSCF entity or a S-CSCF entity.

[0028] The invention also relates to a Session Initiation Protocol message in an Internet Protocol Multimedia Subsystem network, comprising a group identifier associated with a plurality of Proxy Call Session Control Function entities, for instance in a Via header and/or a Record-route header, and/or a group identifier associated with a plurality of Serving Call Session Control Function entities, for instance in a Via header and/or a Record-route header.

BRIEF DESCRIPTION OF THE DRAWINGS



[0029] The invention will now be further elucidated by means of non-limiting examples referring to the drawing, in which

Fig. 1 shows an example of a schematic representation of a network according to the invention;

Fig. 2 shows an example of a schematic representation of logical relationships between nodes in an IMS network according to the invention;

Fig. 3 shows an example of subscriber registration according to the invention;

Fig. 4 shows an example of Session establishment by a User Agent according to the invention;

Fig. 5 shows an example of Session establishment towards a User Agent according to the invention; and

Fig. 6 shows an example of call establishment by a User Agent with transaction based synchronisation according to the invention.


DETAILED DESCRIPTION



[0030] Voice Over Internet Protocol (VOIP) networks, notably Internet Protocol (IP) Multimedia Subsystem (IMS) networks as defined by the 3rd Generation Partnership Project (3GPP), are designed around a set of functional entities, also referred to as nodes herein, each performing particular tasks. These nodes can be used in both prior art networks and in a network according to the invention.

[0031] Below is given a (non-exhaustive) list of typical nodes in a Voice Over IP network. Also is described their usual use in prior art networks.
  • User-to-network proxy entity; the user-to-network proxy entity is functionally connected between a user equipment and the IMS network; it resides at the edge of the IMS network. Between the user-to-network proxy entity and the user equipment, resides the Access Network. Some of the tasks of the user-to-network proxy entity include: ensuring integrity of signalling messages arriving from the user equipment or being sent to the user equipment, asserting data received from the user equipment, applying signalling encryption and signalling compression (e.g. for wireless connections) for data connection with the user equipment.
  • Registrar; when a VOIP subscriber registers as user in the VOIP network, she deposits her public user identity and her contact address, typically an Internet Protocol (IP) address (optionally with a user part), in the registrar. This enables calls being established towards that VOIP user, i.e. towards that public user identity, to be offered to this user's user equipment. The registrar resides in the IP network (sub-network) of the VOIP operator. The combination of public user identity and contact address is known as a binding. The registration procedure may include authentication.
  • Inbound proxy; when a call is established towards a VOIP subscriber, the call will enter the VOIP network via the inbound proxy. The inbound proxy queries a Location server to get an indication of the registrar that holds the binding of this subscriber. The inbound proxy is also used to obtain the address of the registrar that shall be used for subscriber registration.
  • Location server; the location server keeps track of the registrar in which a subscriber is registered. The selection of registrar is done by the VOIP network, not by the user.
  • Network-to-network proxy entity; when a VOIP call is established that breaks out to or breaks in from another network, then the signalling traverses a network-to-network proxy entity. If the other network uses another signalling protocol, e.g. ISDN User Part (ISUP) for the Integrated Services Digital Network (ISDN), then the network-to-network proxy has to perform signalling conversion. For breaking out from VOIP network to another VOIP / non-VOIP network, a 'gateway selector' may be used; this gateway selector selects the Network-to-network proxy entity or gateway to be used for the breakout.


[0032] The above-described nodes for the VOIP network form part of the Control plane, which handles signalling for subscriber registration, the establishment of calls and other tasks. Besides control plane nodes, the VOIP network contains nodes that form part of the User plane. The User plane carries the media for a call, e.g. Pulse Code Modulation (PCM (ITU-T G.711)) encoded voice.

[0033] A signalling protocol commonly used in contemporary VOIP networks is the Session Initiation Protocol (SIP). SIP is defined by the Internet engineering task force (IETF; www.ietf.org) and is published in RFC 3261 (RFC = Request for comments; is a naming convention for IETF standards). Many extensions and enhancements to SIP are introduced, each described in a separate IETF RFC. For carrying voice and other real-time media such as video over the user plane, the Real-time Transport Protocol (RTP) may be used, which is published in RFC 3550. Besides SIP and RTP, Diameter protocol is used between designated nodes in the VOIP network, for various processes, such as registration and terminating call establishment. Diameter base protocol is published in RFC 3588.

[0034] The IP Multimedia Subsystem (IMS) has adopted various protocols from IETF, such as SIP, RTP and Diameter. The architecture of an IMS network includes nodes that resemble the nodes that were described for the VOIP network, such as (list is not exhaustive):

SIP user agent (SIP-UA). The SIP-UA is the user equipment, such as a mobile communications device or a wireline communications device.



[0035] Proxy Call Session Control Function (P-CSCF) entity. The P-CSCF entity serves as user-to-network proxy entity. A subscriber is assigned to a P-CSCF during IMS registration. Hereto, the subscriber (the user equipment) 'discovers' a P-CSCF entity during registration. Various methods are defined for the subscriber to discover his P-CSCF. The selection of P-CSCF may e.g. be done by Dynamic Host Configuration Protocol (DHCP) associated with the Access Network or may be set manually in the user equipment, e.g. by the user. Once a subscriber is registered with a particular user equipment in the IMS network, all call related signalling between this subscriber user equipment and network has to traverse that particular proxy entity, i.e. the P-CSCF.

[0036] Serving Call Session Control Function (S-CSCF) entity. The S-CSCF entity performs the role of registrar. The subscriber places his contact address, e.g. IP address, in a repository associated with the S-CSCF entity, enabling the S-CSCF entity to forward an incoming call to that subscriber. The S-CSCF entity also acts as Service Node. When a call is established from or to an IMS subscriber, the call signalling traverses the S-CSCF entity. The S-CSCF entity may then apply services for this call from/to the subscriber. These services may be performed in the S-CSCF entity or in an external node, such as a SIP Application Server (SIP-AS). As the subscriber will be registered with a particular S-CSCF entity, all call related signalling to/from the end-user has to be handled by this particular S-CSCF entity.

[0037] Interrogating Call Session Control Function (I-CSCF) entity. The I-CSCF entity is the inbound proxy for the IMS network. When a call enters the IMS network, the I-CSCF entity queries a Home Subscriber Server (HSS) to obtain the address of the S-CSCF entity where the subscriber is registered, i.e. which holds the subscribers binding (contact address). In addition, when a subscriber registers in the IMS network, the I-CSCF entity assists in sending the registration message to an appropriate S-CSCF entity (if not already registered) or to the currently used S-CSCF entity (if already registered). I-CSCF does not hold subscriber data.

[0038] Home Subscriber Server (HSS). The HSS holds subscriber records, containing IMS subscription data. When a subscriber registers in the IMS network, the HSS is updated as to which S-CSCF entity is now holding the subscriber's binding. The HSS will, in turn, provide IMS subscription data to the S-CSCF entity. Some of this subscription data may be forwarded from the S-CSCF entity to the P-CSCF entity. And some of that data may be forwarded further from the P-CSCF entity to the user equipment.

[0039] Interconnect Border Control Function (IBCF) entity. The IBCF entity interconnects two IMS networks. In that role, it may perform tasks such as protocol adaptation (e.g. IPv4 - IPv6), service restriction, resource usage restriction (bandwidth control), topology hiding (shielding IP addresses and host names) and interconnect / transit accounting. The IBCF entity does not hold subscriber data.

[0040] Media Gateway Control Function (MGCF) entity. The MGCF entity performs signalling connection between the IMS network and Circuit switched (CS) networks, such as ISDN or GSM. The MGCF entity does not hold subscriber data.

[0041] Most of the nodes in a VOIP network, such as an IMS network, are deployed in redundant or geographically distributed method, as is common in telecommunication networks. Reasons include: load sharing (e.g. due to the number of subscribers in the network or due to the call density), geographic distribution (e.g. because of the size of the geographical area to cover) and reliability (e.g. switching over to another node in the case of temporary node outage / link failure or e.g. in the case of node maintenance).

[0042] As described above, a subscriber will be registered in the prior art IMS network through a particular P-CSCF entity and will be registered in a particular S-CSCF entity. Hence, in order to guarantee correct handling of services in the network, it is required that nodes in the IMS network remain synchronized. One node needs to know which other node is holding subscriber data related to the same subscriber. One can visualize this by depicting registration relationships in the prior art IMS network. These relationships are static, not related to communication activity at any moment. The following registration relationships may be defined:
  1. (1) between SIP-UA and P-CSCF entity
    • The SIP-UA stores the network address of the P-CSCF entity (resulting from P-CSCF discovery procedure), and possibly security association related data and/or signalling compression related data;
    • The P-CSCF entity stores the public identity of the SIP-UA (as received from the SIP-UA), and possibly security association related data and/or signalling compression related data.
  2. (2) between SIP-UA and S-CSCF entity
    • The SIP-UA stores the S-CSCF network address (also referred to as 'Service-route'), as received from the S-CSCF entity in a SIP 200 Ok response to a SIP Register request;
    • The S-CSCF entity stores the contact address of the SIP-UA, as well as terminal capabilities, if applicable, both as received from the SIP-UA in the SIP Register request.
  3. (3) between SIP-UA and HSS
    • The SIP-UA stores subscription data of the subscriber, received from the HSS, via the S-CSCF entity and the P-CSCF entity, such as a list of Public user identities that may be used by this SIP-UA for establishing and receiving calls. The HSS does not store data received from the SIP-UA, so that the relation between the SIP-UA and HSS is unidirectional.
  4. (4) between P-CSCF and S-CSCF
    • The P-CSCF entity stores the S-CSCF entity network address ('Service-route'), as received from the S-CSCF entity;
    • The S-CSCF entity stores the P-CSCF entity network address (also referred to as 'Path'), as received from the P-CSCF entity.
  5. (5) between P-CSCF and HSS
    • The P-CSCF entity stores subscription data of the subscriber received from the HSS, via the S-CSCF entity, such as charging parameters or the aforementioned list of Public user identities. The HSS does not store data received from the P-CSCF entity, so that the relation between the P-CSCF entity and the HSS is unidirectional.
  6. (6) between S-CSCF and HSS
    • The S-CSCF entity stores subscriber subscription data, received from the HSS. The S-CSCF entity does not store the HSS address.
    • The HSS stores the network address of the S-CSCF entity.


[0043] Next, an example of a network according to the invention will be described. It will be appreciated that the network according to the invention in certain aspects relies on the above described relationships between nodes in the prior art network.

[0044] Fig. 1 shows an example of a network 1 according to the invention. In this example, the network comprises a Session Initiation Protocol User Agent (SIP-UA) 2, a plurality of Proxy Call Session Control Function (P-CSCF) entities 4.i (i=1,2,3,...), an Interrogating Call Session Control Function (I-CSCF) entity 6 and a plurality of Serving Call Session Control Function (S-CSCF) entities 8.j (j=1,2,3,...). In this example, the network also comprises a Home Subscriber Server (HSS) 10.

[0045] In this example, the SIP-UA 2 comprises retrieving means 18, a repository 20, input/output means 22, control means 24 and selection means 26. In this example, the P-CSCF entities 4.i each comprise input/output means 28, control means 30, distribution means 31, retrieving means 33, and optionally a repository 32. In this example, the I-CSCF entity 6 comprises input/output means 34, control means 36, retrieving means 38, optional selection means 40 and a repository 42. In this example, the S-CSCF entities 8,j each comprise input/output means 44, control means 46, retrieving means 48, selection means 50, a repository 52 and distribution means 54.

[0046] In this example, for registration the SIP-UA 2 does not discover a single P-CSCF entity network address, but instead discovers a P-CSCF group identifier. The P-CSCF group identifier is associated with the plurality of P-CSCF entities 4.i. The P-CSCF group identifier may for instance be a domain name.

[0047] The actual registration process of the IMS subscriber (SIP-UA) is done through a selected one P-CSCF entity of the plurality of P-CSCF entities 4.i. In this example, the SIP-UA contacts a Domain Name Server (DNS) 16 for retrieving a network address corresponding to the selected P-CSCF entity. Thereto, the SIP-UA may use the retrieving means 18. Here DNS name resolving of the P-CSCF group identifier by the SIP-UA yields the network address, e.g. IP address, of one particular P-CSCF through which the registration shall be done. This particular P-CSCF is used for the registration process. It will be appreciated that the SIP-UA now has derived the network address of one P-CSCF entity of the plurality of P-CSCF entities on the basis of the P-CSCF group identifier. It will be appreciated that DNS may return multiple network addresses, e.g. multiple IP addresses, related to multiple P-CSCF entities of the plurality of P-CSCF entities 4.i. The SIP-UA 2 may in such case select one network address for the registration process using the selection means 26. It will be appreciated that the SIP-UA now has selected the network address of one P-CSCF entity of the plurality of P-CSCF entities on the basis of the P-CSCF group identifier.

[0048] Regular IP address usage may be applied here, entailing that when the sending of the SIP registration message to one IP address fails (because the P-CSCF related to that IP address is not operational at that moment), the SIP-UA may attempt to send the SIP registration message to another IP address. Such method to try a second IP address in the case that the first IP address fails, is standard IP methodology, known in the art.

[0049] It will be appreciated that the DNS 16 may apply a rule when returning multiple network addresses as a response to a P-CSCF group identifier. The DNS may for instance return a list of network addresses, the order of which is adjusted for present load of the P-CSCF entities associated with the network addresses in the list. Alternatively, the DNS 16 may vary, e.g. cycle, the order of the addresses in the list. This may be useful in that nodes often simply use the first address of the list of addresses returned. Alternatively, or additionally, the DNS may append a weight factor to each address returned, for e.g. reflecting the current load for these nodes.

[0050] The Path header that the P-CSCF entity includes in the SIP Register may be the P-CSCF group identifier. The selected P-CSCF entity 4.i forwards the Registration message to an I-CSCF entity 6 which selects a S-CSCF entity 8.j, as in prior art networks. In this example, the I-CSCF entity selects a S-CSCF group identifier for this subscriber, rather than the address (host name) of a single S-CSCF entity. The S-CSCF group identifier is associated with the plurality of S-CSCF entities 8.j.

[0051] The actual registration process is done through a selected S-CSCF entity of the plurality of S-CSCF entities 8.j. In this example, DNS name resolving by the selected I-CSCF entity, yields the network address of the selected S-CSCF entity of the plurality of S-CSCF entities 8.j through which the registration shall be done. It will be appreciated that the DNS 16' queried by the I-CSCF entity may be the same DNS as queried by the SIP-UA, or another DNS. It will be appreciated that DNS may return multiple network addresses, e.g. multiple IP addresses, related to multiple S-CSCF entities of the plurality of S-CSCF entities. The I-CSCF entity may select one IP address using the selection means 40. If the selected S-CSCF entity is not operational, the I-CSCF entity may try to send the SIP Registration message to another S-CSCF entity of the plurality of S-CSCF entities, of which it may also have received the IP address from DNS. It will further be appreciated that the I-CSCF entity may have cached, in the repository 42, the IP addresses of the S-CSCF entities within the plurality of S-CSCF entities. So long as the validity period of these addresses has not expired, the I-CSCF entity would not have to perform a DNS query.

[0052] The selected P-CSCF entity receives a Service-route from the selected S-CSCF entity, in the 200 Ok message. This Service-route may be a group Service-route, rather than a Service-route related to a single S-CSCF entity. The Service-route may comprise the S-CSCF group identifier. The P-CSCF entity may store this group Service-route.

[0053] In this example, the SIP-UA 2 stores the (discovered) P-CSCF group identifier in the repository 20 and uses that every time it initiates a SIP session towards the network or initiates a stand-alone transaction. Similarly, the SIP-UA stores the S-CSCF group identifier that it receives in the 200 Ok for the registration in the repository 20. Each SIP session establishment or stand-alone transaction may be done through a different P-CSCF entity within the plurality of P-CSCF entities 4.i and through a different S-CSCF entity within the plurality of S-CSCF entities 8.j.

[0054] In a preferred embodiment, the data related to (a) the relation between the selected P-CSCF entity and the SIP-UA, (b) the relation between the selected P-CSCF entity and the selected S-CSCF entity and/or (c) the relation between the selected P-CSCF entity and the HSS is not kept solely within the selected P-CSCF entity through which the registration is done, but is distributed within the plurality of P-CSCF entities. Thereto, the P-CSCF entities 4.i may use the distribution means 31. Resulting from this data distribution, SIP session establishment and stand-alone SIP transactions may be done through any of the P-CSCF entities of the plurality of P-CSCF entities.

[0055] Data synchronisation between the P-CSCF entities is schematically depicted in Fig. 1 by arrow 12.

[0056] In a preferred embodiment, the data related to (a) the relation between the selected S-CSCF entity and the SIP-UA, (b) the relation between the selected S-CSCF entity and the selected P-CSCF entity and/or (c) the relation between the selected S-CSCF entity and the HSS is not kept solely within the selected S-CSCF through which the registration is done, but is distributed within the plurality of S-CSCF entities. Thereto, the S-CSCF entities 8.j may use the distribution means 54. Resulting from this data distribution, SIP session establishment and stand-alone SIP transactions may be done through any of the S-CSCF entities within the plurality of S-CSCF entities.

[0057] Data synchronisation between the S-CSCF entities is schematically depicted in Fig. 1 by arrow 14.

[0058] In this example, the HSS 10 stores the S-CSCF group identifier, which it receives from the selected S-CSCF entity through which the subscriber has done registration. When the HSS has to steer a SIP Invite request message or a SIP Register request message to a S-CSCF entity, the SIP Invite or SIP Register will be sent to any of the S-CSCF entities in the plurality of S-CSCF entities.

[0059] When the HSS has to update the subscriber data stored in the S-CSCF entity repository 52, it may perform the updating towards any of the S-CSCF entities within the group of S-CSCF entities allocated to this subscriber. The S-CSCF entity receiving the updated data takes care that the updated data is distributed within the plurality of S-CSCF entities using the distribution means 54.

[0060] Resulting from the registration method as described above, the relationships in the IMS network for a particular subscriber will be as follows.

[0061] The SIP-UA has a relation with a plurality of P-CSCF entities (by virtue of storing the P-CSCF group identifier in the repository 20) as well as a relation with a plurality of S-CSCF entities (by virtue of storing the S-CSCF group identifier in the repository 20). A SIP session or stand-alone transaction initiated by the SIP-UA may be established through any of the P-CSCF entities and any one of the S-CSCF entities within their respective plurality. It is noted that security and compression related data stored by the SIP-UA, needed for the data connection with a P-CSCF over (public) internet shall be such that the SIP-UA can communicate (exchange SIP messages) with any one of the P-CSCF entities within the plurality of P-CSCF entities.

[0062] Each P-CSCF entity within the plurality of P-CSCF entities has, for this subscriber, a relation with this subscriber's plurality of S-CSCF entities (e.g. by virtue of storing the S-CSCF group identifier, in the repository 32). It is noted that security and compression related data stored by each P-CSCF entity, needed for the data connection with the SIP-UA over (public) internet shall be such that each P-CSCF entity of the plurality of P-CSCF entities can communicate (exchange SIP messages) with the SIP-UA.

[0063] Each S-CSCF within the plurality of S-CSCF entities has, for this subscriber, a relation with this subscriber's plurality of P-CSCF entities (e.g. by virtue of storing the P-CSCF group identifier in the repository 52). A SIP session or stand-alone transaction destined for the SIP-UA may be established through any of the S-CSCF entities and any of the P-CSCF entities within their respective plurality.

[0064] The HSS maintains, for this subscriber, a relation with this subscriber's plurality of S-CSCF entities (e.g. by virtue of storing the S-CSCF group identifier).

[0065] An incoming SIP session or stand-alone transaction as well as subscriber data update may be directed towards any one of the S-CSCF entities in the plurality of S-CSCF entities.

[0066] Fig. 2 depicts the relationships that may exist after subscriber registration (registration relationships), in accordance with the above registration.

[0067] Fig. 3 shows an example of registration by the SIP-UA, in accordance with the invention. In step (1), the SIP-UA 2 discovers the P-CSCF address being the P-CSCF group identifier (sip:p-cscf-cluster1.provider.com) identifying a group, here identified as cluster 1, of P-CSCF entities and uses it as Route header in SIP Register. The SIP-UA applies DNS resolving (not depicted) and obtains an IP address associated with the P-CSCF group identifier. In this example, the IP address is the IP address of P-CSCF1. The SIP-UA sends a SIP Register towards this IP address.

[0068] In step (2), P-CSCF1 recognizes the address in the Route header (sip:p-cscf-cluster1.provider.com) as its own group identifier, so removes this Route header. P-CSCF1 adds the group proxy address as Path header (Path:<sip:term@p-cscf-cluster1.provider.com;lr>).

[0069] In step (3), the I-CSCF entity contacts the HSS and receives S-CSCF capabilities. Based on these capabilities, the I-CSCF entity selects the group of S-CSCF entities identified as cluster 1 (sip:s-cscf-cluster1.provider.com) and uses that address as Route header. The I-CSCF entity applies DNS resolving and, in this example retrieves/selects the IP address of S-CSCF2.

[0070] In step (4) S-CSCF2 contacts the HSS and receives authorization data. The HSS stores the address, i.e. the group identifier s-cscf-cluster1.provider.com of the S-CSCF cluster that S-CSCF2 belongs to.

[0071] In step (5) S-CSCF2 stores the data received from the HSS. S-CSCF2 then synchronises subscriber data with the other S-CSCF entities within the plurality of S-CSCF entities, in this case with S-CSCF1.

[0072] All S-CSCF entities in the plurality of S-CSCF entities are now prepared to receive the second registration message.

[0073] In step (6), when P-CSCF1 receives the 401 Unauthorized, it stores data contained in this response and then synchronises subscriber data with the other P-CSCF entities within the plurality of P-CSCF entities, in this case with P-CSCF2.

[0074] All P-CSCF entities in the plurality of P-CSCF entities are now prepared to receive the second registration message.

[0075] In step (7), the SIP-UA sends the second Register message and uses again sip:p-cscf-cluster1.provider.com as the Route header. This time, DNS resolving leads to sending the SIP Register message to P-CSCF2 (but it could also have been P-CSCF1).

[0076] In step (8), P-CSCF2 recognizes the address in the Route header (sip:p-cscf-cluster1.provider.com) as its own group address, so removes this Route header. P-CSCF2 adds the group proxy address as Path header. P-CSCF2 has, due to data synchronization initiated by P-CSCF1, data available for the security relation with the SIP-UA.

[0077] In step (9), the I-CSCF entity (which could be another I-CSCF entity than used in the first registration request) contacts the HSS. The HSS informs the I-CSCF entity that the subscriber shall be registered with s-cscf-cluster1.provider.com. DNS resolving by the I-CSCF entity leads to the SIP Register being sent to S-CSCF1 (but it could also have been S-CSCF2). S-CSCF1 has, due to data synchronization initiated by S-CSCF2, data available for authenticating the subscriber. S-CSCF1 informs the HSS about the subscriber assignment.

[0078] In step (10), the HSS stores the S-CSCF entity address in the form of the S-CSCF group identifier (s-cscf-cluster1.provider.com) and provides S-CSCF1 with subscription data. The HSS is prepared to direct SIP session establishment requests to any of the S-CSCF entities in the plurality of S-CSCF entities.

[0079] In step (11), S-CSCF1 stores the data, as normal, and synchronises subscriber data with the other S-CSCF entities in the plurality of S-CSCF entities, in this case with S-CSCF2. The service-route provided towards the calling party identifies the plurality of S-CSCF entities. All S-CSCF entities in the plurality of S-CSCF entities are now prepared to establish SIP sessions for the subscriber.

[0080] In step (12), P-CSCF2 stores the service-route and optionally other subscriber data (e.g. P-associated-URI) and then synchronises subscriber data with the other P-CSCF entities in the plurality of P-CSCF entities, in this case with P-CSCF1. All P-CSCF entities in the plurality of P-CSCF entities are now prepared to establish SIP sessions for this SIP-UA of this subscriber.

[0081] In step (13), the SIP-UA receives the 200 Ok and stores the Service-route and other subscriber data. The SIP-UA is now ready to establish and receive SIP sessions through any of the P-CSCF entities in the plurality of P-CSCF entities and through any of the S-CSCF entities in the plurality of S-CSCF entities.

[0082] In this example, the distribution of data between logical entities in the IMS network is done through existing SIP signalling methodology. For example, when the SIP-UA registers in the IMS network, it provides its data towards the P-CSCF entity through which the registration is taking place. By virtue of this P-CSCF entity sharing this subscriber data with other P-CSCF entities within the plurality of P-CSCF entities, the SIP-UA is essentially providing its data towards the plurality of P-CSCF entities. This plurality of P-CSCF entities may be considered to constitute a logical P-CSCF entity.

[0083] Likewise, data from the SIP-UA is sent to the S-CSCF entity. The SIP message carrying the data from the SIP-UA to the S-CSCF entity traverses the P-CSCF entity (that is to say, the P-CSCF entity that was selected for the registration procedure). The selected P-CSCF entity may add specific data elements to this SIP message, such as Path. By virtue of the S-CSCF entity sharing the subscriber data with other S-CSCF entities in the plurality of S-CSCF entities, the SIP-UA and P-CSCF entity are essentially providing their data towards the plurality of S-CSCF entities. This plurality of S-CSCF entities may be considered to constitute a logical S-CSCF entity.

[0084] In similar fashion, the S-CSCF entity stores for this subscriber the address of a logical P-CSCF entity, and the HSS stores for this subscriber the address of a logical S-CSCF entity.

[0085] Whenever a SIP session is established or a stand-alone transaction is initiated, the SIP request may be sent via the logical S-CSCF entity for the subscriber and via the logical P-CSCF entity for the subscriber.

[0086] Fig. 4 shows a simplified example of SIP session establishment by the SIP-UA. It is noted that provisional responses are not depicted in this example.

[0087] In step (1), the SIP-UA uses the discovered P-CSCF entity address, i.e. the P-CSCF group identifier, and the received service route, i.e. the S-CSCF group identifier, to set the Route headers in the SIP Invite. DNS resolving by the SIP-UA results in the Invite being sent to one P-CSCF entity of the plurality of P-CSCF entities associated with the P-CSCF group identifier, in this example to P-CSCF1.

[0088] In step (2), the selected P-CSCF entity uses its own address for the Via header and for the Record-route header. This will have the effect that the remainder of the transaction (Via header) as well as the remainder of the SIP session (Record-route header) run through this P-CSCF entity. DNS resolving by P-CSCF1, using the retrieving means 33, results in the Invite being sent to S-CSCF1, in this example.

[0089] In step (3), the selected S-CSCF entity uses its own address for the Via header and for the Record-route header. This will have the effect that the remainder of the transaction as well as the remainder of the SIP session run through this S-CSCF entity.

[0090] In step (4), the SIP-UA stores the received Record-route headers for sending subsequent requests within this SIP session, starting with the Ack request.

[0091] Fig. 5 shows a simplified example of SIP session establishment towards the SIP-UA. It is noted that provisional responses are not depicted in this example.

[0092] In step (1), a SIP session is established towards the S-CSCF entity of the SIP-UA. The address of the S-CSCF entity may e.g. be obtained from the HSS by the I-CSCF entity. In this example, the address will be the S-CSCF group identifier. DNS resolving of the S-CSCF group identifier (in this example by the I-CSCF entity retrieving means 38) results in the Invite being sent to one of the S-CSCF entities of the plurality of S-CSCF entities associated with the S-CSCF group identifier, in this example to S-CSCF1.

[0093] In step (2), the selected S-CSCF1 uses its own address for Via header and for Record-route header. The remainder of the transaction and the remainder of the SIP session are routed through this S-CSCF entity. S-CSCF1 uses the stored Path header to set the Route header. DNS resolving of the P-CSCF group identifier (in this example by S-CSCF1 retrieving means 48) results in the Invite being sent to one P-CSCF entity of the plurality of P-CSCF associated with the P-CSCF group identifier, in this example to P-CSCF1.

[0094] In step (3), the selected P-CSCF1 uses its own address for Via header and for Record-route header. The remainder of the transaction and the remainder of the SIP session are routed through this P-CSCF.

[0095] Fig. 6 shows a simplified example of SIP session establishment by the SIP-UA, whereby data synchronization is applied for each completed SIP transaction.

[0096] In this example, the selected P-CSCF entity and the selected S-CSCF entity use the P-CSCF group identifier and S-CSCF group identifier, respectively, to set the Record route header. As a result, subsequent requests in the SIP session may be handled by any one of the proxy entities within the respective pluralities.

[0097] In this example, neither the data synchronization between P-CSCF entities in the plurality of P-CSCF entities nor the data synchronization between S-CSCF entities in the plurality of S-CSCF entities will be done through SIP signalling or through Diameter procedures. This approach results from the fact that the plurality of P-CSCF entities is addressed as and identifies itself as a single, logical P-CSCF entity.

[0098] In this example, when a P-CSCF entity has processed a registration procedure from a subscriber (Register transaction successfully completed), it uses data distribution techniques to share subscriber data with the other P-CSCF entities in the plurality of P-CSCF entities. This data distribution is preferably completed before the P-CSCF entity responds to the SIP-UA with a confirmation of the registration. A subsequent SIP session establishment or stand-alone SIP transaction may be handled by any of the P-CSCF entities in the plurality of P-CSCF entities, as each P-CSCF entity will have (access to) the subscriber data resulting from the registration.

[0099] The P-CSCF entities in the plurality may each have a database. Alternatively, the P-CSCF entities may have access to a shared database. The same principle can be applied to the S-CSCF entities. A shared database is a common technique for redundant computer systems.

[0100] Likewise, S-CSCF entities in the plurality of S-CSCF entities use data distribution techniques to share subscriber data with the other S-CSCF entities in the plurality.

[0101] Planned server shutdown is described for a P-CSCF entity. It will be appreciated that the principle applies equally for a S-CSCF entity.

[0102] When a P-CSCF entity is to be put into maintenance, DNS 16, 16' could be modified such that DNS will from that moment on no longer return the host name and/or IP address for that particular P-CSCF entity. Due to caching by DNS clients, a defined grace period is preferably applied. After that grace period and resulting from the DNS modification, no node will select this particular P-CSCF entity anymore, when sending a SIP request message to the P-CSCF group identifier. Hence, the load will gradually be distributed over n-1 P-CSCF entities, i.e. the load on the other P-CSCF entities in the group will gradually increase.

[0103] When a particular P-CSCF entity is selected at SIP session establishment, this P-CSCF entity may be used for the entire SIP session. It is needed to monitor the SIP sessions in progress on the P-CSCF entity that is to be put in maintenance mode. All sessions being handled by this P-CSCF entity are preferably completed before the P-CSCF entity can be put into maintenance mode. By that time, all load related to the subscriber group is taken over by the other P-CSCF entities in the plurality of P-CSCF entities. The P-CSCF entity may now be put in maintenance mode.

[0104] When the concept of a logical P-CSCF entity is applied to a single SIP transaction instead of to a single SIP session, the above-referred additional grace period (time needed to monitor the P-CSCF entity for active transactions) will be much shorter, since the duration of a transaction is smaller than the duration of a SIP session.

[0105] When the P-CSCF entity is to be put back into operation, the following steps could be taken in this order (apart from other required steps needed to get the P-CSCF entity fully operational): the P-CSCF entity shall instruct its database to initiate data synchronization with the database(s) from the other P-CSCF entities in the plurality of P-CSCF entities; and when data synchronization is complete, DNS may be modified back, so nodes may select this particular P-CSCF entity when sending a SIP request message to the P-CSCF group identifier. Due to caching IP addressing in other nodes (specifically the SIP-UA and the S-CSCF entity), the load on this P-CSCF entity will gradually increase and the load on the other P-CSCF entities will gradually decrease.

[0106] In general, when, in the case of node failure or node shut down, the load from n P-CSCF entities or m S-CSCF entities needs to be taken over by n-1 P-CSCF entities or m-1 S-CSCF entities, respectively, these n-1 P-CSCF entities or m-1 S-CSCF entities preferably have sufficient capacity hereto. The network (node capacity and link capacity) is preferably dimensioned accordingly.

[0107] Below, node failure is described for a P-CSCF entity. It will be appreciated that the principle applies equally for a S-CSCF entity.

[0108] It is considered that in the case of node failure, ongoing transactions being handled by a P-CSCF entity may be not completed and ongoing SIP sessions may fail, presuming that data related to a SIP session is not synchronized during the SIP session. When a subsequent (i.e. within a Session) transaction request is directed to a particular P-CSCF entity whilst that particular P-CSCF entity has become inoperational since the establishment of the session, that transaction can't be handled by another P-CSCF entity. The unforeseen failure of transaction related signalling will have the effect that the transaction as such fails. In addition, if a SIP session is to be handled in its entirety by the same P-CSCF entity as where the SIP session establishment started, then P-CSCF entity failure has the effect that any SIP session being handled by that P-CSCF entity will fail (e.g. due to absence of heartbeat response messages).

[0109] When an entity establishes a SIP session or (stand-alone) SIP transaction towards the plurality of P-CSCF entities and this entity uses the (cached) host name / IP address of a P-CSCF entity that has node failure, then the SIP session establishment attempt or SIP transaction attempt will fail. DNS methodology may be applied in order to have this entity attempt to establish this SIP session / SIP transaction through any of the other P-CSCF entities. For example, when DNS query is applied for the plurality of P-CSCF entities, the DNS client may receive a set of IP addresses.

[0110] When the P-CSCF entity failure is detected, DNS may be modified as described above for planned server shutdown. Entities will then gradually no longer attempt to contact this P-CSCF entity, thereby reducing the negative effect of the node failure. New SIP sessions may then be handled by the remaining n-1 P-CSCF entities.

[0111] When the node is operational again, the steps for putting node back in operation, as described above for planned server shutdown, may be applied.

[0112] In the foregoing specification, the invention has been described with reference to specific examples of embodiments of the invention. It will, however, be evident that various modifications and changes may be made therein without departing from the scope of the invention as set forth in the appended claims.

[0113] In the preceding has been described that a group of P-CSCF entities may act as a logical P-CSCF entity. It has also been described that a group of S-CSCF entities may act as a logical S-CSCF entity. It will be appreciated that it is also possible that a group of P-CSCF entities acts as a logical P-CSCF entity while use is made of a single S-CSCF entity. It will be appreciated that it is also possible that a group of S-CSCF entities acts as a logical S-CSCF entity while use is made of a single P-CSCF entity.

[0114] It will be appreciated that the group of P-CSCF entities acting as the logical P-CSCF entity and/or the group of S-CSCF entities acting as the logical S-CSCF entity may be used for the establishment and continuation of a SIP session and/or the initiation of a stand-alone SIP transaction.

[0115] It will be appreciated that when a SIP session is established, any new SIP transaction initiated within this SIP session uses a signalling path that is the result of individual SIP proxies adding a Record-route header to the SIP Invite (not considering Back-to-back user agent). When a SIP proxy, e.g. a P-CSCF entity, adds a Record-route header to the SIP Invite, it may use the P-CSCF group identifier. This has the effect that subsequent transactions within this SIP session may be established through any of the P-CSCF entities within the group of P-CSCF entities associated with the group identifier. Alternatively, the P-CSCF entity may use its own name (address) as Record-route header. In that case, subsequent transactions within this SIP session will be established through this specific P-CSCF.

[0116] It will be appreciated that when subsequent transactions within a SIP session are established through any one of the P-CSCF entities within the group, the P-CSCF entity preferably ensures that data synchronization takes place, and preferably is completed, no later than the moment that the P-CSCF entity forwards the last Request or Response message related to this transaction. It will be appreciated that once the P-CSCF entity has forwarded the last Request or Response message related to this transaction, a subsequent transaction may be initiated that may be handled by another P-CSCF entity within the group. That other P-CSCF entity needs to have (access to) the up-to-date subscriber data.

[0117] It will be appreciated that the described method of data synchronization per transaction, if desired, may also be applied to record routing proxies that do not have subscriber data, such as Interconnection Border Control function (IBCF) entities. SIP transactions within one SIP session may then be spread over available IBCF entities within a group of IBCF entities.

[0118] However, other modifications, variations, and alternatives are also possible. The specifications, drawings and examples are, accordingly, to be regarded in an illustrative rather than in a restrictive sense.

[0119] In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word 'comprising' does not exclude the presence of other features or steps than those listed in a claim. Furthermore, the words 'a' and 'an' shall not be construed as limited to 'only one', but instead are used to mean 'at least one', and do not exclude a plurality. The mere fact that certain measures are recited in mutually different claims does not indicate that a combination of these measures cannot be used to advantage.


Claims

1. Method of transferring a first message and a second message in a Session Initiation Protocol, SIP, based communications network (1), from a first node (2) to a third node via a second node (4.i, 8.j), wherein the second node is a user-to-network proxy entity, a registrar or service node, comprising the steps of:

- storing, in a repository (20) associated with the first node, a group identifier associated with a plurality of second nodes; and

characterized by within a single session or within a single transaction:

- deriving, by the first node, on the basis of the group identifier a network address corresponding to one second node of the plurality of second nodes;

- transmitting the first message to the third node via the one second node derived by the first node; and

- synchronising among the plurality of second nodes data relating to the first and/or third node;

- deriving, by the first node, on the basis of the group identifier a network address corresponding to an other second node of the plurality of second nodes; and

- transmitting the second message to the third node via the other second node derived by the first node.


 
2. Method according to claim 1, wherein the step of deriving comprises performing a Domain Name Server, DNS, query on the basis of the group identifier.
 
3. Method according to claim 1 or 2, wherein the first message comprises the group identifier, and the method further comprising the steps:

- deriving, by the third node, on the basis of the group identifier a network address corresponding to one second node of the plurality of second nodes; and

- transmitting, in response to receiving the first message, a response from the third node to the first node via the one second node derived by the third node.


 
4. Method according to claim 1, 2, or 3, wherein the SIP based communications network is an Internet Protocol Multimedia Subsystem, IMS, communications network, and wherein the second node is a Proxy Call Session Control Function, P-CSCF, entity (4.i).
 
5. Method according to claim 1, 2, or 3, wherein the SIP based communications network is an Internet Protocol Multimedia Subsystem, IMS, communications network, and wherein the second node is a Serving Call Session Control Function, S-CSCF, entity (8.j).
 
6. Method according to claim 4, wherein the IMS communications network further includes a Serving Call Session Control Function, S-CSCF, entity (8.j), wherein the method further comprises the steps of:

- discovering a second group identifier associated with a plurality of S-CSCF entities,

- selecting on the basis of the second group identifier a network address corresponding to one S-CSCF entity of the plurality of S-CSCF entities,

- storing data relating to the first and/or third node in a repository (52) associated with the selected S-CSCF,

- synchronising by the selected S-CSCF entity of the plurality of S-CSCF entities synchronises data relating to the first and/or third node stored in the repository associated with that selected S-CSCF entity to the remaining S-CSCF entities of the plurality of S-CSCF entities;

so that the first message may be transmitted through any of the S-CSCF entities in the plurality of S-CSCF entities and the second message may be transmitted through any of the S-CSCF entities in the plurality of S-CSCF entities.
 
7. Method according to claim 5, wherein the IMS communications network further includes a P-CSCF entity (4.i), wherein the method further comprises the steps of:

- discovering a second group identifier associated with a plurality of P-CSCF entities,

- selecting on the basis of the second group identifier a network address corresponding to one P-CSCF entity of the plurality of P-CSCF entities,

- storing data relating to the first and/or third node in a repository (32) associated with the selected P-CSCF,

- synchronising by the selected P-CSCF entity of the plurality of P-CSCF entities the data relating to the first and/or third node stored in the repository associated with that selected P-CSCF entity to the remaining P-CSCF entities of the plurality of P-CSCF entities

so that the first message may be transmitted through any of the P-CSCF entities in the plurality of P-CSCF entities and the second message may be transmitted through any of the P-CSCF entities in the plurality of P-CSCF entities.
 
8. Method according to any one of claims 4-7, wherein the first and/or second message comprises the first group identifier and/or the second group identifier, for instance in a Via header and/or a Record-route header.
 
9. Method according to claim 8, wherein a response to the first and/or second message is transmitted from the third node to the first node, via a selected P-CSCF entity (4.i) and a selected S-CSCF entity (8.j), comprising the steps of:

- selecting on the basis of the first group identifier a network address corresponding to one P-CSCF entity of the plurality of P-CSCF entities; and/or

- selecting on the basis of the second group identifier a network address associated with one S-CSCF entity of the plurality of S-CSCF.


 
10. Method according to any one of claims 8-9, wherein the step of selecting the Proxy Call Session Control Function entity on the basis of the first group identifier, and/or selecting the Serving Call Session Control Function entity on the basis of the second group identifier comprises performing a Domain Name Server, DNS, query using the first group identifier and/or the second group identifier, respectively.
 
11. Method according to claim 10, wherein the Domain Name Server query returns a list of network addresses associated with the first group identifier and/or the second group identifier, respectively, wherein optionally the list reflects a current load state or operational availability state of each Proxy Call Session Control Function entity of the plurality of Proxy Call Session Control Function entities and/or each Serving Call Session Control Function entity of the plurality of Serving Call Session Control Function entities, respectively.
 
12. Session Initiation Protocol, SIP, based communications network (1), such as an Internet Protocol Multimedia Subsystem, IMS, communications network, comprising a first node, such as a User Agent, UA, (2) a second node (4.i, 8.j) such as a selected user-to-network proxy entity, such as a Proxy Call Session Control Function, P-CSCF, entity, and/or a selected registrar or service node, such as a Serving Call Session Control Function, S-CSCF, entity, and a third node, such as a recipient node,
wherein the first node (2) has a repository (20) associated therewith, the repository comprising a group identifier associated with a plurality of second nodes;
characterized in that the first node is arranged for deriving, on the basis of the group identifier, a network address corresponding to one second node of the plurality of second nodes for a first message within a SIP session or within a transaction within a SIP session and a network address corresponding to an other second node of the plurality of second nodes for a second message within the same session or transaction;
wherein the second node is arranged for synchronising among the plurality of second nodes data relating to the first and/or third node; and
wherein the network is arranged for transmitting the first message to the third node via the selected one second node and the second message via the selected other node.
 
13. Network node (2, 4.i, 6, 8.j) for transmitting a first message and a second message to a recipient node via an intermediate node in a Session Initiation Protocol, SIP, based communications network, within a single SIP session or a single transaction within a SIP session,
wherein the network node has a repository (20, 32, 42, 52) associated therewith arranged for comprising a group identifier associated with a plurality of intermediate nodes;
wherein the network node is arranged for deriving, on the basis of the group identifier, a network address corresponding to one intermediate node of the plurality of intermediate nodes; and
wherein the network node is arranged for transmitting the first message to the recipient node via the one intermediate node derived by the network node;
wherein the network node is arranged for synchronising among the plurality of intermediate nodes data relating to the network node and/or the recipient node
wherein the network node is arranged for deriving, on the basis of the group identifier, a network address corresponding to an other intermediate node of the plurality of intermediate nodes; and
wherein the network node is arranged for transmitting the second message to the recipient node via the other intermediate node derived by the network node.
 
14. Network node according to claim 12, wherein the network node is a User Agent, such as a user equipment, or a Proxy Call Session Control Function, P-CSCF, entity.
 
15. Plurality of intermediate network nodes (4.i, 8,j) including a first intermediate network node for receiving a first message from a transmitting node and forwarding the message to a recipient node and a second intermediate network node for receiving a second message from the transmitting node and forwarding the message to the recipient node in a Session Initiation Protocol, SIP, based communications network within a single SIP session or a single transaction within a SIP session,
wherein each intermediate node has a repository (32, 52) associated therewith arranged for comprising a group identifier associated with a plurality of such intermediate nodes;
wherein each intermediate node is arranged for synchronising subscriber data among the plurality of intermediate nodes.
 


Ansprüche

1. Verfahren zur Übertragung einer ersten Nachricht und einer zweiten Nachricht in einem Kommunikationsnetz (1) auf Sitzungseinleitungsprotokollbasis (engl. Session Initiation Protocol, kurz SIP) von einem ersten Knoten (2) zu einem dritten Knoten über einen zweiten Knoten (4.i, 8.j), wobei der zweite Knoten eine Benutzer-zu-Netzwerk Proxy-Entität, ein Registrar oder ein Service-Knoten ist, umfassend folgende Schritte:

- Speichern eines Gruppenidentifikators, verbunden mit mehreren zweiten Knoten, in einem Repository (20), verbunden mit dem ersten Knoten;

und
gekennzeichnet innerhalb einer einzelnen Sitzung oder innerhalb einer einzelnen Transaktion durch:

- Ableiten einer Netzwerkadresse entsprechend dem zweiten Knoten der mehreren zweiten Knoten durch den ersten Knoten anhand des Gruppenidentifikators;

- Übertragen der ersten Nachricht an den dritten Knoten über den einen zweiten Knoten, abgeleitet durch den ersten Knoten; und

- Synchronisieren von Daten, bezogen auf den ersten und/oder dritten Knoten, unter den mehreren zweiten Knoten;

- Ableiten einer Netzwerkadresse entsprechend einem anderen zweiten Knoten der mehreren zweiten Knoten durch den ersten Knoten anhand des Gruppenidentifikators; und

- Übertragen der zweiten Nachricht an den dritten Knoten über den anderen zweiten Knoten, abgeleitet durch den ersten Knoten.


 
2. Verfahren nach Anspruch 1, wobei der Schritt des Ableitens die Ausführung einer DNS (engl. Domain Name Server)-Abfrage anhand des Gruppenidentifikators umfasst.
 
3. Verfahren nach Anspruch 1 oder 2, wobei die erste Nachricht den Gruppenidentifikator umfasst und das Verfahren ferner folgende Schritte umfasst:

- Ableiten einer Netzwerkadresse entsprechend dem einen zweiten Knoten der mehreren zweiten Knoten durch den dritten Knoten anhand des Gruppenidentifikators; und

- Übertragen, in Reaktion auf das Empfangen der ersten Nachricht, einer Antwort vom dritten Knoten zum ersten Knoten über den einen zweiten Knoten, abgeleitet durch den dritten Knoten.


 
4. Verfahren nach Anspruch 1, 2 oder 3, wobei das Kommunikationsnetz auf SIP-Basis ein IMS (engl. Internet Protocol Multimedia Subsystem)-Kommunikationsnetz ist und wobei der zweite Knoten eine P-CSCF (engl. Proxy Call Session Control Function)-Entität (4.i) ist.
 
5. Verfahren nach Anspruch 1, 2 oder 3, wobei das Kommunikationsnetz auf SIP-Basis ein IMS-Kommunikationsnetz ist und wobei der zweite Knoten eine S-CSCF (engl. Serving Call Session Control Function)-Entität (8.j) ist.
 
6. Verfahren nach Anspruch 4, wobei das IMS-Kommunikationsnetz ferner eine S-CSCF-Entität (8.j) umfasst, wobei das Verfahren ferner folgende Schritte umfasst:

- Feststellen eines zweiten Gruppenidentifikators, verbunden mit mehreren S-CSCF-Entitäten,

- Auswählen einer Netzwerkadresse entsprechend einer S-CSCF-Entität der mehreren S-CSCF-Entitäten anhand des zweiten Gruppenidentifikators,

- Speichern von Daten bezogen auf den ersten und/oder dritten Knoten in einem Repository (52), verbunden mit der ausgewählten S-CSCF,

- Synchronisieren, durch die ausgewählte S-CSCF-Entität der mehreren S-CSCF-Entitäten, von Daten bezogen auf den ersten und/oder dritten Knoten, gespeichert in dem Repository, verbunden mit dieser ausgewählten S-CSCF-Entität, mit den restlichen S-CSCF-Entitäten der mehreren S-CSCF-Entitäten;

sodass die erste Nachricht durch eine beliebige der S-CSCF-Entitäten in den mehreren S-CSCF-Entitäten übertragen werden kann und die zweite Nachricht durch eine beliebige der S-CSCF-Entitäten in den mehreren S-CSCF-Entitäten übertragen werden kann.
 
7. Verfahren nach Anspruch 5, wobei das IMS-Kommunikationsnetz ferner eine P-CSCF-Entität (4.i) umfasst, wobei das Verfahren ferner folgende Schritte umfasst:

- Feststellen eines zweiten Gruppenidentifikators, verbunden mit mehreren P-CSCF-Entitäten,

- Auswählen einer Netzwerkadresse entsprechend einer P-CSCF-Entität der mehreren P-CSCF-Entitäten anhand des zweiten Gruppenidentifikators,

- Speichern von Daten bezogen auf den ersten und/oder dritten Knoten in einem Repository (32), verbunden mit der ausgewählten P-CSCF,

- Synchronisieren, durch die ausgewählte P-CSCF-Entität der mehreren P-CSCF-Entitäten, von Daten bezogen auf den ersten und/oder dritten Knoten, gespeichert in dem Repository, verbunden mit dieser ausgewählten P-CSCF-Entität, mit den restlichen P-CSCF-Entitäten der mehreren S-CSCF-Entitäten

sodass die erste Nachricht durch eine beliebige der P-CSCF-Entitäten in den mehreren P-CSCF-Entitäten übertragen werden kann und die zweite Nachricht durch eine beliebige der P-CSCF-Entitäten in den mehreren P-CSCF-Entitäten übertragen werden kann.
 
8. Verfahren nach einem der Ansprüche 4-7, wobei die erste und/oder zweite Nachricht den ersten Gruppenidentifikator und/oder den zweiten Gruppenidentifikator umfasst, zum Beispiel in einem Via-Header und/oder einem Record-route-Header.
 
9. Verfahren nach Anspruch 8, wobei eine Antwort auf die erste und/oder zweite Nachricht vom dritten Knoten an den ersten Knoten über eine ausgewählte P-CSCF-Entität (4.i) und eine ausgewählte S-CSCF-Entität (8.j) übertragen wird, umfassend folgende Schritte:

- Auswählen einer Netzwerkadresse entsprechend einer P-CSCF-Entität der mehreren P-CSCF-Entitäten anhand des ersten Gruppenidentifikators; und/oder

- Auswählen einer Netzwerkadresse entsprechend einer S-CSCF-Entität der mehreren S-CSCF-Entitäten anhand des zweiten Gruppenidentifikators.


 
10. Verfahren nach einem der Ansprüche 8-9, wobei die Schritte des Auswählens der P-CSCF-Entität anhand des ersten Gruppenidentifikators und/oder des Auswählens der S-CSCF-Entität anhand des zweiten Gruppenidentifikators das Ausführen einer DNS-Abfrage unter Verwendung des ersten Gruppenidentifikators und/oder des zweiten Gruppenidentifikators umfassen.
 
11. Verfahren nach Anspruch 10, wobei die DNS-Abfrage eine Liste von Netzwerkadressen, verbunden mit dem ersten Gruppenidentifikator und/oder dem zweiten Gruppenidentifikator zurückgibt, wobei optional die Liste einen aktuellen Belastungszustand oder operationellen Verfügbarkeitszustand jeder P-CSCF-Entität der mehreren P-CSCF-Entitäten und/oder jeder S-CSCF-Entität der mehreren S-CSCF-Entitäten wiedergibt.
 
12. Kommunikationsnetz (1) auf Sitzungseinleitungsprotokollbasis (SIP), wie etwa ein IMS (Internet Protocol Multimedia Subsystem)-Kommunikationsnetz, umfassend einen ersten Knoten, wie etwa einen User Agent, UA (2), einen zweiten Knoten (4.i, 8.j) wie etwa eine ausgewählte Benutzer-zu-Netzwerk Proxy-Entität, wie etwa eine P-CSCF (Proxy Call Session Control Function)-Entität und/oder einen ausgewählten Registrar oder Serviceknoten, wie etwa eine S-CSCF (Serving Call Session Control Function)-Entität, und einen dritten Knoten, wie etwa einen Empfängerknoten,
wobei der erste Knoten (2) ein damit verbundenes Repository (20) umfasst, das Repository umfassend einen Gruppenidentifikator, verbunden mit mehreren zweiten Knoten;
dadurch gekennzeichnet, dass der erste Knoten angeordnet ist, um anhand des Gruppenidentifikators eine Netzwerkadresse entsprechend einem zweiten Knoten der mehreren zweiten Knoten für eine erste Nachricht innerhalb einer SIP-Sitzung oder innerhalb einer Transaktion innerhalb einer SIP-Sitzung und eine Netzwerkadresse entsprechend einem anderen zweiten Knoten der mehreren zweiten Knoten für eine zweite Nachricht innerhalb derselben Sitzung oder Transaktion abzuleiten;
wobei der zweite Knoten angeordnet ist, um unter den mehreren zweiten Knoten Daten bezogen auf den ersten und/oder dritten Knoten zu synchronisieren; und
wobei das Netzwerk angeordnet ist, um die erste Nachricht an den dritten Knoten über den ausgewählten einen zweiten Knoten und die zweite Nachricht über den ausgewählten anderen Knoten zu übertragen.
 
13. Netzwerkknoten (2, 4.i, 6, 8.j) zum Übertragen einer ersten Nachricht und einer zweiten Nachricht an einen Empfängerknoten über einen Zwischenknoten in einem Kommunikationsnetz auf SIP-Basis innerhalb einer einzelnen SIP-Sitzung oder einer einzelnen Transaktion innerhalb einer SIP-Sitzung,
wobei der Netzwerkknoten ein damit verbundenes Repository (20, 32, 42, 52) hat, angeordnet um einen Gruppenidentifikator, verbunden mit mehreren der Zwischenknoten, zu umfassen;
wobei der Netzwerkknoten angeordnet ist, um anhand des Gruppenidentifikators eine Netzwerkadresse entsprechend einem Zwischenknoten der mehreren Zwischenknoten abzuleiten; und
wobei der Netzwerkknoten angeordnet ist, um die erste Nachricht an den Empfängerknoten über den einen Zwischenknoten, abgeleitet durch den Netzwerkknoten, zu übertragen;
wobei der Netzwerkknoten angeordnet ist, um unter den mehreren Zwischenknoten Daten bezogen auf den Netzwerkknoten und/oder den Empfängerknoten zu synchronisieren;
wobei der Netzwerkknoten angeordnet ist, um anhand des Gruppenidentifikators eine Netzwerkadresse entsprechend einem anderen Zwischenknoten der mehreren Zwischenknoten abzuleiten; und
wobei der Netzwerkknoten angeordnet ist, um die zweite Nachricht an den Empfängerknoten über den anderen Zwischenknoten, abgeleitet durch den Netzwerkknoten, zu übertragen.
 
14. Netzwerkknoten nach Anspruch 12, wobei der Netzwerkknoten ein User Agent wie etwa eine Benutzerausrüstung oder eine P-CSCF-Entität ist.
 
15. Mehrere Zwischennetzwerkknoten (4.i, 8.j), umfassend einen ersten Netzwerkzwischenknoten zum Empfangen einer ersten Nachricht von einem Übertragungsknoten und Weiterleiten der Nachricht an einen Empfängerknoten und einen zweiten Netzwerkzwischenknoten zum Empfangen einer zweiten Nachricht von dem Übertragungsknoten und Weiterleiten der Nachricht an einen Empfängerknoten in einem Kommunikationsnetz auf SIP-Basis innerhalb einer einzelnen SIP-Sitzung oder einer einzelnen Transaktion innerhalb einer SIP-Sitzung,
wobei jeder Zwischenknoten ein damit verbundenes Repository (32, 52) hat, angeordnet um einen Gruppenidentifikator, verbunden mit mehreren solcher Zwischenknoten, zu umfassen;
wobei jeder Zwischenknoten angeordnet ist, um Abonnentendaten unter den mehreren Zwischenknoten zu synchronisieren.
 


Revendications

1. Procédé de transfert d'un premier message et d'un second message dans un réseau de communication de type « protocole d'ouverture de session », SIP (1), d'un premier noeud (2) à un troisième noeud par l'intermédiaire d'un deuxième noeud (4.i, 8.j), dans lequel le deuxième noeud est une entité mandataire de type « utilisateur vers réseau », un noeud d'enregistrement ou un noeud de service, comprenant les étapes ci-dessous consistant à :

- stocker, dans un référentiel (20) associé au premier noeud, un identifiant de groupe associé à une pluralité de deuxièmes noeuds ; et

caractérisé par les étapes ci-dessous consistant à, au cours d'une session unique ou d'une opération unique :

- dériver, par le premier noeud, sur la base de l'identifiant de groupe, une adresse réseau correspondant à un deuxième noeud de la pluralité de deuxièmes noeuds ;

- transmettre le premier message au troisième noeud par l'intermédiaire dudit un deuxième noeud dérivé par le premier noeud ; et

- synchroniser, parmi la pluralité de deuxièmes noeuds, des données relatives au(x) premier et/ou troisième noeuds ;

- dériver, par le premier noeud, sur la base de l'identifiant de groupe, une adresse réseau correspondant à un autre deuxième noeud de la pluralité de deuxièmes noeuds ; et

- transmettre le second message au troisième noeud par l'intermédiaire de l'autre deuxième noeud dérivé par le premier noeud.


 
2. Procédé selon la revendication 1, dans lequel l'étape de dérivation consiste à mettre en oeuvre une demande de serveur de noms de domaine, DNS, sur la base de l'identifiant de groupe.
 
3. Procédé selon la revendication 1 ou 2, dans lequel le premier message comprend l'identifiant de groupe, et le procédé comporte en outre les étapes ci-dessous consistant à :

- dériver, par le troisième noeud, sur la base de l'identifiant de groupe, une adresse réseau correspondant à un deuxième noeud de la pluralité de deuxièmes noeuds ; et

- transmettre, en réponse à la réception du premier message, une réponse du troisième noeud au premier noeud par l'intermédiaire dudit un deuxième noeud dérivé par le troisième noeud.


 
4. Procédé selon la revendication 1, 2 ou 3, dans lequel le réseau de communication de type « protocole SIP » est un réseau de communication de sous-système multimédia de protocole Internet, IMS, et dans lequel le deuxième noeud est une entité de fonction mandataire de commande de session d'appel, P-CSCF (4.i).
 
5. Procédé selon la revendication 1, 2 ou 3, dans lequel le réseau de communication de type « protocole SIP » est un réseau de communication de sous-système multimédia de protocole Internet, IMS, et dans lequel le deuxième noeud est une entité de fonction serveuse de commande de session d'appel, S-CSCF (8.j).
 
6. Procédé selon la revendication 4, dans lequel le réseau de communication de sous-système IMS inclut en outre une entité de fonction serveuse de commande de session d'appel, S-CSCF (8.j), dans lequel le procédé comprend en outre les étapes ci-dessous consistant à :

- découvrir un second identifiant de groupe associé à une pluralité d'entités de fonction S-CSCF ;

- sélectionner, sur la base du second identifiant de groupe, une adresse réseau correspondant à une entité de fonction S-CSCF de la pluralité d'entités de fonction S-CSCF ;

- stocker des données relatives au(x) premier et/ou troisième noeuds dans un référentiel (52) associé à la fonction S-CSCF sélectionnée ;

- synchroniser, par l'entité de fonction S-CSCF sélectionnée de la pluralité d'entités de fonction S-CSCF, des données relatives au(x) premier et/ou troisième noeuds, stockées dans le référentiel associé à cette entité de fonction S-CSCF sélectionnée, sur les entités de fonction S-CSCF restantes de la pluralité d'entités de fonction S-CSCF ;

de sorte que le premier message peut être transmis à travers l'une quelconque des entités de fonction S-CSCF dans la pluralité d'entités de fonction S-CSCF et que le second message peut être transmis à travers l'une quelconque des entités de fonction S-CSCF dans la pluralité d'entités de fonction S-CSCF.
 
7. Procédé selon la revendication 5, dans lequel le réseau de communication de sous-système IMS inclut en outre une entité de fonction P-CSCF (4.i), dans lequel le procédé comprend en outre les étapes ci-dessous consistant à :

- découvrir un second identifiant de groupe associé à une pluralité d'entités de fonction P-CSCF ;

- sélectionner, sur la base du second identifiant de groupe, une adresse réseau correspondant à une entité de fonction P-CSCF de la pluralité d'entités de fonction P-CSCF ;

- stocker des données relatives au(x) premier et/ou troisième noeuds dans un référentiel (32) associé à la fonction P-CSCF sélectionnée ;

- synchroniser, par l'entité de fonction P-CSCF sélectionnée de la pluralité d'entités de fonction P-CSCF, des données relatives au(x) premier et/ou troisième noeuds, stockées dans le référentiel associé à cette entité de fonction P-CSCF sélectionnée, sur les entités de fonction P-CSCF restantes de la pluralité d'entités de fonction P-CSCF ;

de sorte que le premier message peut être transmis à travers l'une quelconque des entités de fonction P-CSCF dans la pluralité d'entités de fonction P-CSCF et que le second message peut être transmis à travers l'une quelconque des entités de fonction P-CSCF dans la pluralité d'entités de fonction P-CSCF.
 
8. Procédé selon l'une quelconque des revendications 4 à 7, dans lequel le ou les premier et/ou second messages comportent le premier identifiant de groupe et/ou le second identifiant de groupe, par exemple dans un entête de type « Via » et/ou dans un entête de type « enregistrement de chemin » (Record-route).
 
9. Procédé selon la revendication 8, dans lequel une réponse au(x) premier et/ou second messages est transmise du troisième noeud au premier noeud, par l'intermédiaire d'une entité de fonction P-CSCF sélectionnée (4.i) et d'une entité de fonction S-CSCF sélectionnée (8.j), comprenant les étapes ci-dessous consistant à :

- sélectionner, sur la base du premier identifiant de groupe, une adresse réseau correspondant à une entité de fonction P-CSCF de la pluralité d'entités de fonction P-CSCF ; et/ou

- sélectionner, sur la base du second identifiant de groupe, une adresse réseau associée à une entité de fonction S-CSCF de la pluralité d'entités de fonction S-CSCF.


 
10. Procédé selon l'une quelconque des revendications 8 à 9, dans lequel l'étape de sélection de l'entité de fonction mandataire de commande de session d'appel sur la base du premier identifiant de groupe, et/ou l'étape de sélection de l'entité de fonction serveuse de commande de session d'appel sur la base du second identifiant de groupe, consiste(nt) à mettre en oeuvre une demande de serveur de noms de domaine, DNS, en utilisant le premier identifiant de groupe et/ou le second identifiant de groupe, respectivement.
 
11. Procédé selon la revendication 10, dans lequel la demande de serveur de noms de domaine renvoie une liste d'adresses réseau associées au premier identifiant de groupe et/ou au second identifiant de groupe, respectivement, dans lequel facultativement la liste reflète un état de charge en cours ou un état de disponibilité fonctionnelle de chaque entité de fonction mandataire de commande de session d'appel de la pluralité d'entités de fonction mandataire de commande de session d'appel et/ou de chaque entité de fonction serveuse de commande de session d'appel de la pluralité d'entités de fonction serveuse de commande de session d'appel, respectivement.
 
12. Réseau de communication de type « protocole d'ouverture de session », SIP (1), par exemple un réseau de communication de sous-système multimédia de protocole Internet, IMS, comprenant un premier noeud, par exemple un agent utilisateur, UA (2), un deuxième noeud (4.i, 8.j), par exemple une entité mandataire de type « utilisateur vers réseau » sélectionnée, par exemple une entité de fonction mandataire de commande de session d'appel, P-CSCF, et/ou un noeud d'enregistrement ou un noeud de service sélectionné, par exemple une entité de fonction serveuse de commande de session d'appel, S-CSCF, et un troisième noeud, par exemple un noeud destinataire ;
dans lequel le premier noeud (2) présente un référentiel (20) qui lui est associé, le référentiel comprenant un identifiant de groupe associé à une pluralité de deuxièmes noeuds ;
caractérisé en ce que le premier noeud est agencé de manière à dériver, sur la base de l'identifiant de groupe, une adresse réseau correspondant à un deuxième noeud de la pluralité de deuxièmes noeuds pour un premier message dans une session de protocole SIP, ou au sein d'une opération dans une session de protocole SIP, et une adresse réseau correspondant à une autre deuxième noeud de la pluralité de deuxièmes noeuds pour un second message dans la même session ou opération ;
dans lequel le deuxième noeud est agencé de manière à synchroniser, parmi la pluralité de deuxièmes noeuds, des données relatives au(x) premier et/ou troisième noeuds ; et
dans lequel le réseau est agencé de manière à transmettre le premier message au troisième noeud, par l'intermédiaire dudit un deuxième noeud sélectionné, et le second message par l'intermédiaire de l'autre noeud sélectionné.
 
13. Noeud de réseau (2, 4.i, 6, 8.j) destiné à transmettre un premier message et un second message à un noeud destinataire par le biais d'un noeud intermédiaire dans un réseau de communication de type « protocole d'ouverture de session », SIP, au cours d'une unique session de protocole SIP ou d'une opération unique dans une session de protocole SIP ;
dans lequel le noeud de réseau présente un référentiel (20, 32, 42, 52), qui lui est associé, agencé de manière à comporter un identifiant de groupe associé à une pluralité de noeuds intermédiaires ;
dans lequel le noeud de réseau est agencé de manière à dériver, sur la base de l'identifiant de groupe, une adresse réseau correspondant à un noeud intermédiaire de la pluralité de noeuds intermédiaires ; et
dans lequel le noeud de réseau est agencé de manière à transmettre le premier message au noeud destinataire par l'intermédiaire dudit un noeud intermédiaire dérivé par le noeud de réseau ;
dans lequel le noeud de réseau est agencé de manière à synchroniser, parmi la pluralité de noeuds intermédiaires, des données relatives au noeud de réseau et/ou au noeud destinataire ;
dans lequel le noeud de réseau est agencé de manière à dériver, sur la base de l'identifiant de groupe, une adresse réseau correspondant à un autre noeud intermédiaire de la pluralité de noeuds intermédiaires ; et
dans lequel le noeud de réseau est agencé de manière à transmettre le second message au noeud destinataire par l'intermédiaire de l'autre noeud intermédiaire dérivé par le noeud de réseau.
 
14. Noeud de réseau selon la revendication 12, dans lequel le noeud de réseau est un agent utilisateur, par exemple un équipement d'utilisateur, ou une entité de fonction mandataire de commande de session d'appel, P-CSCF.
 
15. Pluralité de noeuds de réseau intermédiaires (4.i, 8, j) incluant un premier noeud de réseau intermédiaire destiné à recevoir un premier message en provenance d'un noeud émetteur et à transférer le message à un noeud destinataire, et incluant un second noeud de réseau intermédiaire destiné à recevoir un second message en provenance du noeud émetteur et à transférer le message au noeud destinataire dans un réseau de communication de type « protocole d'ouverture de session », SIP, au cours d'une unique session de protocole SIP ou d'une opération unique dans une session de protocole SIP ;
dans lequel chaque noeud intermédiaire présente un référentiel (32, 52), qui lui est associé, agencé de manière à comporter un identifiant de groupe associé à une pluralité de tels noeuds intermédiaires ; et
dans lequel chaque noeud intermédiaire est agencé de manière à synchroniser des données d'abonné parmi la pluralité de noeuds intermédiaires.
 




Drawing























Cited references

REFERENCES CITED IN THE DESCRIPTION



This list of references cited by the applicant is for the reader's convenience only. It does not form part of the European patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be excluded and the EPO disclaims all liability in this regard.

Patent documents cited in the description




Non-patent literature cited in the description