Call handling system and method

Abstract

A method for handling a call from a calling device. The method includes receiving a call initiation message (e.g., a SIP INVITE message) for setting up a call between the calling device (e.g., a PBX or SIP UA) and a called device, the call initiation message comprising user identification information (e.g., an IMPU). After receiving the call initiation message, the method also includes determining whether user information associated with the user identification information indicates that use of a third-party (3P) identifier (ID) is permitted.

Description

[Technical Field]

[0001] SUMMARY OF THE INVENTION Embodiments are disclosed that relate to systems and methods for call handling. [Background technology]

[0002] There are scenarios in which a user of an Internet Protocol (IP) Multimedia System (IMS) subscription (e.g., an employee of an enterprise that uses IMS for communication services) uses a third-party (3P) identifier (ID) (e.g., an enterprise employee ID that includes the employee's full name, the enterprise name, title, enterprise location, etc.) when making a call to a callee. The IMS network can present the 3P ID to the callee during the subsequent call process. The user (e.g., a third-party subscriber) (also known as the "caller") can similarly access the IMS network directly or through a Session Initiation Protocol (SIP) trunk.

[0003] The 3rd Generation Partnership Project (3GPP) Technical Report (TR) 33.890 version 0.3.0 (hereinafter "TR33.890") (see 3GPP Technical Document (Tdoc) S3-222958) describes "Key Problem #1," which covers research into enhanced IMS networks that should be able to support user verification and authorization during IMS calls. The objective is, for example, to prevent a malicious device (a.k.a., user equipment (UE)) from using a 3P ID belonging to another person (an employee) or a forged ID to initiate an IMS call in the IMS network, or from using a 3P ID that no longer belongs to the caller to initiate an IMS call in the IMS network (e.g., a user uses an ID assigned by a particular company even after the user has left the company). TR33.890 proposes a solution based on the existence of a database that maintains the relationship between the 3P ID and each user's IMS identity used within the IMS domain (i.e., each user's IMS Private User Identity (IMPI) and / or IMS Public User Identity (IMPU)) (see, for example, step 3 in Figure 1, which is a copy of Figure 6.1.2.2-1 from TR33.890).

[0004] Typically, an Integrated Circuit Card (ICC), such as a Universal Integrated Circuit Card (UICC), in a device configured to utilize IMS contains an application known as an IMS Identity Module (ISIM), which contains parameters for identifying and authenticating the device to IMS. Among the data present on the ISIM are an IMPI and at least one IMPU. The IMPI is an identity assigned by the home network and contains the home operator's domain information. The IMPU functions like a telephone number. The relationship between the IMPI and IMPU is also described in 3GPP Technical Specification (TS) 23.228 V17.3.0 ("TS 23.228") and is shown in Figure 4.5 of TS 23.228, which illustrates an "IMS subscription" that includes a single private user identity and a set of one or more public user identities associated with the private user identity. According to TS 23.228 clause 4.3.3.1, "Every IM CN subsystem user shall have one or more private user identities. The private identities are assigned by the home network operator and are used, for example, for registration, authorization, administration, and accounting purposes," and according to clause 4.3.3.2, "Every IM CN subsystem user shall have one or more public user identities, including one in the form of at least a SIP URI. The public user identities are used by any user to request communications with other users." As stated in TS 23.228, "It shall be possible to support wildcarded public user identities. A wildcarded public user identity represents a set of public user identities grouped together."

[0005] The message flow shown in FIG. 1 includes 13 steps, which are described in TR 33.890 and are described below.

[0006] 1. The third party (3P) PBX (Private Branch Exchange) sends a SIP INVITE containing the IMS identity of the calling UE (i.e., the IMPU of the calling UE) (which also contains the IMPU of the called UE) and which may or may not contain the 3P ID for the third party (3P) subscriber to the Interconnect Border Control Function (IBCF).

[0007] 2. The IBCF forwards the SIP request to the originating IMS subsystem entity, which may include the I-CSFC, the S-CSCF, the MMtel AS, etc.

[0008] 3. The originating IMS subsystem checks whether the IMS subscription of the calling PBX is authorized (i.e., allowed) to use the 3P ID. If the PBX is not authorized to use the 3P ID, the originating IMS subsystem ignores the 3P ID in the SIP INVITE (if present) and does not perform the rest of the 3P ID-related steps during call setup. The call continues without presenting the 3P ID to the called endpoint. If the PBX is authorized to use the 3P ID, the originating IMS subsystem obtains Rich Call Data (RCD) for the 3P subscriber from a database based on the received IMS identity (IMPU). If no RCD data exists for this user (IMS identity), the rest of the 3P ID-related steps are not performed during call setup. The call continues without presenting the 3P ID to the called endpoint. Note: If the 3P ID was not received in the SIP INVITE from the PBX, database lookup suppression may be applied optionally based on local policy. In case of a mismatch between the 3P ID received in the SIP INVITE and the data retrieved from the database based on the IMS Identity, the local policy of the originating IMS subsystem governs how the SIP Identity header will be populated with rich call data.

