A client device (e.g., user equipment or “UE”) may be configured to engage in a media communication session, such as a WebRTC session, with another client device. The client devices may separate a quality of service (QoS) specification from a QoS flow definition, to allow for separate interactive connectivity establishment (ICE) negotiation. The QoS specification may cover all segments of a connection for the media communication session. For example, QoS may be requested for a case where a server (e.g., a Traversal Using Relay Network Address Translation (TURN) server) is hosted by a mobile network operator (MNO). The QoS specification and the QoS flow description may be linked.

The present invention relates to systems and methods suitable for verifying and compensating nodes for streaming multimedia. In particular, the present invention relates to systems and methods that utilize a blockchain to verify and compensate devices for computational resources contributions when streaming multimedia over a decentralized network.

Network address translation (NAT) flow migration between wireless access points (APs) in a manner that ensures that client devices can seamlessly roam between APs is described. An AP on which a NAT flow is first created is designated as an anchor NAT flow AP for that NAT flow during the lifetime of the NAT flow. When a non-anchor AP to which a client has roamed receives a packet that matches an active NAT flow, the non-anchor AP forwards the packet to the anchor AP for that NAT flow. The roamed AP may consult NAT flow uplink session information to identify the anchor AP as a next hop for the matching packet. Upon receipt, the anchor AP source NATs the packet with its own IP address and routes the packet towards the Internet. Downlink packets that match the NAT flow are routed in a similar manner through the anchor AP.

Network address translation (NAT) flow migration between wireless access points (APs) in a manner that ensures that client devices can seamlessly roam between APs is described. An AP on which a NAT flow is first created is designated as an anchor NAT flow AP for that NAT flow during the lifetime of the NAT flow. When a non-anchor AP to which a client has roamed receives a packet that matches an active NAT flow, the non-anchor AP forwards the packet to the anchor AP for that NAT flow. The roamed AP may consult NAT flow uplink session information to identify the anchor AP as a next hop for the matching packet. Upon receipt, the anchor AP source NATs the packet with its own IP address and routes the packet towards the Internet. Downlink packets that match the NAT flow are routed in a similar manner through the anchor AP.

A method and a call routing system (CRS) are provided for routing an incoming call made to one of multiple numbers of a user to a call receiving client application (CRCA) deployed on one or more user devices when the called number is not reachable. The CRS, in communication with the CRCA deployed on one or more user devices, sets up a user account using one or more of the user's multiple numbers. The CRS detects availability of the CRCA on one or more user devices over a data network to accept an incoming call. The CRS receives the incoming call made to one of the numbers, when the called number is not reachable. The CRS routes the incoming call to the CRCA on one or more user devices over the data network on detecting the availability of the CRCA on one or more user devices over the data network.

Various embodiments provide methods, devices, and non-transitory processor-readable storage media enabling network path probing with a communications device by sending probes via a network connection to a STUN server and receiving probe replies. The communications device may increment a counter and transmit a test probe configured to be dropped at the first access point (NAT) causing all subsequent NATs to release their IP/port mappings. The communications device may send another probe to the STUN server and receive a probe reply. The communications device may compare the first and second probe replies to determine whether the final IP addresses within the network path match. By continuously incrementing the counter and querying access points, the communications device may determine the number of access points lay along any given network path. The presence of addition or unexpected numbers of NAT Servers may indicate the presence of a rogue access point.

Systems and methods for routing data in a network are described. A client device may send a request for video data that has been captured by a camera of a security system. A gateway of the security system may receive the request and determine if the client device is able to support encryption. The gateway may select a protocol with which to transmit the video data to the client device according to a priority attribute of the protocol and the capability of the client device to support encryption. The video data may be sent to the client device via the selected protocol.

Systems and methods for communicating between a first and a second peer using interactive connectivity establishment (ICE) protocol, the first and second peers sharing a symmetric network address translation (NAT) having wireless isolation enabled and no support for hair-pinning. At a first Traversal Using Relay NAT (TURN) server designated as a relay candidate by a TURN Virtual Internet Platform (VIP), it is determined that a first port allocated by the symmetric NAT for a first request for communication initiated by the first peer and directed to the TURN VIP, is different from a second port allocated by the symmetric NAT for a first packet transmitted from the first peer to the first TURN server, based on a first indication. The second port is mapped to the first port. Using a similar port mapping for the second peer, peer-to-peer communication between the first and second peers is enabled.

A virtual desktop server include an application framework comprising a real-time media application to provide real-time communications (RTC), a native RTC engine to execute a portion of the real-time media application when received, and a processor coupled to the application framework and to the native RTC engine. The processor redirects original application program interfaces (APIs) of the real-time media application intended for the native RTC engine based on redirection code injected into the real-time media application so that the portion of the real-time media application is to be redirected. The processor receives from a client computing device capabilities of the client computing device to execute the redirected portion of the real-time media application. The processor switches to a fallback mode if the client computing device has limited capabilities.

A virtual desktop server include an application framework comprising a real-time media application to provide real-time communications (RTC), a native RTC engine to execute a portion of the real-time media application when received, and a processor coupled to the application framework and to the native RTC engine. The processor redirects original application program interfaces (APIs) of the real-time media application intended for the native RTC engine based on redirection code injected into the real-time media application so that the portion of the real-time media application is to be redirected. The processor receives from a client computing device capabilities of the client computing device to execute the redirected portion of the real-time media application. The processor switches to a fallback mode if the client computing device has limited capabilities.