The x.9.13 release is now available. This is a really minor but very important release. If you are using any of the .NET-based or Java SDKs in combination with Chrome, please upgrade as soon as possible.
A change to the DTLS layer in Chrome 53+ is causing problems in the DTLS handshake performed by the BouncyCastle library shipped with earlier releases of IceLink. Specifically, BouncyCastle 1.8.0 (.NET) and 1.5.3 (Java) will fail to properly respond to a DTLS version negotiation when it is in the server role. This will happen under ordinary conditions when Chrome is the side that sends the SDP offer. In the IceLink examples, this will happen when Chrome joins a session first, and then a .NET or Java-based peer joins second. This only affects connections with Chrome. Firefox and IceLink-to-IceLink connections are unaffected.
This is not a bug in Chrome, but rather a bug in how BouncyCastle handles DTLS version negotiation in the server role. Upgrading to BouncyCastle 1.8.1 (.NET) and 1.5.4 (Java) resolves the problem.
Head on over to the Downloads page to pick up the latest!
Comments
7 comments
I use both .net and Chrome clients.
I updated my .net client to use 2.9.13, and it doesn't solve the problem, it sometimes runs, sometimes doesn't.
For example it worked 1-2 times out of 20 .
Regards,
Emil Langazov
I also tested the examples in 2.9.13
it works there, but with my old source code, that worked fine before chrome 53, it doesn't work well
Hi Emil, can you share debug logs? All our tests against Chrome 53 from.NET in both directions are passing for 2.9.13. Double-check to make sure that you're building against the right libraries and that you're pulling in the new BouncyCastle.dll and not the old crypto.dll.
I think i figured out the problem.
it seems the problem is not in the .net code.
In our Typescript code, we have this :
var serverAddressIceLink = ['login.electromeet.com', 'stun.l.google.com:19302', 'stun1.l.google.com:19302', 'stun2.l.google.com:19302', 'stun3.l.google.com:19302', 'stun4.l.google.com:19302', 'stun01.sipphone.com', 'stun.ekiga.net', 'stun.fwdnet.net', 'stun.ideasip.com', 'stun.iptel.org', 'stun.rixtelecom.se', 'stun.schlund.de', 'stunserver.org', 'stun.softjoys.com', 'stun.voiparound.com', 'stun.voipbuster.com', 'stun.voipstunt.com', 'stun.voxgratia.org', 'stun.xten.com'];
......
.....
private startAudioWebRtc(failCallBack): void {
fm.icelink.webrtc.userMedia.getMedia({
audio: true,
onFailure: (e) => {
BootstrapDialog.alert("Unable to access audio device. Please make sure you have allowed it, and that you use Chrome or Firefox.");
//alert('Could not get media. ' + e.getException().message);
jslog.error("Could not get media.", e.getException());
failCallBack();
},
onSuccess: (e) => {
this.localMedia = e.getLocalStream();
this.microphoneMeter(this.localMedia.getBackingStream());
var audioStream = new fm.icelink.webrtc.audioStream(this.localMedia);
this.conference = new fm.icelink.conference(serverAddressIceLink, [audioStream]);
....
...
....
With this list of ICE servers, it doesn't work,
and when I replace the list with only one host frome example, it works without a problem.
So I think that the problem appears when we use the list of ICE servers.
At the .net end, which runs at our server, we don't make any changes in the ICE server list (we change only on the client's side in JS).
Regards,
Emil
In Chrome, IceLink simply wraps the native WebRTC API, so the server addresses are passed directly into the native RTCPeerConnection where they are used internally. I've never seen that many servers provided, but I don't see why it should be a problem, so it might be worth filing a bug report with the Chrome development team if it fails when you have that many.
I think I finally realized what is the problem.
It works only with your ICE server from the examples.
If you replace with any of the servers in the list that I used, it stops working.
Please try with some of Google servers first.I tried with 4-5 other of the public STUN servers on my list,and none of them worked.
They were working before the changes in the encryption.
Regards,
Emil
We don't actually control any of that in Chrome. It's Chrome internally that's making requests to the STUN servers. We just forward the servers along to the native Chrome API.
What does your server setup look like on the .NET side?
Please sign in to leave a comment.