WO2016050291A1

WO2016050291A1 - Parallel registration in an internet multimedia subsystem

Info

Publication number: WO2016050291A1
Application number: PCT/EP2014/071035
Authority: WO
Inventors: Peter Leis; Jiadong Shen
Original assignee: Nokia Solutions And Networks Oy
Priority date: 2014-10-01
Filing date: 2014-10-01
Publication date: 2016-04-07

Abstract

Systems, methods, apparatuses, and computer program products for parallel registration, for example, in internet multimedia system (IMS) are provided. One method includes, during session creation using session initiation protocol (SIP), inserting, by a network node, an indication in local session state or session initiation protocol of a contact address of a network entity which is creating the session. The method may further include using the indication contained in the local session state or session initiation protocol to perform request targeting.

Description

DESCRIPTION TITLE

PARALLEL REGISTRATION IN AN INTERNET MULTIMEDIA SUBSYSTEM

FIELD:

[0001] Embodiments of the invention relate generally to wireless communications networks, and, in particular, some embodiments are applicable to the internet multimedia subsystem (IMS), which delivers internet protocol (IP) multimedia services.

BACKGROUND: [0002] Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN) refers to a communications network including base stations, or Node-Bs, and radio network controllers (RNC). UTRAN allows for connectivity between the user equipment (UE) and the core network. The RNC provides control functionalities for one or more Node Bs. The RNC and its corresponding Node Bs are called the Radio Network Subsystem (RNS).

[0003] Long Term Evolution (LTE) refers to improvements of the UMTS through improved efficiency and services, lower costs, and use of new spectrum opportunities. In particular, LTE is a 3rd Generation Partnership Project (3GPP) standard that provides for uplink peak rates of at least 50 megabits per second (Mbps) and downlink peak rates of at least 100 Mbps. LTE supports scalable carrier bandwidths from 20 MHz down to 1 .4 MHz and supports both Frequency Division Duplexing (FDD) and Time Division Duplexing (TDD).

[0004] As mentioned above, LTE improves spectral efficiency in communication networks, allowing carriers to provide more data and voice services over a given bandwidth. Therefore, LTE is designed to fulfill future needs for high-speed data and media transport in addition to high-capacity voice support. Advantages of LTE include high throughput, low latency, FDD and TDD support in the same platform, an improved end-user experience, and a simple architecture resulting in low operating costs. In addition, LTE is an all internet protocol (IP) based network, supporting both IPv4 and IPv6. [0005] The Evolved 3GPP Packet Switched Domain, which is also known as the

Evolved Packet System (EPS), provides IP connectivity using the E-UTRAN. In addition, the internet multimedia subsystem (IMS) is the standardized solution for multimedia telephony over IP-based networks. For example, voice over LTE (VoLTE) technology utilizes IMS.

SUMMARY: [0006] One embodiment is directed to a method which may include, during session creation using session initiation protocol (SIP), inserting, by a network node, an indication in local session state or session initiation protocol of a contact address of a network entity which is creating the session. The method may further include using the indication contained in the local session state or session initiation protocol to perform request targeting. In an embodiment, the using may include replacing a public globally routable user agent uniform resource identifier (GRUU) of a served user contained in the request uniform resource identifier (URI) of a subsequent session initiation protocol (SIP) request with a correct contact header according to the indication.

[0007] Another embodiment is directed to an apparatus which may include at least one processor, and at least one memory including computer program code. The at least one memory and computer program code may be configured, with the at least one processor, to cause the apparatus at least to insert, during session creation with session initiation protocol (SIP), an indication in local session state or session initiation protocol of a contact address of a network entity which is creating the session. The at least one memory and computer program code may be further configured, with the at least one processor, to cause the apparatus to use the indication contained in the local session state or session initiation protocol to perform request targeting. In an embodiment, the using may include replacing a public globally routable user agent uniform resource identifier (GRUU) of a served user contained in the request uniform resource identifier (URI) of a subsequent session initiation protocol (SIP) request with a correct contact header according to the indication.

[0008] Another embodiment is directed to an apparatus which may include inserting means for inserting, during session creation with session initiation protocol (SIP), an indication in local session state or session initiation protocol of a contact address of a network entity which is creating the session. The apparatus may also include using means for using the indication contained in the local session state or session initiation protocol to perform request targeting. In an embodiment, the using means may include means for replacing a public globally routable user agent uniform resource identifier (GRUU) of a served user contained in the request uniform resource identifier (URI) of a subsequent session initiation protocol (SIP) request with a correct contact header according to the indication.

