VIRTUAL WEB REAL-TIME COMMUNICATIONS (WEBRTC) GATEWAYS, AND RELATED METHODS, SYSTEMS, AND COMPUTER-READABLE MEDIA

Virtual Web Real-Time Communications (WebRTC) gateways, and related methods, systems, and computer-readable media are disclosed herein. In one embodiment, a method for providing a virtual WebRTC gateway comprises instantiating a virtual WebRTC agent corresponding to a WebRTC client, and instantiating a virtual non-WebRTC agent corresponding to a non-WebRTC client. The method further comprises establishing a WebRTC interactive flow between the virtual WebRTC agent and the WebRTC client, and establishing a non-WebRTC interactive flow between the virtual non-WebRTC agent and the non-WebRTC client. The method also comprises directing a content of the WebRTC interactive flow to the non-WebRTC interactive flow, and a content of the non-WebRTC interactive flow to the WebRTC interactive flow, via the virtual WebRTC agent and the virtual non-WebRTC agent. In this manner, the virtual WebRTC gateway may provide interoperability between otherwise-incompatible WebRTC clients and non-WebRTC clients.

BACKGROUND

1. Field of the Disclosure

The technology of the disclosure relates generally to Web Real-Time Communications (WebRTC) interactive sessions.

2. Technical Background

Web Real-Time Communications (WebRTC) represents an ongoing effort to develop industry standards for integrating real-time communications functionality into web clients, such as web browsers, to enable direct interaction with other web clients. This real-time communications functionality is accessible by web developers via standard markup tags, such as those provided by version 5 of the Hypertext Markup Language (HTML5), and client-side scripting Application Programming Interfaces (APIs), such as JavaScript APIs. More information regarding WebRTC may be found in “WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web,” by Alan B. Johnston and Daniel C. Burnett (2012 Digital Codex LLC), which is incorporated herein in its entirety by reference.

WebRTC provides built-in capabilities for establishing real-time video, audio, and/or data streams in both point-to-point interactive sessions and multi-party interactive sessions. The WebRTC standards are currently under joint development by the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF). Information on the current state of WebRTC standards can be found at, e.g., http://www.w3c.org and http://www/ietf.org.

Existing protocols for providing interactive flows, such as Session Initiation Protocol (SIP), H.323, and Jingle, are not compatible with WebRTC due to new features and media extensions provided by WebRTC. As a result, retrofitting gateway applications that employ these existing protocols to add WebRTC capabilities would involve non-trivial development efforts. Moreover, the varying levels of WebRTC support that are currently provided by different WebRTC clients may present further compatibility and support issues for gateway applications.

SUMMARY OF THE DETAILED DESCRIPTION

Embodiments disclosed in the detailed description provide virtual Web Real-Time Communications (WebRTC) gateways. Related methods, systems, and computer-readable media are also disclosed. In some embodiments, an interactive flow server, through which a WebRTC client and a non-WebRTC client seek to establish an interactive session, instantiates a virtual WebRTC agent and a virtual non-WebRTC agent. The interactive flow server may cause the WebRTC client to establish a WebRTC interactive flow with the virtual WebRTC agent, and may cause the non-WebRTC client to establish a non-WebRTC interactive flow with the virtual non-WebRTC agent. The interactive flow server may then connect the virtual WebRTC agent and the virtual non-WebRTC agent “back-to-back” by directing output from the virtual WebRTC agent as input into the virtual non-WebRTC agent, and vice versa. In this manner, the interactive flow server may provide a virtual WebRTC gateway between the WebRTC client and the non-WebRTC client, while also providing additional media processing and handling functionality. As non-limiting examples, the media processing and handling functionality may include recording and/or monitoring of the WebRTC and/or non-WebRTC interactive flows, and/or extracting content from or injecting content into the WebRTC and/or non-WebRTC interactive flows.

In this regard, in one embodiment, a method for providing a virtual WebRTC gateway is provided. The method comprises instantiating, by a virtual WebRTC gateway executing on a computing device, a virtual WebRTC agent corresponding to a WebRTC client. The method further comprises instantiating a virtual non-WebRTC agent corresponding to a non-WebRTC client. The method also comprises establishing a WebRTC interactive flow between the virtual WebRTC agent and the WebRTC client. The method additionally comprises establishing a non-WebRTC interactive flow between the virtual non-WebRTC agent and the non-WebRTC client. The method further comprises directing a content of the WebRTC interactive flow to the non-WebRTC interactive flow, and a content of the non-WebRTC interactive flow to the WebRTC interactive flow, via the virtual WebRTC agent and the virtual non-WebRTC agent.

