GB2632488A - Authorizing use of third party specific user identities in internet protocol multimedia subsystems - Google Patents

Abstract

A request is transmitted (140) to a signing server 13 to sign a uniform resource identifier associated with third party user data. A signed token associated with the URI is received (140) in reply, and a session initiation invitation request (e.g. SIP INVITE) is modified by inserting 150 the URI and the signed token into the invitation request. The modified request is then provided 160 to a destination network for initiating communication. Also disclosed is the use of a verification server 18 to verify the URI using the signed token and, if verified, to forward the invitation request to a destination user equipment. The party sending the modified invitation request may retrieve, from storage 14, an identifier associated with the third party user data and, if the identifier is determined not to be a URI, then the identifier may be converted into a URI.

Description

TITLE

AUTHORIZING USE OF THIRD PARTY SPECIFIC USER IDENTITIES

IN INTERNET PROTOCOL MULTIMEDIA SUBSYSTEMS

TECHNICAL FIELD:

[0001] Some example embodiments may generally relate to mobile or wireless telecommunication systems, such as Long Term Evolution (LTE) or fifth generation (5G) new radio (NR) access technology, or 5G beyond, or other communications systems. For example, certain example embodiments may o relate to authorizing the use of third party spec fic user identities in internet protocol (IP) multimedia subsystems (IMS).

BACKGROUND:

[0002] Examples of mobile or wireless telecommunication systems may include the Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN), Long Term Evolution (LTE) Evolved UTRAN (E-UTRAN), LTE-Advanced (LTE-A), MulteFire, LTE-A Pro, and/or fifth generation (5G) radio access technology or new radio (NR) access technology. Fifth generation (5G) wireless systems refer to the next generation (NG) of radio systems and network architecture. 5G network technology is mostly based on new radio (NR) technology, but the 5G (or NG) network can also build on E-UTRAN radio. It is estimated that NR may provide bitrates on the order of 10-20 Gbit/s or higher, and may support at least enhanced mobile broadband (eMBB) and ultra-reliable low-latency communication (URLLC) as well as massive machine-type communication (mMTC). NR is expected to deliver extreme broadband and ultra-robust, low-latency connectivity and massive networking to support the Internet of Things (loT).

SUMMARY:

100031 Various example embodiments may provide an apparatus including means for transmitting a request to a signing server to sign an identifier associated with third party user data, which has been determined to be a uniform resource identifier. The apparatus may also include means for receiving a reply comprising a signed token associated with the uniform resource identifier and means for modifying a session initiation protocol invitation request by inserting the uniform resource identifier and the signed token into one or more headers of the session initiation protocol invitation io request. The apparatus may further include means for providing the modified session initiation protocol invitation request to a destination network for initiating communication between at least two user equipment.

[0004] Certain example embodiments may provide an apparatus including means for receiving, from a network, a session initiation protocol invitation request comprising a uniform resource identifier and a signed token in one or more headers of the session initiation protocol invitation request. The apparatus may also include means for verifying, using a verification server, the uniform resource identifier using the signed token. The apparatus may further include means for, when the uniform resource identifier is verified, relaying the session initiation protocol invitation request including the uniform resource identifier to a destination user equipment for configuring communication with at least one other user equipment. The at least one other user equipment may retrieve third party user data associated with an identifier from a third party network.

[0005] Some example embodiments may provide a method including transmitting a request to a signing server to sign an identifier associated with third party user data, which has been determined to be a uniform resource identifier. The method may also include receiving a reply comprising a signed token associated with the uniform resource identifier and modifying a session initiation protocol invitation request by inserting the uniform resource identifier and the signed token into one or more headers of the session initiation protocol invitation request. The method may further include providing the modified session initiation protocol invitation request to a destination network for initiating communication between at least two user equipment.

100061 Various example embodiments may provide a method including receiving, from a network, a session initiation protocol invitation request comprising a uniform resource identifier and a signed token in one or more headers of the session initiation protocol invitation request. The method may also include verifying, using a verification server, the uniform resource identifier using the signed token. The method may further include, when the uniform resource identifier is verified, relaying the session initiation protocol invitation request including the uniform resource identifier to a destination user equipment for configuring communication with at least one other user equipment. The at least one other user equipment may retrieve third party user data associated with an identifier from a third party network.

BRIEF DESCRIPTION OF THE DRAWINGS:

