Uma implementação Pascal nativa da stack peer-to-peer do WebRTC: RTCPeerConnection, coleta de candidatos ICE e checks de conectividade, cliente + servidor STUN e TURN, acordo de chaves DTLS-SRTP e data channels SCTP — com signalling via WebSocket já conectado.
Traga P2P em nível de navegador para o Delphi — sem empacotar o Chromium.
Uma biblioteca WebRTC Delphi deixa dois processos Delphi (ou um processo Delphi e um navegador) estabelecerem um canal direto, com NAT traversal e criptografia ponta a ponta, sem rotear o payload por um servidor central. O sgcWebSockets fornece cada bloco de construção do WebRTC como um componente Pascal: TsgcRTCPeerConnection espelha a API RTCPeerConnection do W3C, TsgcSTUNClient / TsgcSTUNServer implementam a RFC 8489, TsgcTURNClient / TsgcTURNServer implementam a RFC 8656, e TsgcICEClient, um agente ICE completo, amarra tudo.
Diferente de stacks baseadas em navegador (que exigem Chromium ou libwebrtc — dezenas de megabytes de código nativo e um build complicado), a implementação do sgcWebSockets é Pascal puro sobre OpenSSL e é compilada dentro do seu binário. Roda do Delphi 7 ao Delphi 13 e entrega binários nativos para Win32/Win64, Linux64, macOS, iOS e Android.
Enterprise para os componentes, mais o pack sgcWebRTC para offer e answer, DataChannels e tracks. Ambos vêm no All-Access.
Blocos de construção
Cada componente WebRTC, exposto
A peer connection é o destaque, mas as peças de apoio são componentes de primeira classe também.
RTCPeerConnection
TsgcRTCPeerConnection espelha a API do W3C: CreateOffer, CreateAnswer, SetLocalDescription, SetRemoteDescription, AddIceCandidate, CreateDataChannel, AddTrack. Veja RTCPeerConnection.
Offer / answer SDP
Serializador e parser SDP embutidos. Gere offers, aceite answers, faça trickle de candidatos ICE com o mesmo formato de fio que Chrome e Firefox produzem.
Agente ICE
Coleta completa de candidatos: host, server-reflexive (descoberto por STUN), relayed (alocado por TURN). Pareamento, priorização e checks de conectividade conforme a RFC 8445. Página ICE.
Cliente + servidor STUN
Cliente STUN e servidor STUN standalone para descoberta de NAT e keep-alive. Rode seu próprio endpoint STUN com duas linhas de Pascal.
Cliente + servidor TURN
Cliente TURN para alocação de relay e servidor TURN para self-hosting. Credenciais de longo prazo, IPv4 + IPv6.
DTLS-SRTP
O protocolo obrigatório de acordo de chaves do WebRTC. Handshake DTLS 1.2 sobre o mesmo caminho UDP negociado por ICE, exportando keying material para SRTP.
Data channels SCTP
Mensagens confiáveis / não confiáveis, ordenadas / não ordenadas sobre o transporte de mídia WebRTC — a forma padrão de enviar dados arbitrários da aplicação peer-to-peer.
Signalling WebSocket
Use os TsgcWebSocketClient / TsgcWebSocketHTTPServer inclusos como seu canal de signalling, ou o par de protocolos pronto TsgcWSPClient_RTCPeerConnection e TsgcWSPServer_RTCPeerConnection. Uma biblioteca para tudo.
Signalling
Signalling via WebSocket: o padrão
WebRTC não define um protocolo de signalling — você traz o seu. A escolha convencional é um canal WebSocket que carrega três tipos de mensagem: offer (SDP do chamador), answer (SDP do chamado) e ice-candidate (candidatos enviados em trickle por qualquer lado). O sgcWebSockets já inclui as duas pontas desse canal. TsgcWSPServer_RTCPeerConnection emparelha um chamador com um chamado e repassa as descrições e os candidatos entre eles, TsgcWSPClient_RTCPeerConnection é o cliente correspondente, e TsgcWSPServer_WebRTC faz o mesmo trabalho para peers de navegador, enviando a lista de servidores ICE para cada um que entra.
Como o componente de peer connection e o servidor de signalling vivem na mesma biblioteca, você pode subir uma aplicação WebRTC completa — descoberta coordenada, NAT traversal, payload P2P criptografado — sem integrar um único SDK de terceiros.
NAT traversal
Configurando servidores ICE
A mesma lista iceServers que um navegador usa, exposta como RTCOptions.ICEServers — com servidores públicos e seu próprio TURN privado.
uses
sgcP2P, sgcP2P_DataChannel;
// TFormPeer mantém FPeer, FChannel e FIncoming: TStringListprocedure 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;
// lado de saída. CreateDataChannel ativa RTCOptions.DTLS
FChannel := FPeer.CreateDataChannel('chat');
FChannel.OnMessage := OnChannelMessage;
FPeer.CreateOffer;
end;
procedure TFormPeer.OnLocalDescription(Sender: TObject;
const aType, aSDP: string);
begin// aType é 'offer' ou '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// disparado em uma thread worker, faça o marshal antes de tocar em um controle
FIncoming.Add(aText);
end;
// envia uma mensagem peer-to-peer
FChannel.Send('Hello from Delphi');
Self-host
Rode seu próprio STUN / TURN em Delphi
A maioria das equipes começa com o Google STUN público e um serviço TURN de terceiros (Twilio, Xirsys, coturn). Quando o tráfego cresce, a conta de banda de relay também cresce — e TURN é, na prática, a única peça do WebRTC em que você paga por byte. A biblioteca permite self-hosting: TsgcSTUNServer e TsgcTURNServer caem em uma aplicação de console ou em um serviço Windows e respondem por padrão na UDP 3478, na porta e no endereço que você colocar em Bindings. Credenciais de longo prazo, IPv4 e IPv6, uma faixa de portas de relay em TURNOptions.Allocation e uma cota de alocação por usuário são todos embutidos.