x.9.13 Release

Follow

Comments

7 comments

  • Avatar
    Emil Langazov

    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

  • Avatar
    Emil Langazov (Edited )

    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

     

  • Avatar
    Anton Venema

    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.

  • Avatar
    Emil Langazov

    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

  • Avatar
    Anton Venema (Edited )

    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.

  • Avatar
    Emil Langazov

    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

  • Avatar
    Anton Venema

    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.