Cloudflare calls

[RichardFoss]

Hi there,

I am building a WebRTC Producer on an M1 Mac using node-datachannel to stream audio to Cloudflare Calls (an SFU). I’ve run into a significant hurdle regarding the SDP handshake.

The Setup:

Local: node-datachannel (v0.11.x) on macOS.

Remote: Cloudflare Calls SFU (ICE-Lite).

Role: Local is Producer (Offer), Cloudflare is Answerer.

The Problem:
Cloudflare Calls is designed for "Trickle ICE" browsers. Its initial SDP Answer is "minimal"—it lacks the a=ice-ufrag and a=ice-pwd attributes in the initial response, as it expects to trade these via ICE candidates later.

When I pass this minimal SDP to pc.setRemoteDescription(sdp, "answer"), the library correctly throws:
Error: libdatachannel error while adding remote description: Remote description has no ICE user fragment.

What I've Tried:
I have attempted to manually "reconstruct" a full SDP Answer in my signaling worker by injecting a dummy ufrag/pwd and the Cloudflare Anycast IP (162.159.195.1). While this satisfies the parser, the ICE state ultimately moves to failed because the credentials don't match the SFU's internal session state.

The Question:
Is there a recommended pattern for using node-datachannel with an SFU that doesn't provide ICE credentials until the "Trickle" phase? Can I manually set the ICE credentials on the PeerConnection after setRemoteDescription, or is there a way to force the library to wait for a "complete" SDP before starting the handshake?

Any advice on bridging the gap between a Non-Trickle client and a Trickle-heavy SFU would be greatly appreciated.

[paullouisageneau]

Cloudflare Calls is designed for "Trickle ICE" browsers. Its initial SDP Answer is "minimal"—it lacks the a=ice-ufrag and a=ice-pwd attributes in the initial response, as it expects to trade these via ICE candidates later.

Could you give more details? With Trickle ICE, candidates are sent later, but ice-ufrag and ice-pwd are still mandatory attributes in both SDP offers and answers according to RFC 5245 and RFC 8839, and you can't transmit the ice-pwd via an ICE candidate anyway. Is this a non-standard extension? Do you have an example?

Local: node-datachannel (v0.11.x) on macOS.

This version is from 2024, I think you should update.

[RichardFoss]

Thank you for the feedback, much appreciated! I’ve confirmed that Cloudflare Calls (as an ICE-Lite SFU) is indeed non-standard; it returns a 'minimal' SDP answer that lacks the ice-ufrag and ice-pwd attributes entirely.

I have attempted to work around this by manually injecting the ufrag and pwd (symmetric to the offer) into the remote description before calling setRemoteDescription. My SDP now looks like this:

Code snippet
v=0
o=- 0 0 IN IP4 127.0.0.1
s=-
t=0 0
a=ice-lite
m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 162.159.195.1
a=mid:immergo-spatial
a=sendonly
a=ice-ufrag:+y80
a=ice-pwd:TP9mFV3mcLRPFroNV4mkM6
a=setup:passive
a=fingerprint:sha-256 [REAL_FINGERPRINT_FROM_SFU]
a=rtpmap:111 opus/48000/2
a=candidate:1 1 UDP 2122260223 162.159.195.1 443 typ host
Even with this 'compliant' string, the PeerConnection moves to failed then closed.

Does node-datachannel require the SFU to generate its own unique ufrag/pwd, or should symmetric credentials work?

Is there a way to enable verbose logging in the Node.js wrapper to see if the failure is occurring during the STUN check or the DTLS handshake?

Since Cloudflare expects 'Trickle ICE' and doesn't provide these values in the SDP, is node-datachannel currently capable of connecting to an SFU that behaves this way?

[RichardFoss]

I meant to add, I am using v0.32.1 of node-datachannel. Apologies, I had already updated!

[RichardFoss]

And just a follow up, simpler query: - Cloudflare's SFU requires the client to connect via ICE before a track is added, but it only provides ICE credentials after a track is added. Is there a way for node-datachannel to handle this circular dependency by initiating a 'bare' ICE connection without a media track or credentials in the initial SDP?

[paullouisageneau]

