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] Embodiments relating to systems and methods for call handling are disclosed.

Background Art

[0002] There is a scenario where 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 including the employee's full name, the enterprise name, job title, enterprise location, etc.) when initiating a call to a callee. The IMS network can present the 3P ID to the callee during the subsequent call origination process. A user (e.g., a third-party subscriber) (also referred to as a "caller") can likewise access the IMS network either directly or via a Session Initiation Protocol (SIP) trunk.

[0003] Third 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 Issue #1," which covers research on enhanced IMS networks that should be able to support user verification and authorization during IMS calls. The objective is to prevent, for example, a malicious device (also known as a user device (UE)) from using a 3P ID belonging to another person (an employee) or a forged ID to initiate an IMS call on an IMS network, or from using a 3P ID that no longer belongs to the caller to initiate an IMS call on an IMS network (for example, a user using an ID assigned by a particular company after leaving the company). TR33.890 proposes a solution based on the existence of a database that maintains the relationship between 3P IDs and each user's IMS identification information used within the IMS domain (i.e., each user's IMS private user identification information (IMPI) and / or IMS public user identification information (IMPU)) (see, for example, step 3 in Figure 1, which is a copy of Figure 6.1.2.2-1 from TR33.890).

[0004] Generally, an integrated circuit card (ICC), such as a Universal Integrated Circuit Card (UICC), within a device configured to utilize IMS contains an application known as an IMS Identification 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 identification information 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 ("TS23.228"), and is shown in Figure 4.5 of TS23.228, which illustrates an "IMS subscription" that includes a single private user identification information and a set of one or more public user identification information associated with the private user identification information. According to Section 4.3.3.1 of TS23.228, "Every IM CN subsystem user shall have one or more private user identifiers, which are assigned by the home network operator and used for purposes such as registration, authorization, administration, and accounting," and according to Section 4.3.3.2, "Every IM CN subsystem user shall have one or more public user identifiers, which shall include at least one in the form of a SIP URI, which are used by any user to request communication with other users." As stated in TS23.228, "it shall be possible to support wildcarded public user identifiers, which represent a set of public user identifiers grouped together."

[0005] The message flow shown in Figure 1 consists of 13 steps, which are described in TR33.890 and are described below.