[0009] Another embodiment is directed to a computer program, embodied on a computer readable medium. The computer program, when run on a processor, performs a method which may include, during session creation using session initiation protocol (SIP), inserting, by a network node, an indication in local session state or session initiation protocol of a contact address of a network entity which is creating the session. The method may further include using the indication contained in the local session state or session initiation protocol to perform request targeting. In an embodiment, the using may include replacing a public globally routable user agent uniform resource identifier (GRUU) of a served user contained in the request uniform resource identifier (URI) of a subsequent session initiation protocol (SIP) request with a correct contact header according to the indication. BRIEF DESCRIPTION OF THE DRAWINGS:

[00010] For proper understanding of the invention, reference should be made to the accompanying drawings, wherein:

[00011] Fig. 1 illustrates an example block diagram of parallel registration depicting the two registrations for a single UE; [00012] Fig. 2 illustrates an example call flow diagram depicting route set creation for an originating request, according to one embodiment;

[00013] Fig. 3 illustrates a call flow diagram depicting route set creation for a terminating request, according to one embodiment;

[00014] Fig. 4 illustrates a call flow diagram for performing request targeting, according to an embodiment;

[00015] Fig. 5 illustrates an example block diagram of an apparatus, according to an embodiment;

[00016] Fig. 6 illustrates a block diagram of an apparatus, according to another embodiment; and [00017] Fig. 7 illustrates a flow diagram of a method, according to an embodiment. DETAILED DESCRIPTION:

[00018] It will be readily understood that the components of the invention, as generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of embodiments of systems, methods, apparatuses, and computer program products for parallel registration, for example, via Gm and 12 interfaces, as represented in the attached figures, is not intended to limit the scope of the invention, but is merely representative of selected embodiments of the invention. [00019] The features, structures, or characteristics of the invention described throughout this specification may be combined in any suitable manner in one or more embodiments. For example, the usage of the phrases "certain embodiments," "some embodiments," or other similar language, throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the present invention. Thus, appearances of the phrases "in certain embodiments," "in some embodiments," "in other embodiments," or other similar language, throughout this specification do not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. [00020] Additionally, if desired, the different functions discussed below may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the described functions may be optional or may be combined. As such, the following description should be considered as merely illustrative of the principles, teachings and embodiments of this invention, and not in limitation thereof. [00021] The internet multimedia subsystem (IMS) is the standardized solution for multimedia telephony over IP based networks, such as voice over LTE (VoLTE). An important feature of IMS is the so called IMS centralized services (ICS).

[00022] Embodiments of the invention deal with some aspects related to parallel registration. For instance, one scenario is that a registration request, such as a SIP REGISTER, is sent from a UE directly via Gm interface and in parallel the MSC sends a registration request via 12 interface on behalf of the UE. One embodiment addresses how the serving call session control function (S-CSCF) performs request targeting for subsequent requests when globally routable user agent uniform resource identifiers (GRUUs) are used in the aforementioned scenario. For example, one use case may be when the operator wants to provide rich communication services (RCS) services and in parallel uses ICS enhanced MSC to provide voice service.

[00023] Fig. 1 illustrates an example block diagram of parallel registration depicting the two registrations for a single UE. The registration request from the MSC (e.g., via I2 interface) may include the following parameters: Temporary Public User Identity, specific Private User Identity, MSC contact address, session initiation protocol (SIP) instance. ID which is based on UE International Mobile Subscriber Identity (IMEI), and support for GRUU. The registration request from the MSC may not use the mechanism for multiple registration ("reg-id"), as specified in RFC 5626.

[00024] The registration request via Gm interface may include the following parameters: Public User Identity, Private User Identity, UE contact address, SIP instance. ID which is based on UE IMEI, support for GRUU, and may or may not include "reg-id" which is the mechanism used for multiple registration as specified in RFC 5626.

[00025] As consequence of the above, the S-CSCF will assign the same public GRUU to the UE and to the MSC (which acts on behalf of the UE) because the public GRUU is based on a public user identity and the SIP instance. ID.