z o [0007] For proper understanding of example embodiments, reference should be made to the accompanying drawings, as follows: 100081 FIG. 1 illustrates an example of a signal diagram of one or more procedures, according to certain example embodiments; [0009] FIG. 2 illustrates an example of a flow diagram of a method, according 25 to various example embodiments; [0010] FIG. 3 illustrates an example of a flow diagram of another method, according to some example embodiments; and [NM FIG. 4 illustrates a set of apparatuses, according to various example embodiments.

DETAILED DESCRIPTION:

[0012] It will be readily understood that the components of certain example embodiments, as generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. The following is a detailed description of some example embodiments of systems, methods, apparatuses, and non-transitory computer program products for authorizing the use of third party specific user identities in internet protocol (IP) multimedia subsystems (IMS). Although the devices discussed below and shown in the figures refer to 5G or Next Generation NodeB (gNB) devices and user equipment devices, this disclosure is not limited to only the network nodes, gNBs, and UEs discussed herein.

[0013] It may be readily understood that the components of certain example embodiments, as generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations.

Different reference designations from multiple figures may be used out of sequence in the description, to refer to a same element to illustrate their features or functions. If desired, the different functions or procedures discussed herein may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the described functions or procedures may be optional or may be combined. As such, the following description should be considered as illustrative of the principles and teachings of certain example embodiments, and not in limitation thereof [0014] In 5G/NR technology, next generation real time communications (NG RTC) may implement IMS as a network architecture that integrates with the 4G LTE and 5G networks to enable IP-based real-time services. The networks may use IMS to communicate, for example, voice calls, video calls/streaming, text messages, multimedia messages, and/or other real time services. The 3rd generation partnership project (3GPP) may have certain protocols established for implementing IMS networks. However, access to IMS networks by a third party, such as, for example, an enterprise user, may not be authorized. Conventional IMS networks may not have a mechanism in which a serving IMS network can authorize a third party user and authorize whether a third party user is allowed to use third-party specific user identities to communicate with the IMS network, such as initiating a telephone call via the IMS and providing additional user related data such as job title or department name besides the telephone number.

[0015] A third party may have a specific user ID(s), which may be, for example, a company name and logo, department name, location, picture, job title, and the like. The third party IDs may comply with Internet engineering task force (1ETF) draft-ietf-sipcore-callinfo-rcd or any similar document agreed by TETE which defines rich call data (RCD) as jCard, which may be in the form of a JavaScript object notation (JSON) object. The third party 1Ds may be stored at a server and can be fetched via a uniform resource indicator (URI) pointing to a respective resource on the server. The server may be, for example, a Web server. The URI may be transported as part of a Call-Info header field in a session initiation protocol (SIP) request from an A-side to a B-side. A jCard may also be carried in the body of an SIP request. To avoid illegal or fake information from being provided by a scammer or spammer, the provided data, such as the URI in the Call-Info header, may be signed by an originating network by invoking a signing server based on IETF draft-ietfstir-passport-rcd or a similar document agreed by TETE A terminating network side may verify the provided data by invoking a verification server.

[0016] A technique for authorising third party, e.g., enterprise, user data, such as the URI in the Call-Info header, may be to sign the third party user data by the signing server. The third party user data may be provided by a third party user or by an IP private branch exchange (IP PBX). The IMS may trust provided data based on a service level agreement (SLA) and may sign the provided data using, for example, the IETF draft-ietf-stir-passport-rcd. This technique may have less impact on the IMS and may not require the IMS to fetch or store Enterprise specific data. However, this technique may not allow the IMS to check whether a third party, e.g., enterprise, user is authorized to use the provided data, which may include a job title, even in case when third party subscription data may be stored in a home subscriber server (HSS) of the IMS.

[0017] Another technique may be to use the IMS to fetch the third party specific user data from the third party network during IMS call setup. For to example, a serving call session control function (S-CSCF) and/or telephony application server (TAS) of the IMS may be used. This can be done via a network exposure function (NEF) or directly via a third party application function (AF), such as an enterprise AF. This technique may require the IMS to query the third party (e.g., enterprise) network during call setup if the calling ID is a certain IMS public user identity (IMPU), and allows authorization of the usage of the third party user data while avoiding storing the data in the HSS. In the case of IP PBX, no individual subscription data may exist in the HSS, and the IMS may need to trust the data provided by the IP PBX.

[0018] A further technique may be to use only group data, such as company name and logo, which may be stored in the HSS without individual data, including third party individual data. This technique may not require that the IMS interact with the third party network but may require storing data in the HSS which might differ for various different third party networks. This technique may not allow to store individual third party specific user data in the HSS.

[0019] Various example embodiments may advantageously improve upon the deficiencies of the above-mentioned techniques. Certain example embodiments may provide for allowing the IMS to authorize use of third party specific user identities by a third party (e.g., enterprise) user without storing the individual user identity information in the IMS/HSS. If the data is stored in the HSS, it may be disadvantageous as different third parties may use different sets of data and the data may frequently change, such as when an employee moves from one job to another or is relocated within the company. Various example embodiments may provide that the data may be stored in the third party (e.g., enterprise) network or another storage. The draft-ietf-stirpassport-rcd may be used for defining the data. The third party specific user data may be accessible via an individual and unique ID which may be, for example, a URI as described in draft-ietf-stir-passport-rcd.

to 100201 Some example embodiments may provide that the IMS stores individual subscription data of the third party (e.g., enterprise) user. An HSS may store subscription data of third party (e.g., enterprise) users. A unique ID, such as a static URI, associated with third party user data stored on a server (e.g., a web server) in the third party network may be stored as new parameter within a service profile of the third party user together with the IMPU. The service profile may include, for example, information on activated call forwarding or other multimedia telephony service information. Different identifiers (IDs) may be stored per service profile. TAS or S-CSCF may obtain, such as by downloading, the ID together with the service profile from HSS.

[0021] If the unique ID is a URI, the unique ID may be directly inserted in the Call-Info header according to draft-ietf-stir-passport-rcd and may be signed by the signing server which is triggered by the IMS. If the unique ID is not a URI, the TAS, S-CSCF or another entity of the network may translate the ID into an URI prior to inserting the URI into the Call-Info header. By using the unique ID as a URI, third party user data may not need to be fetched from the third party (e.g., enterprise) network during call setup and it may not be required to store individual third party user data in the HSS. Although the third party user data may change in the third party (e.g., enterprise) network, the unique ID or URI may not change or may only rarely change. The third party (e.g., enterprise) server may redirect an HTTP request to a new URI and may provide the new URI to the IMS. The unique 1D/URI may be provided by the third party (e.g., enterprise) network together with the IMPU and other service relevant data, and thus may be considered as trusted. Accordingly, various example embodiments may provide that the IMS may not be required to accept untrusted data when provided by the UE in a SIP INVITE.

[0022] According to some example embodiments, the IMS may, via the TAS, the HSS, and/or the S-CSCF, use the unique ID/URI to fetch the third party data directly from the server where the data are stored. This may be achieved by an IITTP GET request that includes the unique ID/URI as Request URI. The HTTP GET request may be provided during or after storing the data in the PISS or during call setup. The HTTP GET request may be repeated at regular or pre-set time intervals. The unique 1D/URI may be provided to the HSS via operation, administration and maintenance (OAM) or by the third party network via an NEF API with other IMPU specific service data, or by any other means.

[0023] Certain example embodiments may involve an IP PBX in which the IMS may be only aware of a used PBX pilot directory number (DN).

However, the IMS may not know whether individual DNs out of a pilot DN range are valid or not, which means the IMS may not know whether individual DNs are assigned to a certain user of the IP PBX. The HSS may not store subscription data of individual third party, e.g., enterprise, users. The IMS may consider the third party user data or the URI provided by the IP PBX as trusted in a similar manner as the IMS trusts a calling number identity provided by the IP PBX. Some example embodiments may provide that the IMS may be configured per pilot DN with information or instructions that are configured to define the manner in which a unique ID/URI is created based on the IMPU that is used as the calling number. Configuration per pilot DN may be done in the TAS or CSCF. The information or instructions for configuring the IMS per pilot DN may be stored in the HSS and provided via OAM or by the third party network via a NEF API.

[0024] FIG. 1 illustrates an example of a signal diagram of one or more 5 procedures for storing a URI directing to third party user data in an HSS per IMPU of a user, according to certain example embodiments. The one or more procedures may be performed using, for example, a third party network, an originating IMS network, and a terminating IMS network. At 110, a third party user equipment (UE A) 10 in a third party network may send an SIP 10 invite message with an IMPU as a calling ID to a CSCF 12 of the originating IMS network. Service profiles including the IMPU and URI directing to user data stored in a third party network may be stored in an HSS 14. The service profiles may be stored via OAM or by the third party network via an NEF in the 1-155.

[0025] At 120, the CSCF 12 may forward the SIP INVITE, which was received from the UE A 10, to a TAS 15 to execute specified services. At 130, the TAS 15 may query the HSS 14 to retrieve a service profile. The service profile may include the URI pointing to user data stored in the third party network specific for the IMPU. At 140, the TAS 15, or alternatively, for example, a CSCF or SBC 16 on the originating IMS network, may request a signing server 13 to sign the URI by, for example, draft-ietf-sipcore-callinfo-rcd, draft-ietf-stirpassport-rcd and ATIS-1000094. Data may be fetched via the URI using the format as defined in draft-ietf-sipcore-callinfo-rcd. This data may then be signed as defined in draft-ietf-stir-passport-rcd and AT1S-1000094. Output of the signing process is a token which is put in the SIP INVITE. The URI may be implicitly authorized for use as the URI is stored in HSS 14. The signing server 13 may respond with a signed token according to draft-ietf-stirpassport-red. The signed token may be used as a signature for the rich call data of the user of UE A 10 in addition to an existing token which is a signature for a calling line ID of the user. The signed token and existing token may be transported in an extra identity header. The signed token may be the output of a process where the rich call data (RCD) are signed, and the existing token may be the output of signing the calling line ID.

[0026] At 150, the TAS 15 may add or insert the URI in a Call-Info header according to draft-ietf-sipcore-callinfo-red. The signed token may be transported in the SIP INVITE to the terminating IMS network via the SBC 16. At 160, the SBC 16 on the originating IMS network may forward the SIP INVITE to the terminating IMS network. At 170, the SBC, CSCF or TAS 17 on the terminating IMS network may verify the signed token via a verification server 18, using, for example, draftietf-sipcore-callinfo-rcd, draft-ietf-stirpassport-rcd and ATIS-1000094.

[0027] At 180, the SIP INVITE may be forwarded to a UE B 19. At 190, the UE B 19 may transmit an HTTP request using the provided URI in the SIP 15 INVITE to retrieve and display specific third party user data of UE A 10 at UE B 19.

[0028] Various example embodiments may provide technological advantages for an IMS to be able to make an informed decision on whether to trust third party user data. The IMS may not need to accept such data when provided by the UE in a SIP INVITE. Certain example embodiments allow for authorizing a third party to access an 1MS network, and define procedures for authorized third parties to verify whether a third party user is allowed to use third-party specific identities to initiate a telephone call.

[0029] FIG. 2 illustrates an example flow diagram of a method, according to certain example embodiments. In an example embodiment, the method of FIG. 2 may be performed by a network element, or a group of multiple network elements in a 3GPP system, such as LTE or 5G-NR. For instance, in an example embodiment, the method of FIG. 2 may be performed by a network element of an originating IMS network, such as a TAS, similar to apparatus 410 illustrated in FIG. 4.

100301 According to various example embodiments, the method of FIG. 2 may include, at 210, transmitting a request to a signing server to sign an identifier associated with third party user data, which has been determined to be a URI. The method may also include, at 220, receiving a reply comprising a signed token associated with the uniform resource identifier, and at 230, modifying an SIP INVITE request by inserting the URI and the signed token into one or more headers of the SIP INVITE request. At 240, the method may include providing the modified SIP INVITE request to a destination network for initiating communication between at least two UEs.

[0031] Certain example embodiments may provide that the method further includes retrieving, from a storage device, an identifier associated with third party user data, and/or determining whether the identifier retrieved from the storage is a URI. The method may also include converting the identifier into the URI when the identifier retrieved from the storage is determined to not be a URI. Alternatively, or in addition, the method may include retrieving, from the storage, a service profile that includes the identifier. The third party user data associated with the identifier may include user data of a user in a third party network. Some example embodiments may provide that the method includes retrieving the identifier from the third party network via an application programming interface or providing the identifier via an operation and management interface.

[0032] Various example embodiments may provide that the method includes retrieving the third party user data associated with the identifier from the third party network, and transmitting a request to a signing server to sign the third party user data retrieved from the third party network. The method may also include receiving a reply including the signed token associated with the third party user data and modifying an SIP INVITE request by inserting the third party user data and the signed token into one or several headers of the SIP INVITE request. The modified SIP INVITE request may be provided to a destination network for initiating communication between at least two UEs. The identifier may be provided by an IP PBX.

[0033] FIG. 3 illustrates an example flow diagram of a method, according to certain example embodiments. In an example embodiment, the method of FIG. 3 may be performed by a network element, or a group of multiple network elements in a 3GPP system, such as LTE or 5G-NR. For instance, in an example embodiment, the method of FIG. 3 may be performed by a network element of a terminating IMS network, such as an SBC, CSCF or TAS, similar to apparatus 420 illustrated in FIG. 4.

[0034] According to various example embodiments, the method of FIG. 3 may include, at 310, receiving, from a network, an SIP INVITE request including a URI and a signed token in one or more headers of the SIP INVITE request. At 320, the method may include verifying, using a verification server, the URI using the signed token, and at 330, the method may include relaying the SIP INVITE request including the URI to a destination UE for configuring communication with at least one other UE, when the URI is verified. The at least one other user equipment may retrieve a third party user data associated with an identifier from a third party network.

[0035] Certain example embodiments may provide that the URI is verified by (i) transmitting, to the verification server, a verification request including the URI and the signed token and (ii) receiving a reply including an indication of whether the URI is verified. The storage may be caused to create the identifier based on a PBX DN and a calling number provided in the SIP INVITE request using provisioned instructions or to retrieve instructions from a storage. The method may also include retrieving the provisioned instructions from the third party network via an API or providing provisioned instructions via an OAM interface. The method may also include retrieving the third party user data associated with the identifier from the third party network and relaying the session initiation protocol invitation request including the third party user data to the destination user equipment for configuring communication with the at least one other user equipment.

[0036] FIG. 4 illustrates a set of apparatuses 410 and 420 according to various example embodiments. In the various example embodiments, the apparatus 410 may be a network, network entity, or element in a communications network or associated with such a network, such as a network element in an originating IMS network. For example, the TAS 15 may be an example of apparatus 410. It should be noted that one of ordinary skill in the art would understand that apparatus 410 may include components or features not shown in FIG. 4. In addition, apparatus 420 may be a network, network entity, or element in a communications network or associated with such a network, such as a terminating IMS network. For example, the SBC, CSCF, or TAS may be an example of apparatus 420. It should be noted that one of ordinary skill in the art would understand that apparatus 420 may include components or features not shown in FIG. 4.

[0037] According to various example embodiments, the apparatus 410 may include at least one processor 412, and at least one memory 414, as shown in FIG. 4. The memory 414 may store instructions that, when executed by the processor 412, may cause the apparatus 410 to transmit a request to a signing server to sign an identifier associated with third party user data, which has been determined to be a uniform resource identifier. The apparatus 410 may further be caused to receive a reply comprising a signed token associated with the uniform resource identifier and modify a session initiation protocol invitation request by inserting the uniform resource identifier and the signed token into one or more headers of the session initiation protocol invitation request. The apparatus 410 may also be caused to provide the modified session initiation protocol invitation request to a destination network for initiating communication between at least two user equipment.

[0038] According to various example embodiments, the apparatus 420 may include at least one processor 422, and at least one memory 424, as shown in FIG. 4. The memory 424 may store instructions that, when executed by the processor 422, may cause the apparatus 420 to receive, from a network, a session initiation protocol invitation request comprising a uniform resource identifier and a signed token in one or more headers of the session initiation protocol invitation request. The apparatus 420 may also be caused to verify, using a verification server, the uniform resource identifier using the signed token. The apparatus may further be caused to, when the uniform resource identifier is verified, relay the session initiation protocol invitation request including the uniform resource identifier to a destination user equipment for configuring communication with at least one other user equipment. The at least one other user equipment may retrieve third party user data associated with an identifier from a third party network.

[0039] In some example embodiments, apparatuses 410 and/or 420 may include one or more processors, one or more computer-readable storage medium (for example, memory, storage, or the like), one or more radio access components (for example, a modem, a transceiver, or the like), and/or a user interface. In some example embodiments, apparatuses 410 and/or 420 may be z o configured to operate using one or more radio access technologies, such as GSM, LTE, LTE-A, NR, SG, WLAN, WiFi, NB-IoT, Bluetooth, NFC, MulteFire, and/or any other radio access technologies.

[0040] As illustrated in the example of FIG. 4, apparatuses 410 and/or 420 may include or be coupled to processors 412 and 422, respectively, for processing information and executing instructions or operations. Processors 412 and 422 may be any type of general or specific purpose processor. In fact, processors 412 and 422 may include one or more of general-purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (AS1Cs), and processors based on a multi-core processor architecture, as examples. While a single processor 412 (and 422) for each of apparatuses 410 and/or 420 is shown in FIG. 4, multiple processors may be utilized according to other example embodiments. For example, it should be understood that, in certain example embodiments, apparatuses 410 and/or 420 may include two or more processors that may form a multiprocessor system (for example, in this case processors 412 and 422 may represent a multiprocessor) that may support multiprocessing. According to certain example embodiments, the multiprocessor system may be tightly coupled or loosely coupled to, for example, form a computer cluster).

