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
The text was updated successfully, but these errors were encountered:
… in: Issue #195 Added certificate argument to the RTCDtlsTransport constructor, as noted in: Issue #218 Added the "failed" state to RTCDtlsTransportState, as noted in: Issue #219 Changed getNominatedCandidatePair to getSelectedCandidatePair, as noted in: Issue #220 Added support for WebRTC 1.0 RTCIceCredentialType, as noted in: Issue #222 Clarified behavior of createAssociatedGatherer(), as noted in: Issue #223 Changed spelling from "iceservers" to "iceServers" for consistency with WebRTC 1.0, as noted in: Issue #225 Added support for SCTP port numbers, as noted in: Issue #227 Changed "outbound-rtp" to "outboundrtp" within the Statistics API, as noted in: Issue #229 Changed maxPacketLifetime and maxRetransmits from unsigned short to unsigned long, as noted in: Issue #231 Clarified DataChannel negotiation, as noted in: Issue #233 Added getContributingSources() method, as noted in: Issue #236 Fixes to Examples 5 and 6, as noted in: Issue 237 and Issue #239 Fixed cut and paste errors in Example 11, as noted in: Issue #241