In another embodiment, a system for providing a virtual WebRTC gateway is provided. The system comprises at least one communications interface, and an interactive flow server associated with the at least one communications interface. The interactive flow server comprises a virtual WebRTC gateway configured to instantiate a virtual WebRTC agent corresponding to a WebRTC client, and instantiate a virtual non-WebRTC agent corresponding to a non-WebRTC client. The virtual WebRTC gateway is further configured to establish a WebRTC interactive flow between the virtual WebRTC agent and the WebRTC client. The virtual WebRTC gateway is also configured to establish a non-WebRTC interactive flow between the virtual non-WebRTC agent and the non-WebRTC client. The virtual WebRTC gateway is additionally configured to direct a content of the WebRTC interactive flow to the non-WebRTC interactive flow, and a content of the non-WebRTC interactive flow to the WebRTC interactive flow, via the virtual WebRTC agent and the virtual non-WebRTC agent.

In another embodiment, a non-transitory computer-readable medium is provided. The non-transitory computer-readable medium has stored thereon computer-executable instructions to cause a processor to implement a method comprising instantiating a virtual WebRTC agent corresponding to a WebRTC client. The method implemented by the computer-executable instructions further comprises instantiating a virtual non-WebRTC agent corresponding to a non-WebRTC client. The method implemented by the computer-executable instructions also comprises establishing a WebRTC interactive flow between the virtual WebRTC agent and the WebRTC client. The method implemented by the computer-executable instructions additionally comprises establishing a non-WebRTC interactive flow between the virtual non-WebRTC agent and the non-WebRTC client. The method implemented by the computer-executable instructions further comprises directing a content of the WebRTC interactive flow to the non-WebRTC interactive flow, and a content of the non-WebRTC interactive flow to the WebRTC interactive flow, via the virtual WebRTC agent and the virtual non-WebRTC agent.

DETAILED DESCRIPTION

With reference now to the drawing figures, several exemplary embodiments of the present disclosure are described. The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

Embodiments disclosed in the detailed description provide virtual Web Real-Time Communications (WebRTC) gateways. Related methods, systems, and computer-readable media are also disclosed. In some embodiments, an interactive flow server, through which a WebRTC client and a non-WebRTC client seek to establish an interactive session, instantiates a virtual WebRTC agent and a virtual non-WebRTC agent. The interactive flow server may cause the WebRTC client to establish a WebRTC interactive flow with the virtual WebRTC agent, and may cause the non-WebRTC client to establish a non-WebRTC interactive flow with the virtual non-WebRTC agent. The interactive flow server may then connect the virtual WebRTC agent and the virtual non-WebRTC agent “back-to-back” by directing output from the virtual WebRTC agent as input into the virtual non-WebRTC agent, and vice versa. In this manner, the interactive flow server may provide a virtual WebRTC gateway between the WebRTC client and the non-WebRTC client, while also providing additional media processing and handling functionality. As non-limiting examples, the media processing and handling functionality may include recording and/or monitoring of the WebRTC and/or non-WebRTC interactive flows, and/or extracting content from or injecting content into the WebRTC and/or non-WebRTC interactive flows.

In this regard, in one embodiment, a method for providing a virtual WebRTC gateway is provided. The method comprises instantiating, by a virtual WebRTC gateway executing on a computing device, a virtual WebRTC agent corresponding to a WebRTC client. The method further comprises instantiating a virtual non-WebRTC agent corresponding to a non-WebRTC client. The method also comprises establishing a WebRTC interactive flow between the virtual WebRTC agent and the WebRTC client. The method additionally comprises establishing a non-WebRTC interactive flow between the virtual non-WebRTC agent and the non-WebRTC client. The method further comprises directing a content of the WebRTC interactive flow to the non-WebRTC interactive flow, and a content of the non-WebRTC interactive flow to the WebRTC interactive flow, via the virtual WebRTC agent and the virtual non-WebRTC agent.

FIG. 1illustrates an exemplary interactive communications system10providing virtual WebRTC gateways as disclosed herein. In particular, the exemplary interactive communications system10provides an interactive flow server12that executes on a computing device14, and that includes a virtual WebRTC gateway16. The virtual WebRTC gateway16handles instantiation of virtual WebRTC agents and virtual non-WebRTC agents, and coordinates establishing and directing of content of interactive flows to provide interoperability between a WebRTC endpoint and a non-WebRTC endpoint. As used herein, a “virtual WebRTC agent” refers to an instance of a WebRTC-enabled browser or other client application that executes on the computing device14under the control of the virtual WebRTC gateway16. A “virtual non-WebRTC agent” refers to an instance of a client application that executes on the computing device14under the control of the virtual WebRTC gateway16, and that provides real-time communications capabilities according to a protocol other than WebRTC. As non-limiting examples, such non-WebRTC protocols may include Session Initiation Protocol (SIP), H.323, Jingle, or other protocols providing session-centric interactive flows. A “WebRTC interactive flow,” as disclosed herein, refers to an interactive media flow and/or an interactive data flow that passes between or among two or more endpoints according to WebRTC, while a “non-WebRTC interactive flow” refers to an interactive media flow and/or an interactive data flow according to a protocol other than WebRTC. As non-limiting examples, an interactive media flow constituting a WebRTC or non-WebRTC interactive flow may comprise a real-time audio stream and/or a real-time video stream, or other real-time media or data streams. Data and/or media comprising an interactive flow may be collectively referred to herein as “content.”

