New to WebRTC? Top WebRTC Terms You Need To Know
Posted On March 16, 2017 by Andy Abramson in Blog, Ecosystem, Media, Resources
One of the great things about Web Real-Time Communication (WebRTC) is that you don’t have to be a technical expert — or even a developer — to implement the technology within your organization. You can easily outsource the project to a third party development team and rely on a Platform as a Service (PaaS) provider like Temasys Communications to power your new service. In doing so, you’ll receive a custom-built, fully-managed WebRTC provider that can work with any application or website. This way will get you to market much faster, and more reliably.
Even so, before you get started with your WebRTC project, it might be helpful to have a fundamental understanding of the terminology used and what those terms mean. We hope this will make it very easy to communicate with your tech team, and they’ll appreciate your effort to understand how WebRTC works.
Here are the top WebRTC terms you need to know:
WebRTC: Let’s start from the top. Web Real-Time Communications — or “WebRTC” — is a set of open source application programming interfaces (APIs) and codecs that enable real-time audio, video and data transfers to take place over an Internet browser like Chrome, Firefox or Opera. Microsoft Edge is slowly adding support for WebRTC in Edge for Windows 10. Use of WebRTC now occurs across all vertical markets, with some of the most popular being telehealth, customer service, insurance, and gaming.
Not all browsers currently support WebRTC. However, those that don’t — namely Safari and Microsoft’s Internet Explorer — can support WebRTC using plugins from Temasys. Most WebRTC data transmissions use a peer-to-peer architecture, which allows users to exchange data between one another without having to use any third-party servers.
WebRTC technology has been around since 2011 and is moving out of its nascent stage. WebRTC finds its way into more web and mobile apps every day. Many businesses are expanding beyond basic use cases, and are finding creative ways to leverage the technology creating new services that solve everyday problems.
Network Address Translation (NAT): Most enterprises today operate on private networks protected by NAT devices. They act like basic firewalls. NAT devices restrict communication between corporate networks, and when this happens, a capability called NAT traversal is required to establish connectivity over the public Internet.
Signaling: NAT traversal requires using various protocols and servers to establish connectivity between private networks. This process is called signaling. Signaling is necessary for exchanging things like network discovery information (namely public IP addresses and port numbers), data, metadata, and session control messages.
Interactive Connectivity Establishment (ICE): This framework is used to streamline networking complexities so that signaling can take place during a WebRTC session. ICE works to find the most optimal path between two endpoints.
Session Traversal Utilities for NAT (STUN): This is one of the critical services that ICE uses to connect to private corporate networks. It’s STUN’s job to discover network address translators as well as IP addresses and port numbers on host networks. STUN also transports the information back to the host. STUN servers are necessary for setting up direct links between users.
Traversal Using Relays around NAT (TURN) protocol: STUN is not always successful. When this happens, ICE will use the TURN protocol to try and establish real-time connectivity. To work properly one needs to install a third party TURN server in between the two end users, to relay information back and forth. It takes over where peer-to-peer connections will fail. Using TURN can add latency and other performance issues, but TURN servers are often mandatory for enterprise solutions and help dramatically increase connection success rates.
Extra Credit: Additional Protocols You Should Know About
Now that we have described some of the basic components that make WebRTC possible, let’s explore some of the various protocols used during the signaling process:
Session Description Protocol (SDP): Not all protocols deliver media between end users. The SDP protocol, for instance, acts as a negotiator between different endpoints and users. It collects information on the format, media types and parameters and then uses that information to set up a session profile.
User Datagram Protocol (UDP): The UDP protocol allows computers to send messages called datagrams to other endpoints on the public Internet.
Datagram Transport Layer Security (DTLS): This protocol is a variation of the Transport Security Layer (TLS) protocol. It’s used to prevent interference or interception during WebRTC sessions on packet-switched networks.
Stream Control Transmission Protocol (SCTP): A transport layer protocol, SCTP is commonly used to send Public Switched Telephone Network (PSTN) signals over IP networks.
Extensible Messaging and Presence Protocol (XMPP): The XMPP protocol is known as a good way to for exchange messaging and presence information between end users. It is primarily used in “asynchronous” messaging solutions and sometimes used as the signaling protocol for WebRTC applications.
Session Initiation Protocol (SIP): The SIP protocol was invented to support Voice over IP solutions. It’s a “call setup” protocol that operates at the application layer. Predominantly used in the web audio conferencing world, SIP is pretty flexible as it was designed to be a general-purpose way to set up real-time multimedia sessions between groups of participants. As a result, its use as a signaling protocol for WebRTC solutions is pretty common.
Proprietary Signaling: It’s not exactly a “term” that can be tied back to specific definitions or explanations. However, there are many proponents of WebRTC who advocate not using XMPP or SIP for WebRTC solutions. The alternative is to use them only when you need to interoperate with VoIP systems or the POTS (Plain Old Telephone System). If you want to avoid using one of these legacy protocols, and build a pure WebRTC application, it means building your own signaling solution.
I already hear you saying, “Wow! That sounds complicated. And expensive!” We agree. If you insist on DIY, you’ll find that Websockets and Node.js are two commonly used components of such offerings. There are lots of resources out there if one is terribly interested. One such example is Muaz Khan’s “WebRTC Signaling Concepts.” In our opinion, though, an even better option is to consider using a Platform as a Service that has already done all of this for you.
WebRTC is complicated. As a company that lives and breathes WebRTC, we are here to help make it easier, simpler to understand, and to use. There are many different components involved which means more WebRTC terms will inevitably find their way into your vocabulary.
To learn more about how you can leverage hassle-free WebRTC in your enterprise, contact Temasys today.