You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
});
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
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.
});
The text was updated successfully, but these errors were encountered: