BIDIRECTIONAL DATA EXCHANGE

BACKGROUND

A variety of computer networking applications involve establishing connections between two or more computing devices. Such networking applications can include multimedia streaming, Voice over IP (VoIP) communications, file sharing, online multiplayer video games, etc. The performance of these networking applications can be negatively impacted by various network security policies and devices, which often limit the ability of two computing devices to exchange data over a network.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example computer-facilitated communication between two users.

FIG. 2 schematically illustrates transmission of a data stream between two computing devices.

FIG. 3 schematically illustrates transmission of a data stream in a network environment utilizing Network Address Translation (NAT).

FIG. 4 schematically illustrates transmission of a data stream in a network environment utilizing Deep Packet Inspection (DPI).

FIG. 5 illustrates an example method for bidirectional data exchange.

FIG. 6 schematically illustrates bidirectional exchange of data using a request and response protocol.

FIG. 7 illustrates another example method for bidirectional data exchange.

FIG. 8 schematically illustrates an example computing system.

DETAILED DESCRIPTION

A variety of different protocols and encoding techniques can be used to transmit data from one computer to another. Such protocols are often characterized via four conceptual layers that collectively form the Internet protocol suite, including the application layer, transport layer, Internet layer, and link layer. For example, when accessing a website, a computer may retrieve a Hypertext Markup Language (HTML) file from a remote server having a unique Internet Protocol (IP) address, which is a part of the Internet layer. The HTML document may be retrieved using the Hypertext Transfer Protocol (HTTP) of the application layer, with network packet transmission being managed by the Transmission Control Protocol (TCP) of the transport layer. In a multimedia streaming environment, a computer may connect to a server and retrieve multimedia content using the Real-Time Transport Protocol (RTP) of the application layer, with transmission of individual data packets (or datagrams) being handled by the User Datagram Protocol (UDP) of the transport layer. In general, different protocols and technologies may be differently-suited to different network applications and environments.

In an ideal scenario, a computing device would in most or all cases be able to send and receive data over a network using the best-suited network protocols. For example, TCP may be used in settings where transmission reliability and fidelity is preferred, at the expense of latency. Similarly, UDP may be used in settings where low latency is more important than reliable transmission. However, in some cases various network restrictions imposed by firewalls, security policies, Network Address Translation (NAT) devices, etc., may present a technical problem in that they limit the types of network traffic that a particular computing device can send and/or receive. Existing solutions to this technical problem, such as Interactive Connectivity Establishment (ICE), can help two computing devices identify a mutually viable communication path. However, such solutions can be ineffective in some network environments, such as when a network security policy only allows transmission of packets sent via a request and response protocol like HTTP. This can interfere with network applications that rely on bidirectional data flow, such as bidirectional media streaming, file sharing, VoIP and other types of computer-facilitated communication, online multiplayer gaming, etc. The functionality of such applications can therefore be significantly impaired, if not completely interrupted, unless network security is relaxed or special exceptions are added to the security policy. Both of these approaches have drawbacks, and may be impossible when a user attempting to establish a connection does not have control over their network configuration.

Accordingly, the present disclosure is directed to technical solutions to the problem of network security and/or infrastructure interfering with bidirectional data transmission. These solutions include techniques for bidirectional data exchange using a request and response protocol. As a technical result of the solutions described herein, multiple request and response data streams can be used to emulate a single, bidirectional data stream. This can enable two computing devices to establish a connection and exchange data as part of a bidirectional data stream, even when network policies only allow request and response traffic via, for example, HTTP. It will be understood that, while the bidirectional data exchange techniques described herein are especially beneficial in network environments that restrict some types of network traffic, the techniques described herein may be used in any network environment where a connection is established between two computing devices over a network, and need not be limited to any particular network environment, application, or protocol.

