WebRTC is easy to implement and use, thanks to its open-source origin and widespread adoption. Our previous blog post explained the main differences between the WebRTC and WebSocket protocols, with the pros and cons of both solutions. If you have chosen to use WebRTC in your project, you need to remember there are still a few choices to be made – and we have selected 3 areas that should be given extra care. Here are 3 things to consider before you launch your WebRTC project.
Implementing APIs
WebRTC is making use of three distinct APIs. Knowing how they can help with the goals you want to achieve with your project is crucial to navigating through them and carefully choosing the right solution for you. All three are very powerful and can help you make the best of your application.
RTCPeerConnection
RTCPeerConnection can negotiate and facilitate stable peer-to-peer communication or data streaming. With multiple codecs and streaming protocols within WebRTC, RTCPeerConnection can streamline and simplify many complexities arising from their implementation. This is especially helpful with maintaining multiple tools supplementing stable communications, like echo canceling, dynamic jitter buffering, packet-loss minimization, audio gain control, or noise reduction.
RTCDataChannel
WebRTC can facilitate types of communication other than audio/video. The RTCDataChannel API ensures low latency and high bandwidth on peer-to-peer data exchange, which can be useful for file transfer, text chat, or gaming solutions. With the API, you can implement multiple channels supporting prioritization simultaneously, built-in data congestion control, or delivery semantics – and you can use it even without audio or video streams.
MediaStream (or getUserMedia)
MediaStream (also known as getUserMedia) API manages the synchronized media streams. When the microphone and camera produce audio and video needed for the connection, the API synchronizes it into parallel audio and video tracks.
All of the above are widely supported by all major mobile and desktop browsers and can coexist peacefully, so using all three should not cause any additional resource drain for end-users.
Signaling
To send data between peers (users or browsers), WebRTC uses the RTCPeerConnection API – but it also needs a method for signaling, which is a process of communication coordination and data control. Before the connection between peers can be established, a signaling server (or signaling device) needs to take care of the following:
The methods and protocols responsible for signaling are not included in the RTCPeerConnection API or specified in the WebRTC protocol itself. That is why choosing the messaging protocol used for signaling is essential, with the most popular ones being SIP and XMPP.
SIP and XMPP protocols have various possible usages. A text-based request-response control, SIP runs UDP, TCP, and SCTP. XMPP, an XML-based client-server solution, can use only TCP. Thanks to UPD support, SIP can handle more complex communication solutions, while XMPP has a broader adoption among many clients. It is also possible to integrate both into a dual-stack solution for optimal coverage of possibilities. Other protocols are available, and any compatible two-way duplex communication solution will do the trick.
With signaling capabilities, it’s essential to understand the end goal for your project. Make sure your signaling servers are easily scalable in case of user growth and increasing bandwidth needs. Allocating appropriate resources to establish all necessary connections can be tricky, so make sure your hardware has room to grow. Simple peer-to-peer solutions seem small enough to be almost handling themselves. Still, massive volumes of audio and video streams can be a strain on servers responsible for negotiating proper paths between end-users.
Security
Security is a vital factor to consider with real-time communication applications and plugins, as any compromise can have devastating results. An application might be streaming or recording audio and video without the user’s knowledge, unencrypted data and media might leak on the path from a peer to a server, or malicious software and viruses could be planted inside app packages.
Luckily, encryption is forced by the protocol for all elements present in a WebRTC connection, including signaling paths. With secure protocols like DTLS or SRTP implemented, it lowers the chances of media and data leaks occurring. However, it is still important to ensure that encryption is enforced end-to-end on all elements and servers included in your project, as the entire structure will always be as secure as its weakest link. That is why it’s essential to stick to the basic security hygiene procedures, even on plain-text channels.
