Introduction
Peer-to-peer is a communication architecture that provides a way for applications to communicate and exchange data directly without relying on centralized servers. WebRTC within this space is an open web standard created as an option for providing real-time peer-to-peer communication capabilities to different types of applications. It supports video, voice, and generic data communication with its original focus centred around video and voice. With time, however, its data communication capabilities have also become a core part thanks to its wide use case in different communications applications. (WebRTC, n.d.)
Some use cases for WebRTC today are file sharing, telemedicine, gaming, live streaming, machine learning processing, haptic devices, educational platforms and sensor data collection, amongst others (Mahmoud & Abozariba, 2024)
. The technology is available on all modern browsers through standard JavaScript APIs (Application Programming Interface), with APIs also available for several other languages. Native WebRTC implementations are also available for major platforms like Android and iOS (WebRTC, n.d.).
WebRTC as a Solution
As not all applications have network communication built in, peer-to-peer can provide a way to bridge this gap when such functionality is desired. The thesis on which this article is based aims to utilize WebRTC to enable the option for users to establish communication between different running instances of an open-source program. The thesis explores its potential as a low-cost solution to network communication while examining implementation alternatives, topology trade-offs, challenges, and limitations.
One of WebRTC’s strengths is its ability to support a wide range of real-time peer-to-peer communication use cases through standardized APIs. This versatility also introduces technical complexity, as WebRTC relies on several interconnected APIs, protocols, and mechanisms for establishing connections and transferring media and application data (W3C, 2025; MDN Web Docs, 2025).
Establishing peer-to-peer over WebRTC
Communication through WebRTC is established through a sequence of steps:
- Signaling
- Connecting
- Securing
- Communicating
These steps are required to be sequential to establish communication, with a summary of them shown in Figure 1. Signaling is the first and only step that directly requires the use of external means, as its purpose is to get both connecting peers the information necessary to establish a connection, by sending a session description protocol (SDP) package. The way this is handled is entirely up to the developer and does not concern WebRTC. Any architecture suitable for sending the SDP can be used be it REST endpoints, WebSockets, or a database, it could even be exchanged through text messages if desired (DuBois, Mogren, & Zhukov, n.d.).
The second step, connecting, presents some of the significant challenges within WebRTC as a technology. The information exchanged during signaling contains a set of candidate network addresses through which each peer may be reachable. The connection process relies on ICE (Interactive Connectivity Establishment), which gathers and evaluates network candidates to find a viable connection path between the peers. STUN (Session Traversal Utilities for NAT) can be used to discover addresses through which a peer may be reachable. If a direct connection cannot be established, a TURN (Traversal Using Relays around NAT) server can relay the communication between the peers. Networks are however, configured in a number of different ways and depending on the network configuration a user’s computer operates behind, direct connections may in some cases prove itself difficult. In these cases a TURN (Traversal Using Relays around NAT) server is most commonly used to act as a bridge between the two peers to relay the information between them, though this comes with bandwidth costs for the server itself that usually translates to a monetary cost as well (DuBois, Mogren, & Zhukov, n.d.).
The last two steps are securing and communicating which, similarly to connecting, happens automatically once the previous step has been completed. WebRTC provides encrypted and authenticated communication by default. Media streams use SRTP (Secure Real-time Transport Protocol), while data channels use DTLS (Datagram Transport Layer Security). Communication can then start once securing is complete, which uses RTP for media-based communication, and SCTP (Stream Control Transmission Protocol) for data (DuBois, Mogren, & Zhukov, n.d.).
Conclusion: A Proven and Effective Solution
The evaluation and integration of WebRTC into the project has given merit to its potential usage and long-term suitability in this environment, while answering proposed research questions. This is further supported by the project’s current public runtime of over two years, during which WebRTC has been used at its core for data communication. The main challenge was identified as the technical knowledge required for a proper implementation, and the main limitations as potential congestion and potential TURN server cost depending on expected usage if the project aim is to remain low-cost throughout its lifetime. Nonetheless, WebRTC is an effective solution for peer-to-peer network communication and is well suited for integration with standalone open-source projects.
