A native Pascal implementation of the WebRTC peer-to-peer stack: RTCPeerConnection, ICE candidate gathering and connectivity checks, STUN and TURN client + server, DTLS-SRTP key agreement and SCTP data channels — with WebSocket signalling already wired in.
Bring browser-grade P2P to Delphi — without bundling Chromium.
A Delphi WebRTC library lets two Delphi processes (or a Delphi process and a browser) establish a direct, NAT-traversed, end-to-end-encrypted channel without routing payload through a central server. sgcWebSockets provides every WebRTC building block as a Pascal component: TsgcRTCPeerConnection mirrors the W3C RTCPeerConnection API, TsgcSTUNClient / TsgcSTUNServer implement RFC 8489, TsgcTURNClient / TsgcTURNServer implement RFC 8656, and TsgcICEClient, a complete ICE agent, ties them together.
Unlike browser-based stacks (which require Chromium or libwebrtc — tens of megabytes of native code and a complicated build) the sgcWebSockets implementation is pure Pascal on top of OpenSSL and is compiled into your binary. It runs on Delphi 7 through Delphi 13 and ships native binaries for Win32/Win64, Linux64, macOS, iOS and Android.
TsgcRTCPeerConnection
RFC 8825 / 8445 / 8489 / 8656 / 6347 / 4960 / 8831
Enterprise for the components, plus the sgcWebRTC pack for offer and answer, DataChannels and tracks. Both ship in All-Access.
The peer connection is the headline, but the supporting pieces are first-class components too.
TsgcRTCPeerConnection mirrors the W3C API: CreateOffer, CreateAnswer, SetLocalDescription, SetRemoteDescription, AddIceCandidate, CreateDataChannel, AddTrack. See RTCPeerConnection.
Built-in SDP serialiser and parser. Generate offers, accept answers, trickle ICE candidates with the same wire format Chrome and Firefox produce.
Full candidate gathering: host, server-reflexive (STUN-discovered), relayed (TURN-allocated). Pairing, prioritisation and connectivity checks per RFC 8445. ICE page.
Stand-alone STUN client and STUN server for NAT discovery and keep-alive. Run your own STUN endpoint with two lines of Pascal.
TURN client for relay allocation and TURN server for self-hosting. Long-term credentials, IPv4 + IPv6.
The mandatory WebRTC key-agreement protocol. DTLS 1.2 handshake over the same ICE-negotiated UDP path, exporting keying material for SRTP.
Reliable / unreliable, ordered / unordered messages over the WebRTC media transport — the standard way to send arbitrary application data peer-to-peer.
Use the bundled TsgcWebSocketClient / TsgcWebSocketHTTPServer as your signalling channel, or the ready-made TsgcWSPClient_RTCPeerConnection and TsgcWSPServer_RTCPeerConnection protocol pair. One library for everything.
WebRTC does not define a signalling protocol — you bring your own. The conventional choice is a WebSocket channel that carries three message types: offer (SDP from the caller), answer (SDP from the callee) and ice-candidate (candidates trickled by either side). sgcWebSockets includes both ends of that channel already. TsgcWSPServer_RTCPeerConnection pairs a caller with a callee and relays their descriptions and candidates, TsgcWSPClient_RTCPeerConnection is the matching client, and TsgcWSPServer_WebRTC does the same job for browser peers, pushing the ICE server list to each one as it joins.
Because the peer-connection component and the signalling server live in the same library, you can stand up a complete WebRTC application — coordinated discovery, NAT traversal, encrypted P2P payload — without integrating a single third-party SDK.
The same iceServers list a browser uses, exposed as RTCOptions.ICEServers — with both public servers and your own private TURN.
uses
sgcP2P, sgcP2P_DataChannel;
// TFormPeer holds FPeer, FChannel and FIncoming: TStringList
procedure TFormPeer.CreatePeer;
begin
FPeer := TsgcRTCPeerConnection.Create(nil);
FPeer.RTCOptions.ICEServers.AddURL('stun:stun.l.google.com:19302');
FPeer.RTCOptions.ICEServers.AddURL('turn:turn.example.com:3478',
'alice', 's3cret');
FPeer.OnLocalDescription := OnLocalDescription;
FPeer.OnIceCandidate := OnIceCandidate;
FPeer.OnDataChannel := OnDataChannel;
// outbound side. CreateDataChannel turns RTCOptions.DTLS on
FChannel := FPeer.CreateDataChannel('chat');
FChannel.OnMessage := OnChannelMessage;
FPeer.CreateOffer;
end;
procedure TFormPeer.OnLocalDescription(Sender: TObject;
const aType, aSDP: string);
begin
// aType is 'offer' or 'answer'
SignalToPeer(aType, aSDP);
end;
procedure TFormPeer.OnIceCandidate(Sender: TObject;
const aCandidate, aSdpMid: string; aSdpMLineIndex: Integer);
begin
SignalCandidate(aCandidate, aSdpMid, aSdpMLineIndex);
end;
procedure TFormPeer.OnDataChannel(Sender: TObject;
aChannel: TsgcRTCDataChannel);
begin
FChannel := aChannel;
FChannel.OnMessage := OnChannelMessage;
end;
procedure TFormPeer.OnChannelMessage(Sender: TObject;
const aText: string);
begin
// fires on a worker thread, marshal before you touch a control
FIncoming.Add(aText);
end;
// send a message peer to peer
FChannel.Send('Hello from Delphi');Most teams start with public Google STUN and a third-party TURN service (Twilio, Xirsys, coturn). When traffic ramps up, the relay bandwidth bill ramps up too — and TURN is, in practice, the only piece of WebRTC where you pay per-byte. The library lets you self-host: TsgcSTUNServer and TsgcTURNServer drop into a console application or a Windows service and answer on UDP 3478 by default, on whatever port and address you put in Bindings. Long-term credentials, IPv4 and IPv6, a relay port range in TURNOptions.Allocation and a per-user allocation quota are all built in.
The whole job on one page. Signalling, the offer and answer, ICE candidates, when STUN is enough and when you need TURN, data channels, and audio and video tracks. One of the Delphi use cases.
Landing page for every peer-to-peer component.
Detailed component reference.
Candidate gathering and connectivity checks.
End-to-end walkthrough of a Delphi-to-Delphi data channel.
Self-hosting your own STUN/TURN infrastructure in Delphi.
Cross-referencing the reference C implementation for interoperability tests.