For purposes of illustration, a WebRTC interactive flow18inFIG. 1is shown as passing between the computing device14and a computing device20, and a non-WebRTC interactive flow22is shown as passing between the computing device14and a computing device24. It is to be understood that the computing devices14,20, and24may all be located within a same public or private network, or may be located within separate, communicatively coupled public or private networks. Some embodiments of the interactive communications system10ofFIG. 1may provide that each of the computing devices14,20, and24may be any computing device having network communications capabilities, such as a smartphone, a tablet computer, a dedicated web appliance, a media server, a desktop or server computer, or a purpose-built communications device, as non-limiting examples. The computing devices14,20, and24include communications interfaces26,28, and30, respectively, for connecting the computing devices14,20, and24to one or more public and/or private networks. In some embodiments, the elements of the computing devices14,20, and24may be distributed across more than one computing device14,20,24.

The computing device20ofFIG. 1includes a WebRTC client32. The WebRTC client32may be a WebRTC-enabled web browser application, a dedicated communications application, a mobile application, or an interface-less application, such as a daemon or service application, as non-limiting examples. The WebRTC client32implements the protocols, codecs, and Application Programming Interfaces (APIs) necessary to provide the WebRTC interactive flow18between the computing device20and the computing device14. The computing device24ofFIG. 1includes a non-WebRTC client34, which provides real-time communications capabilities based on a protocol other than WebRTC. The non-WebRTC client34may be a web browser application, a dedicated communications application, a mobile application, or an interface-less application, such as a daemon or service application, as non-limiting examples. As a non-limiting example, the non-WebRTC client34may be a SIP user agent client providing a SIP signaling stack and a Real-time Transport Protocol (RTP) media stack compatible with a SIP network or service. In some embodiments, non-limiting examples of other non-WebRTC clients34may be an H.323 client application or a Jingle client application. The non-WebRTC client34implements the protocols, codecs, and APIs necessary to provide the non-WebRTC interactive flow22between the computing device24and the computing device14.

As seen inFIG. 1, the computing device20is communicatively coupled to an audio in device36(e.g., a microphone) for receiving audio input, and an audio out device38(for example, speakers or headphones) for generating audio output. The computing device20is further communicatively coupled to a video in device40(such as a camera, webcam, or other video source) for receiving video input, and a video out device42(e.g., a display) for displaying video output. Likewise, the computing device24is communicatively coupled to an audio in device44, an audio out device46, a video in device48, and a video out device50. The audio in devices36and44, the audio out devices38and46, the video in devices40and48, and/or the video out devices42and50may be integrated into the respective computing devices20and24, and/or they may be peripheral devices and/or virtual devices communicatively coupled to the respective computing devices20and24. In some embodiments, the computing devices20and/or24may be communicatively coupled to more or fewer devices than illustrated inFIG. 1.

Because WebRTC and non-WebRTC protocols are fundamentally incompatible, the WebRTC client32and the non-WebRTC client34are unable to establish an interactive flow directly with one another via a peer connection. To enable interoperability between the WebRTC client32and the non-WebRTC client34, the virtual WebRTC gateway16provides a virtual WebRTC agent52and a virtual non-WebRTC agent54. In the example ofFIG. 1, the WebRTC client32downloads a WebRTC web application (not shown) from a WebRTC application provider56of the interactive flow server12via a Hyper Text Transfer Protocol (HTTP)/Hyper Text Transfer Protocol Secure (HTTPS) connection58. In some embodiments, the WebRTC web application may comprise an HTML5/JavaScript web application that provides a rich user interface using HTML5, and uses JavaScript to handle user input and to communicate with the WebRTC application provider56. The virtual WebRTC gateway16then instantiates the virtual WebRTC agent52corresponding to the WebRTC client32. In some embodiments, the virtual WebRTC gateway16may instantiate the virtual WebRTC agent52by launching an instance of a WebRTC client, such as a web browser, on the computing device14. Some embodiments may provide that the virtual WebRTC agent52is executed within a virtual instance of an operating system.

After instantiation, the virtual WebRTC agent52is directed by the virtual WebRTC gateway16to download a virtual WebRTC application (not shown) from a virtual WebRTC application provider60. Some embodiments may provide that the virtual WebRTC application provider60is communicatively coupled to the virtual WebRTC gateway16. In some embodiments, the virtual WebRTC application provider60may be integrated into or otherwise constitute an element of the virtual WebRTC gateway16and/or the WebRTC application provider56. The virtual WebRTC application includes specialized instructions for interfacing with the WebRTC APIs of the virtual WebRTC agent52. The virtual WebRTC agent52may communicate via the virtual WebRTC application with the WebRTC client32, and with the virtual WebRTC gateway16.

The virtual WebRTC gateway16also instantiates the virtual non-WebRTC agent54corresponding to the non-WebRTC client34. In some embodiments, the virtual WebRTC gateway16may instantiate the virtual non-WebRTC agent54by launching one or more instances of a non-WebRTC client, such as a SIP user agent client, an H.323 client, or a Jingle client, on the computing device14. Some embodiments may provide that the virtual non-WebRTC agent54is executed within a virtual instance of an operating system.