[0041] Processors 412 and 422 may perform functions associated with the operation of apparatuses 410 and/or 420, respectively, including, as some examples, precoding of antenna gain/phase parameters, encoding and decoding of individual bits forming a communication message, formatting of information, and overall control of the apparatuses 410 and/or 420, including processes illustrated in FIGS. 1-3.

[0042] Apparatuses 410 and/or 420 may further include or be coupled to memory 414 and/or 424 (intemal or external), respectively, which may be coupled to processors 412 and 422, respectively, for storing information and instructions that may be executed by processors 412 and 422. Memory 414 (and memory 424) may be one or more memories and of any type suitable to the local application environment, and may be implemented using any suitable volatile or nonvolatile data storage technology such as a semiconductor-based memory device, a magnetic memory device and system, an optical memory device and system, fixed memory, and/or removable memory. For example, memory 414 (and memory 424) can be comprised of any combination of random access memory (RAM), read only memory (ROM), static storage such as a magnetic or optical disk, hard disk drive (HDL), or any other type of non-transitory machine or computer readable media. The instructions stored in memory 414 and memory 424 may include program instructions or computer program code that, when executed by processors 412 and 422, enable the apparatuses 410 and/or 420 to perform tasks as described herein.

[0043] In certain example embodiments, apparatuses 410 and/or 420 may further include or be coupled to (internal or external) a drive or port that is configured to accept and read an external computer readable storage medium, such as an optical disc, USB drive, flash drive, or any other storage medium. For example, the external computer readable storage medium may store a computer program or software for execution by processors 412 and 422 and/or apparatuses 410 and/or 420 to perform any of the methods illustrated in FIGs. 1-3.