FIG. 1 illustrates an example computer-facilitated communication between two users. Specifically, FIG. 1 shows an example user 100 using a computing device 102 to communicate with a remote user 104 as part of a VoIP call. Such communication may include exchange of a data stream between computing device 102 and a remote computing device used by remote user 104. The data stream may include one or both of digitized audio and video from at least one call participant. As shown in FIG. 1, audio and video of user 100 is captured by a webcam 106 of computing device 102 and transmitted to the remote computing device of remote user 104. At the same time, audio and video captured by the remote computing device is sent to computing device 102 and presented to user 100. Accordingly, the data stream exchanged between computing device 102 and the remote computing device is bidirectional, such that audio/video of user 100 is being sent at the same time as audio/video of remote user 104 is being received.

As indicated above, a variety of different protocols and connection types can be used to facilitate data transfer, though some network environments will be better suited to bidirectional data exchange than others. FIG. 2 schematically illustrates an example network environment in which a first computing device 200 and a second computing device 202 exchange a bidirectional data stream 204. Data stream 204 includes an outgoing portion 206 including data sent from the first computing device to the second computing device, as well as an incoming portion 208 including data sent from the second computing device to the first computing device. In the example of FIG. 1, outgoing portion 206 may include digitized audio/video of user 100, while incoming portion 208 includes digitized audio/video of remote user 104. In other examples, the outgoing and incoming portions of the data stream may include other types of data, depending on the specific purpose of the data exchange.

In the example of FIG. 2, a direct connection is established between the first and second computing devices. While the data stream may travel through any number of intermediate network routers, switches, cables, and/or other network infrastructure between the two computing devices, each data packet sent from the first computing device is addressed to the second computing device, and not an intermediate server. In other words, the network traffic is not relayed, filtered, inspected, etc., en route. Accordingly, the example of FIG. 2 illustrates an ideal connection between the two computing devices, in which the computing devices can use any suitable set of network protocols to communicate, and network performance will not be hindered by external influences.

However, in real-world implementations, the specifics of a particular network environment can interfere with the ability of two computing devices to successfully establish a connection. FIG. 3 shows an example of such an environment, in which a first computing device 300 and a second computing device 302 exchange a bidirectional data stream 304, including an outgoing portion 306 and an incoming portion 308. In FIG. 3, the first and second computing devices are on opposite sides of a network device 310 that performs Network Address Translation (NAT). Use of NAT in this example allows for creation of a local network, in which each device on the local network has a unique local network address, though all devices on the local network share a single public network address (e.g., IP address) on a larger network (e.g., the Internet). While use of NAT is widespread and presents many advantages, it can interfere with direct communication between two computing devices on opposite sides of the NAT device, as the NAT device may be unable to determine which device on the local network the incoming network traffic is intended for. This problem can be exacerbated when both computing devices are each on separate local networks that use NAT, which is often the case.

Accordingly, use of VoIP applications in network environments featuring NAT, as well as other network applications that require bidirectional data exchange between two computing devices, can require the use of one or more NAT traversal techniques. Two common solutions for NAT traversal are Session Traversal Utilities for NAT (STUN) and Traversal Using Relays around NAT (TURN). Accordingly, in FIG. 3, the bidirectional data stream is shown passing through an intermediate server 312, which may be configured as a STUN or TURN server.

STUN generally involves a computing device behind NAT querying a STUN server for the network address (e.g., IP address) that the computing device presents to the public network. Once this network address is provided, the computing device can establish a connection with the second computing device, and specify the public network address to which the second computing device should send incoming data. Notably, once the STUN server provides the public network address, data can flow directly between the first and second computing devices, without requiring additional involvement of the STUN server.

TURN is generally used in situations where STUN alone is not sufficient. When TURN is used, the first computing device will connect to a TURN server and request that the server allocate a relay that can be used to exchange data with the second computing device. The two computing devices can then each connect to the TURN server, which has a well-known address on the public network (e.g., the Internet), and the TURN server will pass data sent by one computing device on to the other computing device. In this manner, each computing device can communicate with the other, without needing to know the network address of the other computing device.

