go-webrtc

ps://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 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... 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... 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... And how it passes them down to usrsctplib here: 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/medi... And how it passes them to BoringSSL here: 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/medi... And how it receives them: https://cs.chromium.org/chromium/src/third_party/webrtc/medi... 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 :).