Enabling Real-Time Communication for Remote Inspection

Traditional inspection methods often involve dispatching inspectors to various locations, which can be both time-consuming and costly, especially when dealing with sites spread across a large area. However, advancements in technology have introduced a more streamlined approach: remote inspections through video conferencing.

This innovative method facilitates real-time communication between on-site inspectors and back-office specialists, effectively eliminating geographical barriers and optimising the inspection process. On-site inspectors can focus on issue collection and observation, while remote specialists can concurrently document findings and provide expert guidance. This division of labor not only enhances efficiency but also ensures accuracy, as specialists can dedicate their undivided attention to analysing data and formulating solutions without being hindered by on-site logistics.

Web Real-Time Communication

WebRTC (Web Real-Time Communication) is a technology that enables Web applications and sites to capture and optionally stream audio and/or video media, as well as to exchange arbitrary data between browsers without requiring an intermediary. The set of standards that comprise WebRTC makes it possible to share data and perform teleconferencing peer-to-peer, without requiring that the user install plug-ins or any other third-party software. (from mdn web docs).

When adding real-time communication capabilities to a web application, WebRTC is the obvious choice. The advantage of not needing to set up intermediary servers, allowing users to communicate directly with each other, increases efficiency and ensures scalability. Initially, it all sounded promising and straightforward; however, the deeper we delved, we learned more and more that it was not as simple in practice as in theory.

Signaling Servers

First thing first, there are signaling servers. Signaling is the discovery and negotiation process of establishing a connection between devices. The role of a signaling server is to serve as an intermediary, allowing two peers to find and establish a connection while minimizing the exposure of potentially private information as much as possible. Each device will send and receive session description protocol (SDP), which contains information for connectivity establishment to the server. Unless you somehow manage to pass the IP address and port information of one device to another, signaling servers are considered necessary.

Network Address Translation Traversal

Now, we have a server allowing users to exchange connectivity information, that should be it, right? Turns out, there's more to it, thanks to Network Address Translation (NAT). NAT is a common technique used in routers to allow multiple devices within a private network to share a single public IP address. However, NAT poses challenges for peer-to-peer communication because it modifies the IP addresses and ports of outgoing packets, making it difficult for external devices to initiate connections directly to devices behind the NAT. This is when NAT traversal comes into play, with Session Traversal Utilities for NAT (STUN) and Traversal Using Relays around NAT (TURN).

STUN servers assist in identifying the public IP address and port of a device behind NAT. When a device attempts to establish a connection with another device, it sends a request to a STUN server. The STUN server responds with the public IP address and port that the request appeared to come from.

There are cases where direct communication is not feasible due to symmetric NAT or other restrictions. TURN servers are there for this reason, acting as relay points for data transmission between peers. When direct communication is not possible, devices establish connections with the TURN server instead. The TURN server then relays data between the peers, allowing them to communicate indirectly through the server.

Media Servers 

You might be thinking, why do we need a media server when WebRTC is designed for direct communication between clients? While WebRTC enables peer-to-peer communication, there are scenarios where the use of a media server can complement its capabilities.

One common example is when there is a need for broadcasting a stream to multiple recipients, such as in a webinar or live streaming scenario. In such cases, a media server can receive the stream from one client and distribute it to multiple clients simultaneously, relieving the sender from the burden of handling multiple connections.

Additionally, media servers can provide advanced features like recording, transcoding, and network optimization, enhancing the overall quality and scalability of real-time communication applications. While WebRTC shines in enabling direct communication between peers, the inclusion of a media server can extend its functionality to meet the diverse needs of modern communication platforms.

Amazon Chime SDK

Considering all the complexities of implementing WebRTC from scratch, utilizing a Communication Platform as a Service (CPaaS) platform emerges as an appealing alternative. Among all the platforms, the Amazon Chime SDK stood out to us, being a comprehensive solution offering a set of real-time communication components, empowering developers to effortlessly integrate messaging, audio, video, and screen sharing functionalities into their applications.

In future blog posts, we'll delve deeper into how to leverage the Amazon Chime SDK to build immersive communication experiences that elevate user engagement and collaboration. Stay tuned for our upcoming content where we'll explore practical use cases and step-by-step guides on harnessing the power of the Amazon Chime SDK to enhance your applications.