precalculating and encoding offer/answer in username/cred for stun/turn server

[unicomp21]

I realize offer/answer for a datachannel can be handled via simple http request/response, but I'm hitting scenarios where this is cumbersome.

When only using datachannels, could it be possible to precompute the offer/answer in browser/javascript, and send this serded/encoded payload to violet via/piggbacked on the stun|turn login message? And then violet uses the browser/precalculated answer as it's own? I'm thinking a text encoding w/ length/prefixed delimiters would allow putting multiple fields in the username? (ie uname, password, offer sdp, answer sdp)

The goal is a quick/easy datachannel connection w/ the backend server which is running nodejs.

Have a good one! @paullouisageneau

[paullouisageneau]

I realize offer/answer for a datachannel can be handled via simple http request/response, but I'm hitting scenarios where this is cumbersome.

Yes indeed, actually the WHIP/WHEP protocols do this.

When only using datachannels, could it be possible to precompute the offer/answer in browser/javascript, and send this serded/encoded payload to violet via/piggbacked on the stun|turn login message? And then violet uses the browser/precalculated answer as it's own? I'm thinking a text encoding w/ length/prefixed delimiters would allow putting multiple fields in the username? (ie uname, password, offer sdp, answer sdp)

I don't really understand why you would do that, as the STUN/TURN server is distinct from your signaling server and remote WebRTC endpoint.

In practice it is not possible: to generate the full offer/answer description, you need local candidates, which are obtained from STUN and TURN servers. Therefore, you can't generate the description before sending a request to the STUN and TURN servers.

[unicomp21]

STUN/TURN server is distinct from your signaling server and remote WebRTC endpoint.

What I'm suggesting is they all reside in the same app/process, specifically to achieve the goal described above.

[unicomp21]

Does anything prevent building violet via emscripten? And running in the browser?

[paullouisageneau]

Does anything prevent building violet via emscripten? And running in the browser?

It is not possible since there is no socket API access in the browser. Even if there was, the server would not be on the public Internet so it would be useless.

[unicomp21]

Yes, true, but w/ the goal of calculating both offer/answer in the browser, serde'ing them into the logon message, and using the same offer/answer pair on the remote end (turn/stun/libdatachannel), might be a possible approach?

[paullouisageneau]

The only way to "precalculate" the remote answer is to know everything in advance, certificates, credentials, and ports (Note that it necessarily breaks security). Therefore, the transmission via the TURN username is useless, it is simpler to hack the server so it accepts any incoming peer connection with an approach similar to WebRTC direct.

[unicomp21]

sorry, I'm confused, webrtc-direct works in browsers?

anyhow, think I've found a way? using a homegrown turn: server w/ short circuit built-in? server side issues the offer and disables fingerprint check for returned answer? then browser can establish datachannel/turn: to backend by simply providing a unique/uuid sessionid in the logon message? rest of sdp is a simple template for offer/answer?

[paullouisageneau]

sorry, I'm confused, webrtc-direct works in browsers?

Yes it does. You don't need exactly WebRTC direct for your use case, anything implementing the same principle would work, but my point is that the TURN server is useless.

[unicomp21]

What about scenarios where browser is running behind symmetric nat? turn: server is still useless?

[paullouisageneau]

What about scenarios where browser is running behind symmetric nat? turn: server is still useless?

Yes it is useless. The server is open, so the client can always reach it (like it could reach the TURN server).

[unicomp21]

Meaning udp can hole punch thru a symmetric nat?

---claude---
A TURN server is needed for symmetric NAT scenarios. In symmetric NAT, each outbound connection from the same internal IP:port gets mapped to a different external IP:port. This makes it impossible for peer-to-peer connections to work directly, requiring a TURN server to relay the traffic.

For asymmetric NAT (including full-cone, restricted-cone, and port-restricted cone NAT), STUN servers are usually sufficient since the NAT mapping remains consistent and predictable.

[paullouisageneau]

Meaning udp can hole punch thru a symmetric nat?

It is not even hole-punching in that case. The server is not behind a NAT. If the client can reach the server on its address and port, the server can reach the client following the reverse path. All client-server protocols rely on this, for instance DNS over UDP. NAT mapping type on client side has nothing to do with it.

[unicomp21]

It is not even hole-punching in that case.

got it, thanks for setting me straight.

[unicomp21]

is there a working impl somewhere for webrtc-direct w/ browser integ tests?

[paullouisageneau]

libp2p has different implementations with tests: libp2p/specs#412 Again, you don't need exactly WebRTC direct, only the same principle.