Thank you for the feedback, much appreciated! I’ve confirmed that Cloudflare Calls (as an ICE-Lite SFU) is indeed non-standard; it returns a 'minimal' SDP answer that lacks the ice-ufrag and ice-pwd attributes entirely.

Just a clarification here, this is not about ICE-lite or Trickle ICE. They are standard and supported, but the thing is that both endpoints must still include both ice-ufrag and ice-pwd attributes.

Does node-datachannel require the SFU to generate its own unique ufrag/pwd, or should symmetric credentials work?

It needs to know what ufrag and pwd to use to authenticate with the SFU, and credentials are not symmetrical.

Is there a way to enable verbose logging in the Node.js wrapper to see if the failure is occurring during the STUN check or the DTLS handshake?

Yes, nodeDataChannel.initLogger('Verbose') enables verbose logging in libdatachannel.

Since Cloudflare expects 'Trickle ICE' and doesn't provide these values in the SDP, is node-datachannel currently capable of connecting to an SFU that behaves this way?

I don't think any WebRTC endpoint would be capable of connecting to an SFU behaving this way, so either the SFU expects non-standard client behavior or you are doing something wrong. Is there some documentation?

And just a follow up, simpler query: - Cloudflare's SFU requires the client to connect via ICE before a track is added, but it only provides ICE credentials after a track is added. Is there a way for node-datachannel to handle this circular dependency by initiating a 'bare' ICE connection without a media track or credentials in the initial SDP?

If there is such a circular dependency, you are probably not using the service correctly. You can't connect via ICE without ICE credentials. Also, you can't open a peer connection without media, you must offer a track. Could you please give an example of SDP exchange?

[RichardFoss]

Thank you for your comprehensive response and apologies for my slow reply. I have been trying to resolve my cloudflare communication issue, but still without success.

Here is an example of my exchange from my node.js server code (using node-datachannel) to the cloudflare SFU app via a cloudflare worker.

This is the relevant part of the code that I use to communicate with the worker:

async function initWebRTC() {
  console.log("Setting up Cloudflare WebRTC Bridge...");  
  // --- 0. ENABLE VERBOSE LOGGING ---
  nodeDataChannel.initLogger("Verbose");
  // 1. Initialize PeerConnection
  pc = new nodeDataChannel.PeerConnection("ImmerGo-Producer", {
    iceServers: ["stun:stun.cloudflare.com:3478"]
  });
  // 2. Create and Add the Audio Track
  try {
    const audio = new nodeDataChannel.Audio("immergo-spatial", "sendonly");
    audioTrack = pc.addTrack(audio);
  } catch (e) {
    console.error("Critical: Could not add track.");
    return;
  }
  // 3. Generate Local SDP Offer
  await pc.setLocalDescription();
  const localSdp = pc.localDescription().sdp;
  // 4. Send to Worker
  try {
    const response = await fetch("https://immergo-hub.r-foss.workers.dev/calls/start-producer", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        authKey: "A secret key",
        sdp: localSdp
      })
    });
    if (!response.ok) {
        console.error("❌ Worker Error Status:", response.status);
        return;
    }

