Field of the Disclosure
The technology of the disclosure relates generally to Web Real-Time Communications (WebRTC) interactive sessions utilizing Session Initiation Protocol (SIP) signaling.
Technical Background
Web Real-Time Communications (WebRTC) is 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 Hyper Text 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, 2nd Edition (2013 Digital Codex LLC), which is incorporated in its entirety herein 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.
In a typical WebRTC exchange, two WebRTC clients retrieve WebRTC web applications, such as HTML5/JavaScript web applications, from a web application server. Through the web applications, the two WebRTC clients engage in an initiation dialogue for initiating a peer connection over which a WebRTC interactive flow (e.g., a real-time video, audio, and/or data exchange) will pass. This initiation dialogue may include a media negotiation used to communicate and reach an agreement on parameters that define characteristics of the WebRTC interactive flow. In some embodiments, the media negotiation may be implemented via a WebRTC offer/answer exchange (using, e.g., Session Description Protocol (SDP) objects) via a secure network connection such as a Hyper Text Transfer Protocol Secure (HTTPS) connection or a Secure WebSockets connection. Once the initiation dialogue is complete, the WebRTC clients may then establish a direct peer connection with one another, and may begin an exchange of media or data packets transporting real-time communications.
While WebRTC provides the media capabilities necessary for real-time communications, it does not specify a call signaling mechanism to be used for a WebRTC interactive flow. Accordingly, the responsibility for implementing call signaling for the WebRTC interactive flow falls to the WebRTC web application. One approach for call signaling is to employ a Session Initiation Protocol (SIP) user agent, implemented either at a WebRTC endpoint or at an intermediate web server. However, a SIP user agent implemented at a WebRTC endpoint may require the use of client-side scripting code that may be viewed and/or manipulated by an end user. As a result, intellectual property within the SIP user agent may be compromised, or the code constituting the SIP user agent may be manipulated for malicious purposes. A SIP user agent implemented at an intermediate web server may avoid these issues, but may introduce new challenges. For instance, the SIP user agent at the web server may need to constantly maintain a state of an ongoing WebRTC communication. This may violate the stateless nature of the web server, and may result in load-balancing and/or reliability problems for the web server.
Embodiments disclosed in the detailed description provide reliable Session Initiation Protocol (SIP) signaling for Web Real-Time Communications (WebRTC) interactive flows. Related methods, systems, and computer-readable media are also disclosed. In this regard, some embodiments disclosed herein provide a WebRTC client comprising a call state management agent working in conjunction with a stateless SIP user agent to provide reliable SIP signaling. The WebRTC client may establish a WebRTC interactive flow with a remote endpoint, using the stateless SIP user agent to handle call signaling. As the WebRTC interactive flow progresses, the stateless SIP user agent may generate a call state that encapsulates a current state of the WebRTC interactive flow. The call state management agent may receive the call state from the stateless SIP user agent, and may store the call state in a local persistent data store as a browser cookie or other local storage, and/or in a network persistent data store (i.e., in the “cloud”). Accordingly, in the event that the WebRTC client and/or the stateless SIP user agent is terminated, the call state management agent may provide the stored call state to the stateless SIP user agent (or to an alternate stateless SIP user agent). The stateless SIP user agent may then restore the WebRTC interactive flow based on the stored call state.
In this regard, in one embodiment, a method for providing reliable SIP signaling for WebRTC interactive flows is provided. The method comprises establishing, via a stateless SIP user agent executing on a first web server, a WebRTC interactive flow between a WebRTC client executing on a computing device and a remote endpoint. The method further comprises receiving, by the WebRTC client, a call state from the stateless SIP user agent, the call state indicating a current state of the WebRTC interactive flow. The method additionally comprises storing, by the WebRTC client, the call state. In this manner, the call state of the WebRTC interactive flow may be accessible for restoring the WebRTC interactive flow in the event of an unexpected termination of the WebRTC client and/or the stateless SIP user agent.
In another embodiment, a system for providing reliable SIP signaling for WebRTC interactive flows is provided. The system comprises at least one communications interface, and a first web server executing a stateless SIP user agent. The system further comprises a computing device associated with the at least one communications interface and communicatively coupled to the stateless SIP user agent, the computing device executing a WebRTC client comprising a call state management agent. The WebRTC client is configured to establish a WebRTC interactive flow with a remote endpoint via the stateless SIP user agent. The call state management agent is configured to receive a call state from the stateless SIP user agent, the call state indicating a current state of the WebRTC interactive flow. The call state management agent is further configured to store the call state.
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 establishing, via a stateless SIP user agent, a WebRTC interactive flow between a WebRTC client and a remote endpoint. The method implemented by the computer-executable instructions further comprises receiving, by the WebRTC client, a call state from the stateless SIP user agent, the call state indicating a current state of the WebRTC interactive flow. The method implemented by the computer-executable instructions additionally comprises storing, by the WebRTC client, the call state.
The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.
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 reliable Session Initiation Protocol (SIP) signaling for Web Real-Time Communications (WebRTC) interactive flows. Related methods, systems, and computer-readable media are also disclosed. In this regard, some embodiments disclosed herein provide a WebRTC client comprising a call state management agent working in conjunction with a stateless SIP user agent to provide reliable SIP signaling. The WebRTC client may establish a WebRTC interactive flow with a remote endpoint, using the stateless SIP user agent to handle call signaling. As the WebRTC interactive flow progresses, the stateless SIP user agent may generate a call state that encapsulates a current state of the WebRTC interactive flow. The call state management agent may receive the call state from the stateless SIP user agent, and may store the call state in a local persistent data store as a browser cookie or other local storage, and/or in a network persistent data store (i.e., in the “cloud”). Accordingly, in the event that the WebRTC client and/or the stateless SIP user agent is terminated, the call state management agent may provide the stored call state to the stateless SIP user agent (or to an alternate stateless SIP user agent). The stateless SIP user agent may then restore the WebRTC interactive flow based on the stored call state.
In this regard, in one embodiment, a method for providing reliable SIP signaling for WebRTC interactive flows is provided. The method comprises establishing, via a stateless SIP user agent executing on a first web server, a WebRTC interactive flow between a WebRTC client executing on a computing device and a remote endpoint. The method further comprises receiving, by the WebRTC client, a call state from the stateless SIP user agent, the call state indicating a current state of the WebRTC interactive flow. The method additionally comprises storing, by the WebRTC client, the call state. In this manner, the call state of the WebRTC interactive flow may be accessible for restoring the WebRTC interactive flow in the event of an unexpected termination of the WebRTC client and/or the stateless SIP user agent.
Before discussing details of the call state management agent 12 and the stateless SIP user agent 14, the establishment of a WebRTC interactive flow using SIP signaling in the communications system 10 of
The communications system 10 of
The WebRTC client 18, in the example of
In the example of
As seen in
Also provided by the first web server 38 is the stateless SIP user agent 14. The stateless SIP user agent 14 may be configured to receive a user agent (UA) instruction 44 from the WebRTC web application 42 for establishing or participating in a WebRTC interactive flow. In some embodiments, the UA instruction 44 may represent a high level abstraction of a call signaling request such as “make call,” “accept call,” or “drop call,” as non-limiting examples. The stateless SIP user agent 14 may map the UA instruction 44 into a SIP message(s) 46, which may be sent to the remote endpoint 32 via the SIP network 34. In some embodiments, the SIP message(s) 46 may include a Hyper Text Transfer Protocol (HTTP) session identifier to allow the stateless SIP user agent 14 to associate future SIP messages 46 received from the SIP network 34 with the WebRTC client 18. The stateless SIP user agent 14 may also map a SIP message(s) 46 received from the SIP network 34 into an event representing a high level abstraction of a call signaling event such as “new incoming call,” “call dropped,” or “call accepted,” as non-limiting examples. Such events may be used by the stateless SIP user agent 14 to maintain an awareness of a current state of a WebRTC interactive flow.
Some embodiments may also provide a second web server 48 executing an alternate stateless SIP user agent 50. The alternate stateless SIP user agent 50 may act as a backup for the stateless SIP user agent 14 in the event that the stateless SIP user agent 14 becomes unavailable. Accordingly, the alternate stateless SIP user agent 50 may receive UA instructions 52 from the scripting engine 26 of the WebRTC client 18, and may exchange SIP messages 54 with the remote endpoint 32 via the SIP network 34. In some embodiments, the first web server 38 and the second web server 48 may each be a single server, while some embodiments may provide that the first web server 38 and/or the second web server 48 comprise multiple servers that are communicatively coupled to each other. It is to be understood that the first web server 38 and/or the second web server 48 may reside within the same public or private network as the computing device 16 and/or the remote endpoint 32, or may be located within a separate, communicatively coupled public or private network.
In a typical WebRTC communications scenario wherein SIP signaling is provided by a SIP user agent executing on a web server, the web-based SIP user agent scenario may maintain a call state that indicates a current state of a WebRTC interactive flow. In other words, the SIP user agent is stateful. However, the use of such a SIP user agent is inconsistent with the stateless nature of a typical web server. Moreover, a stateful SIP user agent may present load-balancing and reliability issues. For example, in the event of a termination of the SIP user agent or the web server executing it (caused by, e.g., a web server crash), the current state of any ongoing WebRTC interactive flows may be lost, making restoration of the WebRTC interactive flows and/or corresponding SIP signaling difficult or impossible.
In this regard, the call state management agent 12 and the stateless SIP user agent 14 of
In some embodiments, the call state management agent 12 may store the call state 60 in the local persistent data store 22 as a browser cookie 62 or as other local storage, as indicated by bidirectional arrow 64. Some embodiments may provide that the call state management agent 12 may store the call state 60 in the network persistent data store 24 (i.e., “cloud” storage), as shown by bidirectional arrow 66. Storing the call state 60 on the network persistent data store 24 may permit the WebRTC interactive flow 56 to be restored using a different computing device than the computing device 16 with which the WebRTC interactive flow 56 was originally established. According to some embodiments described herein, the call state 60 may be stored in a serialized base64 text representation.
The stored call state 60 may be used to restore the WebRTC interactive flow 56 in the event of a termination (either unexpected or intentional) of the WebRTC client 18. After such a termination, the WebRTC client 18 may be restarted, and the call state management agent 12 may access the stored call state 60 from the local persistent data store 22 and/or the network persistent data store 24. The call state management agent 12 may then provide the stored call state 60 to the stateless SIP user agent 14. Because the stored call state 60 contains information regarding the last known state of the WebRTC interactive flow 56, the stateless SIP user agent 14 may restore the WebRTC interactive flow 56 between the WebRTC client 18 and the remote endpoint 32 based on the stored call state 60. In some embodiments wherein the call state 60 is stored in the network persistent data store 24, the WebRTC interactive flow 56 may be restored using a different computing device than the computing device 16 with which the WebRTC interactive flow 56 was originally established.
The stored call state 60 may be also be used to restore the WebRTC interactive flow 56 in the event of a termination of the stateless SIP user agent 14. After such a termination, the WebRTC client 18 may identify and contact the alternate stateless SIP user agent 50, based on load-balancing and/or web server failover techniques known in the art. The call state management agent 12 may then access the stored call state 60 from the local persistent data store 22 and/or the network persistent data store 24, and provide the stored call state 60 to the alternate stateless SIP user agent 50. As the stored call state 60 contains information regarding the last known state of the WebRTC interactive flow 56, the alternate stateless SIP user agent 50 may restore the WebRTC interactive flow 56 between the WebRTC client 18 and the remote endpoint 32 based on the stored call state 60. Once the WebRTC interactive flow 56 has been restored, the alternate stateless SIP user agent 50 may provide a call state 68 to the call state management agent 12 in the manner described above with respect to the stateless SIP user agent 14 and the call state 60.
To illustrate exemplary communications flows during an establishment of a WebRTC interactive flow between the WebRTC client 18 and the remote endpoint 32 via the stateless SIP user agent 14 of
In the example of
Upon receiving the MakeCall instruction, the stateless SIP user agent 14 sends a SIP INVITE message to the remote endpoint 32, as shown by arrow 72. The remote endpoint 32 responds with a SIP 180 RINGING message to the stateless SIP user agent 14, as indicated by arrow 74. The stateless SIP user agent 14 sends an Alerting event, accompanied by a call state, to the scripting engine 26 of the WebRTC client 18, as shown by arrow 76. As with the user agent instructions, the events sent by the stateless SIP user agent 14 to the WebRTC client 18 may be custom events specific to the WebRTC web application 42 and/or the stateless SIP user agent 14. Note that, at this point, because a WebRTC interactive flow has not yet been established, the call state may not be stored by the call state management agent 12. Once the remote endpoint 32 determines to participate in the WebRTC interactive flow, the remote endpoint 32 sends a SIP 200 OK message to the stateless SIP user agent 14, as indicated by arrow 78. The SIP 200 OK message is accompanied by an SDP object that represents an “answer,” and that indicates which of the offered media types and capabilities are supported and acceptable by the remote endpoint 32 for the WebRTC interactive flow.
After receiving the SIP 200 OK message, the stateless SIP user agent 14 sends an Answered event along with both the SDP object and a call state to the scripting engine 26, as indicated by arrow 80. The call state may include SIP dialog information, SIP transaction information, and/or an HTTP session identifier, as non-limiting examples. The stateless SIP user agent 14 sends a SIP ACK message to the remote endpoint 32 to acknowledge receipt of the SIP 200 OK message, as shown by arrow 82. The scripting engine 26 then passes the call state received from the stateless SIP user agent 14 to the call state management agent 12, as shown by arrow 84. The call state management agent 12 then stores the call state in the local persistent data store 22, as indicated by arrow 86. In some embodiments, the call state management agent 12 may store the call state in a “cloud” data store, such as the network persistent data store 24 of
The WebRTC functionality provider 28 and the remote endpoint 32 then proceed with establishing a WebRTC interactive flow with one another, as shown by bidirectional arrow 88. Establishment of the WebRTC interactive flow may include “hole punching” using protocols such as Interactive Connectivity Establishment (ICE) to determine the best way to establish direct communications between the WebRTC client 18 and the remote endpoint 32. Establishment of the WebRTC interactive flow may also include key negotiations to establish a secure peer connection between the WebRTC client 18 and the remote endpoint 32. As noted above with respect to
As discussed above, a stored call state may be used to restore a WebRTC interactive flow in the event that a WebRTC client is terminated (either unexpectedly by a crash of the WebRTC client, or intentionally by a user desiring to restore the WebRTC interactive flow using a different computing device). In this regard,
The exemplary communications flows illustrated by
The scripting engine 26 issues a RefreshCall instruction, accompanied by a WebRTC SDP object and the call state, to the stateless SIP user agent 14, as indicated by arrow 94. In some embodiments, the scripting engine 26 may automatically issue the RefreshCall instruction after determining, based on the call state, that a previous WebRTC interactive flow was terminated. The WebRTC SDP object that is sent with the RefreshCall instruction represents an “offer,” and specifies the media types and capabilities that the WebRTC client 18 supports and prefers for use in the restored WebRTC interactive flow.
Upon receiving the RefreshCall command, the WebRTC SDP object, and the call state, the stateless SIP user agent 14 sends a SIP RE-INVITE command to the remote endpoint 32 based on the call state, as shown by arrow 96. As noted above, the call state contains information regarding the last known state of the WebRTC interactive flow, and may comprise SIP dialog information, SIP transaction information, and/or an HTTP session identifier, as non-limiting examples. The remote endpoint 32 responds by sending a SIP 200 OK message to the stateless SIP user agent 14, as indicated by arrow 98. The SIP 200 OK message is accompanied by an SDP object that represents an “answer,” and that indicates which of the offered media types and capabilities are supported and acceptable by the remote endpoint 32 for the restored WebRTC interactive flow.
After receiving the SIP 200 OK message, the stateless SIP user agent 14 sends a Refreshed event along with the SDP object and a call state to the scripting engine 26, as indicated by arrow 100. The stateless SIP user agent 14 sends a SIP ACK message to the remote endpoint 32 to acknowledge receipt of the SIP 200 OK message, as shown by arrow 102. The scripting engine 26 then passes the call state received from the stateless SIP user agent 14 to the call state management agent 12, as indicated by arrow 104. The call state management agent 12 stores the call state in the local persistent data store 22, as shown by arrow 106. In some embodiments, the call state management agent 12 may store the call state in a “cloud” data store, such as the network persistent data store 24 of
The WebRTC functionality provider 28 and the remote endpoint 32 then restore a WebRTC interactive flow between one another (as shown by bidirectional arrow 108), including hole punching and key negotiations as necessary. As noted above with respect to
A stored call state may also be used to restore a WebRTC interactive flow in the event that a stateless SIP user agent is terminated. Accordingly,
The exemplary communications flows illustrated by
At this point, the WebRTC client 18 identifies the alternate stateless SIP user agent 50, using load-balancing and/or web server failover techniques known in the art, to contact in order to restore the WebRTC interactive flow. Upon identifying the alternate stateless SIP user agent 50, the scripting engine 26 issues a RefreshCall command, accompanied by a WebRTC SDP object and the call state, to the alternate stateless SIP user agent 50, as indicated by arrow 114. In some embodiments, the scripting engine 26 may automatically issue the RefreshCall command after determining, based on the call state, that a previous WebRTC interactive flow was terminated. The WebRTC SDP object that accompanies the RefreshCall command represents an “offer,” and specifies the media types and capabilities that the WebRTC client 18 supports and prefers for use in the restored WebRTC interactive flow.
Upon receiving the RefreshCall command, the WebRTC SDP object, and the call state, the alternate stateless SIP user agent 50 sends a SIP RE-INVITE command to the remote endpoint 32 based on the call state, as shown by arrow 116. In some embodiments, the call state contains information regarding the last known state of the WebRTC interactive flow, and may comprise SIP dialog information, SIP transaction information, and/or an HTTP session identifier, as non-limiting examples. The remote endpoint 32 responds with a SIP 200 OK message sent to the alternate stateless SIP user agent 50, as indicated by arrow 118. The SIP 200 OK message is accompanied by a WebRTC SDP object that represents an “answer,” and that indicates which of the offered media types and capabilities are supported and acceptable by the remote endpoint 32 for the restored WebRTC interactive flow.
After receiving the SIP 200 OK message, the alternate stateless SIP user agent 50 sends a Refreshed event along with the SDP object and a call state to the scripting engine 26, as indicated by arrow 120. The alternate stateless SIP user agent 50 sends a SIP ACK message to the remote endpoint 32 to acknowledge receipt of the SIP 200 OK message, as shown by arrow 122. The scripting engine 26 passes the call state to the call state management agent 12, as shown by arrow 124. The call state management agent 12 then stores the call state in the local persistent data store 22, as indicated by arrow 126. In some embodiments, the call state management agent 12 may store the call state in a “cloud” data store, such as the network persistent data store 24 of
The WebRTC functionality provider 28 and the remote endpoint 32 then restore a WebRTC interactive flow between one another (as shown by bidirectional arrow 128), including hole punching and key negotiations as necessary. As noted above with respect to
The WebRTC client 18 (in particular, the call state management agent 12) next receives a call state 60 from the stateless SIP user agent 14 (block 132). The call state 60 indicates a current state of the WebRTC interactive flow 56, and may comprise SIP dialog information, SIP transaction information, and/or an HTTP session identifier, as non-limiting examples. In some embodiments, the WebRTC client 18 receives a call state 60 from the stateless SIP user agent 14 with each occurrence of an event corresponding to a change in state of the WebRTC interactive flow 56.
The WebRTC client 18 then stores the call state 60 (block 134). Some embodiments may provide that the call state 60 is stored in the local persistent data store 22 as a browser cookie 62 accessible to the WebRTC client 18. In some embodiments, the WebRTC client 18 may store the call state 60 on a network persistent data store 24 instead of or in addition to storing the call state 60 on the local persistent data store 22. Storing the call state 60 on the network persistent data store 24 may permit the WebRTC interactive flow 56 to be restored using a different computing device than the computing device 16 with which the WebRTC interactive flow 56 was originally established.
In
If no call state 60 has been received, processing proceeds to block 140 of
With continuing reference to
The WebRTC client 18 next determines whether the WebRTC interactive flow 56 should be ended (block 154). As non-limiting examples, a user of the WebRTC client 18 may have indicated a desire to end the WebRTC interactive flow 56, or the call state management agent 12 may have received a call state 60 indicating that the remote endpoint 32 wishes to end the WebRTC interactive flow 56. If the WebRTC interactive flow 56 should be ended, the WebRTC client 18 closes any outstanding connections (block 156). If it is determined at block 154 that the WebRTC interactive flow 56 is ongoing, processing returns to block 138. Processing then continues in this loop defined by the flowchart of
As noted above with respect to block 140 of
The call state management agent 12 of the WebRTC client 18 then accesses the stored call state 60 (block 158). In some embodiments, accessing the stored call state 60 may comprise reading the call state 60 from the local persistent data store 22 and/or from the network persistent data store 24. The call state management agent 12 of the WebRTC client 18 next provides the stored call state 60 to the stateless SIP user agent 14 (block 160). Some embodiments may provide that the stored call state 60 is provided to the stateless SIP user agent 14 as part of an instruction such as a custom RefreshCall instruction.
Based on the stored call state 60 provided by the call state management agent 12, the stateless SIP user agent 14 restores the WebRTC interactive flow 56 between the WebRTC client 18 and the remote endpoint 32 via the stateless SIP user agent 14 (block 162). For example, the call state 60 may include SIP dialog information, SIP transaction information, and/or an HTTP session identifier that enables the stateless SIP user agent 14 to restore the WebRTC interactive flow 56. Upon the restoration of the WebRTC interactive flow 56, processing returns to block 138 of
If it was determined at decision block 150 of
The call state management agent 12 of the WebRTC client 18 then accesses the stored call state 60 (block 164). Some embodiments may provide that accessing the stored call state 60 may comprise reading the call state 60 from the local persistent data store 22 and/or from the network persistent data store 24. The call state management agent 12 of the WebRTC client 18 next provides the stored call state 60 to the alternate stateless SIP user agent 50 (block 166). Some embodiments may provide that the stored call state 60 is provided to the alternate stateless SIP user agent 50 as part of an instruction such as a custom RefreshCall instruction.
Based on the stored call state 60 provided by the call state management agent 12, the alternate stateless SIP user agent 50 restores the WebRTC interactive flow 56 between the WebRTC client 18 and the remote endpoint 32 via the alternate stateless SIP user agent 50 (block 168). For example, the call state 60 may include SIP dialog information, SIP transaction information, and/or an HTTP session identifier that enables the alternate stateless SIP user agent 50 to restore the WebRTC interactive flow 56. Upon the restoration of the WebRTC interactive flow 56, processing returns to block 138 of
The exemplary computer system 172 includes a processing device or processor 174, a main memory 176 (as non-limiting examples, read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM), etc.), and a static memory 178 (as non-limiting examples, flash memory, static random access memory (SRAM), etc.), which may communicate with each other via a bus 180. Alternatively, the processing device 174 may be connected to the main memory 176 and/or the static memory 178 directly or via some other connectivity means.
The processing device 174 represents one or more processing devices such as a microprocessor, central processing unit (CPU), or the like. More particularly, the processing device 174 may 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 processors implementing a combination of instruction sets. The processing device 174 is configured to execute processing logic in instructions 182 and/or cached instructions 184 for performing the operations and steps discussed herein.
The computer system 172 may further include a communications interface in the form of a network interface device 186. It also may or may not include an input 188 to receive input and selections to be communicated to the computer system 172 when executing the instructions 182, 184. It also may or may not include an output 190, including but not limited to display(s) 192. The display(s) 192 may 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 system 172 may or may not include a data storage device 194 that includes using drive(s) 196 to store the functions described herein in a computer-readable medium 198, on which is stored one or more sets of instructions 200 (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 system 170, a participant user device, and/or a licensing server, as non-limiting examples. The one or more sets of instructions 200 may also reside, completely or at least partially, within the main memory 176 and/or within the processing device 174 during execution thereof by the computer system 172. The main memory 176 and the processing device 174 also constitute machine-accessible storage media. The instructions 182, 184, and/or 200 may further be transmitted or received over a network 202 via the network interface device 186. The network 202 may be an intra-network or an inter-network.
While the computer-readable medium 198 is shown in an exemplary embodiment to be a single medium, the term “machine-accessible storage medium” should be taken to include a single medium or multiple media (as non-limiting examples, a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions 200. The term “machine-accessible storage medium” shall also be taken to include any medium that is capable of storing, encoding, or carrying a set of instructions for execution by the machine, and that cause the machine to perform any one or more of the methodologies disclosed herein. The term “machine-accessible storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals.
The embodiments disclosed herein may be embodied in hardware and in instructions that are stored in hardware, and may reside, as non-limiting examples, in Random Access Memory (RAM), flash memory, Read Only Memory (ROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), registers, a hard disk, a removable disk, a CD-ROM, or any other form of computer readable medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an Application Specific Integrated Circuit (ASIC). The ASIC may reside in a remote station. In the alternative, the processor and the storage medium may reside as discrete components in a remote station, base station, or server.
It is also noted that the operational steps described in any of the exemplary embodiments herein are described to provide examples and discussion. The operations described may be performed in numerous different sequences other than the illustrated sequences. Furthermore, operations described in a single operational step may actually be performed in a number of different steps. Additionally, one or more operational steps discussed in the exemplary embodiments may be combined. It is to be understood that the operational steps illustrated in the flow chart diagrams may be subject to numerous different modifications as will be readily apparent to one of skill in the art. Those of skill in the art would also understand that information and signals may be represented using any of a variety of different technologies and techniques. As non-limiting examples, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.
The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the spirit or scope of the disclosure. Thus, the disclosure is not intended to be limited to the examples and designs described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Number | Name | Date | Kind |
---|---|---|---|
6714967 | Horvitz | Mar 2004 | B1 |
7107316 | Brown et al. | Sep 2006 | B2 |
7145898 | Elliott | Dec 2006 | B1 |
7266591 | Johnston | Sep 2007 | B1 |
7379993 | Valdes et al. | May 2008 | B2 |
7636348 | Bettis et al. | Dec 2009 | B2 |
7661027 | Langen | Feb 2010 | B2 |
7730309 | Zimmermann | Jun 2010 | B2 |
8015484 | Backer | Sep 2011 | B2 |
8036360 | Gogineni | Oct 2011 | B1 |
8250635 | Chari et al. | Aug 2012 | B2 |
8300632 | Davis et al. | Oct 2012 | B2 |
8467308 | Johnston | Jun 2013 | B2 |
8494507 | Tedesco et al. | Jul 2013 | B1 |
8601144 | Ryner | Dec 2013 | B1 |
8605711 | Sinnreich et al. | Dec 2013 | B1 |
8606950 | Glatron et al. | Dec 2013 | B2 |
8693392 | Cooper et al. | Apr 2014 | B2 |
8695077 | Gerhard | Apr 2014 | B1 |
8737596 | Kelley et al. | May 2014 | B2 |
8744147 | Torti | Jun 2014 | B2 |
8832271 | McCarty | Sep 2014 | B2 |
8856236 | Moore et al. | Oct 2014 | B2 |
8861692 | Phelps et al. | Oct 2014 | B1 |
8867731 | Lum et al. | Oct 2014 | B2 |
9331967 | Gangadharan | May 2016 | B2 |
20020019846 | Miloslavsky | Feb 2002 | A1 |
20020161685 | Dwinnell | Oct 2002 | A1 |
20030112766 | Riedel et al. | Jun 2003 | A1 |
20030120599 | Agboatwalla et al. | Jun 2003 | A1 |
20030131245 | Linderman | Jul 2003 | A1 |
20030188193 | Venkataramappa | Oct 2003 | A1 |
20040019494 | Ridgeway et al. | Jan 2004 | A1 |
20040081173 | Feather | Apr 2004 | A1 |
20040093515 | Reeves, Jr. | May 2004 | A1 |
20040167984 | Herrmann | Aug 2004 | A1 |
20040216173 | Horoszowski et al. | Oct 2004 | A1 |
20050084082 | Horvitz et al. | Apr 2005 | A1 |
20050177380 | Pritchard et al. | Aug 2005 | A1 |
20050204148 | Mayo | Sep 2005 | A1 |
20060104526 | Gringeler et al. | May 2006 | A1 |
20060155814 | Bennett et al. | Jul 2006 | A1 |
20060159063 | Kumar | Jul 2006 | A1 |
20060200855 | Willis | Sep 2006 | A1 |
20060230438 | Shappir et al. | Oct 2006 | A1 |
20070083929 | Sprosts et al. | Apr 2007 | A1 |
20070143408 | Daigle | Jun 2007 | A1 |
20070255662 | Tumminaro | Nov 2007 | A1 |
20070283423 | Bradley et al. | Dec 2007 | A1 |
20080046414 | Haub et al. | Feb 2008 | A1 |
20080046457 | Haub et al. | Feb 2008 | A1 |
20080046838 | Haub et al. | Feb 2008 | A1 |
20080127137 | Becker et al. | May 2008 | A1 |
20080144804 | Mergen | Jun 2008 | A1 |
20080147551 | Connelly | Jun 2008 | A1 |
20080162642 | Bachiri et al. | Jul 2008 | A1 |
20080183991 | Cosmadopoulos | Jul 2008 | A1 |
20080189421 | Langen | Aug 2008 | A1 |
20080192646 | Song et al. | Aug 2008 | A1 |
20080270541 | Keener et al. | Oct 2008 | A1 |
20080282254 | Blander | Nov 2008 | A1 |
20080317233 | Rey | Dec 2008 | A1 |
20090070477 | Baum et al. | Mar 2009 | A1 |
20090094684 | Chinnusamy et al. | Apr 2009 | A1 |
20090217109 | Sekaran | Aug 2009 | A1 |
20090252159 | Lawson | Oct 2009 | A1 |
20090300060 | Beringer et al. | Dec 2009 | A1 |
20100011282 | Dollard et al. | Jan 2010 | A1 |
20100023519 | Kailash et al. | Jan 2010 | A1 |
20100024019 | Backlund | Jan 2010 | A1 |
20100037324 | Grant et al. | Feb 2010 | A1 |
20100118700 | Blum et al. | May 2010 | A1 |
20100150139 | Lawson | Jun 2010 | A1 |
20100246571 | Geppert et al. | Sep 2010 | A1 |
20110072144 | Fikouras | Mar 2011 | A1 |
20110078319 | Ishida | Mar 2011 | A1 |
20110081008 | Lawson | Apr 2011 | A1 |
20110099277 | Yao | Apr 2011 | A1 |
20110102930 | Johnston et al. | May 2011 | A1 |
20110176537 | Lawson | Jul 2011 | A1 |
20110206013 | Aramoto et al. | Aug 2011 | A1 |
20110238862 | Chaturvedi et al. | Sep 2011 | A1 |
20110283259 | Lawson | Nov 2011 | A1 |
20120001932 | Burnett et al. | Jan 2012 | A1 |
20120036180 | Thornton | Feb 2012 | A1 |
20120079031 | Matthews et al. | Mar 2012 | A1 |
20120137231 | Maxfield et al. | May 2012 | A1 |
20120158862 | Mosko et al. | Jun 2012 | A1 |
20120192086 | Ghods et al. | Jul 2012 | A1 |
20130002799 | Mock | Jan 2013 | A1 |
20130067102 | Paller | Mar 2013 | A1 |
20130078972 | Levien et al. | Mar 2013 | A1 |
20130091286 | Spencer | Apr 2013 | A1 |
20130128883 | Lawson | May 2013 | A1 |
20130138829 | Bulava | May 2013 | A1 |
20130163580 | Vass | Jun 2013 | A1 |
20130246563 | Cardozo | Sep 2013 | A1 |
20130297738 | Tarkoma | Nov 2013 | A1 |
20130321340 | Seo et al. | Dec 2013 | A1 |
20130325934 | Fausak et al. | Dec 2013 | A1 |
20130346329 | Alib-Bulatao et al. | Dec 2013 | A1 |
20140013202 | Schlumberger | Jan 2014 | A1 |
20140019626 | Hubler | Jan 2014 | A1 |
20140043994 | Bansal et al. | Feb 2014 | A1 |
20140064467 | Lawson | Mar 2014 | A1 |
20140095633 | Yoakum | Apr 2014 | A1 |
20140095724 | Yoakum et al. | Apr 2014 | A1 |
20140095731 | Carey et al. | Apr 2014 | A1 |
20140108594 | Siegel et al. | Apr 2014 | A1 |
20140126708 | Sayko | May 2014 | A1 |
20140126714 | Sayko | May 2014 | A1 |
20140126715 | Lum | May 2014 | A1 |
20140143823 | Manchester et al. | May 2014 | A1 |
20140149512 | Leitch | May 2014 | A1 |
20140161237 | Tolksdorf | Jun 2014 | A1 |
20140201820 | Li et al. | Jul 2014 | A1 |
20140219167 | Santhanam et al. | Aug 2014 | A1 |
20140222893 | Gangadharan | Aug 2014 | A1 |
20140222894 | Gangadharan | Aug 2014 | A1 |
20140222930 | Gangadharan | Aug 2014 | A1 |
20140222957 | Gangadharan | Aug 2014 | A1 |
20140222963 | Gangadharan | Aug 2014 | A1 |
20140223452 | Santhanam | Aug 2014 | A1 |
20140237057 | Khodorenko | Aug 2014 | A1 |
20140241215 | Massover et al. | Aug 2014 | A1 |
20140244235 | Michaelis | Aug 2014 | A1 |
20140245143 | Saint-Marc | Aug 2014 | A1 |
20140258822 | Li et al. | Sep 2014 | A1 |
20140269326 | Westin et al. | Sep 2014 | A1 |
20140270104 | O'Connor | Sep 2014 | A1 |
20140280734 | Chaturvedi et al. | Sep 2014 | A1 |
20140280995 | Ezell | Sep 2014 | A1 |
20140282054 | Yoakum | Sep 2014 | A1 |
20140282135 | Segre | Sep 2014 | A1 |
20140282399 | Gorelik et al. | Sep 2014 | A1 |
20140282765 | Casey et al. | Sep 2014 | A1 |
20140282903 | Singh | Sep 2014 | A1 |
20140324979 | Gao et al. | Oct 2014 | A1 |
20140325078 | Shan | Oct 2014 | A1 |
20140330976 | van Bemmel | Nov 2014 | A1 |
20140330977 | van Bemmel | Nov 2014 | A1 |
20140344169 | Phelps et al. | Nov 2014 | A1 |
20140348044 | Narayanan | Nov 2014 | A1 |
20140359004 | Zhou | Dec 2014 | A1 |
20140365676 | Yoakum | Dec 2014 | A1 |
20140379823 | Wilsher | Dec 2014 | A1 |
20140379931 | Gaviria | Dec 2014 | A1 |
20150002614 | Zino et al. | Jan 2015 | A1 |
20150002619 | Johnston et al. | Jan 2015 | A1 |
20150006610 | Johnston | Jan 2015 | A1 |
20150006611 | Johnston et al. | Jan 2015 | A1 |
20150006741 | Narayanan | Jan 2015 | A1 |
20150026473 | Johnston et al. | Jan 2015 | A1 |
20150036690 | Pastro | Feb 2015 | A1 |
20150039687 | Waxman et al. | Feb 2015 | A1 |
20150039760 | Yoakum | Feb 2015 | A1 |
20150052067 | Thiyagarajan et al. | Feb 2015 | A1 |
20150106528 | Somes | Apr 2015 | A1 |
20150180825 | Ren | Jun 2015 | A1 |
20150229635 | Saridaki | Aug 2015 | A1 |
Number | Date | Country |
---|---|---|
1615386 | Jan 2006 | EP |
2529316 | Dec 2012 | EP |
2295747 | Jun 1996 | GB |
2468758 | Sep 2010 | GB |
2468759 | Sep 2010 | GB |
2517833 | Mar 2015 | GB |
2002207683 | Jul 2002 | JP |
2002374318 | Dec 2002 | JP |
2005346556 | Dec 2005 | JP |
2006050407 | Feb 2006 | JP |
2011504665 | Feb 2011 | JP |
2014060008 | Apr 2014 | WO |
2014123738 | Aug 2014 | WO |
2014190094 | Nov 2014 | WO |
2015032277 | Mar 2015 | WO |
Entry |
---|
Barth, Adam. “HTTP state management mechanism.” (2011). |
Singh, Kundan, and Henning Schulzrinne. “Failover, load sharing and server architecture in SIP telephony.” Computer Communications 30.5 (2007): 927-942. |
Singh, Kundan Narendra. Reliable, scalable and interoperable internet telephony. Diss. Columbia University, 2006. |
Marwah, Manish, et al. “Efficient, scalable migration of IP telephony calls for enhanced fault-tolerance.” Proceedings. 14th International Conference on Computer Communications and Networks, 2005. ICCCN 2005.. IEEE, 2005. |
Johnston, Alan et al., “Taking on WebRTC in an Enterprise,” IEEE Communications Magazine, Apr. 2013, pp. 48-54, vol. 51, Issue 4. |
Search Report for British patent application GB1317121.0 mailed Mar. 14, 2014, 3 pages. |
Search Report for British patent application GB1317122.8 mailed Mar. 11, 2014, 3 pages. |
Singh, Kundan et al., “Building Communicating Web Applications Leveraging Endpoints and Cloud Resource Service,” Presented at the Sixth International Conference on Cloud Computing, Jun. 28, 2013, Santa Clara, California, IEEE Computer Society, pp. 486-493. |
Singh, Kundan et al., “Private Overlay of Enterprise Social Data and Interactions in the Public Web Context,” presented at the 9th IEEE International Conference on Collaborative Computing: Networking, Applications and Worksharing (Collaboratecom), Oct. 20-23, 2013, Austin, Texas, IEEE, 10 pages. |
Berners-Lee, Tim, “Socially Aware Cloud Storage,” Notes on web design, Aug. 17, 2009, http://www.w3.org/DesignIssues/CloudStorage.html, 9 pages. |
Chandra, Ramesh et al., “Separating Web Applications from User Data Storage with BStore,” presented at the USENIX Conference on Web Application Development, Jun. 2010, Boston, Massachusettes, 13 pages. |
Davids, Carol et al., “SIP APIs for Voice and Video Communications on the Web,” presented at the International Conference on Principles, Systems and Applications of IP Telecommunications (IPTcomm), Aug. 2011, Chicago, Illinois, 7 pages. |
Geambasu, Roxana et al., “Organizing and Sharing Distributed Personal Web-Service Data,” presented at the International World Wide Web Conference, Apr. 21-25, 2008, Beijing, China, International World Wide Web Conference Committee, pp. 755-764. |
Hsu, F. et al., “Secure File System Services for Web 2.0 Applications,” presented at the ACM Cloud Computing Security Workshop, Nov. 13, 2009, Chicago, Illinois, Association for Computing Machinery, 7 pages. |
Joshi, R., “Data-Oriented Architecture: A Loosley Coupled Real-Time SOA,” Whitepaper, Aug. 2007, Real-Time Innovations, Inc., http://rtcgroup.com/whitepapers/files/RTI—DataOrientedArchitecture—WhitePaper.pdf, 54 pages. |
Vahdat, Amin et al., “WebFS: A Global Cache Coherent File System,” UC Berkeley, Dec. 1996, retrieved Sep. 16, 2014 from https://www.cs.duke.edu/˜vandat/webfs/webfs.html, 12 pages. |
Non-Final Office Action for U.S. Appl. No. 14/037,440, mailed Sep. 12, 2014, 15 pages. |
Loreto, Salvatore et al., “Real-Time Communications in the Web: Issues, Achievements, and Ongoing Standardization Efforts,” IEEE Internet Computing, vol. 16, Issue 5, IEEE Computer Society, Oct. 2, 2012, pp. 68-73. |
Search Report for British patent application GB1411584.4 mailed Dec. 30, 2014, 4 pages. |
Search Report for British patent application GB1411580.2 mailed Dec. 30, 2014, 4 pages. |
Non-Final Office Action for U.S. Appl. No. 13/931,968, mailed Dec. 8, 2014, 6 pages. |
Non-Final Office Action for U.S. Appl. No. 13/835,913, mailed Nov. 20, 2014, 15 pages. |
Non-Final Office Action for U.S. Appl. No. 13/803,292, mailed Jan. 27, 2015, 13 pages. |
Non-Final Office Action for U.S. Appl. No. 14/050,891, mailed Jan. 29, 2015, 9 pages. |
Non-Final Office Action for U.S. Appl. No. 13/955,023, mailed Feb. 2, 2015, 12 pages. |
Notice of Allowance for U.S. Appl. No. 13/931,968, mailed Mar. 23, 2015, 7 pages. |
Final Office Action for U.S. Appl. No. 13/835,913, mailed Mar. 26, 2015, 17 pages. |
Final Office Action for U.S. Appl. No. 14/037,440, mailed Feb. 11, 2015, 19 pages. |
Non-Final Office Action for U.S. Appl. No. 14/068,839, mailed Feb. 20, 2015, 15 pages. |
Barth, A. “The Web Origin Concept,” Internet Engineering Task Force (IETF), Request for Comments 6454 (RFC 6454), Dec. 2011, 19 pages, http://www.ietf.org/rfc6454.txt. |
Fischl, J. et al., “Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS),” Internet Engineering Task Force (IETF), Request for Comments (RFC) 5763, May 2010, 26 pages. |
Jesup, R. et al., “DTLS Encapsulation of SCTP Packets for RTCWEB,” IETF: Network Working Group, Internet Draft, Feb. 16, 2013, 6 pages. |
Johnston, A. et al., “An Origin Attribute for the STUN Protocol,” Internet Engineering Task Force (IETF), Internet-Draft, Jul. 20, 2014, 14 pages, https://tools.ietf.org/html/draft-ietf-tram-stun-origin-00. |
Rescorla, E., “Security Considerations for RTC-Web,” IETF RTCWEB, Internet Draft, Jan. 22, 2013, 16 pages. |
Rescorla, E., “WebRTC Security Architecture,” IETF RTCWEB, Internet Draft, Jul. 14, 2013, 30 pages. |
Corrected Notice of Allowability for U.S. Appl. No. 13/931,968, mailed Apr. 24, 2015, 4 pages. |
Advisory Action for U.S. Appl. No. 14/037,440, mailed May 20, 2015, 3 pages. |
Search Report for British Patent Application GB1419338.7, mailed Apr. 27, 2015, 4 pages. |
Search Report for British Patent Application GB1419334.6, mailed Apr. 28, 2015, 6 pages. |
Notice of Allowance for U.S. Appl. No. 13/944,368, mailed Apr. 1, 2015, 8 pages. |
Non-Final Office Action for U.S. Appl. No. 13/931,967, mailed May 5, 2015, 10 pages. |
Non-Final Office Action for U.S. Appl. No. 13/931,970, mailed May 7, 2015, 9 pages. |
Bergkvist, Adam et al., “WebRTC 1.0: Real-time Communication Between Browsers,” W3C Working Draft, Feb. 9, 2012, http://www.w3.org)TR/2012/WD-webrtc-20120209/, 42 pages. |
Notice of Reason for Refusal for Japanese Patent Application 2013-201228, dispatched Jun. 11, 2015, 8 pages. |
Advisory Action for U.S. Appl. No. 13/835,913, mailed Jun. 10, 2015, 3 pages. |
Final Office Action for U.S. Appl. No. 13/803,292, mailed Jun. 12, 2015, 17 pages. |
Final Office Action and Examiner Initiated Interview Summary for U.S. Appl. No. 14/050,891, mailed Jun. 29, 2015, 11 pages. |
Final Office Action for U.S. Appl. No. 13/955,023, mailed Jul. 20, 2015, 17 pages. |
Corrected Notice of Allowability for U.S. Appl. No. 13/944,368, mailed Jul. 23, 2015, 4 pages. |
Non-Final Office Action for U.S. Appl. No. 14/141,798, mailed Jul. 17, 2015, 13 pages. |
Extended European Search Report for European Patent Application 15161452.6, mailed Jun. 23, 2015, 5 pages. |
Rodriguez, Pedro et al., “Advanced Videoconferencing Services Based on WebRTC,” IADIS International Conferences Web Based Communities and Social Media 2012 and Collaborative Technologies 2012, Jul. 17-23, 2012, pp. 180-184, http://www.iadisportal.org/wbc-2012-proceedings. |
Examination Report for British Patent Application GB1411584.4, mailed Aug. 21, 2015, 1 page. |
Examination Report for British Patent Application GB1411580.2, mailed Aug. 21, 2015, 1 page. |
Notification of Reasons for Refusal for Japanese Patent Application 2013-201221, mailed Aug. 25, 2015, 8 pages. |
Non-Final Office Action for U.S. Appl. No. 13/835,913, mailed Sep. 3, 2015, 19 pages. |
Non-Final Office Action for U.S. Appl. No. 13/912,520, mailed Sep. 9, 2015, 21 pages. |
Non-Final Office Action for U.S. Appl. No. 13/863,662, mailed Sep. 25, 2015, 23 pages. |
Advisory Action for U.S. Appl. No. 13/803,292, mailed Aug. 21, 2015, 3 pages. |
Non-Final Office Action for U.S. Appl. No. 13/803,292, mailed Oct. 9, 2015, 13 pages. |
Advisory Action and Examiner-Initiated Interview Summary for U.S. Appl. No. 14/050,891, mailed Sep. 29, 2015, 4 pages. |
Final Office Action for U.S. Appl. No. 14/068,839, mailed Sep. 9, 2015, 17 pages. |
Final Office Action for U.S. Appl. No. 13/931,967, mailed Aug. 20, 2015, 12 pages. |
Final Office Action for U.S. Appl. No. 13/931,970, mailed Aug. 27, 2015, 10 pages. |
Non-Final Office Action for U.S. Appl. No. 13/955,711, mailed Nov. 9, 2015, 10 pages. |
Notice of Allowance for U.S. Appl. No. 14/050,891, mailed Nov. 10, 2015, 10 pages. |
Non-Final Office Action for U.S. Appl. No. 13/955,023, mailed Dec. 9, 2015, 13 pages. |
Non-Final Office Action for U.S. Appl. No. 14/037,440, mailed Oct. 22, 2015, 15 pages. |
Advisory Action for U.S Appl. No. 13/931,967, mailed Nov. 3, 2015, 3 pages. |
Advisory Action for U.S Appl. No. 13/931,970, mailed Nov. 5, 2015, 3 pages. |
Non-Final Office Action for U.S. Appl. No. 14/068,943, mailed Dec. 2, 2015, 16 pages. |
Non-Final Office Action for U.S. Appl. No. 14/255,429, mailed Nov. 9, 2015, 26 pages. |
Search Report for British Patent Application No. GB1423089.0, mailed Jul. 6, 2015, 4 pages. |
Author Unknown, “WebRTC,” WebRTC.org, Date Accessed: Jan. 26, 2016, 4 pages, http://webrtc.org/. |
Notice of Allowance for U.S. Appl. No. 13/863,662, mailed Feb. 1, 2016, 17 pages. |
Advisory Action and Examiner-Initiated Interview Summary for U.S. Appl. No. 14/068,839, mailed Feb. 12, 2016, 4 pages. |
Final Office Action for U.S. Appl. No. 14/141,798, mailed Dec. 24, 2015, 10 pages. |
Non-Final Office Action for U.S. Appl. No. 14/174,371, mailed Feb. 18, 2016, 18 pages. |
Non-Final Office Action for U.S. Appl. No. 13/931,970, mailed Feb. 23, 2016, 11 pages. |
Andreasen et al., “Session Description Protocol (SDP): Security Descriptions for Media Streams,” Network Working Group, Request for Comments: 4568, Standards Track, The Internet Society, Jul. 2006, 40 pages. |
Baugher et al., “The Secure Real-time Transport Protocol (SRTP),” Network Working Group, Request for Comments: 3711, Standards Track, The Internet Society, Mar. 2004, 51 pages. |
Johnston et al., “WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web,” (Book), Second Edition, Smashwords Edition, Digital Codex LLC, Jun. 2013, 254 pages. |
Many et al., “Traversal Using Relays around NAT (TURN) : Relay Extensions to Session Traversal Utilities for NAT (STUN),” Internet Engineering Task Force, Request for Comments: 5766, Standards Track, IETF Trust, Apr. 2010, 61 pages. |
McGrew et al., “Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-Time Transport Protocol (SRTP),” Internet Engineering Task Force, Request for Comments: 5764, Standards Track, IETF Trust, May 2010, 24 pages. |
Zimmermann et al., “ZRTP: Media Path Key Agreement for Unicast Secure RTP,” Internet Engineering Task Force, Request for Comments: 6189, Informational, IETF Trust, Apr. 2011, 102 pages. |
Number | Date | Country | |
---|---|---|---|
20150127709 A1 | May 2015 | US |