[0009] 4. The originating IMS subsystem adds a P-Asserted Identity header field asserting the 3P subscriber's telephone number and rich call data, and invokes the STI-AS (Secure Telephone Identity Authentication Service) to sign the Identity header according to Figure 6.X.2.1-2: SHAKEN Reference Architecture and TS 24.229 [4].

[0010] 5. The STI-AS interacts with the SKS (not shown in the diagram) and signs the SIP Identity header according to the STIR / SHAKEN framework and draft-ietf-stir-passport-rcd-18.

[0011] 6. The STI-AS returns the signed SIP Identity header to the IMS subsystem.

[0012] 7. The originating IMS subsystem routes the call to the egress IBCF via standard solutions. The SIP INVITE is then routed over the NNI via standard inter-domain routing configuration. The terminating service provider's ingress IBCF receives the INVITE and forwards it to the terminating IMS subsystem.

[0013] 8. The terminating IMS subsystem entity invokes the Secure Telephone Identity Verification Service (STI-VS) to verify the signed SIP Identity header.

[0014] 9. The STI-VS verifies the certificate, extracts the public key, and verifies the signature in the Identity header field, which verifies the caller ID and rich call data when signing the INVITE on the originating STI-AS based on Figure 6.X.2.1-2: SHAKEN Reference Architecture and TS24.229 [4].

[0015] 10. Depending on the result of the STI validation, the STI-VS decides that the call should be completed with the appropriate indicators and the result is passed to the terminating IMS subsystem which continues to set up the call to the terminating SIP UA. If the caller ID is verified OK but the rich call data is not, the call can proceed but does not present the name card information to the terminating SIP UA.

[0016] 11. The SIP INVITE with the verstat parameter is sent to the called SIP user agent (UA).

[0017] 12. The terminating SIP UA sends 18X and 200 to the originating IMS subsystem.

[0018] 13. The originating IMS subsystem sends 18X and 200 to the originating SIP UA. The call continues according to standard solutions. Summary of the Invention

[0019] Currently, several challenges exist, for example, before the originating IMS subsystem contacts a database to verify the third-party identity (3P ID) in step 3 of Figure 1, step 3 includes an authorization step to ensure that the IMS subscription can first use the 3P ID, but it is not yet specified how the originating IMS subsystem will implement this authorization.

[0020]

[0009] Accordingly, in one aspect, a method for handling a call from a calling device is provided. The method includes receiving a call initiation message (e.g., a SIP INVITE message) for setting up a call between the calling device (e.g., a PBX or SIP UA) and a called device, the call initiation message comprising a user identity (e.g., an IMPU). After receiving the call initiation message, the method also includes determining whether user information associated with the user identity indicates that use of a 3P ID is permitted.

[0021] In another aspect, a method is provided that is implemented by a subscriber server. The method includes receiving user information including a user identity and a first 3P allowance indicator value associated with the user identity, the first 3P allowance indicator value indicating whether use of the 3P ID is permitted. The method also includes storing the user information. The method also includes receiving a request message from an IMS subsystem entity requesting the user information. The method further includes sending a response message to the IMS subsystem entity in response to the request message, the response message including the user information.

[0022] In another aspect, a computer program is provided comprising instructions that, when executed by a processing circuit of the device, cause the device to perform any of the methods disclosed herein. In one embodiment, a carrier containing the computer program is provided, the carrier being one of an electronic signal, an optical signal, a radio signal, and a computer-readable storage medium. In another aspect, an apparatus configured to perform the methods disclosed herein is provided. The apparatus may include a memory and a processing circuit coupled to the memory.

[0023] An advantage of the embodiments disclosed herein is that they utilize a subscriber system (e.g., a Home Subscriber System (HSS)) within the IMS subsystem to manage subscription profiles that define the IMS services enabled for users of an IMS subscription, and have minimal impact on IMS procedures.

[0024] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various embodiments. [Brief explanation of the drawings]

[0025] [Figure 1] FIG. 2 illustrates a message flow for establishing a call. [Figure 2] FIG. 10 illustrates a registration message flow. [Figure 3] FIG. 2 illustrates a message flow for establishing a call, according to some embodiments. [Figure 4] FIG. 2 illustrates a message flow for establishing a call, according to some embodiments. [Figure 5] 1 is a flowchart illustrating a process according to some embodiments. [Figure 6] FIG. 1 is a block diagram of an apparatus, according to some embodiments. [Figure 7] 1 is a flowchart illustrating a process according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0026] The present disclosure provides a means for an originating IMS subsystem to perform an authorization check on whether a calling device associated with an IMS subscription can utilize a 3P ID. In one embodiment, the originating IMS subsystem performs the authorization check using user information associated with a user identity included in a call initiation message (e.g., a SIP INVITE message). Accordingly, in some embodiments, new information is defined in user information (e.g., an IMS subscription profile) managed in the HSS of the originating IMS subsystem, and the user information is provided to a Server-Call Session Control Function (S-CSCF) during registration of the IMS IMPI. In these embodiments, authorization enforcement is then performed in the S-CSCF during IMS session setup.

[0027] 3P tolerance indicator regulations