On the cloudflare worker side, I am receiving the sdp and trying to modify it so that the cloudflare SFU accepts it.

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    if (request.method === "OPTIONS") return new Response(null, { headers: corsHeaders });

    try {
      if (url.pathname === "/calls/start-producer") {
        const authBody = await request.json(); // Simple read for diagnosis
        
        const midMatch = authBody.sdp.match(/a=mid:([^\r\n\s]+)/i);
        const actualMid = midMatch ? midMatch[1].trim() : "0";
        
        // standard line endings \r\n (CRLF) 
        const ssrc = "123456789";
        const msid = "immergo-audio-v1";

		let sanitizedSdp = authBody.sdp
          .split('\n')
          .map(line => {
            let l = line.trim();
            if (l.startsWith('m=audio')) return 'm=audio 9 UDP/TLS/RTP/SAVPF 111';
            if (l.startsWith('a=ice-ufrag:')) return 'a=ice-ufrag:placeholderufrag';
            if (l.startsWith('a=ice-pwd:')) return 'a=ice-pwd:placeholderpwdplaceholderpwd';
            if (l.includes('a=setup:')) return 'a=setup:actpass';
            if (l.includes('a=ice-lite')) return null;
            if (l.includes('a=group:LS')) return null;
            return l;
          })
          .filter(line => line !== null && line !== "") // Remove any accidental empty lines
          .join('\r\n');

        sanitizedSdp += `\r\na=rtpmap:111 opus/48000/2`;
        sanitizedSdp += `\r\na=rtcp-mux`;
        sanitizedSdp += `\r\na=msid:${msid} ${msid}`;
        sanitizedSdp += `\r\na=ssrc:${ssrc} cname:immergo-m1`;
        sanitizedSdp += `\r\na=ssrc:${ssrc} msid:${msid} ${msid}\r\n`;

        // --- THE DIAGNOSTIC LOG ---
        console.log("--- START RAW SDP SENDING TO CLOUDFLARE ---");
        console.log(sanitizedSdp);
        console.log("--- END RAW SDP ---");
        console.log("Requested MID in API JSON:", actualMid);

        const res = await fetch(`https://rtc.live.cloudflare.com/v1/apps/${env.CLOUDFLARE_APP_ID}/sessions/new`, {
          method: 'POST',
          headers: { 
            'Authorization': `Bearer ${env.CALLS_APP_SECRET.trim()}`,
            'Content-Type': 'application/json' 
          },
          body: JSON.stringify({
            sessionDescription: { sdp: sanitizedSdp, type: 'offer' },
            tracks: [{ location: 'local', mid: actualMid, trackName: "immergo-spatial" }]
          })
        });

        const data = await res.json();
        console.log("Cloudflare Response:", JSON.stringify(data));

        return new Response(JSON.stringify(data), { headers: corsHeaders });
      }
    } catch (e) {
      console.error("DIAGNOSTIC ERROR:", e.message);
      return new Response(e.message, { status: 500 });
    }

Here is the log that I get:

POST https://immergo-hub.r-foss.workers.dev/calls/start-producer - Ok @ 2026/03/02, 22:26:35
(log) --- START RAW SDP SENDING TO CLOUDFLARE ---
(log) v=0
o=rtc 187079149 0 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE immergo-spatial
a=msid-semantic:WMS *
a=ice-options:ice2,trickle
a=fingerprint:sha-256 C3:5F:9B:86:E6:F6:29:59:38:E6:AF:C3:5F:32:DA:25:95:38:5F:5F:95:F2:86:16:EE:A2:CE:50:21:8F:9B:6F
m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 192.168.1.3
a=mid:immergo-spatial
a=rtcp-mux
a=setup:actpass
a=ice-ufrag:placeholderufrag
a=ice-pwd:placeholderpwdplaceholderpwd
a=candidate:1 1 UDP 2114977791 192.168.1.3 51906 typ host
a=rtpmap:111 opus/48000/2
a=rtcp-mux
a=msid:immergo-audio-v1 immergo-audio-v1
a=ssrc:123456789 cname:immergo-m1
a=ssrc:123456789 msid:immergo-audio-v1 immergo-audio-v1

(log) --- END RAW SDP ---
(log) Requested MID in API JSON: immergo-spatial
(log) Cloudflare Response: {"sessionDescription":{"sdp":"v=0\r\no=- 8263411384059305768 1772483196 IN IP4 0.0.0.0\r\ns=-\r\nt=0 0\r\na=msid-semantic:WMS*\r\na=fingerprint:sha-256 52:51:B1:02:98:00:B4:70:A9:13:58:9B:E7:C1:F5:2D:D7:CA:8F:F8:11:B5:45:CC:77:8F:71:40:03:35:8E:8A\r\na=ice-lite\r\n","type":"answer"},"sessionId":"cc071c242af48928d2c2d1b425ef996d"}

I'm not getting a complete response back, for example no m=audio line, a=mid line or a=ssrc line in the response.

This might be something that I need to bring up in a cloudflare forum. But if you have any ideas, I would much appreciate them!

[longnguyen2004]

Seems like there's a separate endpoint for generating ICE credentials https://developers.cloudflare.com/realtime/turn/generate-credentials/

[paullouisageneau]