[00026] In view of the above-described configuration, an issue arises with respect to request targeting for subsequent requests. The UE or MSC establishes a dialog (e.g., by sending or receiving a SIP INVITE), and the UE or MSC delivers Public_GRUU as a contact address to the far end. When the far end sends an in-dialog request, a request URI (R-URI) will contain the Public_GRUU. The S-CSCF will try to perform request targeting, i.e., it needs to replace the Public_GRUU with the stored contact address. And, according to the standardized procedure, the S-CSCF is required to use the most recently refreshed contact address for request targeting. As the UE and MSC both periodically send reregister requests to refresh their own contact address, the S-CSCF behavior for request targeting is not determinative: either the contact-UE or the contact-MSC may be used to replace the Public-GRUU in R-URI, independently from via which registration/contact address the dialog was created. As a result, if a terminating in-dialog request (which has the GRUU as a request URI) is delivered to the S-CSCF, the S-CSCF does not know whether or not to deliver the request to the MSC or UE. [00027] This problem occurs when the UE or MSC uses Public_GRUU in Contact header for dialog opening request or response because the Public_GRUU is associated to two real contact addresses: contact-UE and contact-MSC. The S-CSCF shall perform request targeting by selecting the most recently refreshed contact address, independently from via which registration/contact address the dialog was created. This may cause the S- CSCF to use a wrong contact address as the target of the subsequent request. In other words, a subsequent request may be sent to a wrong contact address, for example a request within a dialog created by the UE is sent to MSC, or vice versa. This is because this ICS procedure in IMS is a 3GPP extension, which does not (or cannot) follow the procedure defined for multiple SIP registrations from the same instance-id.

[00028] After a call is established either via UE or MSC, the call state is kept in that network element creating the call. That means that when a call is created by a UE, MSC server (MSC-S) does not have any call state, and vice versa. Therefore, all subsequent requests for a call shall be sent to the network element (either UE or MSC), which keeps the call states. So the S-CSCF has to remember which network element has the call state and deliver the subsequent request accordingly (e.g., by de-referencing). According to the standardized procedure, the S-CSCF has to de-reference the Globally Routable User Agent URI (GRUU) to the contact address which is most recently (re-)registered. However this cannot be applied to the IMS centralized services (ICS) use case, because this will mean that the subsequent requests may be delivered for a network element which does not keep the call state. This is because it is assumed that all registrations with the same instance-id come from the same entity, which manages the call states.

[00029] Therefore, according to an embodiment, the S-CSCF is configured to be able to determine or remember whether it is the UE or MSC which established the call (either locally or within the protocol). The S-CSCF is then able to later de-reference the GRUU according to this information, when there are parallel registrations via Gm and 12 interfaces.

[00030] Embodiments of the invention may not affect the GRUU generation itself. Both MSC and UE will still obtain the same GRUU for the same International Mobile Equipment Identifier (IMEI) during registration. Also, different S-CSCF will provide the same GRUU for the same IMEI. It is supported by embodiments of the invention that a new call to the GRUU can be delivered to the user, independently from whether the user is registered via a UE/Gm or via MSC/12. [00031] As outlined in detail above, the rule for request targeting, i.e., that S-CSCF has to dereference a R-URI with GRUU to the most recently refreshed contact address that is bound to this GRUU, cannot be applied when Public_GRUU is contained in the R- URI of a terminating request in IMS, when ICS-12 and GRUU are activated in IMS. Therefore, one embodiment is directed to a procedure that may be conducted by the S- CSCF, when 12 and GRUU are enabled in IMS.

[00032] In an embodiment, during session creation, the S-CSCF may insert (e.g., embed) an indication in the signaling, i.e., in the session protocol or in local session state, that identifies the registration that is used for the dialog (i.e., the registration from the MSC or from the UE). The indication can be for example an identifier in the record-route header. The content of the record-route is used by the far end to build the Route header for subsequent requests, and hence S-CSCF receives this identifier in the Route header. Then, when a subsequent request containing the Public_GRUU of the served user is received, the S-CSCF may use the indication contained in the local session state or in the protocol to perform proper request targeting - to replace the Public_GRUU contained in R-URI of subsequent request with the correct contact address according to the indication.

[00033] As a result, embodiments can ensure that subsequent requests with Public_GRUU as R-URI can always be delivered by the S-CSCF to the correct contact address. In other words, a request within a dialog created by the UE is always sent to the UE, and a request within a dialog created by the MSC is always sent to the MSC.

[00034] According to an embodiment, the indication may be inserted (e.g., embedded) by the S-CSCF for any IMS user with GRUU, either Public_GRUU or Temporary_GRUU, because the S-CSCF may not know whether the UE or MSC will insert a GRUU in response, and which type of GRUU will be inserted. The indication may be used for subsequent request handling if the R-URI of the subsequent request is not a