FIG. 4 shows another example network environment that may interfere with the ability of two computing devices to establish a connection. Specifically, FIG. 4 shows a first computing device 400 and a second computing device 402 attempting to exchange data via a bidirectional data stream 404, which includes an outgoing portion 406 and an incoming portion 408. However, in FIG. 4, network traffic to and from first computing device 400 passes through a network device 410 that performs Deep Packet Inspection (DPI). DPI refers to a wide variety of network traffic inspection and/or filtering techniques that users, organizations, and/or Internet Service Providers (ISPs) can enable on their networks for a variety of reasons. DPI can include inspecting network traffic to identify viruses and other malicious data, inspecting data from specific users to identify improper network usage, blocking traffic to or from specific network addresses or websites, etc. DPI may be performed on a variety of network devices. For example, in some cases DPI may be performed at a proxy server that intercepts network traffic from all devices on a local network.

In some examples, DPI may be used to block network traffic that does not use specific network protocols. For example, because a large percentage of typical Internet traffic is sent as HTTP traffic over TCP, a DPI device may be configured to block traffic sent using different protocols, with the assumption that such traffic is not permitted by a network security policy. However, when a DPI device only allows traffic sent via a request and response protocol like HTTP, the ability of a computing device to send and receive a bidirectional data stream as described above can be compromised, in some cases rendering certain network applications completely unusable.

As an example, when traffic is sent using HTTP, a computing device is generally unable to send a request for data while receiving a response from a remote computing device, and vice versa. In a specific example, a computing device may send an HTTP request to a remote computing device, the request including some amount of data (e.g., digitized audio). After receiving the request, the remote computing device may respond with additional data (e.g., digitized audio from another party). Upon receiving the response, the computing device may send another request including additional data. Notably, after sending the first request, the computing device will be unable to send additional data until after it receives the response from the remote computing device. Similarly, after sending the response, the remote server will be unable to send more data until after it receives another request from the computing device. Accordingly, relying on a traditional request and response protocol for bidirectional communication may require each computing device to wait its “turn” before it can send data. This can make it impossible to conduct a VoIP call as shown in FIG. 1, as gaps are introduced between when a computing device identifies data for transmission, and when the data can actually be transmitted. These limitations can also affect other network applications that rely on bidirectional data exchange, as indicated above. In FIG. 4, the incoming and outgoing portions of bidirectional data stream 404 are shown in dashed lines, indicating that DPI device 410 is interrupting the data exchange.

Accordingly, FIG. 5 illustrates an example method 500 for bidirectional data exchange. Specifically, method 500 can be implemented on a computing device exchanging a bidirectional data stream with a remote computing device, such as a second computing device, intermediate server (e.g., TURN server), etc. In some cases, method 500 may be implemented on a computing system as described below with respect to FIG. 8. Further, method 500 may be implemented in any suitable network environment, and use any suitable request and response protocol. In other words, method 500 need not be restricted to network environments that use NAT, DPI, HTTP, etc.

At 502, method 500 includes sending a first request to a remote computing device via a request and response protocol, the first request including an outgoing portion of a data stream. This is schematically illustrated in FIG. 6, in which a first computing device 600 exchanges a data stream with a remote computing device 602. As indicated above, in some cases, data sent from the first computing device may be inspected by a proxy server or other network device performing DPI.

As used with regard to FIG. 6, a “data stream” will generally refer to the bidirectional exchange of data between the first and second computing devices, and is said to include both incoming and outgoing portions. However, it will be understood that each of the incoming and outgoing portions may be implemented as separate sets of data exchanged between the computing devices (i.e., separate “data streams”) that collectively emulate a single, bidirectional data stream. Each of the incoming and outgoing portions may occasionally be referred to as “request and response streams” or “data streams.”

In the specific example of FIG. 6, the data stream includes data transmitted between the first computing device and a second computing device 604, and the remote computing device is a server configured to facilitate bidirectional data exchange between the first and second computing devices. The remote computing device may be, for example, a TURN server, and/or other suitable computing device. In this example, the techniques for bidirectional exchange described herein may be confined to the first computing device and/or remote computing device, without requiring the second computing device to be specially configured to emulate a bidirectional data stream using individual request and response streams. However, it will be understood that, in some implementations, the remote computing device may be the second computing device, with no intermediate server between the two computing devices.