@RichardFoss After a quick look at the Cloudflare Calls Connection API reference, it seems the API call is completely wrong. The session/new endpoint doesn't even expect a sessionDescription parameter. The endpoint expecting an SDP offer and returning the answer is actually tracks/new.
I'm sorry but it looks like you attempted to vibe code this, the LLM generated garbage, resulting in a misunderstanding about ICE compatibility and wasting everyone's time. The problem is not with libdatachannel but with the incorrect usage of the Cloudflare Calls API.
I think you should start by reading the documentation and looking at examples.

Seems like there's a separate endpoint for generating ICE credentials https://developers.cloudflare.com/realtime/turn/generate-credentials/

@longnguyen2004 This is for TURN credentials and unrelated to ICE ufrag and pwd credentials.

[RichardFoss]

Thank you very much for getting back to me Paul-Louis. I have written an immersive sound system (ImmerGo) that has a node.js (electron) server and browser clients. It sends spatialised sound to speakers, but also generates binaural spatialised sound. I would like to transmit the binaural spatialised sound to remote clients. This is a new area for me and you are quite right, I have been using AI (Claude) to help me with this.

The suggestion from Claude was to use your node-datachannel module and a cloudflare SFU for the fan out to clients. The sessions/new POST had a tracks option, in the hope that a new session and track would be created in one step. There were originally issues with a separate sessions/new and tracks/new. I have gone through your documentation and the cloudflare documentation and below are my steps (these are enabled by Claude, but seem to follow your media example steps). I have also added debug messages that I got from node.js. I do see from the cloudflare documentation that there is the possibility of a websocket connection to the SFU, which I might try. I thought though that a WebRTC data channel using your node-datachannel approach would be more reliable with less latency.

node.js producer:
1.
nodeDataChannel.initLogger("Verbose");

Verbose debugging

    pc = new nodeDataChannel.PeerConnection("ImmerGo-Producer", {
        iceServers: ["stun:stun.cloudflare.com:3478"],
        iceTransportPolicy: "all",
        connectionTimeout: 30000,
        reconnectTimeout: 30000
    });

Sets up a local endpoint capable of creating a peer to peer conection, handling ICE server configuration for NAT traversal. 

    const dc = pc.createDataChannel("immergo-control");
    dc.onOpen(() => console.log("Data channel open"));
    dc.onClosed(() => console.log("Data channel closed"));

This sets up a data channel alongside the audio track. Do you think this is necessary? I don't see it in your media examples.

    const audio = new nodeDataChannel.Audio("immergo-spatial", "sendonly");
    audio.addAudioCodec(111, "opus", "minptime=10;useinbandfec=1");
    audioTrack = pc.addTrack(audio);

Creates an audio track named immergo-spatial and adds this track to the peer connection. In your media examples I see a .Video, so assume that there is also a .Audio capability. I'm getting this code from Claude.

   pc.onStateChange((state) => {
        console.log(`WebRTC State: ${state}`);
        if (state === 'connected') {
            isWebRTCReady = true;
            console.log("Producer is connected to Cloudflare!");
        } else if (state === 'failed') {
            console.error("ICE Connection Failed.");
        }
    });

Monitors the peer connection state changes

await pc.setLocalDescription();

generates a local description offer

7. const localSdp = await waitForIceGathering(pc);

   waits for ICE gathering to complete

   The waitForIceGathering function is:

	function waitForIceGathering(pc) {
	    return new Promise((resolve) => {
	        if (pc.gatheringState() === "complete") {
	            resolve(pc.localDescription().sdp);
	            return;
	        }
	        pc.onGatheringStateChange((state) => {
	            console.log("ICE gathering state:", state);
	            if (state === "complete") {
	                resolve(pc.localDescription().sdp);
	            }
	        });
	    });
	}

    const patchedSdp = localSdp
        .replace(/a=ice-options:ice2,trickle\r\n/, '')
        .replace(/a=ice-options:trickle\r\n/, '')
        .replace(/a=ice-options:ice2\r\n/, '')
        .replace(/a=group:LS[^\r\n]*\r\n/, '');

    console.log("Patched SDP:\n", patchedSdp);

    // Send to worker
    const response = await fetch("https://immergo-hub.r-foss.workers.dev/calls/start-producer", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ authKey: "ImmerGo-Key2026-1-8", sdp: patchedSdp })
    });