[0044] In some example embodiments, apparatus 410 may also include or be coupled to one or more antennas 415 for receiving a downlink signal and for transmitting via an uplink from apparatus 410. Apparatuses 410 and/or 420 may further include transceivers 416 and 426, respectively, configured to transmit and receive information. The transceiver 416 and 426 may also include a radio interface that may correspond to a plurality of radio access technologies including one or more of GSM, LTE, LTE-A, 5G, NR, WLAN, NB-IoT, Bluetooth, BT-LE, NFC, RFTD, UWB, or the like. The radio interface may include other components, such as filters, converters (for example, digital-to-analog converters or the like), symbol demappers, signal shaping components, an Inverse Fast Fourier Transform (IFFT) module, or the like, to process symbols, such as OFDMA symbols, carried by a downlink or an uplink.

[0045] For instance, transceivers 416 and 426 may be respectively configured to modulate information on to a carrier waveform for transmission, and demodulate received information for further processing by other elements of apparatuses 410 and/or 420. In other example embodiments, transceivers 416 and 426 may be capable of transmitting and receiving signals or data directly.

Additionally or alternatively, in some example embodiments, apparatuses 410 and/or 420 may include an input and/or output device (I/O device). In certain example embodiments, apparatuses 410 and/or 420 may further include a user interface, such as a graphical user interface or touchscreen.