When the remote computing device is a TURN server, sending of the first request by the computing device may be preceded by one or more allocate requests intended to establish a relay candidate with the TURN server. In TURN, a relay candidate typically refers to a session maintained by the TURN server that relays data received from one computing device to another computing device over a network. For example, the computing device may send a first allocate request, and receive an allocate error response. Based on data included in the allocate error response, the computing device may send two concurrent allocate requests, one for incoming data and one for outgoing data. In some cases, each of these two concurrent allocate requests may specify a same session ID (provided, for example, in the allocate error response), thereby indicating to the TURN server that the two allocate requests are related. Upon receiving the two allocate requests, the TURN server may create a single relay candidate for the incoming and outgoing request and response streams. In some cases, the allocate requests sent by the computing device may be included within request and response packets. As an example, an allocate request may be included within the body of an otherwise normal HTTP packet. Upon successfully establishing a relay candidate with the TURN server, the computing device may send the first request including the outgoing portion of the data stream, as will be described in more detail below.

In FIG. 6, first computing device 600 sends a first request 606 to remote computing device 602 via a request and response protocol, the first request including an outgoing portion 608 of a data stream. Notably, this may occur once a viable communication path between the computing device and the remote computing device has been established. For example, one or both of the computing devices may use a technique such as ICE to determine that communication via the request and response protocol is possible. In some examples, the first request may be sent over TCP, and the request and response protocol may be HTTP, though any suitable network protocols may be used. When the request and response protocol is HTTP, the first request may be sent as an HTTP POST request. Further, the data stream may include any suitable data. As indicated above, in some examples, the data stream may be a VoIP communication between the first and second computing devices including digitized audio and/or video from at least one call participant. Accordingly, the outgoing portion may include digitized audio and/or video of a user of first computing device 600, such as user 100 of FIG. 1. However, in other cases, the data stream may be sent as part of a file sharing application, multiplayer online gaming application, and/or other suitable network application.

Returning briefly to FIG. 5, at 504, method 500 includes sending a second, separate request to the remote computing device via the request and response protocol, the second request soliciting an incoming portion of the data stream. This is schematically illustrated in FIG. 6, in which first computing device 600 sends a second request 610 to the remote computing device, the second request soliciting an incoming portion 612 of the data stream. Within second request 610, incoming portion 612 is shown with dashed lines, indicating that the second request does not actually include the incoming portion, but rather is requesting the incoming portion of the data stream from the remote computing device. As with the first request, the second request may be sent using any suitable network protocols. When the request and response protocol is HTTP, the second request may be sent as an HTTP GET request. The second request may, for example, include some reference to the first request (e.g., a TURN session ID), some indication as to how large the incoming portion will be, and/or any other information that may enable the remote computing device to effectively respond to the second request.

Returning briefly to FIG. 5, at 506, method 500 includes receiving, from the remote computing device and via the request and response protocol, a response to the second request, the response including the incoming portion of the data stream. This is also schematically illustrated in FIG. 6, in which remote computing device 602 sends a response 614 to the first computing device, the response including incoming portion 612. Within response 614, incoming portion 612 is shown with a solid line, indicating that the incoming portion is included within the response.

In some cases, the first and second requests may be sent by the computing device to the remote computing device at substantially the same time. Once both requests are sent, the remote computing device can send the response to the second request at the same time as the computing device is sending a new request, the new request including a new outgoing portion of the data stream. In this manner, the computing device can send outgoing data at the same time as it receives incoming data, thus emulating a single, bidirectional data stream with two different request and response streams. In some cases, the first and second requests may not be “fulfilled” until after data transmission between the computing device and remote computing device has ceased. In other words, the amount of data transmitted as part of the first request and solicited by the second request can be arbitrarily large, and sent as a plurality of individual data packets over a period of time.