[0028] There are different ways to indicate within the user information associated with an IMS identity whether the use of a 3P ID is allowed for the IMS identity. For example, a "3P allowed" indicator may be added to the user information (IMS subscription profile) and used to provide an indication of whether the use of a 3P ID is allowed (e.g., when the value of the indicator is set to 1 or true, this indicates that the 3P ID is allowed; otherwise, the 3P ID is not allowed). The 3P allowed indicator may be specified within the IMS subscription profile at the IMPI level, which means that all IMPUs associated with the IMS subscription (e.g., all users behind a PBX client) will be allowed to use the 3P ID. The absence of a 3P allowed indicator at the IMPI level is understood when none of the IMPUs associated with the IMPI are allowed to utilize the 3P ID. For example, the user information associated with a particular IMPU (e.g., an IMS subscription profile) may include the IMPI, the particular IMPU, and zero or more other IMPUs. When a 3P tolerance indicator is defined at the IMPI level, the indicator is associated with the IMPI (eg, included in metadata linked to the IMPI in user information).

[0029] Furthermore, when the value of the 3P allowed indicator defined at the IMPI level allows the use of 3P IDs, it is possible to explicitly exclude some IMPUs from being allowed by explicitly setting another 3P ID indication at the IMPU level to a value that is not allowed. For example, consider an IMS subscription profile that includes an IMPI, a first IMPU, and a second IMPU. In this example, assume that the first 3P allowed indicator at the IMPI level is set to 1 to indicate that 3P IDs are allowed, but another 3P allowed indicator associated with the first IMPU indicates that 3P IDs are not allowed. In this scenario, 3P IDs are not allowed for the first IMPU, but are allowed for the second IMPU because there is no 3P allowed indicator associated with the second IMPU that indicates that 3P IDs are not allowed.

[0030] In one embodiment, the 3P allowance indicator may be a "display name." That is, if any particular IMPU in an IMS subscription profile is associated with a display name, this indicates that 3P IDs are allowed for that particular IMPU. However, when wildcarded IMPUs are used (e.g., as in the PBX case), it is not possible for the "display name" to include personalized 3P IDs for each individual IMPU in the wildcarded IMPU set. In this case, the "display name" may simply be set to a value that indicates that any particular IMPU in the set is allowed to use a 3P ID (if a particular IMPU is allowed to use a 3P ID, the IMS subsystem may retrieve the 3P ID associated with the IMPU from a rich call data (RCD) database). That is, the "display name" associated with a wildcarded IMPU or any individual IMPU may be set to a value, e.g., " / RCD / ," or a similar value, to indicate that 3P IDs are allowed for the IMPU.

[0031] Also, the indication that the IMPU is permitted to use the 3P ID may be specified within the subscription of the multimedia telephony service and stored in the HSS as transparent / repository data.

[0032] 3P Tolerance Indicator Delivery to S-CSCF or TAS

[0033] The 3P tolerance indicator is included in the IMS subscription profile (user information) downloaded from the HSS by the S-CSCF during registration of the IMS subscription in the originating IMS subsystem (e.g., PBX registration or SIP UA registration). See steps 6 and 7 in the IMS registration procedure specified in TS 23.228 shown in Figure 2 (which is a copy of Figure 5-1 from TS 23.228). The steps shown in Figure 2 are described below.

[0034] 1. After the UE obtains IP connectivity, the UE can perform IM registration. To do so, the UE sends a Register information flow (public user identity, private user identity, home network domain name, UE IP address, instance identifier, GRUU support indication) to the proxy.

[0035] 2. Upon receiving the registration information flow, the P-CSCF shall examine the "Home Domain Name" to discover the entry point to the home network (i.e., the I-CSCF). The proxy shall send the registration information flow to the I-CSCF (P-CSCF address / name, public user identity, private user identity, P-CSCF network identifier, UE IP address). A name-to-address resolution mechanism is utilized to determine the address of the home network from the home domain name. The P-CSCF network identifier is a string that identifies the network in which the P-CSCF is located in the home network (e.g., the P-CSCF network identifier can be the domain name of the P-CSCF network).

[0036] 3. The I-CSCF shall send a Cx-Query / Cx-Select-Pull information flow to the HSS 201 (Public User Identity, Private User Identity, P-CSCF Network Identifier). The HSS shall check whether the user is already registered. The HSS shall indicate whether the user is allowed to register in that P-CSCF network (identified by the P-CSCF Network Identifier) ​​according to the user subscription and operator limitations / restrictions, if any.

[0037] 4. A Cx-Query Resp / Cx-Select-Pull Resp is sent from the HSS to the I-CSCF. The Cx-Query Resp / Cx-Select-Pull Resp shall contain the S-CSCF name if it is known by the HSS, or the S-CSCF capabilities if it is needed to select a new S-CSCF. When the capabilities are returned, the I-CSCF shall construct a name from the returned capabilities. If the check at the HSS is not successful, the Cx-Query Resp shall reject the registration attempt.