[0046] In certain example embodiments, memory 414 and memory 424 store software modules that provide functionality when executed by processors 412 and 422, respectively. The modules may include, for example, an operating system that provides operating system functionality for apparatuses 410 and/or 420. The memory may also store one or more functional modules, such as an application or program, to provide additional functionality for apparatuses 410 and/or 420. The components of apparatuses 410 and/or 420 may be implemented in hardware, or as any suitable combination of hardware and software. According to certain example embodiments, apparatus 410 may optionally be configured to communicate with apparatus 420 via a wireless or wired communications link 430 according to any radio access technology, such as NR.

[0047] In some example embodiments, an apparatus (e.g., apparatus 410 and/or apparatus 420) may include means for performing a method, a process, or any of the variants discussed herein. Examples of the means may include one or more processors, memory, controllers, transmitters, receivers, and/or computer program code for causing the performance of the operations.

100481 Certain example embodiments may be directed to an apparatus that includes means for transmitting a request to a signing server to sign an identifier associated with third party user data, which has been determined to be a uniform resource identifier. The apparatus may also include a means for receiving a reply comprising a signed token associated with the uniform resource identifier and means for modifying a session initiation protocol invitation request by inserting the uniform resource identifier with the signed token into one or more headers of the session initiation protocol invitation request. The apparatus may further include providing the modified session initiation protocol invitation request to a destination network for initiating communication between at least two user equipment.