Though method 500 and the above description of FIG. 6 focuses primarily on actions performed by the computing device, it will be understood that, according to the present disclosure, one or more actions associated with bidirectional data exchange may additionally or alternatively be performed on what is referred to as the “remote computing device,” which may take the form of an intermediate server, and/or other network computing device that is remote from one or both of the first and second computing devices. Accordingly, FIG. 7 shows another example method 700 for bidirectional data exchange. Specifically, method 500 can be implemented on a network computing device, which may be the same as the remote computing device described above with respect to FIG. 5, (e.g., a TURN server, and/or other suitable server or remote computing device) exchanging a bidirectional data stream with two or more computing devices. In some cases, method 700 may be implemented on a computing system as described below with respect to FIG. 8. Further, method 500 may be implemented on any suitable network environment, using any suitable request and response protocol. In other words, method 500 need not be restricted to network environments that use NAT, DPI, HTTP, etc.

At 702, method 700 includes receiving a first request from a first computing device via a request and response protocol, the first request including a first-device-provided portion of a data stream. This is shown in FIG. 6, in which remote computing device 602 receives first request 606 from first computing device 600. In FIG. 6, portions of the data stream are labeled from the perspective of the first computing device (i.e., outgoing portion 608 and incoming portion 612). From the perspective of the network computing device, the outgoing portion of the data stream is the first-device-provided portion of the data stream.

At 704, method 700 includes sending the first-device-provided portion of the data stream to the second computing device. This is shown in FIG. 6 as, after receiving the first-device-provided portion of the data stream (i.e., outgoing portion 608) from the first computing device, the network computing device sends the first-device-provided portion to second computing device 604. Notably, sending of the first-device-provided portion of the data stream to the second computing device need not use the same network protocol as receiving of the first-device-provided portion from the first computing device. In other words, depending on the network configuration of the second computing device, the network computing device may exchange data with the second computing device using network protocols better suited to bidirectional data exchange. For example, the network computing device may send the first-device-provided portion of the data stream to the second computing device via UDP, as opposed to TCP. Conversion of request-and-response traffic to traffic that relies on a different network protocol may be done in any suitable way.

Returning to FIG. 7, at 706, method 700 includes receiving a second-device-provided portion of the data stream from the second computing device. This is shown in FIG. 6, in which remote computing device 602 receives the second-device-provided portion of the data stream (i.e., incoming portion 612) from the second computing device. In some cases, sending of the first-device-provided portion of the data stream to the second computing device and receiving of the second-device-provided portion of the data stream from the second computing device may happen concurrently, for example using a suitable network protocol that allows for bidirectional data exchange (e.g., RTP over UDP). However, in other cases, data exchange between the network computing device and the second computing device may be done with multiple request and response streams, depending on the network environment of the second computing device.

Returning to FIG. 7, at 708, method 700 includes receiving a second request from the first computing device via the request and response protocol, the second request soliciting the second-device-provided portion of the data stream. This is shown in FIG. 6, in which remote computing device 602 receives second request 610 from first computing device 600, the second request soliciting the second-device-provided portion of the data stream (i.e., incoming portion 612).

Returning to FIG. 7, at 710, method 700 includes sending a response to the second request to the first computing device via the request and response protocol, the response including the second-device-provided portion of the data stream. This is shown in FIG. 6, as remote computing device 602 sends response 614 to first computing device 600, the response including the second-device-provided portion of the data stream (i.e., incoming portion 612).

In some embodiments, the methods and processes described herein may be tied to a computing system of one or more computing devices. In particular, such methods and processes may be implemented as a computer-application program or service, an application-programming interface (API), a library, and/or other computer-program product.

FIG. 8 schematically shows a non-limiting embodiment of a computing system 800 that can enact one or more of the methods and processes described above. Computing system 800 is shown in simplified form. Computing system 800 may take the form of one or more personal computers, server computers, tablet computers, home-entertainment computers, network computing devices, gaming devices, mobile computing devices, mobile communication devices (e.g., smart phone), and/or other computing devices.

Computing system 800 includes a logic machine 802 and a storage machine 804. Computing system 800 may optionally include a display subsystem 806, input subsystem 808, communication subsystem 810, and/or other components not shown in FIG. 8.