The virtual WebRTC gateway16causes the virtual WebRTC agent52to establish the WebRTC interactive flow18with the WebRTC client32, and also causes the virtual non-WebRTC agent54to establish the non-WebRTC interactive flow22with the non-WebRTC client34. The virtual WebRTC gateway16then connects the virtual WebRTC agent52and the virtual non-WebRTC agent54“back-to-back” (i.e., the content output by the WebRTC interactive flow18of the virtual WebRTC agent52is directed as input into the non-WebRTC interactive flow22of the virtual non-WebRTC agent54, and vice versa). To accomplish a “back-to-back” connection, the virtual WebRTC gateway16provides a virtual audio receiver (Rx)62, a virtual audio transmitter (Tx)64, a virtual video receiver66, a virtual video transmitter68, a virtual data receiver70, and a virtual data transmitter72to which the virtual WebRTC agent52is communicatively coupled. Likewise, the virtual non-WebRTC agent54is communicatively coupled to a virtual audio receiver74, a virtual audio transmitter76, a virtual video receiver78, a virtual video transmitter80, a virtual data receiver82, and a virtual data transmitter84provided by the virtual WebRTC gateway16.

The virtual audio receiver62that is communicatively coupled to the virtual WebRTC agent52is configured to direct audio signals received from the virtual WebRTC agent52to the virtual audio transmitter76that is communicatively coupled to the virtual non-WebRTC agent54. The virtual video receiver66that is communicatively coupled to the virtual WebRTC agent52is configured to direct video signals received from the virtual WebRTC agent52to the virtual video transmitter80that is communicatively coupled to the virtual non-WebRTC agent54. The virtual data receiver70that is communicatively coupled to the virtual WebRTC agent52is configured to direct data received from the virtual WebRTC agent52to the virtual data transmitter84that is communicatively coupled to the virtual non-WebRTC agent54.

In a similar fashion, the virtual audio receiver74that is communicatively coupled to the virtual non-WebRTC agent54is configured to direct audio signals received from the virtual non-WebRTC agent54to the virtual audio transmitter64that is communicatively coupled to the virtual WebRTC agent52. The virtual video receiver78that is communicatively coupled to the virtual non-WebRTC agent54is configured to direct video signals received from the virtual non-WebRTC agent54to the virtual video transmitter68that is communicatively coupled to the virtual WebRTC agent52. The virtual data receiver82that is communicatively coupled to the virtual non-WebRTC agent54is configured to direct data received from the virtual non-WebRTC agent54to the virtual data transmitter72that is communicatively coupled to the virtual WebRTC agent52.

It is to be understood that, in some embodiments, one or more of the audio signals, the video signals, and/or the data of the non-WebRTC interactive flow22may not be accessible depending on the capabilities and functionality provided by the virtual non-WebRTC agent54and/or the non-WebRTC client34. For instance, some embodiments of the virtual non-WebRTC agent54and/or the non-WebRTC client34may provide an audio signal and a video signal, but may not be capable of providing a data flow and/or may only provide a data flow using proprietary standards. In such embodiments, the virtual audio receivers62and/or74, the virtual video receivers66and/or78, and/or the virtual data receivers70and/or82may be omitted.

From the perspective of the WebRTC client32and the non-WebRTC client34, the resulting interactive session including the WebRTC interactive flow18and the non-WebRTC interactive flow22appears no different from an interactive session transported over a direct peer connection. During the resulting interactive session, the virtual WebRTC gateway16may extract content from the WebRTC interactive flow18and/or the non-WebRTC interactive flow22by accessing an input from the virtual audio receivers62and/or74, the virtual video receivers66and/or78, and/or the virtual data receivers70and/or82. The virtual WebRTC gateway16may also inject content into the WebRTC interactive flow18and/or the non-WebRTC interactive flow22by modifying an output from the virtual audio transmitters64and/or76, the virtual video transmitters68and/or80, and/or the virtual data transmitters72and84. Thus, some embodiments may provide that content may be extracted from or injected into the WebRTC interactive flow18and/or the non-WebRTC interactive flow22. In some embodiments, content from the WebRTC interactive flow18and/or the non-WebRTC interactive flow22may be recorded or transformed by the virtual WebRTC gateway16.

In some embodiments, content from the WebRTC interactive flow18and/or the non-WebRTC interactive flow22may be optionally directed to or received from a functionality provider86as indicated by bidirectional video feed88, bidirectional audio feed90, and bidirectional data feed92. The functionality provider86may provide additional media processing and handling functionality, such as recording or transforming content of the WebRTC interactive flow18and/or the non-WebRTC interactive flow22. In some embodiments, the functionality provider86may provide content, such as audio or video announcements, to be injected into the WebRTC interactive flow18and/or the non-WebRTC interactive flow22.

