x.9.13 Release

• 

  Emil Langazov September 21, 2016 14:03

  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

  0

  Comment actions Permalink
• 

  Emil Langazov September 21, 2016 14:44 (Edited September 21, 2016 15:07)

  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

   

  0

  Comment actions Permalink
• 

  Anton Venema September 21, 2016 19:00

  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.

  0

  Comment actions Permalink
• 

  Emil Langazov September 27, 2016 12:56

  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

  0

  Comment actions Permalink
• 

  Anton Venema September 27, 2016 21:53 (Edited September 27, 2016 21:53)

  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.

  0

  Comment actions Permalink
• 

  Emil Langazov October 18, 2016 05:44

  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

  0

  Comment actions Permalink
• 

  Anton Venema October 19, 2016 19:39

  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?

  0

  Comment actions Permalink

Please sign in to leave a comment.