[DataChannel] Define bootstrap mechanism for QUIC (or RTCDataChannel)

[mfoltzgoogle]

Before we can pursue apples-to-apples benchmarking of transport protocols, there needs to be a definition of the bootstrapping channel used to establish an RTCDataChannel between controller and receiver, so we can include its metrics in the measurements.

@schien is this something you can help with?

[schien]

Sure, I plan to convert the draft protocol we used in our previous experimental implementation into a proper format for CG.

[schien]

Exchanging SDP and ICE candidates are the missing part for bootstrapping RTCDataChannel. https://wiki.mozilla.org/WebAPI/PresentationAPI:Protocol_Draft#Establish_Data_Channel is the minimal protocol we need.

Three message types to be defined:

1. send-offer: contains the full text of SDP created by the controlling UA
2. send-answer: contains the full text of SDP generated by the receiver UA
3. update-ice-candidate: contains one entry of the available ICE candidate (IP address) upon discovery.

reference: https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Signaling_and_video_calling#Designing_the_signaling_protocol

[tomoyukilabs]

Do we need messages for J-PAKE authentication before exchanging offer/answer and ICE candidates? I suppose that a device identification step would be essential unless the underlying transport channel could provide any equivalent mechanism.

[anssiko]

Per F2F discussion, marked as v2.

[mfoltzgoogle]

RtcDataChannel is not being actively investigated now.