Freedom from downtime and latency with our dedicated bare metal servers.
Handle heavy real-time workloads with unparalleled speed and performance.
Bare metal performance with the flexibility of the cloud.
Effective server-side and tech-agnostic cheat detection.
Scaling game instances with automated global orchestration.
Low-latency game server management for a flawless experience.
Custom tools to detect, intercept, and deflect impending attacks.
Transfer data on a global scale fast, private, and secure.
Reach eyeball networks through meaningful peering relationships.
Go global with our custom and secure privately-owned data center.
Previously, we have mentioned 3 important things to consider when starting a WebRTC project as a developer. In that blog post, we’ve underlined the importance of signaling – a process of communication coordination and data control.
When using WebRTC-based apps, the devices on which they run are usually unable to manage the underlying mechanics of the connection. With the use of the WebRTC signaling server, signals are communicated between end-users, indicating the start of the connection, keeping it up for its duration, and securely terminating it at the end. The signaling servers do not store or transmit any connection data, as that happens directly, peer-to-peer. It makes sure that the communication stream occurs between the devices it’s meant for and helps with the connection’s stability and reliability throughout.
Having a signaling server for your WebRTC application is mandatory, as, without it, there are no ways to negotiate data streaming routes between end-users. The signaling server can either be rented from a hosting provider or created and maintained autonomously by the developers themselves. A signaling server is essential to ensure proper connection and data flow, but it’s not the only type of server that can be useful for WebRTC applications.
With more users joining a WebRTC call, the complexity of the connection can get too much for a simple P2P route between the clients. Even with the best internet access all around the call, with a large cross-connection, you may encounter packet loss – losing data on the way between users – or jitter, which causes inconsistent quality due to packets being delayed and falling out of the regular rhythm of the data stream. You can employ a media server to mix audio and video streams efficiently and keep the side effects as small as possible. It will instantly compile multiple streams using the processing power of the server hardware and send them to all participants, ensuring high quality of communication.
Using a media server is optional, primarily if your WebRTC solution is only used on one-on-one calls. But if you want to offer functionality like group calls and conference calls, recording your calls, broadcasting the transmission, or additional media streaming, it will become crucial for your project to maintain a media server. Those are more often outsourced, requiring more robust connectivity and hardware resources.
WebRTC applications can use NAT (Network Address Translation) servers, which keep track of and manage the IP address space within the connection. The two types of NAT servers used in WebRTC solutions are STUN and TURN – they operate on the principle of negotiating connections through NAT devices and firewalls, establishing a P2P connection between devices with those security features. However, to achieve that goal, they use differing methods.
During a connection, a STUN (Session Traversal Utilities for NAT) server will request the public IP addresses from devices connected and use them to negotiate traffic routes through the security layers of each device. Suppose it fails due to both NAT server and firewall obscuring the possibility. In that case, a TURN (Traversal Using Relays around NAT) server will be used to transmit data from the device to the connection and back around. Each client will connect independently and securely to the TURN server, and all communications will be referenced and maintained while also keeping the devices safe.
STUN and TURN servers are not mandatory for every WebRTC application, but it’s advised to make use of them for maximum security. Just like media servers, they require powerful connectivity and extensive resources, and the shortest physical distance possible from all callers – this is why it is recommended to outsource NAT servers for those purposes from a reliable connectivity partner.
With each additional server added to the mix, your WebRTC project becomes more reliable and secure. Once you have your server hardware in check, you can proceed to implementing necessary protocols and configuring the firewall and NAT traversal for your end-users to stay safely connected.
Subscribe to our Newsletter and stay up to date with the latest from i3D.net