[0038] 5. The I-CSCF shall use the name of the S-CSCF to determine the address of the S-CSCF through a name-address resolution mechanism. The name-address resolution mechanism is allowed to take into account the load information of the S-CSCF (e.g., obtained using network management procedures) when determining the address of the S-CSCF. The I-CSCF shall also determine the name of a preferred home network contact point, possibly based on information received from the HSS. The I-CSCF shall then send the registration information flow (P-CSCF address / name, public user identity, private user identity, P-CSCF network identifier, UE IP address) to the selected S-CSCF. The home network contact point will be used by the P-CSCF to forward session initiation signaling to the home network. The S-CSCF shall reject registration if the number of registered contact addresses for the public user identity from the same UE exceeds the limit of simultaneous registrations configured in the S-CSCF. The S-CSCF shall also reject registrations from separate UEs if the allowed number of simultaneous registrations according to the S-CSCF configuration or per subscribed value for the Public User Identity received from the HSS exceeds the simultaneous registration limit. The S-CSCF shall store the P-CSCF address / name as provided by the visited network. This represents the address / name to which the home network forwards subsequent terminating session signaling to the UE. The S-CSCF shall store the P-CSCF network identity information.

[0039] 6. The S-CSCF 202 shall send Cx-Put / Cx-Pull (Public User Identity, Private User Identity, S-CSCF Name) to the HSS.

[0040] 7. The HSS shall store the S-CSCF name for that user and return the information flow Cx-Put Resp / Cx-Pull Resp (user information) to the S-CSCF. The user information passed from the HSS to the S-CSCF shall include one or more name / address information that can be used to access the platform(s) used for service control while the user is registered at this S-CSCF. The S-CSCF shall store information about the indicated user. In addition to the name / address information, security information may also be sent for use within the S-CSCF. Advantageously, as described above, the user information stored in the HSS and provided to the S-CSCF is extended to include at least one 3P allowance indicator. For example, an operator owning an IMS system provisions the IMPI / IMPU and corresponding user information in the HSS via a provisioning interface not specified by 3GPP. Thus, in some embodiments, the operator includes the 3P allowance indicator(s) in the user information that the operator provisions in the HSS.

[0041] 8. Based on the filter criteria, the S-CSCF shall send the registration information to the service control platform and implement whatever service control procedures are appropriate.

[0042] 9. The S-CSCF shall return a 200 OK information flow (home network contact information, GRUU set) to the I-CSCF.

[0043] 10. The I-CSCF shall send information flow 200 OK (Home Network Contact Information, GRUU Set) to the P-CSCF. After sending information flow 200 OK, the I-CSCF shall release all registration information.

[0044] 11. The P-CSCF shall store the home network contact information and send information flow 200 OK (GRUU Set) to the UE. The P-CSCF may subscribe to notifications of the status of IMS signaling connectivity from the PCRF / PCF (see TS 23.203

[54] and TS 23.503

[95] for further details). If the S-CSCF receives priority information for MPS-subscribed UEs as part of the user profile from the HSS, the S-CSCF provides the priority information to the P-CSCF, and the P-CSCF stores this information for the MPS-subscribed UEs.

[0045] 2 and described above, in step 6, the S-CSCF sends a request message (e.g., Cx-Put / Cx-Pull(Public User Identity, Private User Identity, S-CSCF Name)) to the HSS, and in step 7, the HSS responds to the request by providing user information related to the IMS identity (e.g., IMPU) to the S-CSCF. This user information includes 3P allowance indicator(s) that indicate whether 3P ID is allowed for the IMS identity.

[0046] Alternatively, if the indication that the IMPU is authorized to use the 3P ID is specified within the multimedia telephony service subscription and stored in the HSS as transparent / repository data, the telephony application server (TAS) 203 (also known as the "MMTel AS") will retrieve the indication from the HSS via the Sh reference point, along with the rest of the transparent / repository data related to the IMPU from the HSS. This is shown in Figure 2, which shows the TAS receiving a registration message from the S-CSCF (step 5b in Figure 2), and then retrieving the multimedia telephony service subscription, which is stored in the HSS (step 7b in Figure 2).

[0047] 3P tolerance indicator enforcement

[0048] In some embodiments, enforcement of authorization of whether an IMS subscription (or IMPI or IMPU) can use a 3P ID is delegated to the S-CSCF, and is performed in the S-CSCF during a mobile origination procedure (e.g., by the S-CSCF in response to receiving a SIP INVITE message) based on an IMS subscription profile downloaded from the HSS during IMS registration. Alternatively, if an indication that an IMPU is authorized to use a 3P ID is specified within a multimedia telephony service subscription and stored in the HSS as transparent / repository data, in such an embodiment, enforcement of authorization of whether an IMPU can use a 3P ID is instead delegated to the TAS.

[0049] In one embodiment, the procedure specified in Figure 6.1.2.2-1 in TR33.890 (see Figure 1) is modified as shown in Figure 3. In particular, step 3 in Figure 1 is now step 3b, and a new step (step 3a) is added. Step 3a is added to explicitly include permission of whether an IMS subscription can use a 3P ID based on a 3P allowance indicator included in the subscription profile. Steps 3a and 3b can be described as follows:

[0050] 3a. The originating IMS subsystem entity 304 (e.g., S-CSCF and / or TAS) checks whether the IMS subscription of the calling PBX is authorized to use the 3P ID. To do this, the S-CSCF or TAS in the originating IMS subsystem checks whether the PBX is authorized to use the 3P ID in the IMS subscription profile downloaded from the HSS during the registration of the calling PBX.