Logic machine 802 includes one or more physical devices configured to execute instructions. For example, the logic machine may be configured to execute instructions that are part of one or more applications, services, programs, routines, libraries, objects, components, data structures, or other logical constructs. Such instructions may be implemented to perform a task, implement a data type, transform the state of one or more components, achieve a technical effect, or otherwise arrive at a desired result.

The logic machine may include one or more processors configured to execute software instructions. Additionally or alternatively, the logic machine may include one or more hardware or firmware logic machines configured to execute hardware or firmware instructions. Processors of the logic machine may be single-core or multi-core, and the instructions executed thereon may be configured for sequential, parallel, and/or distributed processing. Individual components of the logic machine optionally may be distributed among two or more separate devices, which may be remotely located and/or configured for coordinated processing. Aspects of the logic machine may be virtualized and executed by remotely accessible, networked computing devices configured in a cloud-computing configuration.

Storage machine 804 includes one or more physical devices configured to hold instructions executable by the logic machine to implement the methods and processes described herein. When such methods and processes are implemented, the state of storage machine 804 may be transformed—e.g., to hold different data.

Storage machine 804 may include removable and/or built-in devices. Storage machine 804 may include optical memory (e.g., CD, DVD, HD-DVD, Blu-Ray Disc, etc.), semiconductor memory (e.g., RAM, EPROM, EEPROM, etc.), and/or magnetic memory (e.g., hard-disk drive, floppy-disk drive, tape drive, MRAM, etc.), among others. Storage machine 804 may include volatile, nonvolatile, dynamic, static, read/write, read-only, random-access, sequential-access, location-addressable, file-addressable, and/or content-addressable devices.

It will be appreciated that storage machine 804 includes one or more physical devices. However, aspects of the instructions described herein alternatively may be propagated by a communication medium (e.g., an electromagnetic signal, an optical signal, etc.) that is not held by a physical device for a finite duration.

Aspects of logic machine 802 and storage machine 804 may be integrated together into one or more hardware-logic components. Such hardware-logic components may include field-programmable gate arrays (FPGAs), program- and application-specific integrated circuits (PASIC/ASICs), program- and application-specific standard products (PSSP/ASSPs), system-on-a-chip (SOC), and complex programmable logic devices (CPLDs), for example.

The terms “module,” “program,” and “engine” may be used to describe an aspect of computing system 800 implemented to perform a particular function. In some cases, a module, program, or engine may be instantiated via logic machine 802 executing instructions held by storage machine 804. It will be understood that different modules, programs, and/or engines may be instantiated from the same application, service, code block, object, library, routine, API, function, etc. Likewise, the same module, program, and/or engine may be instantiated by different applications, services, code blocks, objects, routines, APIs, functions, etc. The terms “module,” “program,” and “engine” may encompass individual or groups of executable files, data files, libraries, drivers, scripts, database records, etc.

It will be appreciated that a “service”, as used herein, is an application program executable across multiple user sessions. A service may be available to one or more system components, programs, and/or other services. In some implementations, a service may run on one or more server-computing devices.

When included, display subsystem 806 may be used to present a visual representation of data held by storage machine 804. This visual representation may take the form of a graphical user interface (GUI). As the herein described methods and processes change the data held by the storage machine, and thus transform the state of the storage machine, the state of display subsystem 806 may likewise be transformed to visually represent changes in the underlying data. Display subsystem 806 may include one or more display devices utilizing virtually any type of technology. Such display devices may be combined with logic machine 802 and/or storage machine 804 in a shared enclosure, or such display devices may be peripheral display devices.

When included, input subsystem 808 may comprise or interface with one or more user-input devices such as a keyboard, mouse, touch screen, or game controller. In some embodiments, the input subsystem may comprise or interface with selected natural user input (NUI) componentry. Such componentry may be integrated or peripheral, and the transduction and/or processing of input actions may be handled on- or off-board. Example NUI componentry may include a microphone for speech and/or voice recognition; an infrared, color, stereoscopic, and/or depth camera for machine vision and/or gesture recognition; a head tracker, eye tracker, accelerometer, and/or gyroscope for motion detection and/or intent recognition; as well as electric-field sensing componentry for assessing brain activity.

