Re: Issue 211: DtlsTransport.getLocalParameters and certificate creation

To resolve Phlipp Hancke's review comments about the sample code and forking, I've been trying to clean up the sample code, including the example in the RTCDtlsTransport section. (in which both ICE and DTLS parameters are signaled, with the potential for forking).   

Unfortunately, that example does not appear to work in practice, due to a problem in the RTCDtlsTransport constructor :(

In the forking scenario, the offerer can signal dtlsTransport.getLocalParameters, and get one or more replies. In this scenario, each of the answerer(s) will have called RTCDtlsTransport.start(), providing the signaled local parameters as an argument. Therefore, each additional reply beyond the first requires a new dtlsTransport to be constructed on the local peer, with the same fingerprint as the original, so that RTCDtlsTransport.start() can be called with the received remote DTLS parameters. 

However, without the certificate management API recently added to WebRTC 1.0 (see: http://w3c.github.io/webrtc-pc/archives/20150611/webrtc.html), this cannot be accomplished; by default, the newly constructed RTCDtlsTransport will have a new certificate and fingerprint. 

If we have a certificate management API, then we need to consider whether getLocalParameters needs to be a Promise, or whether it is only called once the certificate creation Promise is resolved.

Received on Monday, 15 June 2015 18:12:07 UTC