Carrier integration through user network interface agent

Abstract

The present disclosure relates to carrier integration through a user web interface proxy. A method (300) of carrier web integration through a user proxy interface includes receiving a request (130) from a mobile device (110) associated with a subscriber (10) of a carrier provider (301) to establish a voice service with the carrier provider for a companion device (120) linked to the mobile device. The request includes a subscriber identifier (132) of the mobile device. The method further includes authenticating the companion device based on the subscriber identifier, obtaining a session initiation protocol (SIP) credential (140) corresponding to the subscriber identifier, and registering the SIP credential for the companion device at a web interface proxy (200). The web interface proxy is in communication with an internet protocol multimedia subsystem (IMS) (320) of the carrier provider and the companion device. The method further includes establishing the voice service between the companion device and the IMS through the web interface proxy using the SIP credential.

Description

[0001] Case Analysis

[0002] This application is a divisional application of Chinese invention patent application 201980087227.5, filed on September 24, 2019. Technical Field

[0003] This disclosure relates to carrier integration via a proxy through a user network interface. Background Technology

[0004] Historically, voice call services have been provided via circuit-switched networks. However, with network development, voice call services have evolved to utilize Internet Protocol (IP) packet-switched networks. For example, VoIP (Voice over IP) provides voice communication and multimedia sessions over IP networks. Using packet-switched networks, voice call services may involve signaling, digitization of voice signals, and multimedia transmission (e.g., with encoding capabilities). As user equipment, such as smart devices and multimedia devices, continues to innovate, there is a need to adapt and / or simplify the integration of voice call services for these devices with operator provider networks, particularly IP Multimedia Subsystem (MMS) networks. Summary of the Invention

[0005] One aspect of this disclosure provides a method for operator integration via a user network interface proxy. The method includes receiving a request at data processing hardware from a mobile device associated with a subscriber of an operator provider. The request requests the data processing hardware to establish a voice service with the operator provider for a companion device linked to the mobile device. The request includes a subscriber identifier of the mobile device; in response to receiving the request, the method includes the data processing hardware authenticating the companion device based on the subscriber identifier of the mobile device; the data processing hardware acquiring a Session Initiation Protocol (SIP) certificate corresponding to the subscriber identifier of the mobile device; and the data processing hardware registering the SIP certificate for the companion device at a network interface proxy. The network interface proxy communicates with the operator provider's Internet Protocol Multimedia Subsystem (IMS) and the companion device. The method also includes the data processing hardware using the SIP certificate to establish a voice service between the companion device and the IMS via the network interface proxy.

[0006] Implementations of this disclosure may include one or more of the following optional features. In some implementations, the method further includes, after registering the SIP certificate with the companion device, transmitting media data from the companion device from the data processing hardware to the operator provider's IMS via SIP signaling over a transport layer secure connection. In some examples, the network interface agent receives the SIP signaling from the companion device and forwards the SIP signaling and Real-time Transport Protocol (RTP) to the operator provider's IMS. In these examples, the RTP may correspond to Secure RTP and include key exchange based on Datagram Transport Layer Security (DTLS). Transmitting the media data may include transcoding the media data received from the companion device into Enhanced Voice Service (EVS) or Adaptive Multi-Rate (AMR) for the operator provider's IMS. In some implementations, transmitting the media data includes transmitting the media data via a media connection employing a Session Traversal Tool for Network Address Translation (STUN), Network Address Translation (NAT), or Interactive Connection Establishment (ICE).

[0007] In an implementation that includes transmitting media data from a companion device to the operator provider's IMS, the method may further include, at the data processing hardware, receiving a second request from a mobile device associated with a subscriber of the operator provider. Here, the second request includes a subscriber identifier for the mobile device and requests the data processing hardware to establish voice service with the operator provider for one or more companion devices linked to the mobile device. Upon receiving the second request, the method further includes the data processing hardware aggregating the one or more companion devices and the companion device into a combined companion device. Here, the combined companion device is configured to proxy communication with the operator provider's IMS over a single transport layer secure connection via a network interface.

[0008] In some examples, the subscriber identifier includes an International Mobile Subscriber Identity (IMSI). In some implementations, an application running on the mobile device generates the request by generating an authentication token for the subscriber. In these implementations, the authentication token is configured to link the telephone number associated with the subscriber's mobile device to the companion device.

[0009] The network interface agent can optionally be configured to manage the registration of more than one companion device. Here, the registration managed by the network interface agent includes a single SIP registration for each Mobile Station International Subscriber Directory Number (MSISDN) of the operator provider's IMS.