When included, communication subsystem 810 may be configured to communicatively couple computing system 800 with one or more other computing devices. Communication subsystem 810 may include wired and/or wireless communication devices compatible with one or more different communication protocols. As non-limiting examples, the communication subsystem may be configured for communication via a wireless telephone network, or a wired or wireless local- or wide-area network. In some embodiments, the communication subsystem may allow computing system 800 to send and/or receive messages to and/or from other devices via a network such as the Internet.

In an example, a method for bidirectional data exchange comprises: on a computing device, sending a first request to a remote computing device via a request and response protocol, the first request including an outgoing portion of a data stream; sending a second, separate request to the remote computing device via the request and response protocol, the second request soliciting an incoming portion of the data stream; and receiving, from the remote computing device and via the request and response protocol, a response to the second request, the response including the incoming portion of the data stream. In this example or any other example, the request and response protocol is the Hypertext Transfer Protocol (HTTP). In this example or any other example, the first request is an HTTP POST request. In this example or any other example, the second request is an HTTP GET request. In this example or any other example, data sent from the computing device is inspected by a proxy server performing Deep Packet Inspection (DPI). In this example or any other example, the data stream is a Voice over IP (VoIP) communication between the computing device and a second computing device including digitized audio from at least one call participant. In this example or any other example, one or more network devices between the computing device and the remote computing device performs network address translation (NAT). In this example or any other example, the remote computing device is a Traversal Using Relays around NAT (TURN) server.

In an example, a computing device comprises: a communications subsystem; a logic machine; and a storage machine holding instructions executable by the logic machine to: via the communications subsystem, send a first request to a remote computing device via a request and response protocol, the first request including an outgoing portion of a data stream; send a second, separate request to the remote computing device via the request and response protocol, the second request soliciting an incoming portion of the data stream; and receive, from the remote computing device and via the request and response protocol, a response to the second request, the response including the incoming portion of the data stream. In this example or any other example, the request and response protocol is the Hypertext Transfer Protocol (HTTP). In this example or any other example, data sent from the computing device is inspected by a proxy server performing Deep Packet Inspection (DPI). In this example or any other example, the data stream is a Voice over IP (VoIP) communication between the computing device and a second computing device including digitized audio from at least one call participant. In this example or any other example, one or more network devices between the computing device and the remote computing device performs network address translation (NAT). In this example or any other example, the remote computing device is a Traversal Using Relays around NAT (TURN) server.

In an example, a computing device for bidirectional data exchange comprises: means for sending a first request to a remote computing device via a request and response protocol, the first request including an outgoing portion of a data stream; means for sending a second, separate request to the remote computing device via the request and response protocol, the second request soliciting an incoming portion of the data stream; and means for receiving, from the remote computing device and via the request and response protocol, a response to the second request, the response including the incoming portion of the data stream. In this example or any other example, the request and response protocol is the Hypertext Transfer Protocol (HTTP). In this example or any other example, data sent from the computing device is inspected by a proxy server performing Deep Packet Inspection (DPI). In this example or any other example, the data stream is a Voice over IP (VoIP) communication between the computing device and a second computing device including digitized audio from at least one call participant. In this example or any other example, one or more network devices between the computing device and the remote computing device performs network address translation (NAT). In this example or any other example, the remote computing device is a Traversal Using Relays around NAT (TURN) server.

It will be understood that the configurations and/or approaches described herein are exemplary in nature, and that these specific embodiments or examples are not to be considered in a limiting sense, because numerous variations are possible. The specific routines or methods described herein may represent one or more of any number of processing strategies. As such, various acts illustrated and/or described may be performed in the sequence illustrated and/or described, in other sequences, in parallel, or omitted. Likewise, the order of the above-described processes may be changed.

The subject matter of the present disclosure includes all novel and non-obvious combinations and sub-combinations of the various processes, systems and configurations, and other features, functions, acts, and/or properties disclosed herein, as well as any and all equivalents thereof.

BIDIRECTIONAL DATA EXCHANGE

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

International Classifications

Abstract

Description

Claims