[0051] 3b. If the PBX is authorized to use the 3P ID, the originating IMS subsystem obtains rich call data for the 3P subscriber from a database based on the received IMS identity. If no RCD data exists for this user (IMS identity), the rest of the 3P ID related steps are not performed during call setup. The call continues without presenting a 3P ID to the called endpoint. If a 3P ID was not received in the SIP INVITE from the PBX, database lookup suppression may be applied optionally based on local policy. If there is a mismatch between the 3P ID received in the SIP INVITE and the data retrieved from the database based on the IMS identity, the local policy of the originating IMS subsystem governs how the SIP Identity header will be populated with rich call data.

[0052] If the PBX is not permitted to use the 3P ID, the originating IMS subsystem ignores the 3P ID in the SIP INVITE (if present) and does not perform the rest of the 3P ID-related steps during call setup. The call proceeds without presenting the 3P ID to the called endpoint.

[0053] Figure 4 shows another embodiment in which the 3P ID is used by a user (also known as a 3P subscriber) directly connected to the originating IMS subsystem. The steps shown in Figure 4 are described below.

[0054] 1. The 3P subscriber (SIP UA) sends a SIP INVITE that includes an IMS identity (e.g., the caller's IMPU) and may or may not include a 3P ID.

[0055] 2a. The originating IMS subsystem checks whether the IMS subscription of the calling UE is authorized to use the 3P ID. To do this, the S-CSCF (or TAS) in the originating IMS subsystem checks whether the SIP UA is authorized to use the 3P ID in the IMS subscription profile downloaded from the HSS during the SIP UA's registration.

[0056] 2b. If the UE is authorized to use the 3P ID, the originating IMS subsystem obtains the rich call data (RCD) of the 3P subscriber from a database based on the received IMS identity. If no RCD data exists for this user (IMS identity), the rest of the 3P ID related steps are not performed during call setup. The call proceeds without presenting the 3P ID to the called endpoint.

[0057] If the UE is not authorized to use the 3P ID, the originating IMS subsystem ignores the 3P ID in the SIP INVITE (if present) and does not perform the rest of the 3P ID related steps during call setup. The call proceeds without presenting the 3P ID to the called endpoint.

[0058] If no third party identity information is received in the SIP INVITE from the UE, database lookup suppression may be applied optionally based on local policy. If there is a mismatch between the 3P identity received in the SIP INVITE and the data retrieved from the database based on the IMS identity, the local policy of the originating IMS subsystem governs how the SIP identity header will be populated with rich call data.

[0059] 3. The originating IMS subsystem adds a P-Asserted Identity header field asserting the SIP UA's telephone number and rich call data, and invokes the STI-AS to sign the Identity header in accordance with Figure 6.1.2.1-2: SHAKEN Reference Architecture and TS 24.229 [4].

[0060] 4. The STI-AS interacts with the SKS (not shown in the diagram) and signs the SIP Identity header according to the STIR / SHARKEN framework and draft-ietf-stir-passport-rcd-18.

[0061] 5. The STI-AS returns the signed SIP Identity header to the IMS subsystem.

[0062] 6. The originating IMS subsystem routes the call to the egress IBCF via standard solutions. The SIP INVITE is then routed over the NNI via standard inter-domain routing configuration. The terminating service provider's ingress IBCF receives the INVITE over the NNI and forwards it to the terminating IMS subsystem.

[0063] 7. The terminating IMS subsystem invokes the STI-VS to verify the signed SIP Identity header.

[0064] 8. The STI-VS interacts with the STI-CR to verify the certificate, extract the public key, and verify the signature in the Identity header field, which confirms the caller ID and rich call data when signing the INVITE on the originating STI-AS based on Figure 6.X.2.1-2: SHAKEN Reference Architecture and TS24.229 [4].

[0065] 9. Depending on the result of the STI validation, the STI-VS decides that the call should be completed with the appropriate indicators and the result is passed to the terminating IMS subsystem which continues to set up the call to the terminating SIP UA. If the caller ID is verified OK but the rich call data is not, the call can proceed but does not present the name card information to the terminating SIP UA.

[0066] 10. A SIP INVITE with a verstat parameter is sent to the called SIP UA.

[0067] 11. The terminating SIP UA sends 18X and 200 to the originating IMS subsystem.

[0068] 12. The originating IMS subsystem sends 18X and 200 to the originating SIP UA. The call continues according to standard solutions.

[0069] 5 is a flowchart illustrating a process 500, according to one embodiment, for handling a call from a calling device (e.g., PBX 302 or SIP UA 402). Process 500 is implemented by IMS subsystem entity 304 (e.g., S-CSCF 202 and / or TAS 203). Process 500 may begin at step s502. Step s502 includes receiving a call initiation message (e.g., a SIP INVITE message) for setting up a call between the calling device (e.g., PBX or SIP UA) and a called device, the call initiation message including a user identity (e.g., an IMPU). Step s504 includes, after receiving the call initiation message, determining whether user information associated with the user identity indicates that use of a 3P ID is permitted.

[0070] 7 is a flowchart illustrating a process 700 according to one embodiment. Process 700 is performed by a subscriber server (e.g., HSS 201). Process 700 may begin at step s702. Step s702 includes receiving user information including a user identity and a first third-party (3P) allowance indicator value associated with the user identity to indicate whether use of a third-party (3P) identifier (ID) is permitted. Step s704 includes storing the user information. Step s706 includes receiving a request message from the IMS subsystem entity 304 requesting the user information. Step s708 includes sending a response message to the IMS subsystem entity in response to the request message, the response message including the user information.

[0071] 6 is a block diagram of an apparatus 600, according to some embodiments, for implementing an IMS subsystem entity 304. As shown in FIG. 6, the apparatus 600 includes a processing circuit (PC) 602 that may include one or more processors (P) 655 (e.g., one or more general-purpose microprocessors and / or one or more other processors, such as application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), etc.), which may be co-located in a single housing or in a single data center or may be geographically distributed (i.e., the apparatus 600 may be a distributed computing device), and at least one network interface 648 (e.g., a physical interface or air interface) that enables the apparatus 600 to communicate with a network. The PC 602 may comprise at least one network interface 648, a transmitter (Tx) 645, and a receiver (Rx) 647 for enabling the network interface 648 to transmit data to and receive data from other nodes connected to the network 110 (e.g., an Internet Protocol (IP) network) to which the network interface 648 is connected (physically or wirelessly) (e.g., the network interface 648 may be coupled to an antenna configuration comprising one or more antennas for enabling the device 600 to transmit / receive data wirelessly), and a storage unit (a.k.a. "data storage system") 608, which may include one or more non-volatile storage devices and / or one or more volatile storage devices. In embodiments in which the PC 602 includes a programmable processor, a computer-readable storage medium (CRSM) 642 may be provided. The CRSM 642 may store a computer program (CP) 643 comprising computer-readable instructions (CRI) 644. The CRSM 642 may be a non-transitory computer-readable medium, such as a magnetic medium (e.g., a hard disk), an optical medium, a memory device (e.g., a random access memory, a flash memory), etc.In some embodiments, the CRI 644 of the computer program 643, when executed by the PC 602, is configured such that the CRI causes the device 600 to perform the steps described herein (e.g., steps described herein with reference to flowcharts). In other embodiments, the device 600 may be configured to perform the steps described herein without the need for code. That is, for example, the PC 602 may simply consist of one or more ASICs. Thus, features of the embodiments described herein may be implemented in hardware and / or software.