[0049] Various example embodiments may be directed to an apparatus that includes means for receiving, from a network, a session initiation protocol invitation request including a uniform resource identifier and a signed token in one or more headers of the session initiation protocol invitation request. The apparatus may also include means for verifying, using a verification server, the uniform resource identifier using the signed token. The apparatus to may further include means for, when the uniform resource identifier is verified, relaying the session initiation protocol invitation request including the uniform resource identifier to a destination user equipment for configuring communication with at least one other user equipment. The at least one other user equipment may retrieve third party user data associated with an identifier from a third party network.

[0050] According to certain example embodiments, processors 412 and 422, and memory 414 and 424 may be included in or may form a part of processing circuitry or control circuitry. In addition, in some example embodiments, transceivers 416 and 426 may be included in or may form a part of transceiving circuitry.

[0051] As used herein, the term circuitry" may refer to hardware-only circuitry implementations (for example, analog and/or digital circuitry), combinations of hardware circuits and software, combinations of analog and/or digital hardware circuits with software/firmware, any portions of hardware processor(s) with software, including digital signal processors, that work together to cause an apparatus (for example, apparatus 410 and/or 420) to perform various functions, and/or hardware circuit(s) and/or processor(s), or portions thereof, that use software for operation but where the software may not be present when it is not needed for operation. As a further example, as used herein, the term "circuitry" may also cover an implementation of merely a hardware circuit or processor or multiple processors, or portion of a hardware circuit or processor, and the accompanying software and/or firmware. The term circuitry may also cover, for example, a baseband integrated circuit in a server, cellular network node or device, or other computing or network device.

100521 A computer program product may include one or more computer-executable components which, when the program is run, are configured to carry out some example embodiments. The one or more computer-executable components may be at least one software code or portions of it. Modifications and configurations required for implementing functionality of certain example embodiments may be performed as routine(s), which may be implemented as added or updated software routine(s). Software routine(s) may be downloaded into the apparatus.

[0053] As an example, software or a computer program code or portions of it may be in a source code form, object code form, or in some intermediate form, and it may be stored in some sort of carrier, distribution medium, or computer readable medium, which may be any entity or device capable of carrying the program. Such carriers may include a record medium, computer memory, read-only memory, photoelectrical and/or electrical carrier signal, telecommunications signal, and software distribution package, for example. Depending on the processing power needed, the computer program may be executed in a single electronic digital computer or it may be distributed amongst a number of computers. The computer readable medium or computer readable storage medium may be a non-transitory medium. The term -non-transitory," as used herein, is a limitation of the medium itself (e.g., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM).

