Librería WebRTC para Delphi — P2P, ICE, STUN, TURN, DataChannel
Implementación Pascal nativa de la pila peer-to-peer WebRTC: RTCPeerConnection, recopilación de candidatos ICE y comprobaciones de conectividad, cliente y servidor STUN y TURN, acuerdo de claves DTLS-SRTP y data channels SCTP — con la señalización WebSocket ya conectada.
Lleva P2P de calidad navegador a Delphi — sin empaquetar Chromium.
Una librería WebRTC para Delphi permite a dos procesos Delphi (o a un proceso Delphi y un navegador) establecer un canal directo, atravesado por NAT, cifrado de extremo a extremo, sin enrutar el payload por un servidor central. sgcWebSockets aporta cada bloque de construcción WebRTC como componente Pascal: TsgcRTCPeerConnection refleja la API RTCPeerConnection del W3C, TsgcSTUNClient / TsgcSTUNServer implementan RFC 8489, TsgcTURNClient / TsgcTURNServer implementan RFC 8656, y TsgcICEClient, un agente ICE completo, los une.
A diferencia de las pilas basadas en navegador (que requieren Chromium o libwebrtc — decenas de megabytes de código nativo y una compilación complicada), la implementación de sgcWebSockets es Pascal puro sobre OpenSSL y se compila dentro de tu binario. Funciona desde Delphi 7 hasta Delphi 13 y se distribuye con binarios nativos para Win32/Win64, Linux64, macOS, iOS y Android.
Enterprise para los componentes, más el pack sgcWebRTC para offer y answer, DataChannels y tracks. Ambos se incluyen en All-Access.
Bloques de construcción
Cada componente WebRTC, expuesto
La peer connection es la cabecera, pero las piezas de soporte también son componentes de primera clase.
RTCPeerConnection
TsgcRTCPeerConnection refleja la API del W3C: CreateOffer, CreateAnswer, SetLocalDescription, SetRemoteDescription, AddIceCandidate, CreateDataChannel, AddTrack. Ver RTCPeerConnection.
Oferta / respuesta SDP
Serializador y parser SDP integrados. Genera ofertas, acepta respuestas, hace trickle de candidatos ICE con el mismo formato de wire que producen Chrome y Firefox.
Agente ICE
Recopilación completa de candidatos: host, server-reflexive (descubierto por STUN), relayed (asignado por TURN). Emparejamiento, priorización y comprobaciones de conectividad según RFC 8445. Página ICE.
Cliente + servidor STUN
Cliente STUN y servidor STUN autónomos para descubrimiento de NAT y keep-alive. Ejecuta tu propio endpoint STUN con dos líneas de Pascal.
Cliente + servidor TURN
Cliente TURN para asignación de relay y servidor TURN para autoalojarlo. Credenciales de largo plazo, IPv4 + IPv6.
DTLS-SRTP
El protocolo de acuerdo de claves obligatorio de WebRTC. Handshake DTLS 1.2 sobre la misma ruta UDP negociada por ICE, exportando material de claves para SRTP.
Data channels SCTP
Mensajes fiables / no fiables, ordenados / no ordenados sobre el transporte de medios WebRTC — la forma estándar de enviar datos arbitrarios de aplicación peer-to-peer.
Señalización WebSocket
Usa los TsgcWebSocketClient / TsgcWebSocketHTTPServer incluidos como canal de señalización, o la pareja de protocolos ya preparada TsgcWSPClient_RTCPeerConnection y TsgcWSPServer_RTCPeerConnection. Una sola librería para todo.
Señalización
Señalización WebSocket: el patrón estándar
WebRTC no define un protocolo de señalización — tienes que aportar el tuyo. La elección convencional es un canal WebSocket que transporta tres tipos de mensaje: offer (SDP del llamante), answer (SDP del llamado) y ice-candidate (candidatos hechos trickle por cualquiera de los lados). sgcWebSockets incluye ya ambos extremos de ese canal. TsgcWSPServer_RTCPeerConnection empareja a un llamante con un llamado y retransmite sus descripciones y candidatos, TsgcWSPClient_RTCPeerConnection es el cliente correspondiente, y TsgcWSPServer_WebRTC hace el mismo trabajo para pares de navegador, enviando la lista de servidores ICE a cada uno según se une.
Como el componente de peer connection y el servidor de señalización viven en la misma librería, puedes levantar una aplicación WebRTC completa — descubrimiento coordinado, traversal de NAT, payload P2P cifrado — sin integrar un solo SDK de terceros.
Traversal de NAT
Configurando servidores ICE
La misma lista iceServers que usa un navegador, expuesta como RTCOptions.ICEServers — con servidores públicos y tu propio TURN privado.
uses
sgcP2P, sgcP2P_DataChannel;
// TFormPeer contiene FPeer, FChannel y 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 saliente. CreateDataChannel activa RTCOptions.DTLS
FChannel := FPeer.CreateDataChannel('chat');
FChannel.OnMessage := OnChannelMessage;
FPeer.CreateOffer;
end;
procedure TFormPeer.OnLocalDescription(Sender: TObject;
const aType, aSDP: string);
begin// aType es 'offer' o '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// se dispara en un hilo worker, sincroniza antes de tocar un control
FIncoming.Add(aText);
end;
// envía un mensaje peer to peer
FChannel.Send('Hello from Delphi');
Autoalojado
Ejecuta tu propio STUN / TURN en Delphi
La mayoría de equipos arrancan con STUN público de Google y un servicio TURN de terceros (Twilio, Xirsys, coturn). Cuando el tráfico crece, la factura de ancho de banda del relay crece también — y TURN es, en la práctica, la única pieza de WebRTC donde pagas por byte. La librería te permite autoalojarlo: TsgcSTUNServer y TsgcTURNServer encajan en una aplicación de consola o en un servicio Windows y responden por defecto en UDP 3478, en el puerto y la dirección que pongas en Bindings. Credenciales de largo plazo, IPv4 e IPv6, un rango de puertos de relay en TURNOptions.Allocation y una cuota de asignaciones por usuario están todos integrados.