[0072] Overview of Various Embodiments

[0073] A1. A method 500 for handling a call from a calling device 302, 402, the method including: receiving a call initiation message (e.g., a SIP INVITE message) for setting up a call between the calling device (e.g., a PBX or SIP UA) and a called device, the call initiation message comprising user identification information (e.g., an IMPU); obtaining user information associated with the user identification information; and, after receiving the call initiation message, determining whether the user information associated with the user identification information indicates that use of a third-party (3P) identifier (ID) is permitted.

[0074] A2. The method of embodiment A1, further including retrieving user information from subscriber server 201 (eg, a home subscriber server (HSS)) during a registration procedure to register user identity information.

[0075] A3. The method of embodiment A1 or A2, wherein the user information comprises a private user identity (e.g., IMPI), the user information further comprises a first 3P allowance indicator value associated with the private user identity, and the step of determining whether the user information associated with the user identity indicates that use of 3P ID is permitted includes determining whether the first 3P allowance indicator value indicates whether use of 3P ID is permitted.

[0076] A4. The method of embodiment A3, wherein the user identity information is a public user identity information (e.g., an IMPU), the user information further includes the public user identity information, the user information further includes a second 3P allowance indicator value associated with the public user identity information, and the step of determining whether the user information associated with the user identity information indicates that use of the 3P ID is permitted further includes determining whether the second 3P allowance indicator value indicates whether use of the 3P ID is permitted.

[0077] A5. The method of embodiment A1 or A2, wherein the user identification information is a public user identification information (e.g., an IMPU), the user information includes the public user identification information, and the step of determining whether user information associated with the user identification information indicates that use of 3P ID is permitted includes determining whether the user information further includes a display name associated with the public user identification information.

[0078] A6. A method according to any one of embodiments A1 to A4, wherein the step of determining whether user information associated with the user identification information indicates that use of 3P ID is permitted includes determining whether the user information further includes a display name set to a particular value (e.g., set to "RCD").

[0079] B1. An Internet Protocol Multimedia System (IMS) subsystem entity 304 configured to perform a process including receiving a call initiation message (e.g., a SIP INVITE message) for setting up a call between a calling device (e.g., a PBX or SIP UA) and a called device, the call initiation message comprising a user identity (e.g., an IMPU); and, after receiving the call initiation message, determining whether user information associated with the user identity indicates that use of a third-party (3P) identifier (ID) is permitted.

[0080] B2. The IMS subsystem entity of embodiment B1, wherein the process further includes obtaining user information from a subscriber server (eg, a home subscriber server (HSS)) prior to receiving the call initiation message.