[0054] In other example embodiments, the functionality may be performed by hardware or circuitry included in an apparatus (for example, apparatuses 410 and/or 420), for example through the use of an application specific integrated circuit (AS1C), a programmable gate array (PGA), a field programmable gate array (FPGA), or any other combination of hardware and software. In yet another example embodiment, the functionality may be implemented as a signal, a non-tangible means that can be carried by an electromagnetic signal downloaded from the Internet or other network.

[0055] According to certain example embodiments, an apparatus, such as a node, device, or a corresponding component, may be configured as circuitry, a computer or a microprocessor, such as single-chip computer element, or as a chipset, including at least a memory for providing storage capacity used for arithmetic operation and an operation processor for executing the arithmetic operation.

[0056] The features, structures, or characteristics of example embodiments described throughout this specification may be combined in any suitable manner in one or more example embodiments. For example, the usage of the phrases "certain embodiments," "an example embodiment," "some embodiments," or other similar language, throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment.

Thus, appearances of the phrases "in certain embodiments," "an example embodiment," "in some embodiments," "in other embodiments," or other similar language, throughout this specification do not necessarily refer to the same group of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more example embodiments. Further, the terms "cell", "node", "gNB", or other similar language throughout this specification may be used interchangeably. [0057] As used herein, "at least one of the following: <a list of two or more elements>" and "at least one of <a list of two or more elements>" and similar wording, where the list of two or more elements are joined by "and" or "or," mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

[0058] One having ordinary skill in the art will readily understand that the disclosure as discussed above may be practiced with procedures in a different order, and/or with hardware elements in configurations which are different than those which are disclosed. Therefore, although the disclosure has been described based upon these example embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent, while remaining within the spirit and scope of example embodiments. Although the above embodiments refer to 5G NR and LTE technology, the above embodiments may also apply to any other present or future 3GPP technology, such as 1_7E-advanced, fourth generation (4G) technology, and/or sixth generation (6G) technology.

[0059] Partial Glossary: [0060] 3GPP 5G AF 3rd Generation Partnership Project 5th Generation [0061] Application Function [0062] [0063] API Application Programming Interface [0064] AS Application Server 100651 ATI S Alliance for Telecommunications Industry Solutions [0066] CSCF Call Session Control Function [0067] DL Downlink [0068] DN Directory Number [0069] EMBB Enhanced Mobile Broadband [0070] gNB 5G or Next Generation NodeB [0071] HSS Home Subscriber Server [0072] ID Identifier 100731 IETF Internet Engineering Task Force [0074] 1MS IP Multimedia Subsystem [0075] 1MPU IMS Public User Identity [0076] IP Internet Protocol [0077] IP PBX IP Private Branch Exchange 100781 Jcard JSON card [0079] JSON JavaScript Object Notation [0080] LTE Long Term Evolution 100811 MNO Mobile Network Operator [0082] NEF Network Exposure Function [0083] NR New Radio [0084] OAM Operation, Administration and Maintenance [0085] RCD Rich Call Data [0086] RTC Real-Time Communication [0087] S-CSCF Serving CSCF [0088] SBC Session Border Controller [0089] SIP Session Initiation Protocol [0090] STIR Secure Telephone Identity Revisited [0091] TAS Telephony Application Server [0092] UE User Equipment 100931 UL Uplink [0094] URI Uniform Resource Identifier [0095] URL Uniform Resource Locator

Claims (25)

