WebRTC: check implementation, signaling and ICE

Check implementation first

WebRtcPeerConnection is a connection interface. It needs a working implementation for the target platform. A checked clean Reckfell 1.0.0 Windows C# project without an external implementation selects the empty WebRTCPeerConnectionExtension. An SDK class alone does not establish working exchange.

Attach RtcBackendProbe.cs to an Entity in a separate C# level, build and press F6. This clean project should print WebRTC: implementation missing; the engine also warns that no default extension is configured. The probe deliberately avoids calling methods on the empty implementation.

using Reckfell;

public partial class RtcBackendProbe : Entity
{
    public string NativeClass { get; private set; } = "";
    public bool MissingImplementation { get; private set; }
    public Error? InitializeResult { get; private set; }
    private WebRtcPeerConnection? _peer;
    public override void _Ready()
    {
        _peer = new WebRtcPeerConnection(); NativeClass = _peer.GetClass().ToString();
        using Variant script = _peer.GetScript();
        MissingImplementation = NativeClass == "WebRTCPeerConnectionExtension" && script.VariantType == Variant.Type.Nil;
        if (MissingImplementation) { ReckfellApi.Print("WebRTC: implementation missing"); return; }
        InitializeResult = _peer.Initialize();
        ReckfellApi.Print($"WebRTC: implementation={NativeClass}, initialize={InitializeResult}; connection not established by this probe");
    }
    public override void _ExitTree()
    { if (!MissingImplementation) _peer?.Close(); _peer?.Dispose(); _peer = null; }
}

The check distinguishes the default empty class without a script from a selected implementation. Another type still needs Initialize, actual exchange and closing tests on its target platform. The probe itself establishes no connection.

Calling required virtual _initialize on the empty implementation logs an engine error, yet its Error return can be the default Error.Ok. A separate check reproduces this behavior. Error.Ok, an SDK class and successful compilation are therefore insufficient evidence of working WebRTC.

A native backend needs a registered WebRTCPeerConnectionExtension implementation and related channels. SetDefaultExtension selects a registered class; it does not download/start a library. The web implementation uses browser WebRTC, but that does not imply an available C# export or support for a particular browser. Verify ABI and the target 1.0.0 build before using an extension.

What is needed beyond a backend

Signaling exchanges setup data through a separate channel, such as your HTTPS/WebSocket service. It is neither WebRTC game-state delivery nor a service created by CreateOffer.

Both participants must belong to the correct signaling session. Do not apply unrelated SDP/ICE to an arbitrary connection. Message order, replay, lifetime and signaling authorization belong to your application.

Establishment order

1. Create a peer, connect SessionDescriptionCreated, IceCandidateCreated and DataChannelReceived, and configure the implementation through Initialize.
2. On the initiator, create the required data channel before CreateOffer. On SessionDescriptionCreated, apply SetLocalDescription and send type/sdp to the other participant.
3. Apply incoming remote SDP with SetRemoteDescription. The answering side also sends its generated local SDP through signaling.
4. Send IceCandidateCreated data through signaling and apply remote candidates with AddIceCandidate. Coordinate candidate buffering with remote-description readiness in your implementation.
5. Continue Poll. Send gameplay only after the channel actually opens; handle failure/closing rather than waiting forever for one signal.

This is the API workflow, not a verified connected example for the current empty Windows backend. Test the implementation, signaling service, platform pairs, NAT/TURN, network loss and subsequent sessions before claiming support.

Keep layers separate

WebRtcDataChannel transfers data; WebRtcMultiplayerPeer connects suitable peers to high-level MultiplayerApi. A raw data channel does not automatically become an RPC lobby. Channel order/reliability options do not replace payload validation or server permissions.

On completion, close channels/peer and remove them from the signaling session; do not feed new SDP/ICE into an old closed instance. For ordinary native server multiplayer without browser WebRTC, start with the verified ENet lobby. HTTP or WebSocket may suffice for a service connection.