Draft signaling protocol

webrtc/browser-to-browser.md

@@ -24,27 +24,27 @@ the restriction of the browser platform and being behind a NAT and/or firewall.
    connection to be authenticated, i.e. that data send on the relayed connection
    can be trusted.
 
-2. _A_ and _B_ both create a `RTCPeerConnection` and generate an _offer_ and an
-   _answer_ respectively. See `icegatheringstatechange` below on how these may
-   already contain the addresses of the loca node.
+2. _A_ creates an `RTCPeerConnection`. See [#STUN] on what STUN servers to
+   configure at creation time. _A_ creates an SDP offer via
+   `RTCPeerConnection.createOffer()`. _A_ initiates the signaling protocol to _B_
+   via the relayed connection from (1), see [#Signaling protocol] and sends the
+   offer to _B_.
 
-   _A_ and _B_ SHOULD NOT reuse certificates across `RTCPeerConnection`s.
-   Reusing the certificate can be used to identify a node across connections by
-   on-path observers given that WebRTC uses TLS 1.2.
+3. _B_ creates an `RTCPeerConnection`. Again see [#STUN] on what STUN servers to
+   configure at creation time. _B_ receives _A_'s offer send in (2) via the
+   signaling protocol stream and provides the offer to its `RTCPeerConnection`
+   via `RTCPeerConnection.setRemoteDescription`. _B_ then creates an answer via
+   `RTCPeerConnection.createAnswer` and sends it to _A_ via the existing
+   signaling protocol stream (see [#signaling protocol]).
 
-3. _A_ and _B_ exchange the generated _offer_ and _answer_ through some protocol
-   (e.g. an altered DCUtR) via the relayed connection.
+4. _A_ receives _B_'s answer via the signaling protocol stream and sets it
+   locally via `RTCPeerConnection.setRemoteDescription`.
 
-   - One could alter DCUtR or identify-push.
-   - We should support ICE trickle candidates.
-   - We can design our own protocol catered for SDP offer and answer.
-   - Contrary to what browser-to-server does, ideally we would exchange ufrag (username + password).
+5. TODO: Define ICE candidate exchange.
 
-4. _A_ and _B_ set the exchanged _offer_ and _answer_ and thus initiate the
-   connection establishment.
-
-5. Messages on the established `RTCDataChannel` are framed using the message
-   framing mechanism described in [Multiplexing](#multiplexing).
+5. Messages on `RTCDataChannel`s on the established `RTCPeerConnection` are
+   framed using the message framing mechanism described in
+   [Multiplexing](#multiplexing).
 
 The above browser-to-browser WebRTC connection establishment replaces the
 existing [libp2p WebRTC star](https://github.com/libp2p/js-libp2p-webrtc-star)
@@ -60,6 +60,24 @@ protocols.
   [`icegatheringstatechange`
   event](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/icegatheringstatechange_event).
 
+## STUN
+
+TODO: Specify
+
+## Signaling protocol
+
+TODO: Extend
+
+Protocol id `/webrtc-direct`
+
+Messages are sent prefixed with the message length in bytes, encoded as an
+unsigned variable length integer as defined by the [multiformats unsigned-varint
+spec][uvarint-spec].
+
+``` protobuf
+// TODO: Support for offer, answer and ICE candidates
+```
+
 ## FAQ
 
 - Why is there no additional Noise handshake needed?