[0006] 1. A third-party (3P) PBX (private branch exchange) sends a SIP INVITE to the Interconnect Border Control Function (IBCF) that may or may not include the calling UE's IMS identification information (i.e., the calling UE's IMPU) (and also the calling UE's IMPU) and the 3P ID for the third-party (3P) subscriber.

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

[0008] 3. The calling IMS subsystem checks whether the calling PBX's IMS subscription is permitted (i.e., allowed) to use 3P IDs. If the PBX is not permitted to use 3P IDs, the calling IMS subsystem ignores the 3P IDs in the SIP INVITE (if any) and does not perform the remainder of the 3P ID relationship steps during call setup. The call proceeds without presenting the 3P ID to the incoming endpoint. If the PBX is permitted to use 3P IDs, the calling IMS subsystem retrieves the 3P subscriber's Rich Call Data (RCD) from the database based on the received IMS Identifier (IMPU). If no RCD data exists for this user (IMS Identifier), the remainder of the 3P ID relationship steps is not performed during call setup. The call proceeds without presenting the 3P ID to the incoming endpoint. Note: If a 3P ID is not received from the PBX in the SIP INVITE, suppression of the database lookup may be applied at will based on local policy. If there is a discrepancy between the 3P ID received during a SIP INVITE and the data retrieved from the database based on the IMS identity information, how the rich call data is populated into the SIP identity information header is governed by the local policy of the originating IMS subsystem.

[0009] 4. The calling IMS subsystem adds a P-assert identity header field that asserts the 3P subscriber's telephone number and rich call data, and calls STI-AS (Secure Telephone Identity Authentication Service) to sign the identity header based on Figure 6.X.2.1-2: SHAKEN reference architecture and TS24.229[4].

[0010] 5. STI-AS interacts with 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. 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 through a standard solution. The SIP INVITE is then routed over the NNI through a standard inter-domain routing configuration. The incoming service provider's ingress IBCF receives the INVITE and forwards it to the incoming IMS subsystem.

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

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

[0015] 10. Based on the results of the STI validity check, STI-VS determines that the call should be completed with the appropriate indicator and that the result should be passed to the receiving IMS subsystem to continue setting up the call to the receiving SIP UA. If the caller ID is confirmed as OK but the rich call data is not, the call can proceed but will not show the name card information to the receiving SIP UA.

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

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

[0018] 13. The originating IMS subsystem sends 18X and 200 to the originating SIP UA. The call continues according to the standard solution. [Overview of the project]

[0019] Currently, several challenges exist. For example, before the outgoing IMS subsystem contacts the database to verify the third-party ID (3P ID) in step 3 of Figure 1, step 3 includes an authorization step to ensure that the IMS subscription is initially allowed to use the 3P ID, but how the outgoing IMS subsystem implements this authorization is not yet specified.

[0020] Accordingly, in one embodiment, a method is provided for handling a call from a calling device. This method includes 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 calling device, wherein the call initiation message comprises user identification information (e.g., an IMPU). After receiving the call initiation message, the method also includes determining whether the user information associated with the user identification information indicates that the use of a 3P ID is permitted.

[0021] In another embodiment, a method is provided which is performed by a subscriber server. This method includes receiving user information, which includes user identification information and a first 3P permission indicator value associated with the user identification information to indicate whether the use of a 3P ID is permitted. This method also includes storing the user information. This method also includes receiving a request message from an IMS subsystem entity requesting user information. This method further includes sending a response message to the IMS subsystem entity in response to the request message, the response message including user information.

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

[0023] An advantage of the embodiments disclosed in the present specification is that said embodiments utilize a subscriber system in an IMS subsystem (for example, a Home Subscriber System (HSS)) to manage a subscription profile that defines IMS services enabled for a user of an IMS subscription. These embodiments have minimal impact on IMS procedures.

[0024] The accompanying drawings, which are incorporated in and constitute a part of the present specification, illustrate various embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] [Figure 1] is a diagram showing a message flow for establishing a call. [Figure 2] is a diagram showing a registration message flow. [Figure 3] is a diagram showing a message flow for establishing a call, in accordance with some embodiments. [Figure 4] is a diagram showing a message flow for establishing a call, in accordance with some embodiments. [Figure 5] is a flowchart illustrating a process in accordance with some embodiments. [Figure 6] is a block diagram of an apparatus in accordance with some embodiments. [Figure 7] is a flowchart illustrating a process in accordance with some embodiments. DESCRIPTION OF EMBODIMENTS

[0026] This disclosure provides means for an originating IMS subsystem to perform an authorization check to determine 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 user identification information contained in a call initiation message (e.g., a SIP INVITE message). Thus, in some embodiments, new information is defined in user information managed in the originating IMS subsystem's HSS (e.g., an IMS subscription profile), and this user information is provided to the Server-Call Session Control Function (S-CSCF) during IMPI registration in the IMS. In these embodiments, authorization enforcement is then performed in the S-CSCF during IMS session setup.

[0027] 3P Allowable Indicator Regulations

[0028] There are different ways to indicate within user information associated with IMS identification whether the use of 3P IDs is permitted for IMS identification. For example, a "3P Allowed" indicator may be added to user information (IMS subscription profile) and used to indicate whether the use of 3P IDs is permitted (for example, when the indicator value is set to 1 or true, this indicates that 3P IDs are permitted, and otherwise, 3P IDs are not). The 3P Allowed indicator may be defined within the IMS subscription profile at the IMPI level, meaning whether all IMPUs associated with the IMS subscription (e.g., all users behind a PBX client) will be permitted to use 3P IDs. The absence of a 3P Allowed indicator at the IMPI level is understood when none of the IMPUs associated with the IMPI are permitted to utilize 3P IDs. For example, user information associated with a particular IMPU (e.g., IMS subscription profile) may include the IMPI, the specific IMPU, and zero or more other IMPUs. When a 3P-tolerant indicator is defined at the IMPI level, that indicator is associated with IMPI (for example, included in IMPI-linked metadata in user information).

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