strips ice2 and trickle options that Cloudflare may not support and sends to cloudflare worker

Worker:

      if (url.pathname === "/calls/start-producer" && request.method === "POST") {
        const body = await request.json();
        const { authKey, sdp } = body;

        if (authKey !== env.IMMERGO_SECRET_AUTH_KEY) {
          return new Response(JSON.stringify({ error: "Unauthorized" }), { status: 401, headers: corsHeaders });
        }

        console.log("--- Sending offer via Calls API ---");

        // Step 1: Create session
        const sessionResponse = await fetch(
          `https://rtc.live.cloudflare.com/v1/apps/${env.CLOUDFLARE_APP_ID}/sessions/new`,
          {
            method: 'POST',
            headers: {
              'Authorization': `Bearer ${env.CALLS_APP_SECRET.trim()}`,
              'Content-Type': 'application/json'
            }
          }
        );
        const sessionData = await sessionResponse.json();
        console.log("Session:", JSON.stringify(sessionData));

        if (sessionData.errorCode) {
          return new Response(JSON.stringify({ error: "Session failed", details: sessionData }),
            { status: 500, headers: corsHeaders });
        }

        const sessionId = sessionData.sessionId;

 Receives a post with the patched sdp and posts an empty session to cloudflare SFU.

    const midMatch = sdp.match(/a=mid:([^\r\n]+)/);
    const mid = midMatch ? midMatch[1].trim() : 'immergo-spatial';
    const ufrag = sdp.match(/a=ice-ufrag:([^\r\n]+)/)[1];
    const pwd = sdp.match(/a=ice-pwd:([^\r\n]+)/)[1];

Pick up mid, ufrag and pwd from the sdp

    const tracksResponse = await fetch(
      `https://rtc.live.cloudflare.com/v1/apps/${env.CLOUDFLARE_APP_ID}/sessions/${sessionId}/tracks/new`,
      {
        method: 'POST',
        headers: {
          'Authorization': `Bearer ${env.CALLS_APP_SECRET.trim()}`,
          'Content-Type': 'application/json'
        },
        body: JSON.stringify({
          sessionDescription: { sdp, type: 'offer' },
          tracks: [{ location: 'local', trackName: 'immergo-spatial', kind: 'audio', mid }]
        })
      }
    );

    const tracksData = await tracksResponse.json(); 

    const bareAnswer = tracksData.sessionDescription.sdp;
    const fingerprint = bareAnswer.match(/a=fingerprint:[^\r\n]+/)[0];

    // Resolve Cloudflare media IP
    const cfIp = '104.18.13.207';

    // Reconstruct a complete valid answer SDP
    const reconstructedSdp =
      `v=0\r\n` +
      `o=- 0 0 IN IP4 0.0.0.0\r\n` +
      `s=-\r\n` +
      `t=0 0\r\n` +
      `a=group:BUNDLE ${mid}\r\n` +
      `a=msid-semantic:WMS*\r\n` +
      `${fingerprint}\r\n` +
      `a=ice-lite\r\n` +
      `m=audio 1473 UDP/TLS/RTP/SAVPF 111\r\n` +
      `c=IN IP4 ${cfIp}\r\n` +
      `a=mid:${mid}\r\n` +
      `a=rtcp-mux\r\n` +
      `a=rtpmap:111 opus/48000/2\r\n` +
      `a=fmtp:111 minptime=10;useinbandfec=1\r\n` +
      `a=setup:passive\r\n` +
      `a=ice-ufrag:${ufrag}\r\n` +
      `a=ice-pwd:${pwd}\r\n` +
      `a=recvonly\r\n` +
      `a=candidate:1 1 UDP 2113937151 ${cfIp} 1473 typ host\r\n` +
      `a=end-of-candidates\r\n`;

    console.log("Reconstructed SDP:", reconstructedSdp);

    return new Response(JSON.stringify({
      sessionId,
      answerSdp: { sdp: reconstructedSdp, type: 'answer' },
      tracks: tracksData.tracks
    }), { headers: { ...corsHeaders, "Content-Type": "application/json" } });

Worker receives track data from cloudflare SFU and constructs and returns a complete answer SDP to node.js

Producer:

await pc.setRemoteDescription(result.answerSdp.sdp, result.answerSdp.type);

starts ICE connectivity checks directly to Cloudflare

Debugging:

The main debug logs that I get are:

Setting up Cloudflare WebRTC Bridge...
Using STUN server "stun.cloudflare.com:3478"
Generated local SDP description: a=ice-ufrag:PHBt
a=ice-pwd:XWEw8pM9saxidcvX4+J9KA
a=ice-options:ice2,trickle

rtc::impl::PeerConnection::populateLocalDescription@1027] Adding application to local description, mid="0"
2026-03-07 16:00:43.681 VERB  [15793147] [rtc::impl::PeerConnection::processLocalDescription@1040] Issuing local description: v=0
o=rtc 3498164665 0 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0
a=msid-semantic:WMS *
a=ice-options:ice2,trickle
a=fingerprint:sha-256 1F:B4:22:F6:2F:5A:79:13:12:BF:06:CD:21:87:AB:34:CC:D4:75:C5:81:C9:49:01:FC:4A:48:E7:64:93:D7:4E
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=mid:0
a=sendrecv
a=sctp-port:5000
a=max-message-size:262144
a=setup:actpass
a=ice-ufrag:PHBt
a=ice-pwd:XWEw8pM9saxidcvX4+J9KA

