There was a discussion about this on go-nuts: http://grokbase.com/t/gg/golang-nuts/161wbn1vf0/go-nuts-native-go-implementation-of-webrtc-any-interest-in-such-a

There was a discussion about this on go-nuts: http://grokbase.com/t/gg/golang-nuts/161wbn1vf0/go-nuts-native-go-implementation-of-webrtc-any-interest-in-such-a-project http://grokbase.com/t/gg/golang-nuts/161wbn1vf0/go-nuts-nati... There are two bindings for Go built on top of the WebRTC code at webrtc.org: https://github.com/keroserene/go-webrtc https://github.com/keroserene/go-webrtc https://github.com/fd/webrtc https://github.com/fd/webrtc By the way, I work on the WebRTC team at Google, and I don't think it would be that hard to write a data channel server in Go. Here's how you should do it. 1. Get an "SDP offer" from the client. Parse it mainly to get the DTLS fingerprint. You may also choose to get the SCTP max message size. 2. Open a UDP socket. Listen for incoming STUN binding requests and send back binding responses: You can see how the WebRTC client code constructs requests here: https://cs.chromium.org/chromium/src/third_party/webrtc/p2p/base/port.cc?sq=package:chromium&dr=CSs&rcl=1482855583&l=755 https://cs.chromium.org/chromium/src/third_party/webrtc/p2p/... You can see how the WebRTC client code processes responses here: https://cs.chromium.org/chromium/src/third_party/webrtc/p2p/base/port.cc?sq=package:chromium&dr=CSs&rcl=1482855583&l=363 https://cs.chromium.org/chromium/src/third_party/webrtc/p2p/... Or you can read the RFC (warning: not light reading): https://tools.ietf.org/html/rfc5245 https://tools.ietf.org/html/rfc5245 3. Once a valid STUN binding request is received, listen for DTLS packets and hand those over to BoringSSL. Also listen to when BoringSSL wants to send a packet and send those out on the UDP socket back to the client. You can see how the WebRTC client code passes DTLS packets down to BoringSSL here: https://cs.chromium.org/chromium/src/third_party/webrtc/base/opensslstreamadapter.cc?cl=GROK&rcl=1482855583&l=221 https://cs.chromium.org/chromium/src/third_party/webrtc/base... You can see how the WebRTC client code gets packets to send from BoringSSL here: https://cs.chromium.org/chromium/src/third_party/webrtc/base/opensslstreamadapter.cc?cl=GROK&rcl=1482855583&l=239 https://cs.chromium.org/chromium/src/third_party/webrtc/base... 4. Once BoringSSL finishes the DTLS handshake and is processing incoming SCTP packets, listen for those and hand those over to usrsctplib. Also listen to packets usrsctplib wants to send and hand those over to DTLS to send. You can see how the WebRTC client code reads decrypted packets from BoringSSL here: https://cs.chromium.org/chromium/src/third_party/webrtc/base/opensslstreamadapter.cc?cl=GROK&rcl=1482855583&l=647 https://cs.chromium.org/chromium/src/third_party/webrtc/base... And how it passes them down to usrsctplib here: https://cs.chromium.org/chromium/src/third_party/webrtc/media/sctp/sctpdataengine.cc?q=sctpdataengine&sq=package:chromium&l=702 https://cs.chromium.org/chromium/src/third_party/webrtc/medi... You can see how the WebRTC client code gets packets to send from usrsctplib here: https://cs.chromium.org/chromium/src/third_party/webrtc/media/sctp/sctpdataengine.cc?sq=package:chromium&rcl=1482855583&l=254 https://cs.chromium.org/chromium/src/third_party/webrtc/medi... And how it passes them to BoringSSL here: https://cs.chromium.org/chromium/src/third_party/webrtc/base/opensslstreamadapter.cc?cl=GROK&rcl=1482855583&l=583 https://cs.chromium.org/chromium/src/third_party/webrtc/base... 5. Process data channel messages from usrsctplib and send data channel message through usrsctplib. Note that you can ignore the whole "OPEN message" protocol if you call PeerConnection.createDataChannel with the "negotiated: true" option on the WebRTC client side. You can specify the SID you want to use for the data channel as well. You can see how the WebRTC client code passes messages to usrsctplib here: https://cs.chromium.org/chromium/src/third_party/webrtc/media/sctp/sctpdataengine.cc?sq=package:chromium&rcl=1482855583&l=666 https://cs.chromium.org/chromium/src/third_party/webrtc/medi... And how it receives them: https://cs.chromium.org/chromium/src/third_party/webrtc/media/sctp/sctpdataengine.cc?sq=package:chromium&rcl=1482855583&l=428 https://cs.chromium.org/chromium/src/third_party/webrtc/medi... https://cs.chromium.org/chromium/src/third_party/webrtc/media/sctp/sctpdataengine.cc?sq=package:chromium&rcl=1482855583&l=214 https://cs.chromium.org/chromium/src/third_party/webrtc/medi... 6. Serialize an "SDP answer" message which basically just hands back the same looking blob of text, but with a different DTLS fingerprint (the one for the certificate of the server). It also must have two random strings: the ICE username fragment (ufrag) and ICE password (pwd). If you pass that answer to the WebRTC client, all the ICE, DTLS, and SCTP work should happen and after around 6 round trips on the network, you should incoming and outgoing messages. Ok, that probably sounds like a lot, but most of the work is done by BoringSSL and usrsctplib. The bulk of the Go code would be implementing the STUN messages and gluing everything together. Good luck to whoever tries :).