1. WE CLAIM: 1. An apparatus comprising: means for transmitting a request to a signing server to sign an identifier associated with third party user data, which has been determined to be a uniform resource identifier; means for receiving a reply comprising a signed token associated with the uniform resource identifier; means for modifying a session initiation protocol invitation request by inserting the uniform resource identifier and the signed token into one or more headers of the session initiation protocol invitation request; and means for providing the modified session initiation protocol invitation request to a destination network for initiating communication between at least two user equipment.
2. 2. The apparatus according to claim 1, further comprising: means for retrieving, from a storage, an identifier associated with the third party user data.
3. 3. The apparatus according to claim 2, further comprising: means for determining whether the identifier retrieved from the storage is a uniform resource identifier.
4. 4. The apparatus according to claim 3, further comprising: means for, when the identifier retrieved from the storage is determined to not be the uniform resource identifier, converting the identifier into the uniform resource identifier.
5. 5. The apparatus according to any one of claims 1-4, further comprising: means for retrieving, from the storage, a service profile comprising the identifier, wherein the third party user data associated with the identifier comprises user data of a user in a third party network.
6. 6. The apparatus according to any one of claims 1-5, further comprising: means for retrieving the identifier from the third party network via an application programming interface; or means for providing the identifier via an operation and management 10 interface.
7. 7. The apparatus according to any one of claims 1-6, further comprising: means for retrieving the third party user data associated with the identifier from the third party network; means for transmitting a request to a signing server to sign the third party user data retrieved from the third party network; means for receiving a reply comprising the signed token associated with the third party user data; means for modifying a session initiation protocol invitation request by z o inserting the third party user data and the signed token into one or more headers of the session initiation protocol invitation request; and means for providing the modified session initiation protocol invitation request to a destination network for initiating communication between at least two user equipment.
8. 8. The apparatus according to any one of claims 1-7, wherein the identifier is provided by a private branch exchange.
9. 9. An apparatus comprising: means for receiving, from a network, a session initiation protocol invitation request comprising a uniform resource identifier and a signed token in one or more headers of the session initiation protocol invitation request; means for verifying, using a verification server, the uniform resource identifier using the signed token; and means for, when the uniform resource identifier is verified, relaying the session initiation protocol invitation request including the uniform resource identifier to a destination user equipment for configuring communication with at least one other user equipment, wherein the at least one other user equipment retrieves third party user data associated with an identifier from a third party network.
10. 10. The apparatus according to claim 9, wherein the uniform resource identifier is verified by: transmitting, to the verification server, a verification request comprising the uniform resource identifier and the signed token, and receiving a reply comprising an indication of whether the uniform resource identifier is verified.
11. I I. The apparatus according to claim 9 or claim 10, further comprising: means for causing a storage to create the identifier based on a private branch exchange directory number and a calling number provided in the session initiation protocol invitation request using provisioned instructions or to retrieve instructions from the storage.
12. 12. The apparatus according to claim 11, further comprising: means for retrieving the provisioned instructions from the third party network via an application programming interface; or means for providing the provisioned instructions via an operation and management interface.
13. 13. The apparatus according to any one of claims 9-12, further comprising: means for retrieving the third party user data associated with the identifier from the third party network; and means for relaying the session initiation protocol invitation request including the third party user data, to the destination user equipment for configuring communication with the at least one other user equipment.
14. 14. A method comprising: transmitting a request to a signing server to sign an identifier associated with third party user data, which has been determined to be a uniform resource identifier; receiving a reply comprising a signed token associated with the uniform resource identifier; modifying a session initiation protocol invitation request by inserting the uniform resource identifier and the signed token into one or more headers of the session initiation protocol invitation request; and providing the modified session initiation protocol invitation request to a destination network for initiating communication between at least two user equipment.
15. 15. The method according to claim 15, further comprising: retrieving, from a storage, an identifier associated with the third party user data.
16. 16. The method according to claim 14 or claim 15, further comprising: determining whether the identifier retrieved from the storage is a uniform resource identifier.
17. 17. The method according to claim 16, further comprising: when the identifier retrieved from the storage is determined to not be the uniform resource identifier, converting the identifier into the uniform resource identifier.
18. 18. The method according to any one of claims 14-17, further comprising: retrieving, from the storage, a service profile comprising the identifier, wherein the third party user data associated with the identifier comprises user data of a user in a third party network.
19. 19. The method according to any one of claims 14-18, further comprising: retrieving the identifier from the third party network via an application programming interface; or providing the identifier via an operation and management interface.
20. 20. The method according to any one of claims 14-19, further comprising: retrieving the third party user data associated with the identifier from the third party network; transmitting a request to a signing server to sign the third party user data retrieved from the third party network; receiving a reply comprising the signed token associated with the third party user data; modifying a session initiation protocol invitation request by inserting the third party user data and the signed token into one or more headers of the session initiation protocol invitation request; and providing the modified session initiation protocol invitation request to a destination network for initiating communication between at least two user equipment.
21. 21. The method according to any one of claims 14-20, wherein the identifier is provided by a private branch exchange.
22. 22. A method comprising: receiving, from a network, a session initiation protocol invitation 10 request comprising a uniform resource identifier and a signed token in one or more headers of the session initiation protocol invitation request; verifying, using a verification server, the uniform resource identifier using the signed token; and when the uniform resource identifier is verified, relaying the session initiation protocol invitation request including the uniform resource identifier to a destination user equipment for configuring communication with at least one other user equipment, wherein the at least one other user equipment retrieves third party user data associated with an identifier from a third party network.
23. 23. The method according to claim 22, wherein the uniform resource identifier is verified by: transmitting, to the verification server, a verification request comprising the uniform resource identifier and the signed token and receiving a reply comprising an indication of whether the uniform resource identifier is verified.
24. 24. The method according to claim 22 or claim 23, further comprising: causing a storage to create the identifier based on a private branch exchange directory number and a calling number provided in the session initiation protocol invitation request using provisioned instructions or to retrieve instructions from the storage.
25. 25. The method according to claim 24, further comprising: retrieving the provisioned instructions from a third party network via an application programming interface; or providing the provisioned instructions via an operation and management interface.