[0010] Another aspect of this disclosure provides a system for operator integration via a user network interface proxy. The system includes data processing hardware and memory hardware communicating with the data processing hardware. The memory hardware stores instructions that, when executed on the data processing hardware, cause the data processing hardware to perform the following operations: receiving a request from a mobile device associated with a subscriber of an operator provider. The request requests the data processing hardware to establish a voice service with the operator provider for a companion device linked to the mobile device. The request includes a subscriber identifier of the mobile device; in response to receiving the request, the operation further includes authenticating the companion device based on the subscriber identifier of the mobile device; obtaining a Session Initiation Protocol (SIP) certificate corresponding to the subscriber identifier of the mobile device; and registering the SIP certificate for the companion device at a network interface proxy. The network interface proxy communicates with the operator provider's Internet Protocol Multimedia Subsystem (IMS) and the companion device. The operation further includes establishing a voice service between the companion device and the IMS via the network interface proxy using the SIP certificate.

[0011] Implementations of this disclosure may include one or more of the following optional features. In some implementations, the operation further includes, after registering the SIP certificate with the companion device, transmitting media data from the companion device to the operator provider's IMS via SIP signaling over a transport layer secure connection. In some examples, the network interface agent receives the SIP signaling from the companion device and forwards the SIP signaling and Real-time Transport Protocol (RTP) to the operator provider's IMS. In these examples, the RTP may correspond to Secure RTP and include key exchange based on Datagram Transport Layer Security (DTLS). Transmitting the media data may include transcoding the media data received from the companion device into Enhanced Voice Service (EVS) or Adaptive Multi-Rate (AMR) for the operator provider's IMS. In some implementations, transmitting the media data includes transmitting the media data via a media connection employing a Session Traversal Tool for Network Address Translation (STUN), Network Address Translation (NAT) traversal, or Interactive Connectivity Establishment (ICE).

[0012] In an implementation that includes transmitting media data from a companion device to the operator provider's IMS, the operation may further include receiving a second request from a mobile device associated with a subscriber of the operator provider. Here, the second request includes the mobile device's subscriber identifier and requests the data processing hardware to establish voice service with the operator provider for one or more companion devices linked to the mobile device. Upon receiving the second request, the operation further includes aggregating the one or more companion devices and the companion device into a combined companion device. Here, the combined companion device is configured to proxy communication with the operator provider's IMS over a single transport layer secure connection via a network interface.

[0013] In some examples, the subscriber identifier includes an International Mobile Subscriber Identity (IMSI). In some implementations, an application running on the mobile device generates the request by generating an authentication token for the subscriber. In these implementations, the authentication token is configured to link the telephone number associated with the subscriber's mobile device to the companion device.

[0014] The network interface agent can optionally be configured to manage the registration of more than one companion device. Here, the registration managed by the network interface agent includes a single SIP registration for each Mobile Station International Subscriber Directory Number (MSISDN) of the operator provider's IMS.

[0015] Details of one or more embodiments of the present disclosure are set forth in the accompanying drawings and the following description. Other aspects, features, and advantages will become apparent from the description, the drawings, and the claims. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of an exemplary network interface proxy environment.

[0017] Figure 2A and 2B This is a schematic diagram of an exemplary network interface proxy within a network interface proxy environment.

[0018] Figure 3 This is a flowchart illustrating an exemplary operational setup for implementing a network interface proxy method.

[0019] Figure 4 This is a schematic diagram of an exemplary computing device that can be used to implement the systems and methods described herein.

[0020] In the various figures, similar reference numerals indicate similar elements. Detailed Implementation