2026-03-07 16:00:43.681 INFO  [15793147] [rtc::impl::PeerConnection::changeSignalingState@1368] Changed signaling state to have-local-offer
2026-03-07 16:00:43.681 INFO  [15793147] [rtc::impl::PeerConnection::changeGatheringState@1355] Changed gathering state to in-progress
2026-03-07 16:00:43.681 VERB  [15793147] [rtc::impl::IceTransport::LogCallback@390] juice: Gathering candidates
2026-03-07 16:00:43.681 INFO  [15793147] [rtc::impl::IceTransport::LogCallback@390] juice: Changing state to gathering

Changing state to connecting
2026-03-07 16:00:43.682 INFO  [15793147] [rtc::impl::PeerConnection::changeIceState@1337] Changed ICE state to checking
2026-03-07 16:00:43.682 INFO  [15793147] [rtc::impl::PeerConnection::changeState@1319] Changed state to connecting

STUN server binding successful
Got STUN mapped address 41.133.212.35:55432 from server
Candidate gathering done
Changed gathering state to complete
ICE gathering state: complete
ICE gathering complete, waiting for Cloudflare propagation...

Sending SDP to worker...
Patched SDP:
 v=0
o=rtc 3498164665 0 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0
a=msid-semantic:WMS *
a=fingerprint:sha-256 1F:B4:22:F6:2F:5A:79:13:12:BF:06:CD:21:87:AB:34:CC:D4:75:C5:81:C9:49:01:FC:4A:48:E7:64:93:D7:4E
m=application 55432 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 192.168.1.3
a=mid:0
a=sendrecv
a=sctp-port:5000
a=max-message-size:262144
a=setup:actpass
a=ice-ufrag:PHBt
a=ice-pwd:XWEw8pM9saxidcvX4+J9KA
a=candidate:1 1 UDP 2114977791 192.168.1.3 55432 typ host
a=candidate:2 1 UDP 1678769919 41.133.212.35 55432 typ srflx raddr 0.0.0.0 rport 0
a=end-of-candidates

Worker returned keys: [ 'sessionId', 'answerSdp', 'tracks' ]
Session created, sessionId: be8f5917a8ed3344aaaa7e6cebba5b4113fea219972238477e0338220f1cf928
Tracks: [{"mid":"0","trackName":"immergo-spatial"}]
Reconstructed SDP from worker:
 v=0