Public_GRUU.

[00035] Since the S-CSCF is session stateful SIP proxy, it stores session state internally. Therefore, the S-CSCF may store the indication within the local session states. However, to increase reliability, the S-CSCF may also store the indication within the SIP protocol. As a session stateful SIP proxy, the S-CSCF should record-route itself for the dialog, i.e., it inserts (e.g., embeds) a Record-Route header into the request so that the S- CSCF is kept in the signalling path in the whole period of the dialog and is able to perform request targeting handling for GRUU. Therefore, the S-CSCF may also insert the indication in its own Record-Route header.

[00036] According to a standardised procedure as defined in RFC3261 , the far end (either as user agent client (UAC) or as user agent server (UAS) during the dialog creation) must use the Record-Route header set contained in the SIP request (as UAS) or in the SIP response (as UAC) to create a so called route set. This route set is used by the far end to set the Route header set for any subsequent request. That means the Record- Route header inserted (e.g., embedded) by a S-CSCF into a dialog opening request or response is copied by the far end into Route header of any subsequent request. Therefore, in an embodiment of this invention, the S-CSCF may retrieve the indication from the Route header for the S-CSCF contained in the subsequent request and then perform the request targeting properly. The request targeting may thus comprise replacing the Public_GRUU contained in R-URI of subsequent request with the correct contact Address according to the indication, when a subsequent request containing the Public_GRUU of the served user is received. [00037] As outlined above, in one embodiment, during session creation, the S-CSCF may insert an indication either in the local session state or in the SIP protocol about via which contact address the session is created. If the indication is only kept in the local session state, it is not visible to outside elements. However, if the indication is inserted into SIP protocol, the call flow diagrams (Figs. 2-4) discussed in detail below can be applied.

[00038] As the indication may be inserted into the SIP URI for the S-CSCF in Record- Route header, which can be ensured to be copied back into Route header by the far end, this indication could be a specific SIP URI parameter, a specific token in the userinfo part of the SIP URI, or any other form. [00039] For example, internal registration/contact identifier may be used as the indication as follows: Record-Route:<sip:s-cacf1 .ims.com;target-reg-id=12345678> or Record-Route:<sip: target-reg-id=12345678@s-cacf1 .ims.com >. It should be noted that any indication embedded as header parameter in Record-Route header cannot be ensured to be copied back into Route header because RFC3261 defines that the route set only contains a list of URIs as follows: "The route set MUST be set to the list of URIs in the

Record-Route header field from the request, taken in order and preserving all URI parameters." [00040] Fig. 2 illustrates an example call flow diagram depicting route set creation for an originating request, according to one embodiment. As illustrated in Fig. 2, when the UE or MSC sends a dialog opening request like INVITE to the peer (so called originating request), it uses its Public_GRUU as its Contact address. As the S-CSCF is aware via which registration/contact address the request is sent from, it may then insert a Record- Route header into the request, together with an indication about the registration/contact address involved in the dialog. The far end stores the Record-Route header set as route set for the dialog, which is used for sending subsequent requests by the far end.

[00041] Fig. 3 illustrates a call flow diagram depicting route set creation for a terminating request, according to one embodiment. In the example of Fig. 3, when the far end sends a request for the IMS user, the S-CSCF selects the proper target contact address for the incoming terminating request. The S-CSCF may also insert an indication in the Record-Route header about which registration/contact address is addressed for this dialog. The UAS (either UE or MSC) copies the received Record-Route header set into any 1 xx/2xx response sent back to the far end, which then stores the Record-Route header set as route set for the dialog.

[00042] Fig. 4 illustrates a call flow diagram for performing request targeting for subsequent request with Public_GRUU, according to an embodiment. When the far end later sends a subsequent request within the dialog, for example a relNVITE or BYE, or others, it uses the contact address of IMS user as R-URI, which is the Public_GRUU. The S-CSCF may then check the indication contained in the Route header for the S-CSCF and then perform request targeting by using this indication to ensure that the Public_GRUU in R-URI is replaced with the correct real contact address.

[00043] If the subsequent request is a so-called target-refresh request, the S-CSCF may also insert a Record-Route header. As the Route header for the S-CSCF in the subsequent request contains the indication, which was inserted by the S-CSCF during dialog creation, the S-CSCF can copy this indication into the Record-Route header inserted into the subsequent request.