[0030] In one embodiment, the 3P permission 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 a 3P ID is permitted for that particular IMPU. However, when wildcarded IMPUs are used (for example, in the PBX case), it is not possible for the “display name” to contain individualized 3P IDs for each individual IMPU in that wildcarded IMPU set. In this case, the “display name” may simply be set to a value that indicates that any particular IMPU in that set is permitted to use a 3P ID (if a particular IMPU is permitted to use a 3P ID, the IMS subsystem can retrieve the 3P ID associated with the IMPU from the 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, for example, “ / RCD / ”, or a similar value, to indicate that a 3P ID is permitted for the IMPU.

[0031] Furthermore, instructions that allow IMPU to use 3P IDs may be stipulated within the multimedia telephony service subscription and may be stored in the HSS as transparent / repository data.

[0032] 3P-tolerant indicator delivery to S-CSCF or TAS

[0033] The 3P permission indicator is included in the IMS subscription profile (user information) downloaded by the S-CSCF from the HSS during IMS subscription registration 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 TS23.228, shown in Figure 2 (a copy of Figure 5-1 from TS23.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 identification information, private user identification information, home network domain name, UE IP address, instance identifier, GRUU support instructions) 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 identification information, private user identification information, P-CSCF network identifier, UE IP address). A name-address resolution mechanism is used 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 on which the P-CSCF is located within the home network (for example, the P-CSCF network identifier may be the domain name of the P-CSCF network).

[0036] 3. The I-CSCF shall send the Cx-Query / Cx-Select-Pull information flow to the HSS201 (public user identification information, private user identification information, P-CSCF network identifier). The HSS shall check whether the user is already registered. The HSS shall indicate whether the user is permitted to register in that P-CSCF network (identified by the P-CSCF network identifier) ​​in accordance with the user subscription and any operator restrictions / limitations.

[0037] 4. The 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 include the S-CSCF name, if it is known by the HSS, or the S-CSCF capabilities, if they are necessary to select a new S-CSCF. When capabilities are returned, the I-CSCF shall construct a name from the returned capabilities. If the check in the HSS is unsuccessful, 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 the name-address resolution mechanism. The name-address resolution mechanism may take into account the load information of the S-CSCF (e.g., obtained using the network management procedure) when determining the address of the S-CSCF. The I-CSCF shall also determine the name of a suitable home network contact point, depending on the information received from the HSS. The I-CSCF shall then send a registration information flow (P-CSCF address / name, public user identification information, private user identification information, 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 start signaling to the home network. The S-CSCF shall reject registration if the number of registered contact addresses for public user identification information from the same UE exceeds the simultaneous registration limit set in the S-CSCF. S-CSCF shall also reject registration from a separate UE if the number of concurrent registrations allowed per value, according to the S-CSCF settings or subscribed values ​​for public user identification information received from HSS, exceeds the concurrent registration limit. S-CSCF shall store the P-CSCF address / name as provided by the visited network. This represents the address / name from which the home network forwards subsequent session termination signaling to the UE. S-CSCF shall store P-CSCF network ID information.

[0039] 6. S-CSCF202 shall send Cx-Put / Cx-Pull (public user identification information, private user identification information, S-CSCF name) to HSS.

[0040] 7. The HSS shall store the S-CSCF name for the user and return an 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 one or more platforms used for service control while the user is registered in this S-CSCF. The S-CSCF shall store information about the designated user. In addition to name / address information, security information may also be sent for use within the S-CSCF. Advantageously, the user information stored in the HSS and provided to the S-CSCF, as described above, is extended to include at least one 3P-accepting indicator. For example, an operator owning an IMS system provisions IMPI / IMPU and corresponding user information in the HSS via a provisioning interface not defined by 3GPP. Thus, in some embodiments, the operator includes one or more 3P-accepting indicators in the user information that the operator provisions to the HSS.

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

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

[0043] 10. I-CSCF shall send information flow 200 OK (home network contact information, GRUU set) to P-CSCF. After sending information flow 200 OK, I-CSCF shall release all registration information.

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

[54] and TS23.503

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

[0045] As shown in Figure 2 and as described above, in step 6, the S-CSCF sends a request message to the HSS (e.g., Cx-Put / Cx-Pull(public user identification information, private user identification information, S-CSCF name)), and in step 7, the HSS responds to the request by providing the S-CSCF with user information related to the IMS identification information (e.g., IMPU). This user information includes (one or more) 3P acceptance indicators indicating whether the 3P ID is acceptable for the IMS identification information.

[0046] Alternatively, if the instruction that the IMPU is permitted to use a 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 "MMTel AS") will retrieve the instruction 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, where the TAS receives a registration message from the S-CSCF (step 5b in Figure 2) and then retrieves the multimedia telephony service subscription, which is stored in the HSS (step 7b in Figure 2).

