wamp-proto
WAMP-over-WebRTC-DataChannel (SCTP-over-DTLS) as Transport Binding
Proposal: Define WAMP-over-WebRTC DataChannel Transport Binding
see also: WAMP-over-WebTransport (QUIC) Transport Binding
Motivation
WebRTC is widely deployed across browsers, mobile environments, and native apps. It provides:
- Reliable or unreliable transmission modes.
- Ordered or unordered delivery.
- NAT traversal via ICE/STUN/TURN.
- Mandatory security using DTLS-SRTP for keying.
WebRTC DataChannels, specifically:
- Run on SCTP over DTLS over UDP.
- Provide reliable ordered delivery, satisfying all WAMP transport requirements.
- Are widely supported across all major browsers today (Chrome, Firefox, Safari, etc.).
- Enable peer-to-peer WAMP sessions, not only client-to-server.
This opens:
- Browser-to-browser WAMP sessions.
- Edge / local / mesh topologies.
- Cases where WebSockets or QUIC cannot be routed directly.
Proposal
Define a new WAMP transport binding: WAMP-over-WebRTC DataChannel
Key characteristics:
- Each WAMP session runs inside a single reliable, ordered DataChannel.
- The WebRTC signaling layer (SDP/ICE) is out of scope (as with WebSocket TCP setup).
- The transport describes:
- Message framing (e.g., one DataChannel message per WAMP message, or length-prefixed binary)
- Constraints on reliability and ordering mode
- Session start / close conventions
Benefits
- Works today in every major browser — even where WebTransport is not available.
- Enables:
- Browser-to-browser WAMP connections
- Low-latency connectivity in P2P applications
- Operation in restrictive NAT conditions via TURN fallback
- Security is provided automatically by DTLS, no separate TLS negotiation needed.
- Many WebRTC stacks exist in native environments for servers.
Scope of Work
- Define normative transport specification.
- Map WAMP connection establishment to DataChannel state transitions.
- Specify reliable/ordered transport settings.
- Provide implementation examples.
References
- WebRTC API (W3C Recommendation)
- IETF RFC 8261 — SCTP over DTLS
- IETF RFC 8831 — DataChannel Protocol
For reference, we (XConn) have already implemented a working WAMP-over-WebRTC DataChannel transport. We’re excited about this proposal and would be very happy to collaborate on formalizing it as an official WAMP transport. Our team is ready to contribute time and effort toward shaping a proper specification. We’re also willing to adapt our existing implementation to match the community consensus.
@Mahad-10 oh, this is fantastic! that's breaking to new ground for WAMP, I am not aware of any other WAMP implementation having that, and it's exciting to hear you (also @om26er) are interested in formalizing such a thing!
a WAMP AP spec proposal plus one working reference implementation is exactly what we (WAMP project) would need to make it happen. XConn would innovate, break new ground for WAMP! spec + reference/first implementation.
personally, I'd be quite interested in implementing it in AutobahnPython and Crossbar.io. prove it interoperable with XConn then of course. both client side, and router wise. need to talk to some guys about interest and priorities (I have quite some chunks on my plate currently already as normal, but ..).
btw, in that context - cleaning up and tidy up loose ends - I have also filed https://github.com/wamp-proto/wamp-proto/issues/559 recently. both WAMP-over-WebRTC and WAMP-over-QUIC have specific advantages/disadvantages versus WAMP-over-WebSocket and versus each other. both WAMP transports would be interesting to have as an option. I'll post a follow up here comparing all three.
Thanks @xconnio for sharing that XConn already has an experimental WAMP-over-WebRTC transport.
This is extremely valuable prior art and a strong indicator that there is real demand for additional WAMP transports beyond WebSocket — especially ones that support NAT traversal, P2P connectivity, and modern browser networking APIs.
Independent implementations discovering the same idea is a classic sign that standardizing this transport could benefit the broader WAMP ecosystem. It also means we don’t start from zero:
XConn has already solved practical issues (message framing, DataChannel reliability settings, connection lifecycle, etc.) that can help inform a robust WAMP-over-WebRTC specification.
Why XConn’s WAMP-over-WebRTC matters
- Confirms practical, real-world demand for running WAMP over WebRTC DataChannels.
- Demonstrates feasibility with production-like requirements.
- Enables use cases WebSocket cannot address:
- Browser ↔ browser WAMP messaging
- NAT traversal via ICE/STUN/TURN
- Local-LAN / edge / fog / mesh scenarios
- Accelerates spec development by providing existing implementation experience.
This is exactly how successful WAMP extensions have historically evolved: independent experimentation → community interest → specification → interoperable implementations.
Comparison: WebSocket vs WebTransport vs WebRTC DataChannel
Below is a comparison of the three main transport candidates, since each offers different strengths and trade-offs.
Feature Overview
| Feature / Dimension | WebSocket (TCP/TLS) | WebTransport (QUIC/UDP) | WebRTC DataChannel (SCTP/DTLS/UDP) |
|---|---|---|---|
| Browser Support | Universal | Good in Chromium, emerging elsewhere | Universal |
| NAT Traversal | Moderate | Moderate | Excellent (ICE/STUN/TURN) |
| P2P Support | No | No | Yes |
| HOL Blocking | Yes (TCP) | No (streams) | No (SCTP) |
| Multiplexing | One stream | Stream-multiplexed | SCTP channels |
| Server Complexity | Low | Medium (QUIC stack needed) | High (ICE + DTLS + SCTP) |
| Mobile/IP Migration | Weak | Strong | Strong |
| Security | TLS | TLS 1.3 mandatory | DTLS mandatory |
| Best Use Case | Universal baseline | High-performance browser→server | P2P and NAT-traversing topologies |
WAMP-over-WebSocket (Current Standard)
Pros
- Universal browser support
- Mature, simple, well understood
- Easy to deploy over HTTPS/TLS
Cons
- TCP head-of-line blocking
- No P2P or NAT traversal
- Reconnect required on network change
WAMP-over-WebTransport (QUIC)
Pros
- No TCP HOL blocking (independent QUIC streams)
- Faster handshake and reconnect semantics
- Connection migration (mobile-friendly)
- Native multiplexing
- Mandatory TLS 1.3
Cons
- Browser support still expanding
- Requires HTTP/3 + QUIC server stack
- No P2P (browser→server only)
Best for: modern, high-performance browser→server WAMP connections.
WAMP-over-WebRTC DataChannel
Pros
- True P2P support (browser↔browser and browser↔server)
- ICE/STUN/TURN NAT traversal
- No HOL blocking (SCTP)
- Universal browser support today
- Configurable reliability and ordering
Cons
- Higher complexity (SDP, ICE, DTLS)
- Requires full WebRTC stack on server
- Requires external signaling channel (not part of WebRTC)
Best for: P2P WAMP, mesh networks, LAN/edge computing, NAT-challenging environments.
Summary
Each transport fills a different niche:
- WebSocket → universal, simple baseline
- WebTransport → modern, high-performance client→server transport
- WebRTC DataChannel → unique P2P and NAT traversal capabilities
The fact that an independent implementation (XConn) already built WAMP-over-WebRTC strongly supports the idea that both WebRTC and WebTransport could become valuable official transport bindings in the WAMP specification.
Suggested Next Steps
- Document XConn’s prototype behavior (framing, reliability mode, signaling).
- Draft initial WAMP-over-WebRTC binding based on existing prior art.
- Draft initial WAMP-over-WebTransport binding aligned with existing WAMP transport specs.
- Encourage cross-implementation testing early to validate assumptions.
@Mahad-10 can XConn broadcast SDP offers and receive answers via UDP Multicast or mDNS (Zeroconf)? does it support true (p2p) "local WebRTC meshes" without public Internet or external network infrastructure (like routers or access points)?
@oberstet Right now, we don't support this, But we’re open to exploring it further.
Just my 50ct: We are heavy WAMP users, but WebRTC is not in scope for us atm. When WAMP messages are transferred this always needs to touch the backend in our case, because this changes state of some kind. Browser to Browser is too ephemeral for us. We do use WebRTC in some video streaming application with STUN/TURN/ICE but I don't see how WAMP could make this better.
But I am thrilled that there is movement again in the WAMP space. It's an awesome protocol. 🔥 🚀
... When WAMP messages are transferred this always needs to touch the backend in our case, because this changes state of some kind. ...
yes, I understand, and it is definitely pretty much expected / common when structuring WAMP applications, eg. any Callee that wants to keep state likely wants to persist not in user endpoints, but "server side", and also the stuff done via calling any Callee (from user facing/endoint components) is something the administrator/owner of the application realm wants to control (have authority over, not hand that to application endpoints and users), and then have WAMP routers enforce (implement) that control & authority at application realm level.
touching on the "last mile uplink availability" issue, if that is also not an urgent need or pressing issue in your scenario, then what I tried to lay out in https://github.com/wamp-proto/wamp-proto/issues/561 is also not of big / any interest for you I guess.
because that would be possible (also) over WebRTC.
it will also be something possible once we wrap up Crossbar.io as a Android apk ("an app") running as edge node (already available) on user / endpoint devices, connecting to cloud/server side core node (already available) - via router2router WAMP (already available). beside the "Crossbar.io as an apk" thing, the other piece that would make sense: edge node discovery. normally, edge nodes talk to their configured core node, and that's it. but rather than configuring also other edge nodes (nearby) via the usual master node based centralized management, we could do automatic discovery - via Multicast DNS - purely in a local network, and let edge nodes discover "to core node" available route, over any available route, so as long as at least one edge node could connect to its upstream core node, everything still continues to fly happily. anyways, future, maybe;)
But I am thrilled that there is movement again in the WAMP space. It's an awesome protocol. 🔥 🚀
thanks! =) yeah, it's cool to see, I agree!