The Origin of WebRTC

In 2010, Google acquired a company called Global IP Solutions (GIPS). This company's core technologies focused on real-time voice and video communication, including advanced audio codecs (such as Opus), echo cancellation, noise suppression, and more.

After acquiring GIPS, Google open-sourced these proprietary technologies and integrated them with its ongoing browser development efforts. In 2011, Google officially named the technology WebRTC and submitted a standardization draft to the IETF (Internet Engineering Task Force).

Open Source and Standardization

Google introduced WebRTC with the goal of enabling real-time voice and video communication directly within web browsers—without needing to install any plugins, such as Flash or Java applets that were commonly used in the past.

To achieve this goal, Google actively collaborated with several organizations, including:

• IETF (Internet Engineering Task Force): Responsible for defining network communication protocol standards.

• W3C (World Wide Web Consortium): Responsible for setting standards for web-related technologies.

With the joint efforts of these organizations, WebRTC gradually became an open, standardized technology, supported by major browsers like Chrome, Firefox, Safari, and Edge. It ultimately became one of the fundamental technologies for real-time communication on the web.

How WebRTC Works (Technically)

WebRTC (Web Real-Time Communication) enables voice streaming over the internet. In simple terms, it's like a built-in communications toolbox inside your browser, allowing direct voice, video, and data transmission between computers or mobile devices—without the need for complex server intermediaries.

Here are the core steps and technologies involved in voice streaming via WebRTC:

1. Access and Process Local Media (Get Media)

First, WebRTC needs to access your device’s audio input. This is done using browser APIs, which often trigger a pop-up asking for permission to use your microphone.

• getUserMedia() API: This is the starting point of WebRTC. It requests access to your microphone from the operating system. Once granted, your voice is captured.

• Audio Processing: Raw audio signals are large in size. WebRTC digitizes, encodes, and compresses the audio using an audio codec like Opus, which is high-performance and low-latency—ideal for real-time communication.

2. Establishing Peer-to-Peer Connection

The key strength of WebRTC is its ability to establish peer-to-peer (P2P) connections, enabling direct communication between devices without routing data through a central server. This dramatically reduces latency.

• SDP (Session Description Protocol): Devices exchange call configuration information via SDP, such as:

  • Supported audio codecs (e.g., do both support Opus?)

  • IP addresses and port numbers

• ICE (Interactive Connectivity Establishment): Because of complex network environments (like firewalls, routers, or NATs), direct connections can be hard to establish. ICE is a framework to help solve this by trying multiple connection methods:

  • STUN servers: Help a device discover its public IP address.

  • TURN servers: Act as relays when a direct connection isn’t possible due to strict network restrictions—though this introduces additional latency.

3. Real-Time Streaming

Once a P2P connection is established, voice data starts flowing in real time. WebRTC uses two core protocols for this:

• RTP (Real-time Transport Protocol): Packs compressed audio into data packets, adding timestamps and sequence numbers so the receiving side can reassemble the audio in the correct order.

• UDP (User Datagram Protocol): Unlike TCP, UDP is “unreliable”—it doesn't guarantee packet delivery or retransmit lost packets. But for real-time communication, this is a benefit—it’s fast and minimizes latency. Occasional lost packets have minimal impact on overall voice quality.

4. Rendering Audio (Playback)

After receiving RTP packets, WebRTC performs the following processing steps:

• Jitter Buffer: Network instability can cause packets to arrive at irregular intervals (jitter). The receiving end temporarily stores them in a buffer, reorders them, and delivers them at a steady pace to the decoder.

• Decoding and Playback: The compressed audio is decoded and converted back into analog signals, then played through your headphones or speakers.

Summary: How WebRTC Enables Voice over the Web

1. Capture your microphone audio and compress it using the efficient Opus codec.

2. Exchange session details (SDP) and use ICE (STUN/TURN) to determine the best path for a P2P connection.

3. Stream the audio using RTP over UDP, ensuring fast and low-latency transmission.

4. On the receiving end, buffer and reorder packets to handle jitter, decode the audio, and play it back.

All of this complex processing happens automatically inside your browser, which is why it's so easy to make voice calls on many websites without installing any extra software or plugins.

Let me know if you want this translated into more technical or simplified English, or adapted for documentation, a presentation, or educational content.