How Signaling Powers Real‑Time Audio/Video: Inside NERTC’s Network Library

What Is Signaling

Signaling is the essential bridge in real‑time audio/video systems that negotiates media capabilities, identifies participants, controls session flow, and resolves simultaneous session changes. WebRTC does not prescribe a specific signaling protocol, allowing custom implementations.

Single PeerConnection Scheme

To improve performance, NERTC adopts a single‑PeerConnection design where each client creates two PeerConnections (send‑only and recv‑only) and uses a unified WebSocket‑based signaling protocol across iOS, Android, Windows, macOS and Web.

WebSocket Communication Overview

WebSocket provides a full‑duplex channel over a single TCP connection, enabling the server to push messages and the client to send messages without the request‑response limitation of HTTP.

WebSocket Handshake

The handshake upgrades an HTTP connection to WebSocket:

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

Server response:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat

Connection Keep‑Alive

WebSocket uses ping/pong frames (opcode 0x9 and 0xA) to verify that the peer is still responsive; a missing pong triggers reconnection.

Connection Close

When a client initiates closure, it sends a close frame; the peer must reply with its own close frame before the underlying TCP connection is terminated.

Application in NERTC

NERTC’s network library is built on a modular architecture:

API : external interface for the SDK.

Transport : abstracts message transport and connection management (WebSocket, future QUIC).

Message : packs and unpacks WebSocket sub‑protocol messages.

SendBuffer : caches messages and handles retransmission.

Peer : core controller that coordinates Transport, Message and other modules.

Fast Connect and Reconnect Design

Five reconnection scenarios are covered:

Initial connection uses exponential back‑off (200/400/600 ms) with rapid retries.

After a successful connection, disconnection triggers either a server‑initiated onClose event or a client‑detected timeout after three unanswered ping frames, followed by retry intervals of 2/4/6 s.

On onDisconnected, the client switches to an alternative server address and retries until all servers are exhausted.

Network recovery prompts an active reconnection attempt.

If the server explicitly closes the connection, the library clears the cache and stops further retries.

Message Cache and Retransmission

Two message types exist:

Request : expects a response and is cached.

Notification : fire‑and‑forget, not cached.

All outbound messages first enter the SendBuffer. If the connection is healthy, they are sent immediately; otherwise they wait until reconnection succeeds. Upon server‑initiated kick‑off or client‑initiated closure, the cache is cleared.

Performance in Weak Networks

Tests show the library tolerates up to 50 % packet loss. Under severe loss, TCP’s flow control may hit a “window full” state, requiring a reconnection to resume transmission.

Future Plans & Summary

To further improve weak‑network resilience, NERTC is exploring UDP‑based transports such as QUIC, which are nearing productization. In summary, the article covered signaling fundamentals, NERTC’s signaling flow, modular network library design, fast reconnection strategies, and message caching mechanisms.