[00044] If the S-CSCF stores the indication in local session states, the subsequent request reaching the S-CSCF does not contain any indication about the Contact address associated to this dialog. However, the S-CSCF may still use the internal indication to perform proper request targeting to ensure that the correct Contact address is used to replace the Public_GRUU contained in R-URI. Either with internal indication or with indication in SIP protocol, the S-CSCF does not apply the rule for request targeting, i.e., that S-CSCF has to dereference a R-URI with GRUU to the most recently refreshed Contact address that is bound to this GRUU.

[00045] Fig. 5 illustrates an example of an apparatus 10 according to an embodiment. In an embodiment, apparatus 10 may be a node, host, or server in a communications network or serving such a network. For example, in one embodiment, apparatus 10 may be a S-CSCF. It should be noted that one of ordinary skill in the art would understand that apparatus 10 may include components or features not shown in Fig. 5.

[00046] As illustrated in Fig. 5, apparatus 10 includes a processor 22 for processing information and executing instructions or operations. Processor 22 may be any type of general or specific purpose processor. While a single processor 22 is shown in Fig. 5, multiple processors may be utilized according to other embodiments. In fact, processor 22 may include one or more of general-purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), and processors based on a multi-core processor architecture, as examples.

[00047] Apparatus 10 may further include or be coupled to a memory 14 (internal or external), which may be coupled to processor 22, for storing information and instructions that may be executed by processor 22. Memory 14 may be one or more memories and of any type suitable to the local application environment, and may be implemented using any suitable volatile or nonvolatile data storage technology such as a semiconductor-based memory device, a magnetic memory device and system, an optical memory device and system, fixed memory, and removable memory. For example, memory 14 can be comprised of any combination of random access memory (RAM), read only memory (ROM), static storage such as a magnetic or optical disk, or any other type of non- transitory machine or computer readable media. The instructions stored in memory 14 may include program instructions or computer program code that, when executed by processor 22, enable the apparatus 10 to perform tasks as described herein.

[00048] Processor 22 may perform functions associated with the operation of apparatus 10 which may include, for example, precoding of antenna gain/phase parameters, encoding and decoding of individual bits forming a communication message, formatting of information, and overall control of the apparatus 10, including processes related to management of communication resources. [00049] In an embodiment, memory 14 may store software modules that provide functionality when executed by processor 22. The modules may include, for example, an operating system that provides operating system functionality for apparatus 10. The memory may also store one or more functional modules, such as an application or program, to provide additional functionality for apparatus 10. The components of apparatus 10 may be implemented in hardware, or as any suitable combination of hardware and software.

[00050] In one embodiment, apparatus 10 may be network node, such as a S-CSCF. In this embodiment, apparatus 10 may be controlled by memory 14 and processor 22 to insert, during session creation, an indication in local session state or session initiation protocol about which contact is creating the session. Apparatus 10 may be further controlled by memory 14 and processor 22 to use the indication contained in the local session state or session initiation protocol to perform request targeting.

[00051] According to an embodiment, apparatus 10 may be controlled by memory 14 and processor 22 to use the indication by replacing a public GRUU of a served user with the correct contact header according to the indication. In one embodiment, apparatus 10 may be controlled by memory 14 and processor 22 to insert the indication for any internet multimedia subsystem (IMS) user with a public globally routable user agent uniform resource identifier (GRUU) or temporary globally routable user agent uniform resource identifier (GRUU).

[00052] In some embodiments, the indication may be stored internally within apparatus 10 along with local session states. According to certain embodiments, the indication may be embedded within a record-route header of apparatus 10. Also, in certain embodiments, the indication may include a specific SIP URI parameter or a specific token in userinfo part of the SIP URI.

[00053] Fig. 6 illustrates a block diagram of an apparatus 600, according to another embodiment. In this embodiment, apparatus 600 may include inserting means 610 for inserting, during session creation, an indication in local session state or session initiation protocol about which contact is creating the session. Apparatus 600 may also include using means 620 for using the indication contained in the local session state or session initiation protocol to perform request targeting. In one embodiment, the using means 620 may include replacing means 630 for replacing a public GRUU of a served user with the correct contact header according to the indication. [00054] Fig. 7 illustrates a flow diagram of a method, according to one embodiment. In some embodiments, the method of Fig. 7 may be performed by a network node, such as a S-CSCF. The method may include, at 700, inserting, during session creation, an indication in local session state or session initiation protocol about which contact is creating the session. The method may then include, at 710, using the indication contained in the local session state or session initiation protocol to perform request targeting. In an embodiment, the using of the indication may include replacing a public GRUU of a served user with a correct contact header according to the indication.