In the example ofFIG. 1, the virtual WebRTC gateway16and/or the WebRTC application provider56may determine the specific client type and/or client version of the WebRTC client32prior to instantiating the virtual WebRTC agent52. In some embodiments, the client type and/or client version of the WebRTC client32may be determined based on data received as part of a WebRTC offer/answer exchange, a query/response exchange between the virtual WebRTC gateway16and the WebRTC client32, or HTTP header data, or other data provided by the WebRTC client32. The virtual WebRTC gateway16may then instantiate the virtual WebRTC agent52having a client type and/or version corresponding to the client type and/or version of the WebRTC client32. Because the WebRTC client32directly communicates with a virtual WebRTC agent52of the same type and version, incompatibilities due to varying levels of support for WebRTC by the WebRTC client32may be resolved.

In some embodiments, a call control application provider94may be provided to further facilitate the management of an interactive session between the WebRTC client32and the non-WebRTC client34. As a non-limiting example, the call control application provider94may provide a call control application (not shown) that may be downloaded to the WebRTC client32via a HTTP/HTTPS connection96. The call control application provider94may provide additional functionality for generating and sending appropriate interactive flow management commands to the virtual non-WebRTC agent54via the call control application provider94. For instance, if the non-WebRTC client34is a SIP client, the call control application provider94may provide the WebRTC client32with a call control application having an HTML5 interface for initiating, terminating, conferencing, and/or transferring a SIP interactive session. The call control application provider94may then translate input from the WebRTC client32into the corresponding SIP commands, and may relay the corresponding SIP commands to the virtual non-WebRTC agent54.

To generally describe exemplary operations of the virtual WebRTC gateway16ofFIG. 1for providing the virtual WebRTC agent52and the virtual non-WebRTC agent54,FIG. 2is provided. For the sake of clarity, elements ofFIG. 1are referenced in describingFIG. 2. In the example ofFIG. 2, operations begin with the WebRTC application provider56instantiating a virtual WebRTC agent52corresponding to a WebRTC client32(block98). As a non-limiting example, the virtual WebRTC gateway16may instantiate the virtual WebRTC agent52by launching an instance of a WebRTC client, such as a web browser, on the computing device14. The virtual WebRTC gateway16then instantiates a virtual non-WebRTC agent54corresponding to a non-WebRTC client34(block100). In some embodiments, the virtual WebRTC gateway16may instantiate the virtual non-WebRTC agent54by launching an instance of a non-WebRTC client, such as a SIP user agent client, an H.323 client, or a Jingle client, on the computing device14.

The virtual WebRTC gateway16then establishes a WebRTC interactive flow18between the virtual WebRTC agent52and the WebRTC client32(block102). The virtual WebRTC gateway16also establishes a non-WebRTC interactive flow22between the virtual non-WebRTC agent54and the non-WebRTC client34(block104). The virtual WebRTC gateway16next directs a content of the WebRTC interactive flow18to the non-WebRTC interactive flow22, and a content of the non-WebRTC interactive flow22to the WebRTC interactive flow18via the virtual WebRTC agent52and the virtual non-WebRTC agent54(block106). This results in a “back-to-back” connection between the virtual WebRTC agent52and the virtual non-WebRTC agent54. In some embodiments, this may be accomplished through the use of virtual audio receivers62,74and transmitters64,76, virtual video receivers66,78and transmitters68,80, and virtual data receivers70,82and transmitters72,84provided by the virtual WebRTC gateway16, as illustrated inFIG. 1.

To illustrate exemplary communications flows for an outbound interaction request from a WebRTC client32to a non-WebRTC client34using the virtual WebRTC agent52and the virtual non-WebRTC agent54ofFIG. 1,FIG. 3is provided. InFIG. 3, the WebRTC client32, the virtual WebRTC agent52, the virtual WebRTC gateway16, the virtual non-WebRTC agent54, and the non-WebRTC client34ofFIG. 1are each represented by vertical dotted lines. It is to be understood for this example that the WebRTC client32has downloaded a WebRTC-enabled web application, such as an HTML5/JavaScript WebRTC application, from the interactive flow server12. In some embodiments, the non-WebRTC client34may be a SIP user agent client, an H.323 client, or a Jingle client, as non-limiting examples.

As seen inFIG. 3, the establishment of an interactive session via the virtual WebRTC agent52and the virtual non-WebRTC agent54begins with the WebRTC client32sending an outbound interaction request, represented by arrow108, to the virtual WebRTC gateway16. Some embodiments may provide that the outbound interaction request includes a selection of a non-WebRTC protocol by the WebRTC client32from a plurality of non-WebRTC protocols supported by the virtual WebRTC gateway16. In some embodiments, the outbound interaction request may include a SIP Uniform Resource Identifier (URI) or SIP address for the non-WebRTC client34. In response to receiving the outbound interaction request, the virtual WebRTC gateway16instantiates the virtual WebRTC agent52corresponding to the WebRTC client32, as indicated by arrow110. The virtual WebRTC agent52may be instantiated having a client type and/or a client version that is known to be compatible with the WebRTC client32, based on a WebRTC offer/answer exchange, a query/response exchange between the virtual WebRTC gateway16and the WebRTC client32, or HTTP header data, or other data provided by the WebRTC client32.

