US20140150075A1 - Securely establishing ice relay connections - Google Patents
Securely establishing ice relay connections Download PDFInfo
- Publication number
- US20140150075A1 US20140150075A1 US14/093,973 US201314093973A US2014150075A1 US 20140150075 A1 US20140150075 A1 US 20140150075A1 US 201314093973 A US201314093973 A US 201314093973A US 2014150075 A1 US2014150075 A1 US 2014150075A1
- Authority
- US
- United States
- Prior art keywords
- client device
- ice
- relay
- border controller
- session border
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/45—Structures or tools for the administration of authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/30—Profiles
- H04L67/306—User profiles
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/256—NAT traversal
- H04L61/2575—NAT traversal using address mapping retrieval, e.g. simple traversal of user datagram protocol through session traversal utilities for NAT [STUN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/256—NAT traversal
- H04L61/2589—NAT traversal over a relay server, e.g. traversal using relay for network address translation [TURN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes
Definitions
- This application relates generally to methods and apparatuses, including computer program products, for automatically creating Interactive Connectivity Establishment (ICE) relay candidates and securely establishing ICE relay connections without using Traversal Using Relays around NAT (TURN).
- ICE Interactive Connectivity Establishment
- TURN Traversal Using Relays around NAT
- IP Internet Protocol
- a web browser can establish an IP-based HTTPS session with a website for the purpose of retrieving information.
- a device can establish a Session Initiation Protocol (SIP) session with another computing device to, e.g., conduct a phone call.
- SIP Session Initiation Protocol
- Web browsers have recently begun adopting the Web Real-Time Communication (WebRTC) protocol for the purpose of establishing real-time audio and video sessions between browser clients.
- WebRTC Web Real-Time Communication
- the WebRTC protocol as defined by the IETF relies on the ICE (RFC 5245) methods for establishing a direct communication link between the two clients.
- ICE ICE 5245
- the only means for a successful communication link is through the use of a media relay server placed out in the network.
- ICE defines that media relay server to be a TURN server running the TURN protocol (RFC 5766).
- the TURN protocol however is susceptible to many types of attacks such as theft of service and distributed denial of service.
- the ICE protocol is designed to allow two client devices to automatically discover the best way to send voice and video media streams across an IP network.
- Certain network topologies such as those using Firewall/NATs can prevent the devices from directly communicating due to the way in which some Firewall/NATs create and enforce IP address and port access.
- the NAT function automatically maps an external IP address and port to every outbound message stream the client produces.
- the procedures of ICE allow the client to learn what IP address and port the NAT has assigned. When a client decides to initiate a real-time session, the client must first determine which IP address and port combinations are available for the purpose of establishing a media connection with another client. These IP and port combinations are called “candidates” in the terminology of ICE.
- a client begins its candidate discovery by sending a STUN (RFC 5389) binding request to a STUN server somewhere out in the network.
- the STUN server responds to the client binding request and provides the IP address and port information of where the STUN server saw the binding request originate from. If the client is behind a Firewall/NAT, the STUN server sees the external IP address and port that the NAT assigned to this outbound message transmission. This is called the Server Reflexive candidate.
- FIG. 1 depicts a system for establishing a media connection using a TURN service.
- the system 100 includes a website application server 102 that is connected to a plurality of client computing devices (e.g., Client A 108 , Client B 110 ) via Firewall/NAT devices 106 a , 106 b respectively.
- the system also includes a TURN server 104 that is also connected to the client devices 108 , 110 via the Firewall/NAT devices 106 a , 106 b.
- the website application server 102 hands the TURN service credentials to Client A 108 when Client A initiates a call request (e.g., a SIP INVITE, a WebRTC call request) by clicking on a web page link, for example.
- Client A 108 then issues the necessary resource allocation messages to the TURN server 104 using the TURN protocol.
- the allocation response from the TURN server 104 contains the ICE Relay candidate, referred to as (r1) in FIG. 1 , to Client A 108 .
- the port (t1) is the TURN service port and not the Relay candidate.
- the client device then creates a Session Description Protocol (SDP) of its possible media candidates.
- SDP Session Description Protocol
- Client A 108 creates an SDP containing the Host candidate (a1), the Server Reflexive candidate (a2), and the Relay candidate (r1).
- the SDP is then passed up to the website application server 102 using the mechanisms of the media protocol (e.g., WebRTC, SIP).
- the website application server 102 uses the media protocol to send the SDP of Client A 108 down to Client B 110 .
- Client B 110 then initiates its own candidate discovery using STUN.
- Client B 110 does not attempt a TURN reservation because client B sees that Client A 108 has already offered a Relay candidate and only one relay candidate is needed per media stream.
- Client B 110 creates its SDP using the Host candidate (b1) and the Server Reflexive candidate (b2).
- the SDP is handed up to the website application server 102 using the media protocol and the website application server 102 delivers the SDP to Client A 108 .
- Both Client A 108 and Client B 110 now have the other client's SDP and the STUN connectivity checks begin.
- ICE defines the priority of the various permutations that arise when each client systematically tries to communicate between candidates.
- Client A 108 for instance, attempts to send a STUN message from its Host candidate to Client B's ( 110 ) Host candidate (a1-b1). If Client A 108 does not see a response, then Client A tries to send a STUN connectivity message to the Server Reflexive candidate of Client B 110 and make the attempt occur between (a2-b2), as shown in FIG. 1 .
- Client B 110 performs STUN connectivity checks towards Client A's ( 108 ) candidates. If the Host and Reflexive candidates do not succeed, then Client B 110 sends a STUN connectivity check to the Relay candidate (r1).
- the TURN server 104 then encapsulates the request inside a TURN header and forwards the encapsulated request to Client A 108 using the established TURN binding (a2-t1). Because Client A 108 created that TURN binding, Client A receives the encapsulated STUN connectivity message and responds using the reverse path (a2-t1-r1-b2). Client B 110 then successfully receives the connectivity response and both clients 108 , 110 decide to use that connection for the media stream. This entire process must happen for each media stream. For example, a call using audio and video will have to perform the above process twice before exchanging audio and video data.
- the TURN server 104 shown in FIG. 1 is susceptible to attack due to a few of its basic design characteristics.
- the systems and methods described herein allow for a session border controller (SBC) or a Web Session Border Controller (WebSBCTM) server to be used in place of a TURN server such that the media relay function is not subject to the service-affecting attacks of TURN.
- SBC session border controller
- WebSBCTM Web Session Border Controller
- the WebSBC server available from Sansay, Inc. of San Diego, Calif., differs from a TURN server fundamentally by only allowing resource allocations to occur directly from the website application server.
- ICE deployments that rely on TURN servers initiate resource allocations directly from the client which result in the inherent security problems.
- the WebSBC server with its direct interface to the website application server, allows for secure media relay allocations to occur outside of the client's direct involvement or knowledge.
- the WebSBC server allocation information is provided to the website application server application for the purpose of manipulating the media relay binding description, also called the Session Description Protocol (SDP) (see RFC 4566) by adding the allocated relay candidate to the client-provided SDP.
- SDP Session Description Protocol
- the WebSBC server performs the media relay function securely and effectively, without using the TURN protocol.
- the invention features a method for securely connecting a plurality of ICE client devices without using TURN.
- a session border controller receives, via a website application server, a connectivity message from a first ICE client device at a first relay port located on the session border controller, where the session border controller and the website application server are connected by an allocation link.
- the session border controller receives a connectivity message from a second ICE client device at a second relay port located on the session border controller.
- the session border controller authenticates the connectivity messages using credential information received from the website application server.
- the session border controller latches address information associated with the first ICE client device to the first relay port.
- the session border controller latches address information associated with the second ICE client device to the second relay port.
- the session border controller forwards the connectivity message from the first ICE client device to the second ICE client device.
- the session border controller forwards the connectivity message from the second ICE client device to the first ICE client device.
- An ICE relay connection is established indirectly between the first ICE client device and the second ICE client device via the relay ports located on the session border controller.
- the invention in another aspect, features, a system for securely allocating ICE relay candidates without using TURN.
- the system includes a website application server computing device comprising a CPU coupled to a memory and to one or more communication interface ports, and a session border controller coupled to the website application server device via an allocation link.
- the session border controller is configured to receive, via the website application server computing device, a connectivity message from a first ICE client device at a first relay port located on the session border controller.
- the session border controller is configured to receive a connectivity message from a second ICE client device at a second relay port located on the session border controller.
- the session border controller is configured to authenticate the connectivity messages using credential information received from the website application server computing device.
- the session border controller is configured to latch address information associated with the first ICE client device to the first relay port.
- the session border controller is configured to latch address information associated with the second ICE client device to the second relay port.
- the session border controller is configured to forward the connectivity message from the first ICE client device to the second ICE client device.
- the session border controller is configured to forward the connectivity message from the second ICE client device to the first ICE client device.
- the session border controller is configured to establish an ICE relay connection indirectly between the first ICE client device and the second ICE client device via the relay ports located on the session border controller.
- the invention in another aspect, features a computer program product, tangibly embodied in a non-transitory computer readable medium, for securely allocating ICE relay candidates without using TURN.
- the computer program product includes instructions operable to cause a session border controller coupled to a website application server device via an allocation link to receive, via the website application server computing device, a connectivity message from a first ICE client device at a first relay port located on the session border controller.
- the computer program product includes instructions operable to cause the session border controller to receive a connectivity message from a second ICE client device at a second relay port located on the session border controller.
- the computer program product includes instructions operable to cause the session border controller to authenticate the connectivity messages using credential information received from the website application server computing device.
- the computer program product includes instructions operable to cause the session border controller to latch address information associated with the first ICE client device to the first relay port.
- the computer program product includes instructions operable to cause the session border controller to latch address information associated with the second ICE client device to the second relay port.
- the computer program product includes instructions operable to cause the session border controller to forward the connectivity message from the first ICE client device to the second ICE client device.
- the computer program product includes instructions operable to cause the session border controller to forward the connectivity message from the second ICE client device to the first ICE client device.
- the computer program product includes instructions operable to cause the session border controller to establish an ICE relay connection indirectly between the first ICE client device and the second ICE client device via the relay ports located on the session border controller.
- the invention in another aspect, features a method for securely allocating ICE relay candidates without using TURN.
- a first ICE client device receives a request to initiate a media session with a second ICE client device.
- the first ICE client device transmits a STUN binding request to a website application server.
- the first ICE client device receives an ICE relay candidate from the website application server in response to the STUN binding request.
- the first ICE client device generates an ICE relay binding description, the binding description including the ICE relay candidate.
- the first ICE client device transmits the ICE relay binding description to the website application server.
- the first ICE client device receives a modified ICE relay binding description including one or more ICE relay candidates associated with the second ICE client device and one or more relay ports located on a session border controller coupled to the website application server.
- An ICE relay connection is established based on the modified ICE relay binding description, where the ICE relay connection is established (i) directly between the first ICE client device and the second ICE client device via the ICE relay candidates associated with the first and second ICE client devices or (ii) indirectly via relay ports located on the session border controller when the ICE relay connection cannot be established directly between the first ICE client device and second ICE client device.
- the ICE relay connection uses the Web Real-Time Communication (WebRTC) protocol.
- the session border controller is a WebSBC server.
- the session border controller performs a Datagram Transport Layer Security-Secure Real-Time Protocol (DTLS-SRTP) handshake with the first ICE client device to establish a first SRTP key, performs a DTLS-SRTP handshake with the second ICE client device to establish a second SRTP key, decrypts packets received from the first ICE client device using the first SRTP key, and encrypts the received packets using the second SRTP key and transmitting the encrypted packets to the second ICE client device.
- the session border controller replicates the decrypted packets and stores the replicated packets. In some embodiments, the replicated packets are stored for call recording purposes.
- the connectivity message from the first ICE client device includes the address information associated with the first ICE client device and the connectivity message from the second ICE client device includes the address information associated with the second ICE client device.
- the address information associated with the first ICE client device represents a new IP address and port number generated by the first ICE client device upon transmitting the connectivity message to the session border controller.
- the address information associated with the second ICE client device represents a new IP address and port number generated by the second ICE client device upon transmitting the connectivity message to the session border controller.
- the ICE relay candidates associated with the first ICE client device include a server reflexive address associated with a Network Address Translation (NAT) device coupled between the first ICE client device and the website application server.
- the ICE relay candidates associated with the second ICE client device include a server reflexive address associated with a Network Address Translation (NAT) device coupled between the second ICE client device and the website application server.
- NAT Network Address Translation
- the step of establishing an ICE relay connection includes transmitting, by the first ICE client device, a connectivity message to a first one of the relay ports on the session border controller, transmitting, by the second ICE client device, a connectivity message to a second one of the relay ports on the session border controller, authenticating, by the session border controller, the connectivity messages using credential information received from the website application server via the allocation link, latching, by the session border controller, address information associated with the first ICE client device to the first one of the relay ports, latching, by the session border controller, address information associated with the second ICE client device to the second one of the relay ports, forwarding, by the session border controller, the connectivity message from the first ICE client device to the second ICE client device, and forwarding, by the session border controller, the connectivity message from the second ICE client device to the first ICE client device.
- the connectivity message from the first ICE client device includes the address information associated with the first ICE client device and the connectivity message from the second ICE client device includes the address
- FIG. 1 is a block diagram of a system using a TURN model with media allocations performed by the ICE clients, as illustrated in the art.
- FIG. 2 is a block diagram of a system for securely allocating media relay candidates without using TURN.
- FIG. 3 is a flow diagram of a method for securely allocating media relay candidates without using TURN.
- FIG. 4 is a block diagram of a system using a WebSBC server model showing the ICE relay candidates for STUN and WebSBC server, with Firewall/Network Address Translation (NAT) devices.
- NAT Firewall/Network Address Translation
- FIG. 5 is a block diagram of a system for securely allocating media relay candidates without using TURN, the system having WebSockets connections between client devices and the website application server.
- FIG. 6 is a block diagram of a system for securely allocating media relay candidates without using TURN, the system using a SIP session border controller model.
- FIG. 2 is a block diagram of a system for securely allocating media relay candidates without using TURN.
- a successful media relay can be allocated much more securely and with less complexity.
- the clients do not need any modification from the standard ICE procedures.
- the system 200 only utilizes the STUN capabilities of the ICE clients.
- the system 200 includes a website application server 202 that is connected to a plurality of client computing devices (e.g., Client A 208 , Client B 210 ) via Firewall/NAT devices 206 a , 206 b respectively.
- client computing devices e.g., Client A 208 , Client B 210
- Firewall/NAT devices 206 a , 206 b Example client devices can include, but are not limited to, personal computers, tablets, mobile computing devices, smart phones, and the like.
- the system also includes a WebSBC server 204 that is also connected to the client devices 208 , 210 via the Firewall/NAT devices 206 a , 206 b.
- the system 200 requires an Allocation Protocol link to be established between the website application server 202 and the WebSBC server 204 .
- This link should use a secure protocol API such as Representational State Transfer (REST) over HTTP/HTTPS, but other secure protocols can be used as well.
- REST Representational State Transfer
- the link can be initiated by either the website application server 202 or the WebSBC server 204 based on preconfigured addresses. The link is expected to stay up for the duration of service and can provide for multiple client allocations over the common interface.
- FIG. 3 is a flow diagram of a method 300 for securely allocating media relay candidates without using TURN using the system 200 of FIG. 2
- FIG. 4 illustrates the Firewall/NAT and WebRTC/STUN candidates used in the system 200 of FIG. 2 .
- Client A 208 When Client A 208 is told to initiate a media session (e.g., from the user at Client A clicking on a button/link on the website page), Client A 208 sends a STUN binding request to the STUN server (encapsulated in the WebSBC server 204 ) in order to determine its ICE relay candidates.
- STUN server encapsulated in the WebSBC server 204
- the STUN messages are transmitted over UDP (User Datagram Protocol), but the STUN messages can also be transmitted via RTP, DTLS-SRTP (Datagram Transport Layer Security-Secure Real-time Transport Protocol), or other similar protocols without departing from the scope of the invention. Also, as shown in FIG. 2 , the STUN messages share the same network connection as SRTP.
- UDP User Datagram Protocol
- DTLS-SRTP Datagram Transport Layer Security-Secure Real-time Transport Protocol
- the binding request sent by Client A 208 results in the Server Reflexive address (a2) being created.
- Client A 208 then constructs its media relay binding description (also called SDP) using the candidates (a1) and (a2) and passes the media relay binding description up to the website application server 202 via WebSockets or HTTP.
- the website application server 202 receives ( 302 ) the media relay binding description that includes the ICE relay candidates associated with Client A 208 .
- the website application server 202 determines ( 304 ) a subscription profile associated with Client A 208 .
- the website application server 202 decides, based on the subscription profile, to create ( 306 ) an allocation link (denoted by the Allocation Protocol link in FIG. 2 ) to a session border controller (e.g., the WebSBC server 204 ).
- the website application server 202 can send a REST command instructing the WebSBC server 204 to allocate a set of media relay ports.
- a STUN server is encapsulated in the WebSBC server 204 .
- the STUN server can share the Denial of Service (DOS) protection and blocking capabilities as well as the redundancy schemes of the WebSBC server 204 .
- DOS Denial of Service
- the systems described herein are not limited to such an embodiment, however, as the STUN server and the WebSBC server can be deployed as separate nodes in the network without changing the behavior of the system 200 .
- the WebSBC server 204 then allocates two relay ports (r1) and (r2) and returns those candidates to the website application server 202 in an Allocation Protocol response.
- the website application server 202 modifies ( 308 ) the media relay binding description by adding the relay candidate (r2) to Client A's (a1) and (a2) candidates, and transmits ( 310 ) the media relay binding description down to Client B 210 .
- Client B responds by transmitting its two ICE relay candidates (b1) and (b2) to the website application server 202 , and the website application server receives ( 312 ) the two ICE relay candidates from Client B 210 .
- the website application server 202 modifies the media relay binding description to add Relay candidate (r1) to the (b1) and (b2) candidates from Client B 210 .
- the website application server 202 transmits ( 314 ) the media relay binding description, including the relay candidate (r1), to Client A 208 .
- a media relay connection is established ( 316 ) between Client A 208 and Client B 210 based on the media relay binding description, via the relay ports (r1) and (r2) located on the WebSBC server 204 .
- the result of this network-based Relay candidate allocation is that Client A 208 is told to try to connect with Client B 210 using (b1), (b2), and (r1) candidates. Client B 210 subsequently tries to connect using (a1), (a2), and (r2) candidates. If the Host and Reflexive candidates are not able to communicate directly, then both clients 208 , 210 begin sending STUN connectivity messages to the relay candidates (r1) and (r2). The act of sending those messages creates two new Firewall/NAT bindings (a3) and (b3).
- the WebSBC server 204 in FIG. 4 then auto-learns the IP and port binding that occurred when the STUN connectivity messages were received over its (r1) and (r2) relay ports.
- the website application server 202 also shares the STUN short-term credentials, provided in the SDP, to the WebSBC server 204 within the Allocation Protocol so that the WebSBC server 204 can perform STUN authentication before latching the bindings (a3-r1) and (b3-r2).
- Client A 208 happens to attempt a connectivity check to the relay candidate (r1) before Client B 210 does its check to (r2).
- the WebSBC server 204 verifies that Client A 208 actually sent the connectivity message by performing the STUN short-term credential check using the information provided in Allocation Protocol request. If the authentication check passes, the WebSBC server 204 binds the (r1) relay port to the source IP and port (a3) of Client A's message.
- the WebSBC server 204 can either store that STUN message and deliver it to Client B 210 at a later time or the WebSBC server 204 can discard the message, relying on the fact that Client B's attempt should cause a retransmit from Client A 208 .
- Client B 210 attempts a connectivity check to port (r2) and it is verified and latched, the WebSBC server 204 forwards it to the other latched connection on port (r1). From this point on, the two clients 208 , 210 have a secure and authenticated path to complete the STUN connectivity handshake and can begin sending the media streams over the ports (a3-r1-r2-b3), as shown in FIG. 4 .
- the WebSBC server 204 then has provided a network relay service without the same vulnerabilities as TURN. For example, in the WebSBC server model:
- FIG. 5 is a block diagram of a system for securely allocating media relay candidates without using TURN, the system having WebSockets connections between client devices and the website application server.
- the system 500 includes the same components as the system 200 in FIG. 2 , with the added feature of WebSockets connections (e.g., connection 502 , connection 504 ) between the client devices 208 , 210 and the website application server 202 .
- the WebSockets connections 502 , 504 enable full-duplex, low overhead, bidirectional communication between the website application server 202 and the respective clients 208 , 210 —providing a solution to reduce latency and unnecessary traffic that is scalable for large applications.
- the system 500 uses the WebSockets connections for transmitting SIP call control messages, but it should be understood that any protocol can be transmitted using the WebSockets connections to implement a variety of applications—such as real-time messaging, games, social media, and the like.
- FIG. 6 is a block diagram of a system 600 for securely allocating media relay candidates without using TURN, the system using a SIP SBC model.
- the system 600 includes a SIP SBC 602 that is connected via a communications network to client devices 608 , 610 through Firewall/NAT devices 606 a , 606 b respectively.
- the system 600 uses the same ICE relay candidate creation techniques as described above with respect to FIGS. 2-4 .
- the SIP SBC 602 receives a media relay binding description from Client A 608 that includes the ICE relay candidates associated with Client A.
- the SIP SBC 602 allocates relay ports and modifies the media relay binding description to include the relay ports in addition to the ICE relay candidates from Client A 608 .
- the SIP SBC 602 transmits the modified binding description to Client B 610 , and Client B responds by sending its two ICE relay candidates back to the SIP SBC 602 .
- the SIP SBC 602 modifies the media relay binding description to add the (b1) and (b2) candidates from Client B 210 .
- the SIP SBC 602 transmits the media relay binding description, including the relay ports, to Client A 608 .
- a SIP connection is established between Client A 608 and Client B 610 based on the media relay binding description, via the relay ports located on the SIP SBC 602 .
- the following section provides additional detail on the attributes of the allocation protocol used by the system 200 in FIG. 2 over the allocation link between the website application server 202 and the WebSBC server 204 .
- the attributes include:
- Website application server modified SDP as sent to Client A:
- the above-described techniques can be implemented in digital and/or analog electronic circuitry, or in computer hardware, firmware, software, or in combinations of them.
- the implementation can be as a computer program product, i.e., a computer program tangibly embodied in a machine-readable storage device, for execution by, or to control the operation of, a data processing apparatus, e.g., a programmable processor, a computer, and/or multiple computers.
- a computer program can be written in any form of computer or programming language, including source code, compiled code, interpreted code and/or machine code, and the computer program can be deployed in any form, including as a stand-alone program or as a subroutine, element, or other unit suitable for use in a computing environment.
- a computer program can be deployed to be executed on one computer or on multiple computers at one or more sites.
- Method steps can be performed by one or more processors executing a computer program to perform functions by operating on input data and/or generating output data. Method steps can also be performed by, and an apparatus can be implemented as, special purpose logic circuitry, e.g., a FPGA (field programmable gate array), a FPAA (field-programmable analog array), a CPLD (complex programmable logic device), a PSoC (Programmable System-on-Chip), ASIP (application-specific instruction-set processor), or an ASIC (application-specific integrated circuit), or the like.
- Subroutines can refer to portions of the stored computer program and/or the processor, and/or the special circuitry that implement one or more functions.
- processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital or analog computer.
- a processor receives instructions and data from a read-only memory or a random access memory or both.
- the essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and/or data.
- Memory devices such as a cache, can be used to temporarily store data. Memory devices can also be used for long-term data storage.
- a computer also includes, or is operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks.
- a computer can also be operatively coupled to a communications network in order to receive instructions and/or data from the network and/or to transfer instructions and/or data to the network.
- Computer-readable storage mediums suitable for embodying computer program instructions and data include all forms of volatile and non-volatile memory, including by way of example semiconductor memory devices, e.g., DRAM, SRAM, EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and optical disks, e.g., CD, DVD, HD-DVD, and Blu-ray disks.
- the processor and the memory can be supplemented by and/or incorporated in special purpose logic circuitry.
- the above described techniques can be implemented on a computer in communication with a display device, e.g., a CRT (cathode ray tube), plasma, or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse, a trackball, a touchpad, or a motion sensor, by which the user can provide input to the computer (e.g., interact with a user interface element).
- a display device e.g., a CRT (cathode ray tube), plasma, or LCD (liquid crystal display) monitor
- a keyboard and a pointing device e.g., a mouse, a trackball, a touchpad, or a motion sensor, by which the user can provide input to the computer (e.g., interact with a user interface element).
- feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, and/or tactile input.
- feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback
- input from the user can be received in any form, including acoustic, speech, and/or tactile input.
- the above described techniques can be implemented in a distributed computing system that includes a back-end component.
- the back-end component can, for example, be a data server, a middleware component, and/or an application server.
- the above described techniques can be implemented in a distributed computing system that includes a front-end component.
- the front-end component can, for example, be a client computer having a graphical user interface, a Web browser through which a user can interact with an example implementation, and/or other graphical user interfaces for a transmitting device.
- the above described techniques can be implemented in a distributed computing system that includes any combination of such back-end, middleware, or front-end components.
- Transmission medium can include any form or medium of digital or analog data communication (e.g., a communication network).
- Transmission medium can include one or more packet-based networks and/or one or more circuit-based networks in any configuration.
- Packet-based networks can include, for example, the Internet, a carrier internet protocol (IP) network (e.g., local area network (LAN), wide area network (WAN), campus area network (CAN), metropolitan area network (MAN), home area network (HAN)), a private IP network, an IP private branch exchange (IPBX), a wireless network (e.g., radio access network (RAN), Bluetooth, Wi-Fi, WiMAX, general packet radio service (GPRS) network, HiperLAN), and/or other packet-based networks.
- IP carrier internet protocol
- RAN radio access network
- GPRS general packet radio service
- HiperLAN HiperLAN
- Circuit-based networks can include, for example, the public switched telephone network (PSTN), a legacy private branch exchange (PBX), a wireless network (e.g., RAN, code-division multiple access (CDMA) network, time division multiple access (TDMA) network, global system for mobile communications (GSM) network), and/or other circuit-based networks.
- PSTN public switched telephone network
- PBX legacy private branch exchange
- CDMA code-division multiple access
- TDMA time division multiple access
- GSM global system for mobile communications
- Communication protocols can include, for example, Ethernet protocol, Internet Protocol (IP), Voice over IP (VoIP), a Peer-to-Peer (P2P) protocol, Hypertext Transfer Protocol (HTTP), Session Initiation Protocol (SIP), H.323, Media Gateway Control Protocol (MGCP), Signaling System #7 (SS7), a Global System for Mobile Communications (GSM) protocol, a Push-to-Talk (PTT) protocol, a PTT over Cellular (POC) protocol, Universal Mobile Telecommunications System (UMTS), 3GPP Long Term Evolution (LTE) and/or other communication protocols.
- IP Internet Protocol
- VoIP Voice over IP
- P2P Peer-to-Peer
- HTTP Hypertext Transfer Protocol
- SIP Session Initiation Protocol
- H.323 H.323
- MGCP Media Gateway Control Protocol
- SS7 Signaling System #7
- GSM Global System for Mobile Communications
- PTT Push-to-Talk
- POC PTT over Cellular
- UMTS Universal
- Devices of the computing system can include, for example, a computer, a computer with a browser device, a telephone, an IP phone, a mobile device (e.g., cellular phone, personal digital assistant (PDA) device, smart phone, tablet, laptop computer, electronic mail device), and/or other communication devices.
- the browser device includes, for example, a computer (e.g., desktop computer and/or laptop computer) with a World Wide Web browser (e.g., ChromeTM from Google, Inc., Microsoft® Internet Explorer® available from Microsoft Corporation, and/or Mozilla® Firefox available from Mozilla Corporation).
- Mobile computing device include, for example, a Blackberry® from Research in Motion, an iPhone® from Apple Corporation, and/or an AndroidTM-based device.
- IP phones include, for example, a Cisco® Unified IP Phone 7985G and/or a Cisco® Unified Wireless Phone 7920 available from Cisco Systems, Inc.
- Comprise, include, and/or plural forms of each are open ended and include the listed parts and can include additional parts that are not listed. And/or is open ended and includes one or more of the listed parts and combinations of the listed parts.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Multimedia (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
- This application is a continuation of U.S. patent application Ser. No. 13/827,793, filed on Mar. 14, 2013, which claims priority to U.S. Provisional Patent Application No. 61/730,345, filed on Nov. 27, 2012, the contents of which are incorporated herein in their entirety.
- This application relates generally to methods and apparatuses, including computer program products, for automatically creating Interactive Connectivity Establishment (ICE) relay candidates and securely establishing ICE relay connections without using Traversal Using Relays around NAT (TURN).
- An Internet Protocol (IP) session involves the connection between two devices across a network of routers, cables, and switches for the purpose of exchanging packets of information. For example, a web browser can establish an IP-based HTTPS session with a website for the purpose of retrieving information. In another example, a device can establish a Session Initiation Protocol (SIP) session with another computing device to, e.g., conduct a phone call.
- Web browsers have recently begun adopting the Web Real-Time Communication (WebRTC) protocol for the purpose of establishing real-time audio and video sessions between browser clients. The WebRTC protocol as defined by the IETF relies on the ICE (RFC 5245) methods for establishing a direct communication link between the two clients. Under certain network topologies, the only means for a successful communication link is through the use of a media relay server placed out in the network.
- For both SIP and WebRTC sessions, ICE defines that media relay server to be a TURN server running the TURN protocol (RFC 5766). The TURN protocol however is susceptible to many types of attacks such as theft of service and distributed denial of service.
- The ICE protocol is designed to allow two client devices to automatically discover the best way to send voice and video media streams across an IP network. Certain network topologies such as those using Firewall/NATs can prevent the devices from directly communicating due to the way in which some Firewall/NATs create and enforce IP address and port access. The NAT function automatically maps an external IP address and port to every outbound message stream the client produces. The procedures of ICE allow the client to learn what IP address and port the NAT has assigned. When a client decides to initiate a real-time session, the client must first determine which IP address and port combinations are available for the purpose of establishing a media connection with another client. These IP and port combinations are called “candidates” in the terminology of ICE.
- In the simplest model, a client begins its candidate discovery by sending a STUN (RFC 5389) binding request to a STUN server somewhere out in the network. The STUN server responds to the client binding request and provides the IP address and port information of where the STUN server saw the binding request originate from. If the client is behind a Firewall/NAT, the STUN server sees the external IP address and port that the NAT assigned to this outbound message transmission. This is called the Server Reflexive candidate.
- According to ICE, a client in need of a network media relay issues a TURN allocation request using a procedure similar to STUN. In addition to providing the Server Reflexive candidate, the TURN request asks the TURN server to allocate a media relay port for the client to use.
FIG. 1 depicts a system for establishing a media connection using a TURN service. Thesystem 100 includes awebsite application server 102 that is connected to a plurality of client computing devices (e.g.,Client A 108, Client B 110) via Firewall/NAT devices 106 a, 106 b respectively. The system also includes a TURNserver 104 that is also connected to theclient devices NAT devices 106 a, 106 b. - The
website application server 102 hands the TURN service credentials toClient A 108 when Client A initiates a call request (e.g., a SIP INVITE, a WebRTC call request) by clicking on a web page link, for example.Client A 108 then issues the necessary resource allocation messages to the TURNserver 104 using the TURN protocol. The allocation response from the TURNserver 104 contains the ICE Relay candidate, referred to as (r1) inFIG. 1 , toClient A 108. Note that the port (t1) is the TURN service port and not the Relay candidate. - In the TURN model, the client device then creates a Session Description Protocol (SDP) of its possible media candidates. In
FIG. 1 ,Client A 108 creates an SDP containing the Host candidate (a1), the Server Reflexive candidate (a2), and the Relay candidate (r1). The SDP is then passed up to thewebsite application server 102 using the mechanisms of the media protocol (e.g., WebRTC, SIP). Thewebsite application server 102 then uses the media protocol to send the SDP ofClient A 108 down toClient B 110.Client B 110 then initiates its own candidate discovery using STUN.Client B 110 does not attempt a TURN reservation because client B sees thatClient A 108 has already offered a Relay candidate and only one relay candidate is needed per media stream. - After the STUN binding exchange,
Client B 110 creates its SDP using the Host candidate (b1) and the Server Reflexive candidate (b2). The SDP is handed up to thewebsite application server 102 using the media protocol and thewebsite application server 102 delivers the SDP toClient A 108. BothClient A 108 andClient B 110 now have the other client's SDP and the STUN connectivity checks begin. ICE defines the priority of the various permutations that arise when each client systematically tries to communicate between candidates.Client A 108, for instance, attempts to send a STUN message from its Host candidate to Client B's (110) Host candidate (a1-b1). IfClient A 108 does not see a response, then Client A tries to send a STUN connectivity message to the Server Reflexive candidate ofClient B 110 and make the attempt occur between (a2-b2), as shown inFIG. 1 . - At the same time,
Client B 110 performs STUN connectivity checks towards Client A's (108) candidates. If the Host and Reflexive candidates do not succeed, thenClient B 110 sends a STUN connectivity check to the Relay candidate (r1). TheTURN server 104 then encapsulates the request inside a TURN header and forwards the encapsulated request toClient A 108 using the established TURN binding (a2-t1). BecauseClient A 108 created that TURN binding, Client A receives the encapsulated STUN connectivity message and responds using the reverse path (a2-t1-r1-b2).Client B 110 then successfully receives the connectivity response and bothclients - The
TURN server 104 shown inFIG. 1 is susceptible to attack due to a few of its basic design characteristics. -
- 1) The client (e.g., Client B 110) is given the authentication credentials needed by the
TURN server 104 in order to “securely” make the Relay candidate reservation. A compromised client can easily learn the credentials and can use them for other purposes such as using the TURN server for a completely different website, thus stealing service from the original website. - 2) The
TURN server 104 is forced to accept reservation requests from anywhere in the network and must attempt to verify the sender's legitimacy by performing a computation on the provided credentials. This can create a denial of service condition if the TURN server gets flooded with these requests. - 3) The
TURN server 104 must use the same port interface for its TURN reservations and the resulting media flows. The media must flow over the same binding that created the relay reservation in order to successfully traverse the Firewall/NAT (e.g., Firewall/NAT 106 a, 106 b). That is why the TURN protocol requires the media flows to be encapsulated inside a TURN packet so that theTURN server 104 can distinguish the difference between the control and media packets.
- 1) The client (e.g., Client B 110) is given the authentication credentials needed by the
- The systems and methods described herein allow for a session border controller (SBC) or a Web Session Border Controller (WebSBC™) server to be used in place of a TURN server such that the media relay function is not subject to the service-affecting attacks of TURN. The WebSBC server, available from Sansay, Inc. of San Diego, Calif., differs from a TURN server fundamentally by only allowing resource allocations to occur directly from the website application server. In contrast, ICE deployments that rely on TURN servers initiate resource allocations directly from the client which result in the inherent security problems.
- The WebSBC server, with its direct interface to the website application server, allows for secure media relay allocations to occur outside of the client's direct involvement or knowledge. The WebSBC server allocation information is provided to the website application server application for the purpose of manipulating the media relay binding description, also called the Session Description Protocol (SDP) (see RFC 4566) by adding the allocated relay candidate to the client-provided SDP. The SDP that is exchanged between the clients, through the website application server, therefore offers a pre-allocated media relay candidate that the clients naturally use according to the procedures of ICE. The WebSBC server performs the media relay function securely and effectively, without using the TURN protocol.
- The invention, in one aspect, features a method for securely connecting a plurality of ICE client devices without using TURN. A session border controller receives, via a website application server, a connectivity message from a first ICE client device at a first relay port located on the session border controller, where the session border controller and the website application server are connected by an allocation link. The session border controller receives a connectivity message from a second ICE client device at a second relay port located on the session border controller. The session border controller authenticates the connectivity messages using credential information received from the website application server. The session border controller latches address information associated with the first ICE client device to the first relay port. The session border controller latches address information associated with the second ICE client device to the second relay port. The session border controller forwards the connectivity message from the first ICE client device to the second ICE client device. The session border controller forwards the connectivity message from the second ICE client device to the first ICE client device. An ICE relay connection is established indirectly between the first ICE client device and the second ICE client device via the relay ports located on the session border controller.
- The invention, in another aspect, features, a system for securely allocating ICE relay candidates without using TURN. The system includes a website application server computing device comprising a CPU coupled to a memory and to one or more communication interface ports, and a session border controller coupled to the website application server device via an allocation link. The session border controller is configured to receive, via the website application server computing device, a connectivity message from a first ICE client device at a first relay port located on the session border controller. The session border controller is configured to receive a connectivity message from a second ICE client device at a second relay port located on the session border controller. The session border controller is configured to authenticate the connectivity messages using credential information received from the website application server computing device. The session border controller is configured to latch address information associated with the first ICE client device to the first relay port. The session border controller is configured to latch address information associated with the second ICE client device to the second relay port. The session border controller is configured to forward the connectivity message from the first ICE client device to the second ICE client device. The session border controller is configured to forward the connectivity message from the second ICE client device to the first ICE client device. The session border controller is configured to establish an ICE relay connection indirectly between the first ICE client device and the second ICE client device via the relay ports located on the session border controller.
- The invention, in another aspect, features a computer program product, tangibly embodied in a non-transitory computer readable medium, for securely allocating ICE relay candidates without using TURN. The computer program product includes instructions operable to cause a session border controller coupled to a website application server device via an allocation link to receive, via the website application server computing device, a connectivity message from a first ICE client device at a first relay port located on the session border controller. The computer program product includes instructions operable to cause the session border controller to receive a connectivity message from a second ICE client device at a second relay port located on the session border controller. The computer program product includes instructions operable to cause the session border controller to authenticate the connectivity messages using credential information received from the website application server computing device. The computer program product includes instructions operable to cause the session border controller to latch address information associated with the first ICE client device to the first relay port. The computer program product includes instructions operable to cause the session border controller to latch address information associated with the second ICE client device to the second relay port. The computer program product includes instructions operable to cause the session border controller to forward the connectivity message from the first ICE client device to the second ICE client device. The computer program product includes instructions operable to cause the session border controller to forward the connectivity message from the second ICE client device to the first ICE client device. The computer program product includes instructions operable to cause the session border controller to establish an ICE relay connection indirectly between the first ICE client device and the second ICE client device via the relay ports located on the session border controller.
- The invention, in another aspect, features a method for securely allocating ICE relay candidates without using TURN. A first ICE client device receives a request to initiate a media session with a second ICE client device. The first ICE client device transmits a STUN binding request to a website application server. The first ICE client device receives an ICE relay candidate from the website application server in response to the STUN binding request. The first ICE client device generates an ICE relay binding description, the binding description including the ICE relay candidate. The first ICE client device transmits the ICE relay binding description to the website application server. The first ICE client device receives a modified ICE relay binding description including one or more ICE relay candidates associated with the second ICE client device and one or more relay ports located on a session border controller coupled to the website application server. An ICE relay connection is established based on the modified ICE relay binding description, where the ICE relay connection is established (i) directly between the first ICE client device and the second ICE client device via the ICE relay candidates associated with the first and second ICE client devices or (ii) indirectly via relay ports located on the session border controller when the ICE relay connection cannot be established directly between the first ICE client device and second ICE client device.
- Any of the above aspects can include one or more of the following features. In some embodiments, the ICE relay connection uses the Web Real-Time Communication (WebRTC) protocol. In some embodiments, the session border controller is a WebSBC server.
- In some embodiments, the session border controller performs a Datagram Transport Layer Security-Secure Real-Time Protocol (DTLS-SRTP) handshake with the first ICE client device to establish a first SRTP key, performs a DTLS-SRTP handshake with the second ICE client device to establish a second SRTP key, decrypts packets received from the first ICE client device using the first SRTP key, and encrypts the received packets using the second SRTP key and transmitting the encrypted packets to the second ICE client device. In some embodiments, the session border controller replicates the decrypted packets and stores the replicated packets. In some embodiments, the replicated packets are stored for call recording purposes.
- In some embodiments, the connectivity message from the first ICE client device includes the address information associated with the first ICE client device and the connectivity message from the second ICE client device includes the address information associated with the second ICE client device. In some embodiments, the address information associated with the first ICE client device represents a new IP address and port number generated by the first ICE client device upon transmitting the connectivity message to the session border controller. In some embodiments, the address information associated with the second ICE client device represents a new IP address and port number generated by the second ICE client device upon transmitting the connectivity message to the session border controller.
- In some embodiments, the ICE relay candidates associated with the first ICE client device include a server reflexive address associated with a Network Address Translation (NAT) device coupled between the first ICE client device and the website application server. In some embodiments, the ICE relay candidates associated with the second ICE client device include a server reflexive address associated with a Network Address Translation (NAT) device coupled between the second ICE client device and the website application server.
- In some embodiments, the step of establishing an ICE relay connection includes transmitting, by the first ICE client device, a connectivity message to a first one of the relay ports on the session border controller, transmitting, by the second ICE client device, a connectivity message to a second one of the relay ports on the session border controller, authenticating, by the session border controller, the connectivity messages using credential information received from the website application server via the allocation link, latching, by the session border controller, address information associated with the first ICE client device to the first one of the relay ports, latching, by the session border controller, address information associated with the second ICE client device to the second one of the relay ports, forwarding, by the session border controller, the connectivity message from the first ICE client device to the second ICE client device, and forwarding, by the session border controller, the connectivity message from the second ICE client device to the first ICE client device. In some embodiments, the connectivity message from the first ICE client device includes the address information associated with the first ICE client device and the connectivity message from the second ICE client device includes the address information associated with the second ICE client device.
- Other aspects and advantages of the technology will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating the principles of the technology by way of example only.
- The advantages of the technology described above, together with further advantages, may be better understood by referring to the following description taken in conjunction with the accompanying drawings. The drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the technology.
-
FIG. 1 is a block diagram of a system using a TURN model with media allocations performed by the ICE clients, as illustrated in the art. -
FIG. 2 is a block diagram of a system for securely allocating media relay candidates without using TURN. -
FIG. 3 is a flow diagram of a method for securely allocating media relay candidates without using TURN. -
FIG. 4 is a block diagram of a system using a WebSBC server model showing the ICE relay candidates for STUN and WebSBC server, with Firewall/Network Address Translation (NAT) devices. -
FIG. 5 is a block diagram of a system for securely allocating media relay candidates without using TURN, the system having WebSockets connections between client devices and the website application server. -
FIG. 6 is a block diagram of a system for securely allocating media relay candidates without using TURN, the system using a SIP session border controller model. - The systems and methods described herein do not require a TURN server or TURN protocol to be run by the clients.
FIG. 2 is a block diagram of a system for securely allocating media relay candidates without using TURN. By using thesystem 200, a successful media relay can be allocated much more securely and with less complexity. Also, the clients do not need any modification from the standard ICE procedures. Thesystem 200 only utilizes the STUN capabilities of the ICE clients. - The
system 200 includes awebsite application server 202 that is connected to a plurality of client computing devices (e.g.,Client A 208, Client B 210) via Firewall/NAT devices WebSBC server 204 that is also connected to theclient devices NAT devices - The
system 200 requires an Allocation Protocol link to be established between thewebsite application server 202 and theWebSBC server 204. This link should use a secure protocol API such as Representational State Transfer (REST) over HTTP/HTTPS, but other secure protocols can be used as well. The link can be initiated by either thewebsite application server 202 or theWebSBC server 204 based on preconfigured addresses. The link is expected to stay up for the duration of service and can provide for multiple client allocations over the common interface. -
FIG. 3 is a flow diagram of amethod 300 for securely allocating media relay candidates without using TURN using thesystem 200 ofFIG. 2 , andFIG. 4 illustrates the Firewall/NAT and WebRTC/STUN candidates used in thesystem 200 ofFIG. 2 . WhenClient A 208 is told to initiate a media session (e.g., from the user at Client A clicking on a button/link on the website page),Client A 208 sends a STUN binding request to the STUN server (encapsulated in the WebSBC server 204) in order to determine its ICE relay candidates. In one embodiment, the STUN messages are transmitted over UDP (User Datagram Protocol), but the STUN messages can also be transmitted via RTP, DTLS-SRTP (Datagram Transport Layer Security-Secure Real-time Transport Protocol), or other similar protocols without departing from the scope of the invention. Also, as shown inFIG. 2 , the STUN messages share the same network connection as SRTP. - The binding request sent by
Client A 208 results in the Server Reflexive address (a2) being created.Client A 208 then constructs its media relay binding description (also called SDP) using the candidates (a1) and (a2) and passes the media relay binding description up to thewebsite application server 202 via WebSockets or HTTP. Thewebsite application server 202 receives (302) the media relay binding description that includes the ICE relay candidates associated withClient A 208. - The
website application server 202 then determines (304) a subscription profile associated withClient A 208. Thewebsite application server 202 decides, based on the subscription profile, to create (306) an allocation link (denoted by the Allocation Protocol link inFIG. 2 ) to a session border controller (e.g., the WebSBC server 204). Thewebsite application server 202 can send a REST command instructing theWebSBC server 204 to allocate a set of media relay ports. As shown inFIG. 4 , a STUN server is encapsulated in theWebSBC server 204. By encapsulating the STUN server inside theWebSBC server 204, the STUN server can share the Denial of Service (DOS) protection and blocking capabilities as well as the redundancy schemes of theWebSBC server 204. The systems described herein are not limited to such an embodiment, however, as the STUN server and the WebSBC server can be deployed as separate nodes in the network without changing the behavior of thesystem 200. - The
WebSBC server 204 then allocates two relay ports (r1) and (r2) and returns those candidates to thewebsite application server 202 in an Allocation Protocol response. Thewebsite application server 202 then modifies (308) the media relay binding description by adding the relay candidate (r2) to Client A's (a1) and (a2) candidates, and transmits (310) the media relay binding description down toClient B 210. Client B responds by transmitting its two ICE relay candidates (b1) and (b2) to thewebsite application server 202, and the website application server receives (312) the two ICE relay candidates fromClient B 210. Thewebsite application server 202 then modifies the media relay binding description to add Relay candidate (r1) to the (b1) and (b2) candidates fromClient B 210. Thewebsite application server 202 transmits (314) the media relay binding description, including the relay candidate (r1), toClient A 208. A media relay connection is established (316) betweenClient A 208 andClient B 210 based on the media relay binding description, via the relay ports (r1) and (r2) located on theWebSBC server 204. - The result of this network-based Relay candidate allocation is that
Client A 208 is told to try to connect withClient B 210 using (b1), (b2), and (r1) candidates.Client B 210 subsequently tries to connect using (a1), (a2), and (r2) candidates. If the Host and Reflexive candidates are not able to communicate directly, then bothclients - The
WebSBC server 204 inFIG. 4 then auto-learns the IP and port binding that occurred when the STUN connectivity messages were received over its (r1) and (r2) relay ports. Thewebsite application server 202 also shares the STUN short-term credentials, provided in the SDP, to theWebSBC server 204 within the Allocation Protocol so that theWebSBC server 204 can perform STUN authentication before latching the bindings (a3-r1) and (b3-r2). - For example, assume
Client A 208 happens to attempt a connectivity check to the relay candidate (r1) beforeClient B 210 does its check to (r2). TheWebSBC server 204 verifies thatClient A 208 actually sent the connectivity message by performing the STUN short-term credential check using the information provided in Allocation Protocol request. If the authentication check passes, theWebSBC server 204 binds the (r1) relay port to the source IP and port (a3) of Client A's message. TheWebSBC server 204 can either store that STUN message and deliver it toClient B 210 at a later time or theWebSBC server 204 can discard the message, relying on the fact that Client B's attempt should cause a retransmit fromClient A 208. OnceClient B 210 attempts a connectivity check to port (r2) and it is verified and latched, theWebSBC server 204 forwards it to the other latched connection on port (r1). From this point on, the twoclients FIG. 4 . TheWebSBC server 204 then has provided a network relay service without the same vulnerabilities as TURN. For example, in the WebSBC server model: -
- 1) The client is never given reservation credentials so theft of the resource cannot occur.
- 2) The relay ports can be spread across many physical ports and are only accepting random STUN authentications during call setup. This greatly reduces the ability of an attacker being able to cause enough unnecessary processing within the WebSBC server in order to create a denial of service.
- In a second embodiment, the
system 200 ofFIG. 2 can utilize WebSockets connections between the client devices and the website application server for the purpose of call control.FIG. 5 is a block diagram of a system for securely allocating media relay candidates without using TURN, the system having WebSockets connections between client devices and the website application server. Thesystem 500 includes the same components as thesystem 200 inFIG. 2 , with the added feature of WebSockets connections (e.g.,connection 502, connection 504) between theclient devices website application server 202. TheWebSockets connections website application server 202 and therespective clients FIG. 5 , thesystem 500 uses the WebSockets connections for transmitting SIP call control messages, but it should be understood that any protocol can be transmitted using the WebSockets connections to implement a variety of applications—such as real-time messaging, games, social media, and the like. - In a third embodiment, the ICE relay candidate creation techniques described above can be applied to a system using a SIP SBC model.
FIG. 6 is a block diagram of asystem 600 for securely allocating media relay candidates without using TURN, the system using a SIP SBC model. Thesystem 600 includes aSIP SBC 602 that is connected via a communications network toclient devices NAT devices - The
system 600 uses the same ICE relay candidate creation techniques as described above with respect toFIGS. 2-4 . TheSIP SBC 602 receives a media relay binding description fromClient A 608 that includes the ICE relay candidates associated with Client A. TheSIP SBC 602 allocates relay ports and modifies the media relay binding description to include the relay ports in addition to the ICE relay candidates fromClient A 608. TheSIP SBC 602 transmits the modified binding description toClient B 610, and Client B responds by sending its two ICE relay candidates back to theSIP SBC 602. TheSIP SBC 602 then modifies the media relay binding description to add the (b1) and (b2) candidates fromClient B 210. TheSIP SBC 602 transmits the media relay binding description, including the relay ports, toClient A 608. A SIP connection is established betweenClient A 608 andClient B 610 based on the media relay binding description, via the relay ports located on theSIP SBC 602. - Allocation Protocol Attributes
- The following section provides additional detail on the attributes of the allocation protocol used by the
system 200 inFIG. 2 over the allocation link between thewebsite application server 202 and theWebSBC server 204. The attributes include: -
- 1) Secure protocol utilizing mechanisms such as REST over HTTP/HTTPS.
- 2) Ability to initiate and initialize a control session between the website application server and WebSBC server.
- 3) Ability for the website application server to query the status and capabilities of the WebSBC server.
- 4) Ability for the website application server to request a media relay allocation and other services such as IPv4 to IPv6 conversion and transcoding.
- 5) Ability for the WebSBC server to accept, reject, or redirect the resource allocation based on local conditions.
- 6) Ability for all media relay binding description (SDP) elements to be provided to and from the WebSBC server for the purpose of authentication and application features.
- 7) Ability for the website application server to request the WebSBC server to initiate an outbound SIP session using the SDP provided.
- 8) Ability for the website application server to request a media relay de-allocation.
- 9) Ability for the website application server to request and receive media stream events such as dual-tone multi-frequency (DTMF) signaling.
- ICE Media Relay Binding Description Examples Using a WebSBC Server
- The following are examples of the media relay binding description, also called the SDP, transmitted between the
client devices website application server 202, as described above with respect toFIGS. 2-4 . - (1) Client A's SDP as offered to the website application server after its STUN binding request:
-
v=0 o=Sansay-VSXi 188 1493 IN IP4 10.10.0.1 s=session controller c=IN IP4 192.168.0.3 t=0 0 a=ice-pwd:wle83820lwckgikdid a=ice-ufrag:fred m=audio 34902 RTP/AVP 0 b=RS:0 b=RR:0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 73849293 10.10.0.1 21000 typ host a=candidate:2 1 UDP 39203499 192.168.0.3 34902 typ srflx raddr 10.10.0.1 rport 21000 - (2) Website application server modified SDP after WebSBC server relay allocation as sent to Client B:
-
v=0 o=Sansay-VSXi 188 1493 IN IP4 10.10.0.1 s=session controller c=IN IP4 192.168.0.3 t=0 0 a=ice-pwd:wle83820lwckgikdid a=ice-ufrag:fred m=audio 34902 RTP/AVP 0 b=RS:0 b=RR:0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 73849293 10.10.0.1 21000 typ host a=candidate:2 1 UDP 39203499 192.168.0.3 34902 typ srflx raddr 10.10.0.1 rport 21000 a=candidate:3 1 UDP 18320293 69.122.49.7 10034 typ relay raddr 192.168.0.3 rport 34902 - (3) Client B's SDP as offered to the website application server after its STUN binding request:
-
v=0 o=Sansay-VSXi 4943 168 IN IP4 10.0.32.1 s=session controller c=IN IP4 179.128.0.3 t=0 0 a=ice-pwd:olialske329sda a=ice-ufrag:lou m=audio 53120 RTP/AVP 0 b=RS:0 b=RR:0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 55849293 10.0.32.1 39000 typ host a=candidate:2 1 UDP 62203499 179.128.0.3 53120 typ srflx raddr 10.0.32.1 rport 39000 - (4) Website application server modified SDP as sent to Client A:
-
v=0 o=Sansay-VSXi 4943 168 IN IP4 10.0.32.1 s=session controller c=IN IP4 179.128.0.3 t=0 0 a=ice-pwd:olialske329sda a=ice-ufrag:lou m=audio 53120 RTP/AVP 0 b=RS:0 b=RR:0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 55849293 10.0.32.1 39000 typ host a=candidate:2 1 UDP 62203499 179.128.0.3 53120 typ srflx raddr 10.0.32.1 rport 39000 a=candidate:3 1 UDP 94320293 69.122.49.7 10032 typ relay raddr 179.128.0.3 rport 53120 - The above-described techniques can be implemented in digital and/or analog electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The implementation can be as a computer program product, i.e., a computer program tangibly embodied in a machine-readable storage device, for execution by, or to control the operation of, a data processing apparatus, e.g., a programmable processor, a computer, and/or multiple computers. A computer program can be written in any form of computer or programming language, including source code, compiled code, interpreted code and/or machine code, and the computer program can be deployed in any form, including as a stand-alone program or as a subroutine, element, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one or more sites.
- Method steps can be performed by one or more processors executing a computer program to perform functions by operating on input data and/or generating output data. Method steps can also be performed by, and an apparatus can be implemented as, special purpose logic circuitry, e.g., a FPGA (field programmable gate array), a FPAA (field-programmable analog array), a CPLD (complex programmable logic device), a PSoC (Programmable System-on-Chip), ASIP (application-specific instruction-set processor), or an ASIC (application-specific integrated circuit), or the like. Subroutines can refer to portions of the stored computer program and/or the processor, and/or the special circuitry that implement one or more functions.
- Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital or analog computer. Generally, a processor receives instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and/or data. Memory devices, such as a cache, can be used to temporarily store data. Memory devices can also be used for long-term data storage. Generally, a computer also includes, or is operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. A computer can also be operatively coupled to a communications network in order to receive instructions and/or data from the network and/or to transfer instructions and/or data to the network. Computer-readable storage mediums suitable for embodying computer program instructions and data include all forms of volatile and non-volatile memory, including by way of example semiconductor memory devices, e.g., DRAM, SRAM, EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and optical disks, e.g., CD, DVD, HD-DVD, and Blu-ray disks. The processor and the memory can be supplemented by and/or incorporated in special purpose logic circuitry.
- To provide for interaction with a user, the above described techniques can be implemented on a computer in communication with a display device, e.g., a CRT (cathode ray tube), plasma, or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse, a trackball, a touchpad, or a motion sensor, by which the user can provide input to the computer (e.g., interact with a user interface element). Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, and/or tactile input.
- The above described techniques can be implemented in a distributed computing system that includes a back-end component. The back-end component can, for example, be a data server, a middleware component, and/or an application server. The above described techniques can be implemented in a distributed computing system that includes a front-end component. The front-end component can, for example, be a client computer having a graphical user interface, a Web browser through which a user can interact with an example implementation, and/or other graphical user interfaces for a transmitting device. The above described techniques can be implemented in a distributed computing system that includes any combination of such back-end, middleware, or front-end components.
- The components of the computing system can be interconnected by transmission medium, which can include any form or medium of digital or analog data communication (e.g., a communication network). Transmission medium can include one or more packet-based networks and/or one or more circuit-based networks in any configuration. Packet-based networks can include, for example, the Internet, a carrier internet protocol (IP) network (e.g., local area network (LAN), wide area network (WAN), campus area network (CAN), metropolitan area network (MAN), home area network (HAN)), a private IP network, an IP private branch exchange (IPBX), a wireless network (e.g., radio access network (RAN), Bluetooth, Wi-Fi, WiMAX, general packet radio service (GPRS) network, HiperLAN), and/or other packet-based networks. Circuit-based networks can include, for example, the public switched telephone network (PSTN), a legacy private branch exchange (PBX), a wireless network (e.g., RAN, code-division multiple access (CDMA) network, time division multiple access (TDMA) network, global system for mobile communications (GSM) network), and/or other circuit-based networks.
- Information transfer over transmission medium can be based on one or more communication protocols. Communication protocols can include, for example, Ethernet protocol, Internet Protocol (IP), Voice over IP (VoIP), a Peer-to-Peer (P2P) protocol, Hypertext Transfer Protocol (HTTP), Session Initiation Protocol (SIP), H.323, Media Gateway Control Protocol (MGCP), Signaling System #7 (SS7), a Global System for Mobile Communications (GSM) protocol, a Push-to-Talk (PTT) protocol, a PTT over Cellular (POC) protocol, Universal Mobile Telecommunications System (UMTS), 3GPP Long Term Evolution (LTE) and/or other communication protocols.
- Devices of the computing system can include, for example, a computer, a computer with a browser device, a telephone, an IP phone, a mobile device (e.g., cellular phone, personal digital assistant (PDA) device, smart phone, tablet, laptop computer, electronic mail device), and/or other communication devices. The browser device includes, for example, a computer (e.g., desktop computer and/or laptop computer) with a World Wide Web browser (e.g., Chrome™ from Google, Inc., Microsoft® Internet Explorer® available from Microsoft Corporation, and/or Mozilla® Firefox available from Mozilla Corporation). Mobile computing device include, for example, a Blackberry® from Research in Motion, an iPhone® from Apple Corporation, and/or an Android™-based device. IP phones include, for example, a Cisco® Unified IP Phone 7985G and/or a Cisco® Unified Wireless Phone 7920 available from Cisco Systems, Inc.
- Comprise, include, and/or plural forms of each are open ended and include the listed parts and can include additional parts that are not listed. And/or is open ended and includes one or more of the listed parts and combinations of the listed parts.
- One skilled in the art will realize the technology may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The foregoing embodiments are therefore to be considered in all respects illustrative rather than limiting of the technology described herein.
Claims (30)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/093,973 US8725885B1 (en) | 2012-11-27 | 2013-12-02 | Securely establishing ice relay connections |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201261730345P | 2012-11-27 | 2012-11-27 | |
US13/827,793 US8601144B1 (en) | 2012-11-27 | 2013-03-14 | Systems and methods for automatic ICE relay candidate creation |
US14/093,973 US8725885B1 (en) | 2012-11-27 | 2013-12-02 | Securely establishing ice relay connections |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/827,793 Continuation US8601144B1 (en) | 2012-11-27 | 2013-03-14 | Systems and methods for automatic ICE relay candidate creation |
Publications (2)
Publication Number | Publication Date |
---|---|
US8725885B1 US8725885B1 (en) | 2014-05-13 |
US20140150075A1 true US20140150075A1 (en) | 2014-05-29 |
Family
ID=49640905
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/827,793 Active US8601144B1 (en) | 2012-11-27 | 2013-03-14 | Systems and methods for automatic ICE relay candidate creation |
US14/093,973 Active US8725885B1 (en) | 2012-11-27 | 2013-12-02 | Securely establishing ice relay connections |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/827,793 Active US8601144B1 (en) | 2012-11-27 | 2013-03-14 | Systems and methods for automatic ICE relay candidate creation |
Country Status (1)
Country | Link |
---|---|
US (2) | US8601144B1 (en) |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140226664A1 (en) * | 2013-02-08 | 2014-08-14 | Huawei Technologies Co., Ltd. | Method, apparatus, and system for implementing private network traversal |
US20160094591A1 (en) * | 2014-09-25 | 2016-03-31 | Microsoft Technology Licensing, Llc | Media Session between Network Endpoints |
US9596272B2 (en) | 2014-09-25 | 2017-03-14 | Microsoft Technology Licensing, Llc | Media session between network endpoints |
WO2017098171A1 (en) * | 2015-12-10 | 2017-06-15 | Orange | Method of controlling recommendation messages in a communication network |
US20170187678A1 (en) * | 2013-12-27 | 2017-06-29 | Futurewei Technologies, Inc. | Method and apparatus for provisioning traversal using relays around network address translation (turn) credential and servers |
US20170295475A1 (en) * | 2014-10-29 | 2017-10-12 | Kodiak Networks Inc. | System and Method to Leverage Web Real-Time Communication for Implementing Push-to-Talk Solutions |
US10079863B2 (en) | 2015-11-18 | 2018-09-18 | Microsoft Technology Licensing, Llc | Media session between network endpoints |
US10158679B2 (en) | 2015-11-18 | 2018-12-18 | Microsoft Technology Licensing, Llc | Media session between network endpoints |
US10230771B2 (en) * | 2016-10-27 | 2019-03-12 | Microsoft Technology Licensing, Llc | Media session |
US10244003B2 (en) | 2014-09-25 | 2019-03-26 | Microsoft Technology Licensing, Llc | Media session between network endpoints |
US11012437B2 (en) * | 2013-12-27 | 2021-05-18 | Avaya Inc. | Controlling access to traversal using relays around network address translation (TURN) servers using trusted single-use credentials |
US11533179B2 (en) | 2020-08-13 | 2022-12-20 | Cisco Technology, Inc. | Turn authentication using SIP channel discovery |
US11637874B2 (en) * | 2016-09-16 | 2023-04-25 | Ribbon Communications Operating Company, Inc. | Communications apparatus, systems, and methods for preventing and/or minimizing session data clipping |
Families Citing this family (42)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9363133B2 (en) * | 2012-09-28 | 2016-06-07 | Avaya Inc. | Distributed application of enterprise policies to Web Real-Time Communications (WebRTC) interactive sessions, and related methods, systems, and computer-readable media |
US10164929B2 (en) | 2012-09-28 | 2018-12-25 | Avaya Inc. | Intelligent notification of requests for real-time online interaction via real-time communications and/or markup protocols, and related methods, systems, and computer-readable media |
ES2555653T3 (en) * | 2013-02-22 | 2016-01-07 | Telefónica Digital España, S.L.U. | Method and system for telecommunication conference based on a peer-to-peer network (P2P) and on a combined central relay server using a telephony and conference protocol |
US9294458B2 (en) | 2013-03-14 | 2016-03-22 | Avaya Inc. | Managing identity provider (IdP) identifiers for web real-time communications (WebRTC) interactive flows, and related methods, systems, and computer-readable media |
US10205624B2 (en) | 2013-06-07 | 2019-02-12 | Avaya Inc. | Bandwidth-efficient archiving of real-time interactive flows, and related methods, systems, and computer-readable media |
US9525718B2 (en) | 2013-06-30 | 2016-12-20 | Avaya Inc. | Back-to-back virtual web real-time communications (WebRTC) agents, and related methods, systems, and computer-readable media |
US9736130B1 (en) * | 2013-07-05 | 2017-08-15 | Sonus Networks, Inc. | Communications methods and apparatus related to web initiated sessions |
US9282125B2 (en) | 2013-07-30 | 2016-03-08 | Unify Gmbh & Co. Kg | Apparatus and method for communications involving a legacy device |
US9614890B2 (en) | 2013-07-31 | 2017-04-04 | Avaya Inc. | Acquiring and correlating web real-time communications (WEBRTC) interactive flow characteristics, and related methods, systems, and computer-readable media |
US9531808B2 (en) | 2013-08-22 | 2016-12-27 | Avaya Inc. | Providing data resource services within enterprise systems for resource level sharing among multiple applications, and related methods, systems, and computer-readable media |
US10225212B2 (en) | 2013-09-26 | 2019-03-05 | Avaya Inc. | Providing network management based on monitoring quality of service (QOS) characteristics of web real-time communications (WEBRTC) interactive flows, and related methods, systems, and computer-readable media |
US10263952B2 (en) | 2013-10-31 | 2019-04-16 | Avaya Inc. | Providing origin insight for web applications via session traversal utilities for network address translation (STUN) messages, and related methods, systems, and computer-readable media |
US9769214B2 (en) | 2013-11-05 | 2017-09-19 | Avaya Inc. | Providing reliable session initiation protocol (SIP) signaling for web real-time communications (WEBRTC) interactive flows, and related methods, systems, and computer-readable media |
CN104702565B (en) * | 2013-12-05 | 2019-09-17 | 南京中兴新软件有限责任公司 | Media resource shared method, shared server and shared system |
CN104717234A (en) * | 2013-12-11 | 2015-06-17 | 中兴通讯股份有限公司 | Enterprise network communication device and communication method |
FR3017262A1 (en) * | 2014-01-31 | 2015-08-07 | Orange | METHOD AND DEVICE FOR CONNECTING |
FR3017762A1 (en) * | 2014-02-14 | 2015-08-21 | Orange | NOTIFICATION OF BANDWIDTH CONSUMPTION INFORMATION TO A SERVICE PROVIDER IN A TELECOMMUNICATIONS NETWORK |
US10581927B2 (en) | 2014-04-17 | 2020-03-03 | Avaya Inc. | Providing web real-time communications (WebRTC) media services via WebRTC-enabled media servers, and related methods, systems, and computer-readable media |
US9749363B2 (en) | 2014-04-17 | 2017-08-29 | Avaya Inc. | Application of enterprise policies to web real-time communications (WebRTC) interactive sessions using an enterprise session initiation protocol (SIP) engine, and related methods, systems, and computer-readable media |
KR101458368B1 (en) * | 2014-04-28 | 2014-11-19 | 알서포트 주식회사 | Session establishment method using relay server active connection of mobile terminal |
US9380030B2 (en) * | 2014-05-20 | 2016-06-28 | Avay Inc. | Firewall traversal for web real-time communications |
US10298623B2 (en) * | 2014-06-20 | 2019-05-21 | T-Mobile Usa, Inc. | Seamless web real-time communication support on mobile appliances |
US9912705B2 (en) | 2014-06-24 | 2018-03-06 | Avaya Inc. | Enhancing media characteristics during web real-time communications (WebRTC) interactive sessions by using session initiation protocol (SIP) endpoints, and related methods, systems, and computer-readable media |
FR3023093A1 (en) | 2014-06-30 | 2016-01-01 | Orange | METHOD FOR AUTHORIZING THE ESTABLISHMENT OF A PAIR TO BE MIXED IN A MOBILE TELECOMMUNICATIONS NETWORK |
US9369406B2 (en) * | 2014-07-03 | 2016-06-14 | Sas Institute Inc. | Resource server providing a rapidly changing resource |
CN107077382B (en) | 2014-09-26 | 2021-07-16 | 甲骨文国际公司 | System and method for transaction recovery in a multi-tenant application server environment |
US10237236B2 (en) | 2015-06-25 | 2019-03-19 | Microsoft Technology Licensing, Llc | Media Session |
US10554694B2 (en) * | 2015-07-20 | 2020-02-04 | At&T Intellectual Property I, L.P. | System and method for using software defined networking in internet protocol multimedia subsystems |
US10587449B2 (en) | 2016-07-18 | 2020-03-10 | Avaya Inc. | System and method to use location-aware DNS responses as input to media relay selection for WebRTC |
US11178192B2 (en) | 2016-07-19 | 2021-11-16 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and device for facilitating connectivity check between terminal device and media gateway |
US10587658B2 (en) * | 2017-03-03 | 2020-03-10 | At&T Intellectual Property I, L.P. | Real time communication hub for multiple secure connections through shared session |
US10778726B2 (en) * | 2017-08-31 | 2020-09-15 | Microsoft Technology Licensing, Llc | Bidirectional data exchange between computing devices |
US20190068684A1 (en) * | 2017-08-31 | 2019-02-28 | Microsoft Technology Licensing, Llc | Bidirectional data exchange |
US20190141009A1 (en) * | 2017-11-07 | 2019-05-09 | General Electric Company | Session moderator for turn-pattern tcp-packet relay with websocket instantiation |
CN109495599B (en) * | 2018-11-16 | 2023-09-19 | 深圳市网心科技有限公司 | Data transmission method and system, electronic device and computer readable storage medium |
FI129164B (en) * | 2018-12-20 | 2021-08-13 | Telia Co Ab | Communication Solution |
US10805361B2 (en) | 2018-12-21 | 2020-10-13 | Sansay, Inc. | Communication session preservation in geographically redundant cloud-based systems |
US11470041B2 (en) * | 2019-06-20 | 2022-10-11 | Disney Enterprises, Inc. | Software defined network orchestration to manage media flows for broadcast with public cloud networks |
JP6860176B2 (en) * | 2019-07-02 | 2021-04-14 | Necプラットフォームズ株式会社 | Connection control device, connection control method and connection control program |
CN112671944A (en) * | 2020-12-18 | 2021-04-16 | 杭州叙简科技股份有限公司 | Audio and video interaction method based on webrtc and ice detection |
CN114268599A (en) * | 2021-12-21 | 2022-04-01 | 北京青云科技股份有限公司 | Method, device, equipment and medium for establishing instant messaging connection and instant messaging |
CN116896544B (en) * | 2023-08-29 | 2024-04-30 | 好信云(北京)网络通信有限公司 | Method, apparatus, device and medium for establishing a real-time communication connection |
Family Cites Families (36)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7860725B2 (en) * | 1998-05-26 | 2010-12-28 | Ineedmd.Com, Inc. | Method for remote medical consultation and care |
US7546376B2 (en) * | 2000-11-06 | 2009-06-09 | Telefonaktiebolaget Lm Ericsson (Publ) | Media binding to coordinate quality of service requirements for media flows in a multimedia session with IP bearer resources |
US20020184510A1 (en) * | 2001-04-17 | 2002-12-05 | At&T Wireless Services, Inc. | Binding information for IP media flows |
US7383231B2 (en) * | 2004-07-19 | 2008-06-03 | Amazon Technologies, Inc. | Performing automatically authorized programmatic transactions |
GB2421156A (en) | 2004-12-10 | 2006-06-14 | Ericsson Telefon Ab L M | Maintaining session across network address/port translation firewall in the event of an address change with a session manager |
US8249076B1 (en) | 2005-01-14 | 2012-08-21 | Acme Packet, Inc. | Method, system and architecture for validating media sessions in networks that use communication protocols with distinct signaling and media channels |
JP4907649B2 (en) | 2005-06-03 | 2012-04-04 | ソーナス ネットワークス, インコーポレイテッド | Public switched telephone network signaling in media gateways for packet-based networks |
US7983254B2 (en) | 2005-07-20 | 2011-07-19 | Verizon Business Global Llc | Method and system for securing real-time media streams in support of interdomain traversal |
US8432896B2 (en) * | 2005-07-22 | 2013-04-30 | Cisco Technology, Inc. | System and method for optimizing communications between session border controllers and endpoints in a network environment |
US8300636B2 (en) | 2005-09-16 | 2012-10-30 | Acme Products, Inc. | Method and system of routing media packets in a network device |
EP2016727B1 (en) * | 2006-04-24 | 2018-03-28 | KTFreetel Co., Ltd. | Interworking system between ip networks using different ip addressing scheme and interworking method thereof |
CN101119299A (en) * | 2006-08-02 | 2008-02-06 | 华为技术有限公司 | Method for conducting media stream, conduction detecting method and system |
FR2908001B1 (en) | 2006-10-26 | 2009-04-10 | Alcatel Sa | CROSSING A NAT ADDRESS TRANSLATION EQUIPMENT FOR SIP PROTOCOL SIGNALING MESSAGES BY REDUNDANCY OF ADDRESS INFORMATION. |
US8218458B2 (en) | 2006-11-30 | 2012-07-10 | Cisco Systems, Inc. | Method and apparatus for voice conference monitoring |
CN101257433B (en) * | 2007-03-01 | 2011-09-14 | 华为技术有限公司 | Method and system for realizing network address convert traversing |
US7801059B2 (en) * | 2007-04-20 | 2010-09-21 | Panasonic Corporation | IP communication apparatus and NAT type determination method by the same |
US8832280B2 (en) * | 2007-06-29 | 2014-09-09 | Microsoft Corporation | Interactive connectivity establishment for non-enabled endpoints |
WO2009046729A1 (en) * | 2007-09-28 | 2009-04-16 | Siemens Enterprise Communications Gmbh & Co. Kg | Method and device for connecting packet-oriented communication terminals |
CN101179581B (en) * | 2007-12-13 | 2010-06-09 | 北京邮电大学 | Method for performing media transmission using ICE relay candidate address |
CN101465784A (en) * | 2007-12-18 | 2009-06-24 | 友讯科技股份有限公司 | Portable ICE relay server and method thereof |
CN101911645B (en) * | 2008-01-07 | 2016-06-08 | 西门子企业通讯有限责任两合公司 | For verifying method and the end points of the key information between the end points of correspondence |
US8477761B2 (en) * | 2008-03-27 | 2013-07-02 | Ittiam Systems (P) Ltd. | Unified session signaling system for use in multimedia communications |
KR20100050846A (en) * | 2008-11-06 | 2010-05-14 | 삼성전자주식회사 | System and method for interchanging key |
US7941551B2 (en) * | 2009-02-25 | 2011-05-10 | Microsoft Corporation | Tunneling of remote desktop sessions through firewalls |
US8185660B2 (en) * | 2009-05-12 | 2012-05-22 | Cisco Technology, Inc. | Inter-working between network address type (ANAT) endpoints and interactive connectivity establishment (ICE) endpoints |
US9106628B2 (en) * | 2009-07-07 | 2015-08-11 | Alcatel Lucent | Efficient key management system and method |
US9015242B2 (en) * | 2009-09-06 | 2015-04-21 | Tangome, Inc. | Communicating with a user device |
US20110194696A1 (en) * | 2009-09-08 | 2011-08-11 | Information Assurance Specialists, Inc. | Secure protocol terminal adapter |
ES2440327T3 (en) * | 2009-11-20 | 2014-01-28 | Telefonaktiebolaget Lm Ericsson (Publ) | Control of the installation of a packet filter on a user equipment |
US9118733B2 (en) * | 2010-05-21 | 2015-08-25 | Skype | Multilevel routing |
US20120065813A1 (en) * | 2010-09-14 | 2012-03-15 | Nguyen Quang H | System and method for command and data handling in space flight electronics |
US20120142341A1 (en) | 2010-12-06 | 2012-06-07 | Sonus Networks | Internetworking Between a Network Capable of Carrying Voice Over Packet Access and a Network Not Capable of Carrying Voice Over Packet Access |
EP2695047B1 (en) * | 2011-04-04 | 2019-07-03 | BlackBerry Limited | Document management system using printer emulation |
US9219761B2 (en) * | 2011-10-07 | 2015-12-22 | Karl-Erik Ståhl | Device, software module or system for global real-time telecommunication |
US9148359B2 (en) * | 2011-12-22 | 2015-09-29 | Voipfuture Gmbh | Correlation of media plane and signaling plane of media services in a packet-switched network |
JP5972398B2 (en) * | 2012-01-17 | 2016-08-17 | テレフオンアクチーボラゲット エルエム エリクソン(パブル) | ICE-based NAT traversal |
-
2013
- 2013-03-14 US US13/827,793 patent/US8601144B1/en active Active
- 2013-12-02 US US14/093,973 patent/US8725885B1/en active Active
Cited By (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140226664A1 (en) * | 2013-02-08 | 2014-08-14 | Huawei Technologies Co., Ltd. | Method, apparatus, and system for implementing private network traversal |
US8885649B2 (en) * | 2013-02-08 | 2014-11-11 | Huawei Technologies Co., Ltd. | Method, apparatus, and system for implementing private network traversal |
US11012437B2 (en) * | 2013-12-27 | 2021-05-18 | Avaya Inc. | Controlling access to traversal using relays around network address translation (TURN) servers using trusted single-use credentials |
US20170187678A1 (en) * | 2013-12-27 | 2017-06-29 | Futurewei Technologies, Inc. | Method and apparatus for provisioning traversal using relays around network address translation (turn) credential and servers |
US20160094591A1 (en) * | 2014-09-25 | 2016-03-31 | Microsoft Technology Licensing, Llc | Media Session between Network Endpoints |
US9596272B2 (en) | 2014-09-25 | 2017-03-14 | Microsoft Technology Licensing, Llc | Media session between network endpoints |
US10244003B2 (en) | 2014-09-25 | 2019-03-26 | Microsoft Technology Licensing, Llc | Media session between network endpoints |
US10171511B2 (en) * | 2014-09-25 | 2019-01-01 | Microsoft Technology Licensing, Llc | Media session between network endpoints |
EP3213468A4 (en) * | 2014-10-29 | 2018-04-18 | Kodiak Networks, Inc. | System and method to leverage web real-time communication for implementing push-to-talk solutions |
US10085124B2 (en) * | 2014-10-29 | 2018-09-25 | Kodiak Networks Inc. | System and method to leverage web real-time communication for implementing push-to-talk solutions |
US20170295475A1 (en) * | 2014-10-29 | 2017-10-12 | Kodiak Networks Inc. | System and Method to Leverage Web Real-Time Communication for Implementing Push-to-Talk Solutions |
US10079863B2 (en) | 2015-11-18 | 2018-09-18 | Microsoft Technology Licensing, Llc | Media session between network endpoints |
US10158679B2 (en) | 2015-11-18 | 2018-12-18 | Microsoft Technology Licensing, Llc | Media session between network endpoints |
FR3045254A1 (en) * | 2015-12-10 | 2017-06-16 | Orange | METHOD FOR CONTROLLING RECOMMENDATION MESSAGES IN A COMMUNICATION NETWORK |
WO2017098171A1 (en) * | 2015-12-10 | 2017-06-15 | Orange | Method of controlling recommendation messages in a communication network |
US11637874B2 (en) * | 2016-09-16 | 2023-04-25 | Ribbon Communications Operating Company, Inc. | Communications apparatus, systems, and methods for preventing and/or minimizing session data clipping |
US10230771B2 (en) * | 2016-10-27 | 2019-03-12 | Microsoft Technology Licensing, Llc | Media session |
US11533179B2 (en) | 2020-08-13 | 2022-12-20 | Cisco Technology, Inc. | Turn authentication using SIP channel discovery |
Also Published As
Publication number | Publication date |
---|---|
US8601144B1 (en) | 2013-12-03 |
US8725885B1 (en) | 2014-05-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8725885B1 (en) | Securely establishing ice relay connections | |
CN109274634B (en) | Multimedia communication method and device, and storage medium | |
JP6414630B2 (en) | Method and apparatus for provisioning traversal (TURN) credential information and servers using relays for network address translation | |
JP5763267B2 (en) | Lawful intercept based on policy routing in a communication system with end-to-end encryption | |
US8544080B2 (en) | Mobile virtual private networks | |
US9705864B2 (en) | Media session resumption in web session restoration | |
US9172559B2 (en) | Method, apparatus, and network system for terminal to traverse private network to communicate with server in IMS core network | |
EP2790387B1 (en) | Method and system for providing connectivity for an ssl/tls server behind a restrictive firewall or nat | |
EP3192224B1 (en) | Establishment of a secure connection for a communication session | |
EP2991318B1 (en) | Hybrid cloud architecture for media communications | |
WO2016066027A1 (en) | Media transmission method and device | |
US11218515B2 (en) | Media protection within the core network of an IMS network | |
KR20210091310A (en) | Carrier Integration via User Network Interface Proxy | |
JP5331032B2 (en) | Network call control system | |
Barnawi et al. | Security Analysis and Delay Evaluation for SIP-Based mobile MASS examination system | |
Tulimiero | An All-Round Secure IoT Network Architecture | |
Heikkinen | Secure Push in Wireless Environments | |
van Gelder | Media Security in Open IMS Core | |
Abou El Kalam et al. | A Secure Architecture for Nomadic User in IMS Network | |
Vintilă | Potential Applications of IPsec in Next Generation Networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: SANSAY, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:RYNER, GERALD T.;REEL/FRAME:031797/0602 Effective date: 20131129 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.) |
|
FEPP | Fee payment procedure |
Free format text: SURCHARGE FOR LATE PAYMENT, SMALL ENTITY (ORIGINAL EVENT CODE: M2554) |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YR, SMALL ENTITY (ORIGINAL EVENT CODE: M2551) Year of fee payment: 4 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YR, SMALL ENTITY (ORIGINAL EVENT CODE: M2552); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY Year of fee payment: 8 |