[00055] In some embodiments, the inserting of the indication may include inserting the indication for any IMS user with a public GRUU or temporary GRUU. In an embodiment, the method may include storing the indication internally along with local session states. According to one embodiment, the inserting of the indication may include embedding the indication in a record-route header of the network node. According to certain embodiments, the indication may include a specific SIP URI parameter or a specific token in userinfo part of the SIP URI.

[00056] In some embodiments, the functionality of any of the methods described herein, such as those illustrated in Figs. 2-4 and 7 discussed above, may be implemented by software and/or computer program code stored in memory or other computer readable or tangible media, and executed by a processor. In other embodiments, the functionality may be performed by hardware, for example through the use of an application specific integrated circuit (ASIC), a programmable gate array (PGA), a field programmable gate array (FPGA), or any other combination of hardware and software.

[00057] One having ordinary skill in the art will readily understand that the invention as discussed above may be practiced with steps in a different order, and/or with hardware elements in configurations which are different than those which are disclosed. Therefore, although the invention has been described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent. In order to determine the metes and bounds of the invention, therefore, reference should be made to the appended claims.

Claims

CLAIMS:

1 . A method, comprising: during session creation using session initiation protocol (SIP), inserting, by a network node, an indication in local session state or session initiation protocol of a contact address of a network entity which is creating the session; and using the indication contained in the local session state or session initiation protocol to perform request targeting, wherein the using comprises replacing a public globally routable user agent uniform resource identifier (GRUU) of a served user contained in the request uniform resource identifier (URI) of a subsequent session initiation protocol (SIP) request with a correct contact header according to the indication.

2. The method according to claim 1 , wherein the inserting further comprises inserting the indication for any internet multimedia subsystem (IMS) user with a public globally routable user agent uniform resource identifier (GRUU) or temporary globally routable user agent uniform resource identifier (GRUU).

3. The method according to claims 1 or 2, further comprising storing the indication internally along with local session states.

4. The method according to any one of claims 1 -3, wherein the inserting comprises embedding the indication in a record-route header field of the network node.

5. The method according to any one of claims 1 -4, wherein the indication comprises a specific session initiation protocol (SIP) uniform resource identifier (URI) parameter or a specific token in userinfo part of the SIP URI.

6. The method according to any one of claims 1 -5, wherein the network node comprises a serving call session control function (S-CSCF).

7. An apparatus, comprising: at least one processor; and at least one memory including computer program code, the at least one memory and computer program code configured, with the at least one processor, to cause the apparatus at least to insert, during session creation with session initiation protocol (SIP), an indication in local session state or session initiation protocol of a contact address of a network entity which is creating the session; and use the indication contained in the local session state or session initiation protocol to perform request targeting, wherein the using of the indication comprises replacing a public globally routable user agent uniform resource identifier (GRUU) of a served user contained in the request uniform resource identifier (URI) of a subsequent session initiation protocol (SIP) request with a correct contact header according to the indication.

8. An apparatus, comprising: inserting means for inserting, during session creation with session initiation protocol

(SIP), an indication in local session state or session initiation protocol of a contact address of a network entity which is creating the session; and using means for using the indication contained in the local session state or session initiation protocol to perform request targeting, wherein the using means comprises means for replacing a public globally routable user agent uniform resource identifier (GRUU) of a served user contained in the request uniform resource identifier (URI) of a subsequent session initiation protocol (SIP) request with a correct contact header according to the indication.

9. The apparatus according to claim 8, wherein the inserting means further comprises means for inserting the indication for any internet multimedia subsystem (IMS) user with a public globally routable user agent uniform resource identifier (GRUU) or temporary globally routable user agent uniform resource identifier (GRUU).

10. The apparatus according to claims 8 or 9, further comprising means for storing the indication internally along with local session states.

1 1 . The apparatus according to any one of claims 8-10, wherein the inserting means comprises means for embedding the indication in a record-route header of the apparatus.

12. The apparatus according to any one of claims 8-1 1 , wherein the indication comprises a specific session initiation protocol (SIP) uniform resource identifier (URI) parameter or a specific token in userinfo part of the SIP URI.

13. The apparatus according to any one of claims 8-12, wherein the apparatus comprises a serving call session control function (S-CSCF).

14. A computer program, embodied on a computer readable medium, the computer program, when run on a processor, performs a method according to any one of claims 1 -6.