[0081] B3. The IMS subsystem entity of embodiment B1 or B2, wherein the user information comprises a private user identity (e.g., IMPI), the user information further comprises a first 3P allowance indicator value associated with the private user identity, and determining whether the user information associated with the user identity indicates that use of the 3P ID is permitted includes determining whether the first 3P allowance indicator value indicates whether use of the 3P ID is permitted.

[0082] B4. The IMS subsystem entity of embodiment B3, wherein the user identity is a public user identity (e.g., an IMPU), the user information further includes the public user identity, the user information further includes a second 3P allowance indicator value associated with the public user identity, and determining whether the user information associated with the user identity indicates that use of the 3P ID is allowed further includes determining whether the second 3P allowance indicator value indicates whether use of the 3P ID is allowed.

[0083] B5. The IMS subsystem entity of embodiment B1 or B2, wherein the user identity information is a public user identity (e.g., an IMPU), and the user information includes the public user identity, and determining whether user information associated with the user identity indicates that use of the 3P ID is authorized includes determining whether the user information further includes a display name associated with the public user identity.

[0084] B6. An IMS subsystem entity as described in any one of embodiments B1 to B4, wherein the step of determining whether user information associated with the user identity information indicates that use of the 3P ID is permitted includes determining whether the user information further includes a display name set to a particular value (e.g., set to "RCD").

[0085] B7. The IMS subsystem entity of embodiment B1, wherein the IMS subsystem entity is a Server-Call Session Control Function (S-CSCF) 202 or a Telephony Application Server (TAS) 203.

[0086] C1. A method 700 implemented by a subscriber server 201, the method including: receiving user information including a user identification and a first third-party (3P) allowable indicator value associated with the user identification to indicate whether use of a third-party (3P) identifier (ID) is permitted; storing the user information; receiving a request message from an IMS subsystem entity 304 requesting the user information; and sending a response message to the IMS subsystem entity in response to the request message, the response message including the user information.

[0087] C2. The method of embodiment C1, in which the user information comprises a private user identity (eg, IMPI), and the first 3P allowance indicator value is associated with the private user identity.

[0088] C3. The method of embodiment C1, wherein the user information further comprises a public user identity (eg, an IMPU), and wherein the first 3P tolerance indicator value is associated with the public user identity.

[0089] C4. The method of embodiment C1, wherein the user information comprises a private user identity (e.g., an IMPI), the user information further comprises a first public user identity (e.g., a first IMPU), the user information further comprises a second public user identity (e.g., a second IMPU), a first 3P allowed indicator value is associated with the public user identity, a second 3P allowed indicator value is associated with the private user identity, the second 3P allowed indicator value indicates that 3P ID is allowed for the second public user identity, and the first 3P allowed indicator value indicates that 3P ID is not allowed for the first public user identity.

[0090] D1. A computer program 643 comprising instructions 644 that, when executed by processing circuitry 602 of apparatus 600, causes the apparatus to perform the method of any one of embodiments A1 to A6.

[0091] D2. A carrier containing the computer program of embodiment C1, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer-readable storage medium 642.

[0092] E1. An apparatus 600 configured to perform the method of any one of embodiments A1 to A16 or C1 to C4.

[0093] While various embodiments have been described herein, it should be understood that these embodiments have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments. Moreover, unless otherwise indicated herein or clearly contradicted by context, any combination of the above-described elements in all possible variations thereof is encompassed by the present disclosure.

[0094] As used herein, sending a message "to" or "toward" an intended recipient encompasses sending the message directly to the intended recipient or sending the message indirectly to the intended recipient (i.e., one or more other nodes are used to relay the message from the source node to the intended recipient). Similarly, as used herein, receiving a message "from" a sender encompasses receiving the message directly from the sender or receiving the message indirectly from the sender (i.e., one or more nodes are used to relay the message from the sender to the receiving node). Additionally, as used herein, "a" means "at least one" or "one or more."

[0095] Additionally, while the processes described above and illustrated in the figures have been shown as a sequence of steps, this has been done for purposes of illustration only, and it is therefore contemplated that some steps may be added, some steps may be omitted, the order of steps may be rearranged, and some steps may be performed in parallel.

[0096] TIFF2025537002000002.tif84170

Claims

1. A method (500) for handling a call from a calling device (302, 402), the method comprising: receiving a call initiation message for setting up a call between the calling device and the called device (s502), wherein the call initiation message includes user identification information; obtaining user information associated with the user identification information (s504); After receiving the call initiation message, determining whether the user information associated with the user identification information indicates that use of a third-party (3P) identifier (ID) is permitted (s506); The method (500) includes:

2. obtaining the user information includes retrieving the user information from a subscriber server (201) during a registration procedure for registering the user identity; The method of claim 1.

3. the user information includes private user identification information; the user information further includes a first 3P allowance indicator value associated with the private user identity; the step of determining whether the user information associated with the user identification information indicates that use of a 3P ID is permitted includes determining whether the first 3P allowance indicator value indicates whether use of a 3P ID is permitted. The method according to claim 1 or 2.