[0047] 3P tolerance indicator implemented

[0048] In some embodiments, the enforcement of permission for an IMS subscription (or IMPI or IMPU) to use a 3P ID is delegated to the S-CSCF, which is performed by the S-CSCF during the mobile outbound procedure based on the IMS subscription profile downloaded from the HSS during IMS registration (for example, performed by the S-CSCF in response to receiving a SIP INVITE message). Alternatively, if the instruction that an IMPU is permitted to use a 3P ID is specified within the multimedia telephony service subscription and stored in the HSS as transparent / repository data, in such embodiments, the enforcement of permission for an IMPU to use a 3P ID is delegated instead 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 detail, step 3 in Figure 1 is now step 3b, with a new step (step 3a) added. Step 3a is added to explicitly include permission for whether an IMS subscription can use a 3P ID, based on a 3P permission indicator included in the subscription profile. Steps 3a and 3b may be described as follows:

[0050] 3a. The calling IMS subsystem entity 304 (for example, S-CSFC and / or TAS) checks whether the calling PBX's IMS subscription is permitted to use 3P IDs. To grant this permission, the S-CSFC or TAS in the calling IMS subsystem checks in the IMS subscription profile downloaded from the HSS during the calling PBX registration whether the PBX is permitted to use 3P IDs.

[0051] 3b. If the PBX is permitted to use 3P IDs, the originating IMS subsystem retrieves rich call data for the 3P subscriber from the database based on the received IMS identity. If no RCD data exists for this user (IMS identity), the remainder of the 3P ID relationship steps are not performed during call setup. The call proceeds without presenting the 3P ID to the incoming endpoint. If the 3P ID is not received from the PBX during the SIP INVITE, suppression of the database lookup may be applied at will based on the local policy. If there is an inconsistency between the received 3P ID during the SIP INVITE and the data retrieved from the database based on the IMS identity, how the rich call data is populated into the SIP identity header is governed by the originating IMS subsystem's local policy.