With continuing reference toFIG. 3, the WebRTC client32and the virtual WebRTC agent52then begin “hole punching,” indicated by bidirectional arrow112, to determine the best way to establish direct communications. Hole punching is a technique, often using protocols such as Interactive Connectivity Establishment (ICE), in which the WebRTC client32and/or the virtual WebRTC agent52establish a connection with an unrestricted third-party server (not shown) that uncovers external and internal address information for use in direct communications. If the ICE hole punching indicated by arrow112is successful, the WebRTC client32and the virtual WebRTC agent52begin key negotiations to establish a secure peer connection, as indicated by bidirectional arrow114. If the key negotiations are successfully concluded, a peer connection is established between the WebRTC client32and the virtual WebRTC agent52, as indicated by bidirectional arrow116.

Upon establishing a peer connection between the WebRTC client32and the virtual WebRTC agent52, the virtual WebRTC gateway16then instantiates the virtual non-WebRTC agent54corresponding to the non-WebRTC client34, as indicated arrow118. Some embodiments may provide that the virtual non-WebRTC agent54is instantiated to correspond to the selected non-WebRTC protocol indicated by the outbound interaction request. Once instantiated, the virtual non-WebRTC agent54sends an INVITE request, represented by arrow120, to the non-WebRTC client34. In some embodiments, the INVITE request is a protocol-specific message for requesting the initiation of an interactive session. For example, the INVITE request for a SIP client may be a SIP INVITE request sent to the SIP URI or SIP address initially specified by the WebRTC client32in the outbound interaction request. If the non-WebRTC client34agrees to the outbound interaction request, the non-WebRTC client34responds with an OK message to the virtual non-WebRTC agent54, as indicated by arrow122. In embodiments where the non-WebRTC client34is a SIP client, the OK message may be a SIP “200 OK” response message.

The WebRTC client32and the non-WebRTC client34then begin exchanging media and/or data flows. As seen inFIG. 3, content of the WebRTC interactive flow18passes from the WebRTC client32to the virtual WebRTC agent52, as indicated by bidirectional arrow124. Similarly, content of the non-WebRTC interactive flow22passes from the non-WebRTC client34to the virtual non-WebRTC agent54, as indicated by bidirectional arrow126. The virtual WebRTC agent52and the virtual non-WebRTC agent54then send the content of the WebRTC interactive flow18and the non-WebRTC interactive flow22through the virtual WebRTC gateway16, as shown by bidirectional arrows128and130. In this manner, the virtual WebRTC gateway16may selectively control, monitor, and/or modify the content of the WebRTC interactive flow18and/or the non-WebRTC interactive flow22between the WebRTC client32and the non-WebRTC client34.

As a complement to the outbound interaction request illustrated inFIG. 3,FIG. 4illustrates exemplary communications flows for an inbound interaction request to the WebRTC client32from the non-WebRTC client34using the virtual WebRTC agent52and the virtual non-WebRTC agent54ofFIG. 1. InFIG. 4, the WebRTC client32, the virtual WebRTC agent52, the virtual WebRTC gateway16, the virtual non-WebRTC agent54, and the non-WebRTC client34ofFIG. 1are each represented by vertical dotted lines. It is to be understood for this example that the WebRTC client32has downloaded a WebRTC-enabled web application, such as an HTML5/JavaScript WebRTC application, from the interactive flow server12. In some embodiments, the non-WebRTC client34may be a SIP user agent client, an H.323 client, or a Jingle client, as non-limiting examples.

In some embodiments, receiving an inbound interaction request to the WebRTC client32from the non-WebRTC client34requires that the virtual non-WebRTC agent54be instantiated when the WebRTC client32is active. Accordingly, inFIG. 4, the virtual WebRTC gateway16receives an indication that the WebRTC client32is active, as indicated by arrow132. Upon determining that the WebRTC client32is active, the virtual WebRTC gateway16instantiates the virtual non-WebRTC agent54, as indicated by arrow134. Once instantiated, the virtual non-WebRTC agent54awaits an incoming request for interaction.

To initiate an interactive session with the WebRTC client32, the non-WebRTC client34sends an INVITE request, represented by arrow136, to the virtual non-WebRTC agent54. In some embodiments, the INVITE request is a protocol-specific message for requesting the initiation of an interactive session. For example, if the non-WebRTC client34is a SIP user agent client, the INVITE request may be a SIP INVITE request sent to a SIP URI or SIP address assigned to the WebRTC client32and registered with the virtual non-WebRTC agent54.