4. the user identity is a public user identity, the user information further includes the public user identification information; the user information further includes a second 3P allowance indicator value associated with the public user identity; the step of determining whether the user information associated with the user identification information indicates that use of a 3P ID is permitted further includes determining whether the second 3P allowance indicator value indicates whether use of a 3P ID is permitted. The method of claim 3.

5. the user identity is a public user identity, the user information includes the public user identification information; determining whether the user information associated with the user identity indicates that use of 3P ID is permitted includes determining whether the user information further includes a display name associated with the public user identity; The method according to claim 1 or 2.

6. the step of determining whether the user information associated with the user identification information indicates that use of 3P ID is permitted includes determining whether the user information further includes a display name set to a particular value.

5. The method according to any one of claims 1 to 4.

7. an Internet Protocol Multimedia System (IMS) subsystem entity (304), said IMS entity comprising: Receiving a call initiation message for setting up a call between a calling device and a called device (s502), wherein the call initiation message includes user identification information; After receiving the call initiation message, determining whether user information associated with the user identification information indicates that use of a third-party (3P) identifier (ID) is permitted (s506); An Internet Protocol Multimedia System (IMS) subsystem entity (304) configured to implement a process including:

8. The process comprises: obtaining the user information from a subscriber server prior to receiving the call initiation message; The IMS subsystem entity of claim 7 further comprising:

9. the user information includes private user identification information; the user information further includes a first 3P allowance indicator value associated with the private user identity; the step of determining whether the user information associated with the user identification information indicates that use of a 3P ID is permitted includes determining whether the first 3P allowance indicator value indicates whether use of a 3P ID is permitted. An IMS subsystem entity according to claim 7 or 8.

10. the user identity is a public user identity, the user information further includes the public user identification information; the user information further includes a second 3P allowance indicator value associated with the public user identity; the step of determining whether the user information associated with the user identification information indicates that use of a 3P ID is permitted further includes determining whether the second 3P allowance indicator value indicates whether use of a 3P ID is permitted. The IMS subsystem entity of claim 9.

11. the user identity is a public user identity, the user information includes the public user identification information; determining whether the user information associated with the user identity indicates that use of 3P ID is permitted includes determining whether the user information further includes a display name associated with the public user identity; An IMS subsystem entity according to claim 7 or 8.

12. the step of determining whether the user information associated with the user identification information indicates that use of 3P ID is permitted includes determining whether the user information further includes a display name set to a particular value. An IMS subsystem entity according to any one of claims 7 to 10.

13. An IMS subsystem entity according to any one of claims 7 to 12, wherein said IMS subsystem entity is a Server-Call Session Control Function (S-CSCF) (202).

14. The IMS subsystem entity according to any one of claims 7 to 12, wherein said IMS subsystem entity is a Telephony Application Server (TAS) (203).

15. A method (700) implemented by a subscriber server (201), said method comprising: receiving (s702) user information including a user identification and a first third-party (3P) permissive indicator value associated with the user identification to indicate whether use of a 3P identifier (ID) is permitted; storing the user information (s704); receiving (s706) a request message from an IMS subsystem entity (304) requesting said user information; sending a response message to the IMS subsystem entity in response to the request message (s708), the response message including the user information; and A method (700) comprising:

16. the user information further includes private user identification information; the first 3P allowance indicator value is associated with the private user identity; 16. The method of claim 15.

17. the user information further includes public user identification information; the first 3P allowance indicator value is associated with the public user identity; 16. The method of claim 15.

18. the user information further includes private user identification information; the user information further includes a first public user identity; the user information further includes a second public user identity; the first 3P allowance indicator value is associated with the public user identity; a second 3P allowance indicator value associated with said private user identity; the second 3P allowance indicator value indicates that 3P ID is allowed for the second public user identity; the first 3P allowance indicator value indicates that 3P ID is not allowed for the first public user identity.

16. The method of claim 15.

19. A computer program (643) comprising instructions (644) which, when executed by a processing circuit (602) of an apparatus (600), cause said apparatus to perform a method according to any one of claims 1 to 6 or 15 to 18.

20. 20. A carrier containing the computer program of claim 19, said carrier being one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium (642).

21. A subscriber server (201), receiving (s702) user information including a user identification and a first third-party (3P) permissive indicator value associated with the user identification to indicate whether use of a 3P identifier (ID) is permitted; storing the user information (s704); receiving (s706) a request message from an IMS subsystem entity (304) requesting said user information; sending a response message to the IMS subsystem entity in response to the request message (s708), the response message including the user information; and A subscriber server (201) configured to implement a method including:

22. the user information further includes private user identification information; the first 3P allowance indicator value is associated with the private user identity; 22. The subscriber server of claim 21.

23. the user information further includes public user identification information; the first 3P allowance indicator value is associated with the public user identity; 22. The subscriber server of claim 21.

24. the user information further includes private user identification information; the user information further includes a first public user identity; the user information further includes a second public user identity; the first 3P allowance indicator value is associated with the public user identity; a second 3P allowance indicator value associated with said private user identity; the second 3P allowance indicator value indicates that 3P ID is allowed for the second public user identity; the first 3P allowance indicator value indicates that 3P ID is not allowed for the first public user identity.

22. The subscriber server of claim 21.

Images