[0021] Figure 1This is an example of a network interface proxy environment 100. The network interface proxy environment 100 includes a subscriber 10 (e.g., its owner or user) associated with at least one master device 110 and at least one companion device 120, which serve as voice call service endpoints. Here, endpoints 110 and 120 allow subscribers 10 subscribing to the services of operator 301 to communicate with the infrastructure of operator 301 via a user network interface (UNI) proxy 200. Endpoints 110 and 120 generally refer to devices or applications hosted on devices (e.g., browsers). More specifically, these devices may be mobile devices (e.g., mobile phones, tablets, laptops, etc.) or user devices (e.g., voice communication and / or multimedia devices). For example, Figure 1 The main device 110 is described as a mobile device and the accessory device 120 is described as a user device configured with a voice call service (e.g., with audio, video, or multimedia data capabilities). Each of the main device 110 and the accessory device 120 includes data processing hardware 112, 122 and memory hardware 114, 124. The memory hardware 114, 124 communicates with the data processing hardware 112, 122 and stores instructions that, when executed by the data processing hardware 112, 122, cause the data processing hardware 112, 122 to perform one or more operations. Although Figure 1 The description includes one or more main devices 110, 110a-n and one auxiliary device 120, but subscriber 10 can access the network of operator 301 (e.g., Figure 2A and 2B The network 320 can use any number of master devices 110 and any number of accessory devices 120. Therefore, the number of accessory devices 120 is independent of the number of master devices 110. For example, one master device 110 can have four accessory devices 120.

[0022] The voice call service of an endpoint (e.g., master device 110 or accessory device 120) may include any type of media data capable of communication over a packet-switched network. In other words, the endpoint may transmit captured audio, video, multimedia, text (e.g., messaging), etc. For example, each endpoint (e.g., master device 110 or accessory device 120) may include audio capture devices (e.g., microphones) and / or video capture devices (e.g., cameras) to provide the voice call service for subscriber 10. To transmit media associated with the call, endpoints 110, 120 may be configured with various protocols to communicate with operator 301 via UNI agent 200. These protocols may include authentication protocols, signaling protocols, transmission protocols, etc.

[0023] In some implementations, primary device 110 refers to a device registered with operator 301 on behalf of subscriber 10. Even if subscriber 10 may be able to make calls with primary device 110, subscriber 10 may still prefer or wish to make calls with devices other than primary device 110 through operator 301's network (e.g., network 320). This is likely to increase as subscriber 10 acquires more devices capable of communicating across networks. To make calls with devices other than primary device 110, subscriber 10 can integrate companion device 120 as an auxiliary device for voice services with operator 301. In other words, companion device 120 refers to an additional or auxiliary device of subscriber 10 associated with primary device 110 on subscriber account with operator 301. Here, integrating a device with operator 301 means configuring the device to be identified as an authorized device / user of operator 301, which can use operator 301's network (e.g., network 320) to perform voice call services or call multimedia services.

[0024] In some implementations, subscriber 10 links companion device 120 to master device 110. Here, linking means associating companion device 120 with master device 110 such that operator 301 can identify either device as authorized to communicate using operator 301's network 320 (e.g., IP Multimedia Subsystem (IMS) or a simple operator IMS core). For example, master device 110 includes an application 116 capable of generating authentication processes for subscriber 10 (i.e., executed / running on data processing hardware 112). In some examples, application 116 is responsible for assigning a specific phone number (e.g., Mobile Station International Subscriber Directory Number (MSISDN)) on behalf of either of the subscriber's devices 110, 120 to integrate with operator 301. Furthermore, application 116 may be responsible for sending request 130 to UNI agent 200 to enable voice service integration with operator 301. In some implementations, all endpoints 110, 120 of subscriber 10 use the same phone number to integrate with operator 301 via UNI agent 200.

[0025] In some examples, to join and activate voice services (e.g., voice calls) via companion device 120, application 116 may trigger an entitlement process. The entitlement process ensures that the endpoint or its user is authorized to use or subscribe to the voice services of operator 301. In some implementations, the entitlement process also retrieves a Session Initiation Protocol (SIP) certificate 140 from operator 301 to allow companion device 120 to access operator 301's IP Multimedia Subsystem (IMS) network 320 (e.g., ...). Figure 2A and 2BRegistration. As used herein, the terms “IMS 320” and “IMS Network 320” are used interchangeably. Once registered, the companion device 120 can use the operator 301 to make and / or receive voice call services.

[0026] In some configurations, endpoints 110 and 120 communicate with UNI agent 200 via remote system 150 on network 160. For example, UNI agent 200 is remotely hosted in a network environment (e.g., a distributed system or cloud) accessible to subscriber 10. For example, UNI agent 200 could be a web-based application accessible to subscriber 10 (e.g., remotely accessible to endpoints 110 and 120). By being hosted in remote system 150, UNI agent 200 can utilize the computing resources 152 of remote system 150 to function. These computing resources 152 may include remote data processing hardware 154 (e.g., a server) and remote storage hardware 156 (e.g., a remote database hosted in the storage hardware). In other configurations, UNI agent 200 is integrated with companion device 120 such that data processing hardware 122 located on companion device 120 can perform the functions of UNI agent 200 to enable direct communication between operator 301's IMS network 320 and companion device 120. For example, in such a configuration, the accessory device 120 is configured with IMS (i.e., IMS client).

[0027] UNI Proxy 200 is used to connect to the network of Operator 301 (e.g., Network 320) by emulating a legacy network (e.g., IR.51) supported by the End User Equipment (UE). By emulating the legacy network, UNI Proxy 200 simplifies device management for Subscriber 10 of Operator 301. Through UNI Proxy 200, Subscriber 10 can scale the number of endpoints 110, 120 using Operator 301's network (e.g., Network 320) without considering compatibility with Operator 301's devices. Therefore, endpoints 110, 120 can be updated, replaced, reconfigured, etc., at the subscriber level without affecting the functionality of voice services provided by Operator 301. In some examples, UNI Proxy 200 can improve privacy and / or endpoint security by making each endpoint 110, 120 indistinguishable when viewed by Operator 301. In other words, UNI Proxy 200 can make each device communicating with Operator 301 through UNI Proxy 200 appear similar (e.g., primary device 110 appears identical to companion device 120). In some implementations, instead, operator 301 can coordinate with UNI agent 200 to make changes without affecting subscriber 10's endpoint.

[0028] Figure 2A and 2BThis is an example of the relationship between UNI agent 200 and the endpoint of subscriber 10 within network interface agent environment 100, and operator 301. UNI agent 200 includes an empowerer 210, a session initiation protocol (SIP) agent 220, and a media agent 230. Using UNI agent 200, endpoints 110 and 120 can be configured to terminate calls using network 320 of operator 301. To illustrate the functionality of UNI agent 200, Figure 2A and 2B Network 320 of operator 301 is depicted. Telecommunication service providers (also known as operator providers) use operator networks, typically with proprietary network infrastructure, to provide voice call services to subscriber 10.

[0029] Here, operator 301 is shown as including empowerment system 311 and IMS network 320 (also referred to as operator IMS core 320). IMS network 320 generally refers to the IP Multimedia Subsystem (IMS) designed to provide a unified service architecture for packet-switched networks. Typically, IMS network 320 operates at several layers, including application layer, control layer, and access and transport layers, to allow the transmission of multimedia data. Although operator 301 is shown as including empowerment system 311 and IMS network 320, other components and / or infrastructure can be added to or removed from operator 301 without changing the function of UNI agent 200, which serves as the interface between operator 301 and endpoints 110 and 120.

[0030] refer to Figure 2A The authenticator 210 is configured to perform authentication and authorization procedures. The authenticator 210 receives a request 130 to establish voice service with operator 301 for a companion device 120 linked to master device 110. Request 130 includes a subscriber identifier 132, such as MSISDN, IMS Public User Identity (IMPU), or International Mobile Subscriber Identity (IMSI). In some implementations, application 116 transmits request 130 along with the subscriber identifier 132 from master device 110. In other implementations, companion device 120 may initiate request 130 based on communication with master device 110. In some examples, request 130 further includes an authentication token 134 (e.g., generated by application 116) as an authentication certificate for UNI agent 200 to identify subscriber 10. Authentication token 134 may be an Open Authentication (OAuth) token, a message as a one-time password (e.g., SMS OPT), or an Extensible Authentication Protocol (EAP) (e.g., Authentication and Key Agreement Mechanism (EAP-AKA)). Additionally or alternatively, the authentication token 134 may link the phone number associated with subscriber 10’s primary device 110 (e.g., mobile device) to companion device 120.

[0031] Based on request 130, the grantor 210 executes a granting process in communication with operator 301. To initiate the granting process, the grantor 210 sends request 130 to operator 301. For example, Figure 2A An authorization server 312 receiving request 130 is depicted. Here, at the authorization server 312, the operator network 320 may also include an authentication, authorization, and accounting (AAA) server 314 and / or an information technology (IT) / business support system (BSS) 316 to assist the authorization process at the operator 301. In some examples, the authorizer 210 and the operator 301 (e.g., the authorization server 312) communicate via an authorization application programming interface (API).

[0032] Upon request 130 from the empowerer 210, the empowerment server 312 verifies authentication based on the subscriber identifier 132. For example, the empowerment server 312 determines that the subscriber identifier 132 matches the identifier of a known subscriber of operator 301 (e.g., stored at the empowerment server 312 or at another component of operator 301). When operator 301 authenticates request 130, UNI agent 200 may receive or obtain a SIP certificate 140 corresponding to subscriber identifier 132 (e.g., subscriber identifier 132 of master device 110). In some implementations, application 116 receives the SIP certificate 140 and provides it to UNI agent 200 (e.g., to SIP agent 220 of UNI agent 200). Here, application 116 or UNI agent 200 receives the SIP certificate 140 to indicate that companion device 120 has been successfully authenticated. In some configurations, UNI agent 200 or application 116 generates access token 117 for companion device 120 as an indicator that companion device 120 has been certified by carrier 301 and facilitates SIP registration on behalf of companion device 120.

[0033] refer to Figure 2B Using SIP certificate 140, UNI agent 200 registers accessory device 120 with operator 301. Registering accessory device 120 with operator 301 allows UNI agent 200 to establish voice service between accessory device 120 and operator 301 (e.g., using IMS network 320). Registering accessory device 120 allows both UNI agent 200 and operator 301 to be aware that accessory device 120 has been established and is permitted to use operator 301's voice service.

[0034] In some examples, UNI agent 200 registers SIP certificate 140 at SIP agent 220, enabling SIP agent 220 to establish communication between companion device 120 and operator 301. For example, SIP agent 220 includes a database storing SIP certificate 140 and any related data to perform the registration. Here, UNI agent 200 controls and proxies registrations associated with operator 301 on behalf of the endpoint, ensuring that, for example, each unique subscriber identifier 132 appears similar to operator 301 and has no additional impact on operator 301. In other words, UNI agent 200 (e.g., at SIP agent 220) manages registrations on behalf of companion device 120. In some examples, UNI agent 200 manages registrations such that only one SIP registration per subscriber identifier 132 (e.g., MSISDN or IMPU) is relayed to operator 301's IMS network 320 (e.g., for controlling or optimizing network traffic to operator 301). In some implementations, an endpoint, such as the companion device 120, remains registered with the operator 301 once registered until a decision is made to disconnect. In other implementations, the UNI agent 200 manages the endpoint, enabling it to connect and / or disconnect from the operator 301 on demand.

[0035] Continue to refer to Figure 2B After registering the SIP certificate 140 for the companion device 120, the SIP proxy 220 of the UNI proxy 200 is configured to communicate with the IMS network 320 (e.g., shown as the operator's IMS core). In some examples, the interface between the SIP proxy 220 and the operator 301 is a standard Gm interface. Traditionally, the Gm interface refers to the interface that supports message exchange between a SIP user equipment (UE) or VoIP gateway and the proxy call session control function (P-CSCF). Therefore, the Gm interface implements the connection between the UE and the IMS network 320 for registration, authentication, encryption, and session control. In the case of the UNI proxy 200, the Gm interface 222 implements the connection between the P-CSCF 322 of the IMS network 320 and the SIP endpoint (e.g., the master device 110 or the companion device 120) rather than the UE. In some configurations, such as Figure 2BAs shown, SIP proxy 220 transmits SIP signaling 223 from the endpoint to P-CSCF 322 over a Transport Layer Security (TLS) connection via Gm interface 222. Alternatively, operator 301 may choose to use a Local Communication Interface (LCI) to connect to SIP proxy 220 with Interconnect Border Control Function (IBCF). In either configuration, the P-CSCF 322 or IBCF of IMS network 320 can communicate with Service Call State Control Function (S-CSCF) 324 and servers 326, 328 (such as Telephone Application Server (TAS) 326 and Third-Party Registration Server (HSS) 328).

[0036] In some examples, UNI agent 200 is configured to forward SIP signaling 223 via SIP agent 220 and media data 233 (e.g., multimedia data) via media agent 230. For example, media agent 230 receives multimedia data 233 (e.g., audio and / or video) from companion device 120 via network protocol 133 (such as Real-Time Transport (RTP) protocol) and forwards the multimedia data 233 to IMS network 320 via media agent connection 232. In some examples, media agent connection 232 is configured to communicate with IMS access gateway 330 at IMS network 320. Generally, IMS access gateway 330 ensures that the addresses associated with inbound and / or outbound media streams (i.e., initiators and terminators) are correct (e.g., much like Network Address Translation (NAT) functionality). In some implementations, media agent 230 uses Secure RTP (sRTP) for media encryption of the media data via media agent connection 232. In these implementations, media encryption may include key exchange using Datagram Transport Layer Security (DLTS). Alternatively, media encryption may use a simplified data encryption standard (S-DES).

[0037] When transmitting media data 233 between the endpoint and operator 301, the UNI agent 200 can also support NAT traversal. In some examples, the UNI agent 200 uses Interactive Connection Establishment (ICE) to establish a connection path with operator 301. For example, ICE uses Session Traversal Tool for NAT (STUN) or a STUN server to transmit media data 233 for subscriber 10. In some examples, the STUN server allows subscriber 10 at the endpoint to discover information related to the IP address and type of the NAT used to establish the media connection.

[0038] In some configurations (e.g., at media agent 230), UNI agent 200 is configured to transcode media data received from an endpoint (e.g., master device 110 or accessory device 120). In some examples, UNI agent 200 supports media options such as G.711, G.722, and / or Opus. In some implementations, UNI agent 200 supports multiple allowed bit rates within the same codec. For example, UNI agent 200 uses adaptive multirate, such as Adaptive Multirate Narrowband (AMR-NB) or Adaptive Multirate Wideband (AMR-WB), to transcode media received from the endpoint. Additionally or alternatively, UNI agent 200 supports high-definition voice codecs, such as Enhanced Voice Service (EVS). For example, UNI agent 200 operates using both EVS and AMR bands. In some configurations, UNI agent 200 provides media data directly to operator 301 without processing.

[0039] By enabling UNI Agent 200 to provide media data support services (e.g., transcoding), UNI Agent 200 can simplify codec usage and / or codec support between endpoints 110, 120 and operator 301. Conversely, when endpoints support codecs individually (e.g., each multimedia device is licensed a given codec), the licensing cost per endpoint can become expensive. License management at UNI Agent 200 can allow subscriber 10 to use fewer licenses and / or support more codecs across more devices. In other words, UNI Agent 200 acquires and / or implements licenses rather than for endpoints (or each endpoint).

[0040] In some examples, UNI agent 200 receives a second request 130 from master device 110 associated with subscriber 10 of operator 301. Here, the second request 130 is to establish voice service for one or more supplementary devices linked to master device 110. Similar to the first request 130, the second request 130 includes subscriber identifier 132 of master device 110. In this example, UNI agent 200 is configured to aggregate one or more supplementary devices 120 into a combined supplementary device, wherein UNI agent 200 manages the combined supplementary device (or more than one supplementary device 120) such that the combined supplementary device communicates over a single TLS connection 123.

[0041] In some implementations, UNI agent 200 retrieves registration data for the endpoint. Using this registration data, UNI agent 200 can verify when the voice call service is still valid for subscriber 10. Therefore, this step confirms that the endpoint was registered when the call was initiated using network 320 of operator 301.

[0042] Figure 3This is an example of an exemplary operational arrangement for a method 300 for establishing a voice service with a UNI agent 200. In operation 302, method 300 receives a request 130 from a mobile device (e.g., a primary device 110) associated with a subscriber 10 of operator 301. Here, request 130 requests the establishment of a voice service with operator 301 for a companion device 120 linked to mobile device 110, and includes a subscriber identifier 132 of the mobile device. In operation 304, method 300 authenticates companion device 120 based on the subscriber identifier 132 of the mobile device. In operation 306, method 300 obtains a Session Initiation Protocol (SIP) certificate 140 corresponding to the subscriber identifier 132 of the mobile device. In operation 308, method 300 registers the SIP certificate 140 for companion device 120 at the UNI agent 200. The UNI agent 200 communicates with the Internet Protocol Multimedia Subsystem (IMS) network 320 of operator 301 and companion device 120. In operation 310, method 300 uses SIP certificate 140 to establish a voice service between the accessory device 120 and the IMS network 320 via UNI agent 200.

[0043] Figure 4 This is a schematic diagram of an exemplary computing device 400 that can be used to implement the systems (e.g., UNI agent 200, master device 110, and / or accessory device 120) and methods (e.g., method 300) described in this document. The computing device 400 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframes, and other suitable computers. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the inventions described and / or claimed in this document.

[0044] Computing device 400 includes a processor (e.g., data processing hardware) 410, a memory (e.g., memory hardware) 420, a storage device (e.g., memory hardware) 430, a high-speed interface / controller 440 connected to memory 420 and high-speed expansion port 450, and a low-speed interface / controller 460 connected to low-speed bus 470 and storage device 430. Each of components 410, 420, 430, 440, 450, and 460 is interconnected using various buses and may be mounted on a common motherboard or otherwise suitably mounted. Processor 410 can process instructions for execution within computing device 400, including instructions stored in memory 420 or on storage device 430, to display graphical information for a graphical user interface (GUI) on an external input / output device such as a display 480 coupled to high-speed interface 440. In other embodiments, multiple processors and / or multiple buses, as well as multiple memories and memory types, may be suitably used. Furthermore, multiple computing devices 400 can be connected, with each device providing a portion of the necessary operation (e.g., as a server group, blade server group, or multiprocessor system).

[0045] Memory 420 stores information non-transitorily within computing device 400. Memory 420 may be a computer-readable medium, volatile memory cells(s), or non-volatile memory cells(s). Non-transitory memory 420 may be a physical device for temporarily or permanently storing programs (e.g., instruction sequences) or data (e.g., program state information) for use by computing device 400. Examples of non-volatile memory include, but are not limited to, flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electronically erasable programmable read-only memory (EEPROM) (e.g., commonly used in firmware, such as boot programs). Examples of volatile memory include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase-change memory (PCM), and magnetic disks or magnetic tapes.

[0046] Storage device 430 provides mass storage for computing device 400. In some embodiments, storage device 430 is a computer-readable medium. In various embodiments, storage device 430 may be a floppy disk device, hard disk device, optical disk device, magnetic tape device, flash memory or other similar solid-state storage device, or a device array, including devices in a storage area network or other configuration. In other embodiments, a computer program product is tangibly embodied as an information carrier. The computer program product contains instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer or machine-readable medium, such as memory 420, storage device 430, or memory on processor 410.

[0047] High-speed controller 440 manages bandwidth-intensive operations of computing device 400, while low-speed controller 460 manages less bandwidth-intensive operations. This allocation of responsibilities is merely illustrative. In some embodiments, high-speed controller 440 is coupled to memory 420, display 480 (e.g., via a graphics processor or accelerator), and high-speed expansion port 450 which can accept various expansion cards (not shown). In some embodiments, low-speed controller 460 is coupled to storage device 430 and low-speed expansion port 490. Low-speed expansion port 490, which may include various communication ports (e.g., USB, Bluetooth, Ethernet, Wireless Ethernet), can be coupled to one or more input / output devices, such as keyboards, pointing devices, scanners, or network devices, such as switches or routers, for example, via a network adapter.

[0048] As shown in the figure, the computing device 400 can be implemented in a variety of different forms. For example, the computing device 400 can be implemented as a standard server 400a or multiple times in a set of such servers 400a, as a laptop computer 400b, or as part of a rack server system 400c.

[0049] Various implementations of the systems and techniques described herein can be implemented in digital electronic and / or optical circuits, integrated circuits, specially designed ASICs (Application-Specific Integrated Circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be dedicated or general-purpose, coupled to receive data and instructions from a storage system, at least one input device, and at least one output device, and to transmit data and instructions to these devices.

[0050] These computer programs (also referred to as programs, software, software applications, or code) include machine instructions for a programmable processor and can be implemented in high-level procedural and / or object-oriented programming languages ​​and / or in assembly / machine language. As used herein, the terms “machine-readable medium” and “computer-readable medium” mean any computer program product, non-transitory computer-readable medium, means and / or devices for providing machine instructions and / or data to a programmable processor (e.g., disks, optical disks, memory, programmable logic devices (PLDs), including machine-readable media that receive machine instructions as machine-readable signals. The term “machine-readable signal” means any signal used to provide machine instructions and / or data to a programmable processor.

[0051] The processes and logical flows described in this specification can be executed by one or more programmable processors that perform functions by manipulating input data and generating output. The processes and logical flows can also be executed by special-purpose logic circuitry, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits). For example, processors suitable for executing computer programs include general-purpose and special-purpose microprocessors, and any one or more processors of any kind of digital computer. Typically, the processor receives instructions and data from read-only memory or random access memory, or both. The basic elements of a computer are a processor for executing instructions and one or more storage devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks, or operatively coupled to one or more mass storage devices for storing data to receive data from or transfer data thereto, or both. However, a computer need not have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, such as semiconductor memory devices, such as EPROMs, EEPROMs, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and CD-ROMs and DVD-ROMs. Processors and memory can be supplemented by dedicated logic circuits or incorporated into dedicated logic circuits.

[0052] To provide interaction with the user, one or more aspects of this disclosure can be implemented on a computer having a display device and optional keyboard and pointing devices, such as a CRT (cathode ray tube), LCD (liquid crystal display) monitor, or touchscreen, to display information to the user, and pointing devices such as a mouse and trackball, through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including sound, speech, or tactile input. Additionally, the computer can interact with the user by sending documents to and receiving documents from the device used by the user; for example, by sending a webpage to a web browser on the user's client device in response to a request received from a web browser.

[0053] Many embodiments have been described. However, it should be understood that various modifications can be made without departing from the spirit and scope of this disclosure. Therefore, other embodiments are also within the scope of the appended claims.

Claims

1. A computer-implemented method performed by data processing hardware, the method causing the data processing hardware to perform operations comprising: receiving a request from a mobile device associated with a subscriber of a carrier provider, the request requesting the data processing hardware to establish voice services with the carrier provider for a companion device linked to a phone number of the mobile device using the mobile device, the request including a subscriber identifier of the mobile device, the subscriber identifier including an International Mobile Subscriber Identity (IMSI); authenticating the companion device based on the subscriber identifier of the mobile device; obtaining a Session Initiation Protocol (SIP) credential corresponding to the subscriber identifier of the mobile device; registering the SIP credential with an Internet Protocol Multimedia Subsystem (IMS) of the carrier provider for the companion device; linking the phone number of the mobile device with the companion device; and establishing voice services between the companion device and the IMS using the SIP credential. the operations further comprising, after registering the SIP credential with the companion device, transmitting media data from the companion device to the IMS of the carrier provider over SIP signaling over a Transport Layer Security connection.

2. The method of claim 1, wherein, registering the SIP credential with an Internet Protocol Multimedia Subsystem (IMS) of the carrier provider for the companion device includes registering the SIP credential at a network interface proxy.

3. The method of claim 2, wherein, the network interface proxy receives the SIP signaling from the companion device and forwards the SIP signaling and Real-time Transport Protocol (RTP) to the IMS of the carrier provider.

4. The method of claim 3, wherein, the RTP corresponds to Secure RTP and includes Datagram Transport Layer Security (DTLS) based key exchange.

5. The method of claim 4, wherein, 6. The method of claim 2, further comprising: receiving a second request from the mobile device associated with a subscriber of the carrier provider, the second request requesting the data processing hardware to establish voice services with the carrier provider for one or more additional companion devices linked to the mobile device, the second request including the subscriber identifier of the mobile device; and aggregating the one or more additional companion devices and the companion device into a combined companion device. transmitting the media data includes transcoding the media data received from the companion device to Enhanced Voice Services (EVS) or Adaptive Multi-Rate (AMR) for the IMS of the carrier provider. transmitting the media data includes transmitting the media data over a media connection employing Session Traversal Utilities for Network Address Translation (STUN), Network Address Translation (NAT) traversal, or Interactive Connectivity Establishment (ICE).

7. The method of claim 2, wherein, an application executing on the mobile device generates the request by generating an authentication token for the subscriber.

8. The method of claim 2, wherein, registering the SIP credential with the IMS for the companion device includes communicating with a third-party registration server.

9. The method of claim 1, wherein, 11. A system for carrier integration, comprising:

10. The method of claim 1, wherein, data processing hardware; and ​ ​ ​ memory hardware in communication with the data processing hardware, the memory hardware storing instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations comprising: receiving a request from a mobile device associated with a subscriber of a carrier provider, the request requesting the data processing hardware to establish voice services with the carrier provider for a companion device linked to a phone number of the mobile device, the request including a subscriber identifier of the mobile device, the subscriber identifier including an International Mobile Subscriber Identity, IMSI; authenticating the companion device based on the subscriber identifier of the mobile device; obtaining a Session Initiation Protocol, SIP, credential corresponding to the subscriber identifier of the mobile device; registering the SIP credential with an Internet Protocol Multimedia Subsystem, IMS, of the carrier provider for the companion device; linking the phone number of the mobile device with the companion device; and establishing voice services between the companion device and the IMS using the SIP credential.

12. The system of claim 11, wherein, the operations further comprising, after registering the SIP credential with the companion device, transmitting media data from the companion device to the IMS of the carrier provider over SIP signaling over a Transport Layer Security connection.

13. The system of claim 12, wherein, registering the SIP credential with an Internet Protocol Multimedia Subsystem, IMS, of the carrier provider for the companion device includes registering the SIP credential at a network interface proxy.

14. The system of claim 13, wherein, the network interface proxy receives the SIP signaling from the companion device and forwards the SIP signaling and Real-time Transport Protocol, RTP, to the IMS of the carrier provider.

15. The system of claim 14, wherein, the RTP corresponds to Secure RTP and includes Datagram Transport Layer Security, DTLS, based key exchange.

16. The system of claim 12, further comprising: receiving a second request from the mobile device associated with a subscriber of the carrier provider, the second request requesting the data processing hardware to establish voice services with the carrier provider for one or more additional companion devices linked to the mobile device, the second request including the subscriber identifier of the mobile device; and aggregating the one or more additional companion devices and the companion device into a combined companion device. transmitting the media data includes transcoding the media data received from the companion device to Enhanced Voice Services, EVS, or Adaptive Multi-Rate, AMR, for the IMS of the carrier provider.

17. The system of claim 12, wherein, transmitting the media data includes transmitting the media data over a media connection employing Session Traversal Tools for Network Address Translation, STUN, Network Address Translation, NAT, traversal, or Interactive Connectivity Establishment, ICE.

18. The system of claim 12, wherein, the application executing on the mobile device generates the request by generating an authentication token for the subscriber.

19. The system of claim 11, wherein, registering the SIP credential with the IMS for the companion device includes communicating with a third party registration server.

20. The system of claim 11, wherein, ​

Images