In response to receiving the inbound interaction request, the virtual WebRTC gateway16instantiates the virtual WebRTC agent52corresponding to the WebRTC client32, as indicated by arrow138. The virtual WebRTC agent52may be instantiated having a client type and/or a client version that is known to be compatible with the WebRTC client32, based on a WebRTC offer/answer exchange, a query/response exchange between the virtual WebRTC gateway16and the WebRTC client32, or HTTP header data, or other data provided by the WebRTC client32. The WebRTC client32and the virtual WebRTC agent52then begin hole punching, as represented by bidirectional arrow140, to determine the best way to establish direct communications. If the ICE hole punching indicated by arrow140is successful, the WebRTC client32and the virtual WebRTC agent52begin key negotiations to establish a secure peer connection, as indicated by bidirectional arrow142. Once the key negotiations are successfully concluded, a peer connection is established between the WebRTC client32and the virtual WebRTC agent52, as indicated by bidirectional arrow144.

Upon establishing a peer connection between the WebRTC client32and the virtual WebRTC agent52, the virtual non-WebRTC agent54responds with an OK message to the non-WebRTC client34, as indicated by arrow146. In embodiments in which the non-WebRTC client34is a SIP client, the OK message may be a SIP “200 OK” response message. The WebRTC client32and the non-WebRTC client34then begin exchanging media and/or data flows. As seen inFIG. 4, content of the WebRTC interactive flow18passes from the WebRTC client32to the virtual WebRTC agent52, as indicated by bidirectional arrow148. Similarly, content of the non-WebRTC interactive flow22passes from the non-WebRTC client34to the virtual non-WebRTC agent54, as indicated by bidirectional arrow150. The virtual WebRTC agent52and the virtual non-WebRTC agent54then send the content of the WebRTC interactive flow18and the non-WebRTC interactive flow22through the virtual WebRTC gateway16, as shown by bidirectional arrows152and154. In this manner, the virtual WebRTC gateway16may selectively control, monitor, and/or modify the content of the WebRTC interactive flow18and the non-WebRTC interactive flow22between the WebRTC client32and the non-WebRTC client34.

FIGS. 5A and 5Bare provided to illustrate in greater detail an exemplary generalized process for the virtual WebRTC gateway16ofFIG. 1to provide interoperability between a WebRTC client32and a non-WebRTC client34. For illustrative purposes,FIGS. 5A and 5Brefer to elements of the exemplary interactive communications system10ofFIG. 1.FIG. 5Adetails operations for establishing an interactive session in response to an inbound interaction request and/or an outbound interaction request.FIG. 5Billustrates operations for providing additional functionality including extracting content from, injecting content into, recording, and/or transforming the content of the WebRTC interactive flow18and/or the non-WebRTC interactive flow22.

InFIG. 5A, processing begins with the virtual WebRTC gateway16optionally determining whether the WebRTC client32is active (block156). As noted above with respect toFIG. 4, receiving an inbound interaction request to the WebRTC client32from the non-WebRTC client34may require that the virtual non-WebRTC agent54be instantiated when the WebRTC client32is active. Accordingly, if the WebRTC client32is determined to be active, the virtual WebRTC gateway16may instantiate a virtual non-WebRTC agent54corresponding to the non-WebRTC client34(block158). Processing then resumes at block160. However, if the WebRTC client32is determined to not be active at block156, processing returns to block156. It is to be understood that some embodiments of the virtual WebRTC gateway16may be configured to handle only outbound interaction requests from the WebRTC client32to the non-WebRTC client34. For such embodiments, the functionality of blocks156and158may be omitted.

The virtual WebRTC gateway16then determines whether a request for outbound or inbound interaction has been received (block160). In some embodiments, an outbound interaction request may include a SIP URI or SIP address for the non-WebRTC client34. Some embodiments may provide that an inbound interaction request includes a SIP URI or SIP address assigned to the WebRTC client32. If no outbound or inbound interaction request has been received by the virtual WebRTC gateway16, processing returns to block160.

If the virtual WebRTC gateway16determines at block160that an outbound interaction request has been received from the WebRTC client32, the virtual WebRTC gateway16instantiates a virtual non-WebRTC agent54corresponding to the non-WebRTC client34(block162). Processing then resumes at block164. If the virtual WebRTC gateway16determines at block160that an inbound interaction request has been received, processing proceeds directly to block164.

The virtual WebRTC gateway16optionally may determine a client type and/or a client version of the WebRTC client32based on a WebRTC offer/answer exchange, a query/response exchange between the virtual WebRTC gateway16and the WebRTC client32, or HTTP header data, or other data provided by the WebRTC client32(block164). This may enable the virtual WebRTC gateway16to instantiate a virtual WebRTC agent52having a client type and/or version corresponding to the client type and/or version of the WebRTC client32. Because the WebRTC client32directly communicates with a virtual WebRTC agent52of the same type and version, incompatibilities due to varying levels of support for WebRTC by the WebRTC client32may be resolved.

The virtual WebRTC gateway16then instantiates a virtual WebRTC agent52corresponding to the WebRTC client32(block166). In some embodiments, the virtual WebRTC gateway16may instantiate the virtual WebRTC agent52by launching an instance of a WebRTC client such as a web browser on the computing device14. Some embodiments may provide that the virtual WebRTC agent52is executed within a virtual instance of an operating system.