[0052] If the PBX is not permitted to use 3P IDs, the originating IMS subsystem ignores the 3P IDs in the SIP INVITE (if any) and does not perform the remaining 3P ID relationship steps during call setup. The call proceeds without presenting the 3P ID to the incoming 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. A 3P subscriber (SIP UA) sends a SIP INVITE that includes IMS identification information (e.g., the caller's IMPU) and may or may not include a 3P ID.

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

[0056] 2b. If the UE is permitted to use 3P ID, the calling IMS subsystem retrieves the 3P subscriber's Rich Call Data (RCD) from the database based on the received IMS identity. If no RCD data exists for this user (IMS identity), the remainder of the 3P ID relationship steps is not performed during call setup. The call proceeds without presenting the 3P ID to the incoming call endpoint.

[0057] If the UE is not permitted to use 3P IDs, the calling IMS subsystem ignores the 3P IDs in the SIP INVITE (if any) and does not perform the remainder of the 3P ID relationship steps during call setup. The call proceeds without presenting the 3P IDs to the incoming call endpoint.

[0058] If third-party ID information is not received from the UE during a SIP invitation, database lookup suppression may be applied at the discretion of the local policy. If there is a discrepancy between the 3P ID received during the SIP invitation and the data retrieved from the database based on the IMS identity information, how the rich call data is populated into the SIP identity information header is governed by the local policy of the originating IMS subsystem.

[0059] 3. The calling IMS subsystem adds a P Asserted Identification Header field to assert the SIP UA's telephone number and rich call data, and calls the STI-AS to sign the Identification Header based on Figure 6.1.2.1-2: SHAKEN Reference Architecture and TS24.229[4].

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

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

[0062] 6. The originating IMS subsystem routes the call to the exit IBCF through a standard solution. The SIP INVITE is then routed over the NNI through a standard inter-domain routing configuration. The incoming service provider's inbound IBCF receives the INVITE over the NNI and forwards it to the incoming IMS subsystem.

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

[0064] 8. STI-VS interacts with STI-CR to verify the certificate, extracts the public key, verifies the signature in the Identification header field, and verifies the caller ID and rich call data when signing the INVITE on the calling STI-AS based on Figure 6.X.2.1-2: SHAKEN reference architecture and TS24.229[4].

[0065] 9. Based on the results of the STI validity check, STI-VS determines that the call should be completed with the appropriate indicator and that the result should be passed to the receiving IMS subsystem to continue setting up the call to the receiving SIP UA. If the caller ID is confirmed as OK but the rich call data is not, the call can proceed but will not show the name card information to the receiving SIP UA.

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

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

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

[0069] Figure 5 is a flowchart of 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 performed by an IMS subsystem entity 304 (e.g., S-CSCF202 and / or TAS203). Process 500 may begin in step s502. Step s502 is receiving a call initiation message (e.g., a SIP INVITE message) to set up a call between the calling device (e.g., PBX or SIP UA) and the calling device, and includes receiving a call initiation message in which the call initiation message comprises user identification information (e.g., IMPU). Step s504, after receiving the call initiation message, includes determining whether the user information related to the user identification information indicates that the use of a 3P ID is permitted.

[0070] Figure 7 is a flowchart of process 700 according to one embodiment. Process 700 is performed by a subscriber server (e.g., HSS201). Process 700 may begin in step s702. Step s702 includes receiving user information, which includes user identification information and a first third-party (3P) permission indicator value associated with the user identification information to indicate whether the 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, which includes sending a response message that contains the user information.

[0071] Figure 6 is a block diagram of the device 600 according to several embodiments for implementing the IMS subsystem entity 304. As shown in Figure 6, the device 600 comprises a processing circuit (PC) 602 which 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.), the processors of which may be colocated in a single housing or in a single data center or geographically distributed (i.e., the device 600 may be a distributed computing device), and at least one network interface 648 (e.g., a physical interface or an air interface), the device 600 being a network The PC may comprise at least one network interface 648 and a storage unit (also known as 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-temporary computer-readable medium such as a magnetic medium (e.g., a hard disk), an optical medium, or a memory device (e.g., random access memory, flash memory).In some embodiments, the CRI 644 of the computer program 643, when executed by the PC 602, configures the device 600 to perform the steps described herein (for example, the steps described herein with reference to the flowchart). 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 consist of simply one or more ASICs. Thus, the 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 calling devices 302, 402, the method comprising 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 calling device, the method comprising: receiving a call initiation message comprising user identification information (e.g., IMPU); obtaining user information related to the user identification information; and determining, after receiving the call initiation message, whether the user information related to the user identification information indicates that the use of a third-party (3P) identifier (ID) is permitted.

[0074] A2. The method according to Embodiment A1, further comprising retrieving user information from a subscriber server 201 (e.g., a home subscriber server (HSS)) during a registration procedure for registering user identification information.

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

[0076] A4. The method according to Embodiment A3, wherein the user identification information is public user identification information (e.g., IMPU), the user information further comprises public user identification information, the user information further comprises a second 3P permission indicator value related to the public user identification information, and the step of determining whether the user information related to the user identification information indicates whether the use of a 3P ID is permitted further comprises determining whether the second 3P permission indicator value indicates whether the use of a 3P ID is permitted.

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

[0078] A6. The method according to any one of Embodiments A1 to A4, wherein the step of determining whether user information related to user identification information indicates that the use of a 3P ID is permitted includes determining whether the user information further includes a display name set to a specific value (for example, set to "RCD").

[0079] B1. Internet Protocol Multimedia System (IMS) subsystem entity 304, wherein the IMS entity is configured to perform a process that includes 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 calling device, wherein the call initiation message comprises user identification information (e.g., an IMPU), and after receiving the call initiation message, determining whether the user information related to the user identification information indicates that the use of a third-party (3P) identifier (ID) is permitted.

[0080] B2. The IMS subsystem entity according to Embodiment B1, further comprising the process obtaining user information from a subscriber server (e.g., a home subscriber server (HSS)) before receiving a call initiation message.

[0081] B3. An IMS subsystem entity according to Embodiment B1 or B2, wherein the user information comprises private user identification information (e.g., IMPI), the user information further comprises a first 3P permission indicator value associated with the private user identification information, and the step of determining whether the user information associated with the user identification information indicates that the use of a 3P ID is permitted includes determining whether the first 3P permission indicator value indicates whether the use of a 3P ID is permitted.

[0082] B4. The IMS subsystem entity according to Embodiment B3, wherein the user identification information is public user identification information (e.g., IMPU), the user information further includes public user identification information, the user information further includes a second 3P permission indicator value related to the public user identification information, and the step of determining whether the user information related to the user identification information indicates that the use of a 3P ID is permitted further includes determining whether the second 3P permission indicator value indicates whether the use of a 3P ID is permitted.

[0083] B5. The IMS subsystem entity according to Embodiment B1 or B2, wherein the step of determining whether the user identification information is public user identification information (e.g., IMPU), and the user information includes public user identification information, and whether the user information related to the user identification information indicates that the use of a 3P ID is permitted, includes determining whether the user information further includes a display name related to the public user identification information.

[0084] B6. The step of determining whether user information related to user identification information indicates that the use of a 3P ID is permitted includes determining whether the user information further includes a display name set to a specific value (for example, set to "RCD"), as described in any one of Embodiments B1 to B4 of the IMS subsystem entity.

[0085] B7. The IMS subsystem entity according to 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 performed by a subscriber server 201, the method comprising: receiving user information, which includes user identification information and a first third-party (3P) permission indicator value associated with the user identification information for indicating whether the 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 user information; and sending a response message to the IMS subsystem entity in response to the request message, wherein the response message includes user information.

[0087] C2. The method according to Embodiment C1, wherein the user information comprises private user identification information (e.g., IMPI), and the first 3P tolerance indicator value is associated with the private user identification information.

[0088] C3. The method according to Embodiment C1, wherein the user information further comprises public user identification information (e.g., IMPU), and the first 3P tolerance indicator value is associated with the public user identification information.

[0089] C4. The method according to Embodiment C1, wherein the user information comprises private user identification information (e.g., IMPI), the user information further comprises first public user identification information (e.g., first IMPU), the user information further comprises second public user identification information (e.g., second IMPU), a first 3P tolerance indicator value is associated with the public user identification information, a second 3P tolerance indicator value is associated with the private user identification information, the second 3P tolerance indicator value indicates that the 3P ID is acceptable for the second public user identification information, and the first 3P tolerance indicator value indicates that the 3P ID is not acceptable for the first public user identification information.

[0090] D1. A computer program 643 comprising an instruction 644 that, when executed by the processing circuit 602 of the device 600, causes the device to carry out the method according to any one of embodiments A1 to A6.

[0091] D2. A carrier comprising the computer program described in 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. Apparatus 600 configured to carry out the method described in 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 are presented only as examples and not as limitations. Therefore, the breadth and scope of this disclosure should not be limited by any of the exemplary embodiments described above. Furthermore, unless otherwise indicated herein or expressly rejected by the context, any combination of all possible variations of the elements described above is encompassed by this disclosure.

[0094] As used herein, sending a message "to" or "towards" an intended recipient includes sending a message directly to the intended recipient or sending a 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 includes receiving a message directly from the sender or receiving a message indirectly from the sender (i.e., one or more nodes are used to relay the message from the sender to the receiving node). Furthermore, as used herein, "a" means "at least one" or "one or more".

[0095] Furthermore, the process described above and shown in the diagrams is presented as a sequence of steps, but this is done for illustrative purposes only. Therefore, it is intended that some steps may be added, some steps may be omitted, the order of the steps may be rearranged, and some steps may be performed in parallel.

[0096] TIFF0007915894000001.tif84170

Claims

1. A method (500) for handling a call from a calling device (302, 402), wherein the method is: Receiving a call initiation message for setting up a call between the calling device and the receiving device (s502), wherein the call initiation message includes user identification information (s502), Obtaining user information related to the aforementioned user identification information (s504), After receiving the call initiation message, determine whether the user information related to the user identification information indicates that the use of a third-party (3P) identifier (ID) is permitted (s506) Includes, The user information includes private user identification information or public user identification information, The user information further includes a 3P tolerance indicator value related to the private user identification information or the public user identification information, The step of determining whether the user information relating to the user identification information indicates that the use of a 3P ID is permitted includes determining whether the 3P permission indicator value indicates whether the use of a 3P ID is permitted or not, method (500).

2. Obtaining the user information includes retrieving the user information from the subscriber server (201) during a registration procedure for registering the user identification information. The method according to claim 1.

3. The aforementioned user identification information is public user identification information, The user information includes the public user identification information, The step of determining whether the user information relating to the user identification information indicates that the use of a 3P ID is permitted includes determining whether the user information further includes a display name relating to the public user identification information. The method according to claim 1.

4. The step of determining whether the user information related to the user identification information indicates that the use of a 3P ID is permitted includes determining whether the user information further includes a display name set to a specific value. The method according to claim 1.

5. An Internet Protocol Multimedia System (IMS) subsystem entity (304), wherein the IMS subsystem entity is Receiving a call initiation message for setting up a call between a calling device and a receiving device (s502), wherein the call initiation message includes user identification information (s502), After receiving the call initiation message, determine whether the user information related to the user identification information indicates that the use of a third-party (3P) identifier (ID) is permitted (s506) It is configured to perform a process that includes, The user information includes private user identification information or public user identification information, The user information further includes a 3P tolerance indicator value related to the private user identification information or the public user identification information, The step of determining whether the user information relating to the user identification information indicates that the use of a 3P ID is permitted includes determining whether the 3P permission indicator value indicates whether the use of a 3P ID is permitted, in an Internet Protocol Multimedia System (IMS) subsystem entity (304).

6. The aforementioned process, Obtain the user information from the subscriber server before receiving the call initiation message. The IMS subsystem entity according to claim 5, further comprising:

7. The aforementioned user identification information is public user identification information, The user information includes the public user identification information, The step of determining whether the user information relating to the user identification information indicates that the use of a 3P ID is permitted includes determining whether the user information further includes a display name relating to the public user identification information. The IMS subsystem entity according to claim 5.

8. The step of determining whether the user information related to the user identification information indicates that the use of a 3P ID is permitted includes determining whether the user information further includes a display name set to a specific value. The IMS subsystem entity according to claim 5.

9. The IMS subsystem entity according to claim 5, wherein the IMS subsystem entity is a server-call session control function (S-CSCF) (202).

10. The IMS subsystem entity according to claim 5, wherein the IMS subsystem entity is a telephony application server (TAS) (203).

11. A method (700) performed by a subscriber server (201), wherein the method is Receiving user information (s702) which includes user identification information and a first 3P permission indicator value associated with the user identification information to indicate whether or not the use of a third-party (3P) identifier (ID) is permitted, The user information mentioned above is stored (s704), Receiving a request message from the IMS subsystem entity (304) requesting the user information (s706), Sending a response message to the IMS subsystem entity in response to the request message (s708), wherein the response message includes the user information (s708) Includes, The user information further includes private user identification information or public user identification information, Method (700), wherein the first 3P tolerance indicator value is related to the private user identification information or the public user identification information.

12. The user information further includes private user identification information, The user information further includes first public user identification information, The user information further includes a second public user identification information, The first 3P tolerance indicator value is related to the public user identification information, The second 3P tolerance indicator value is related to the private user identification information, The second 3P tolerance indicator value indicates that the 3P ID is acceptable for the second public user identification information. The first 3P tolerance indicator value indicates that the 3P ID is not acceptable for the first public user identification information. The method according to claim 11.

13. The subscriber server (201) is Receiving user information (s702) which includes user identification information and a first 3P permission indicator value associated with the user identification information to indicate whether or not the use of a third-party (3P) identifier (ID) is permitted, The user information mentioned above is stored (s704), Receiving a request message from the IMS subsystem entity (304) requesting the user information (s706), Sending a response message to the IMS subsystem entity in response to the request message (s708), wherein the response message includes the user information (s708) It is configured to implement a method that includes, The user information further includes private user identification information or public user identification information, A subscriber server (201) whose first 3P tolerance indicator value is associated with the private user identification information or the public user identification information.

14. The user information further includes private user identification information, The user information further includes first public user identification information, The user information further includes a second public user identification information, The first 3P tolerance indicator value is related to the public user identification information, The second 3P tolerance indicator value is related to the private user identification information, The second 3P tolerance indicator value indicates that the 3P ID is acceptable for the second public user identification information. The first 3P tolerance indicator value indicates that the 3P ID is not acceptable for the first public user identification information. The subscriber server according to claim 13.

Images