o=- 0 0 IN IP4 0.0.0.0
s=-
t=0 0
a=group:BUNDLE 0
a=msid-semantic:WMS*
a=fingerprint:sha-256 78:36:92:A0:17:E2:D4:63:DC:9F:70:8E:D3:7F:55:54:E2:03:9C:23:78:53:0B:33:8F:38:5F:1B:8F:09:32:E4
a=ice-lite
m=audio 1473 UDP/TLS/RTP/SAVPF 111
c=IN IP4 104.18.13.207
a=mid:0
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
a=setup:passive
a=ice-ufrag:PHBt
a=ice-pwd:XWEw8pM9saxidcvX4+J9KA
a=recvonly
a=candidate:1 1 UDP 2113937151 104.18.13.207 1473 typ host
a=end-of-candidates

Connectivity timer started
Changed signaling state to stable

Changed signaling state to have-local-offer

Remote description set, waiting for connection..
host name
Connectivity timer expired
Changing state to failed
Changed ICE state to failed
Changed state to failed

Changed ICE state to closed
Changed state to closed	
WebRTC State: failed
WebRTC State: closed

It appears that after 2026-03-07 16:00:47.759 VERB  [15793147] [rtc::PeerConnection::setRemoteDescription@184] 

There was a local description issued with three m= sections?

rtc::impl::PeerConnection::processLocalDescription@1040] Issuing local description: v=0
o=rtc 1934331791 0 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 immergo-spatial 1
a=group:LS 0 immergo-spatial
a=msid-semantic:WMS *
a=ice-options:ice2,trickle
a=fingerprint:sha-256 1F:B4:22:F6:2F:5A:79:13:12:BF:06:CD:21:87:AB:34:CC:D4:75:C5:81:C9:49:01:FC:4A:48:E7:64:93:D7:4E
m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=mid:0
a=sendonly
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
a=setup:actpass
a=ice-ufrag:PHBt
a=ice-pwd:XWEw8pM9saxidcvX4+J9KA
a=candidate:1 1 UDP 2114977791 192.168.1.3 55432 typ host
a=candidate:2 1 UDP 1678769919 41.133.212.35 55432 typ srflx raddr 0.0.0.0 rport 0
a=end-of-candidates
m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=mid:immergo-spatial
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
a=setup:actpass
a=ice-ufrag:PHBt
a=ice-pwd:XWEw8pM9saxidcvX4+J9KA
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=mid:1
a=sendrecv
a=sctp-port:5000
a=max-message-size:262144
a=setup:actpass
a=ice-ufrag:PHBt
a=ice-pwd:XWEw8pM9saxidcvX4+J9KA

Do you know why this would be?

[RichardFoss]

@longnguyen2004 - thank you for the link, but as Paul-Louis mentioned this has to do with TURN credentials.

[paullouisageneau]

@RichardFoss Do not edit or reconstruct SDP descriptions. You can't remove random things, hardcode other things, and expect it to work. Also, you need to remove the datachannel.

[RichardFoss]

Thanks for the response Paul-Louis - I perfectly understand your logic - I was giving code that had gone through many attempts at messaging - successive iterations of me testing, debugging, asking for AI help, reconstructing the sdp. However I found that the cloudflare Calls API returned an sdp with no ICE credentials, and a standard implementation would not be able to deal with it. So as I see it, cloudflare's ice-lite SFU architecture performs non standard signalling. If you are able to test the messaging and provide a working example, that would be wonderful. In the meantime, I am using the cloudflare WebSocket adapter - pushing my binaural audio to a "Durable Object" in a cloudflare worker, and having the cloudflare SFU pull from that for playback in client browsers.

[paullouisageneau]

However I found that the cloudflare Calls API returned an sdp with no ICE credentials, and a standard implementation would not be able to deal with it. So as I see it, cloudflare's ice-lite SFU architecture performs non standard signalling.

No, Cloudflare's implementation is standard, the problem is that you don't use it correctly. Every API response contains the current session description, and you are not supposed to forward the provisional description from session/new, but the one from tracks/new, which features media and therefore ICE credentials. Going into an LLM-fueled rabbit hole of SDP rewriting is not going to fix that. They have examples where it interoperates with the standard browser WebRTC API.

[RichardFoss]

Thank you very much for your response Paul-Louis, and also for pointing me to the cloudflare examples. Apologies for my slow reply - I am now busy with a solution where I send audio to my electron renderer, and then a WebRTC connection to the cloudflare SFU. Once I have completed this I will get back to the node-datachannel based solution, follow the examples, and compare latencies.