The virtual WebRTC gateway16then establishes a WebRTC interactive flow18between the virtual WebRTC agent52and the WebRTC client32(block168). The virtual WebRTC gateway16also establishes a non-WebRTC interactive flow22between the virtual non-WebRTC agent54and the non-WebRTC client34(block170). The virtual WebRTC gateway16next directs a content of the WebRTC interactive flow18to the non-WebRTC interactive flow22, and a content of the non-WebRTC interactive flow22to the WebRTC interactive flow18via the virtual WebRTC agent52and the virtual non-WebRTC agent54(block172). This results in a “back-to-back” connection between the virtual WebRTC agent52and the virtual non-WebRTC agent54. In some embodiments, this may be accomplished through the use of virtual audio receivers62,74and transmitters64,76, virtual video receivers66,78and transmitters68,80, and virtual data receivers70,82and transmitters72,84provided by the virtual WebRTC gateway16, as illustrated inFIG. 1. Processing then resumes at block174ofFIG. 5B.

Referring now toFIG. 5B, the virtual WebRTC gateway16at this point may access the contents of the WebRTC interactive flow18and the non-WebRTC interactive flow22, and may provide additional media processing and handling functionality. For example, in some embodiments, the virtual WebRTC gateway16may extract content from the WebRTC interactive flow18, the non-WebRTC interactive flow22, or a combination thereof (block174). Some embodiments may provide that the virtual WebRTC gateway16may inject content into the WebRTC interactive flow18, the non-WebRTC interactive flow22, or a combination thereof (block176). For example, the virtual WebRTC gateway16may insert additional audio, video, and/or data into the WebRTC interactive flow18and/or the non-WebRTC interactive flow22. According to some embodiments, the virtual WebRTC gateway16may record a content of the WebRTC interactive flow18, a content of the non-WebRTC interactive flow22, or a combination thereof (block178). In some embodiments, the virtual WebRTC gateway16may transform a content of the WebRTC interactive flow18, a content of the non-WebRTC interactive flow22, or a combination thereof (block180).

The virtual WebRTC gateway16then determines whether either of the WebRTC interactive flow18or the non-WebRTC interactive flow22has been terminated (block182). If both the WebRTC interactive flow18and the non-WebRTC interactive flow22are still active, processing returns to block174ofFIG. 5B. Otherwise, the virtual WebRTC gateway16terminates the remaining active WebRTC interactive flow18or non-WebRTC interactive flow22, as appropriate (block184).

FIG. 6provides a schematic diagram representation of a processing system186in the exemplary form of an exemplary computer system188adapted to execute instructions to perform the functions described herein. In some embodiments, the processing system186may execute instructions to perform the functions of the WebRTC application provider56and the virtual WebRTC gateway16ofFIG. 1. In this regard, the processing system186may comprise the computer system188, within which a set of instructions for causing the processing system186to perform any one or more of the methodologies discussed herein may be executed. The processing system186may be connected (as a non-limiting example, networked) to other machines in a local area network (LAN), an intranet, an extranet, or the Internet. The processing system186may operate in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. While only a single processing system186is illustrated, the terms “controller” and “server” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. The processing system186may be a server, a personal computer, a desktop computer, a laptop computer, a personal digital assistant (PDA), a computing pad, a mobile device, or any other device and may represent, as non-limiting examples, a server or a user's computer.

The exemplary computer system188includes a processing device or processor190, a main memory192(as non-limiting examples, read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM), etc.), and a static memory194(as non-limiting examples, flash memory, static random access memory (SRAM), etc.), which may communicate with each other via a bus196. Alternatively, the processing device190may be connected to the main memory192and/or the static memory194directly or via some other connectivity means.

The processing device190represents one or more processing devices, such as a microprocessor, a central processing unit (CPU), or the like. More particularly, the processing device190may be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a processor implementing other instruction sets, or a processor implementing a combination of instruction sets. The processing device190is configured to execute processing logic in instructions198and/or cached instructions200for performing the operations and steps discussed herein.

The computer system188may further include a communications interface in the form of a network interface device202. It also may or may not include an input204to receive input and selections to be communicated to the computer system188when executing the instructions198,200. It also may or may not include an output206, including but not limited to display(s)208. The display(s)208may be a video display unit (as non-limiting examples, a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device (as a non-limiting example, a keyboard), a cursor control device (as a non-limiting example, a mouse), and/or a touch screen device (as a non-limiting example, a tablet input device or screen).

The computer system188may or may not include a data storage device210that includes using drive(s)212to store the functions described herein in a computer-readable medium214, on which is stored one or more sets of instructions216(e.g., software) embodying any one or more of the methodologies or functions described herein. The functions can include the methods and/or other functions of the processing system186, a participant user device, and/or a licensing server, as non-limiting examples. The one or more sets of instructions216may also reside, completely or at least partially, within the main memory192and/or within the processing device190during execution thereof by the computer system188. The main memory192and the processing device190also constitute machine-accessible storage media. The instructions198,200, and/or216may further be transmitted or received over a network218via the network interface device202. The network218may be an intra-network or an inter-network.