DTLS: Problem with forking

[aboba]

In Example 6 in what is now Section 4.9, the sample code signals IceGatherer and DtlsTransport parameters, and then constructs IceTransport and DtlsTransport objects for each answer (see below).

The problem is that this doesn't work, because each newly constructed DtlsTransport has its own certificate and fingerprint, which doesn't match the fingerprint that was signaled in the original offer. As a result, remote peer attempts to verify the local fingerprint will fail.

SAMPLE CODE FAIL

mySignaller.mySendInitiate({
"ice": iceGatherer.getLocalParameters(),
"dtls": dtls.getLocalParameters(),
// ... marshall RtpSender/RtpReceiver capabilities as illustrated in Section 6.4 Example 7.
}, function(remote) {
// Create the ICE and DTLS transports
i = iceTransport.push(new RTCIceTransport(iceGatherer));
dtlsTransport.push(new RTCDtlsTransport(iceTransport[i]));
// Start the ICE transport
iceTransport[i].start(iceGatherer, remote.ice, RTCIceRole.controlling);
dtlsTransport[i].start(remote.dtls);
// ... configure RtpSender/RtpReceiver objects as illustrated in Section 6.4 Example 7.
});

[aboba]

Resolution discussed at the ORTC CG meeting was to add a certificate as a mandatory argument in the DtlsTransport constructor.