Edge may produce wrong ICE Binding requests (wrong USERNAME length)

Fixed Issue #12332457


Iñaki B.
Jun 13, 2017
This issue is public.
Reported by 3 people

Sign in to watch or report this issue.

Steps to reproduce

When connecting Edge to Jitsi-videobridge (JVB) I’ve found that, very often, ICE fails. This is because JVB replies 401 with Wrong MESSAGE-INTEGRITY error to some Binding requests sent by Edge.

The issue is fully reported here (Wireshark traces included):


The most interesting comment in that issue is the latest one, in which a Jitsi developer has found out that some of those ICE Binding requests from Edge may have a wrong length value for the USERNAME attribute, producing the above error (screenshots attached):



Comments and activity

  • Microsoft Edge Team

    Changed Assigned To to “Steven K.”

    Changed Status to “Confirmed”

  • Please, let’s close this issue. It’s a duplicate of https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/12332512/
    When I reported the issue, I had various problems submitting the report. As a result, two similar issues were reported.

    Let’s please close this issue and just focus on 12332512.
    Thanks a lot.

  • Hi 

    I already duplicated 12332512 to this one.  I used this one because it had two attachments.  :-)

    I have also already verified the wireshark capture and see that a duplicate packet is sent ~75 ns later that has an extra ‘0’ in the username field.

    Do you mind if we use this bug report as I have already sent this one on.


  • Also, I noticed in the discussion that someone was able to repro this very easily.  Are you aware of the conditions that cause this to happen readily?  That would be useful as well.

    Thank you for the submission and the support.

  • Microsoft Edge Team

    Changed Assigned To to “Steven K.”

    Changed Status from “Confirmed”

  • Hi Steven, sure, let’s use this issue.

    I have also already verified the wireshark capture and see that a duplicate packet is sent ~75 ns later that has an extra ‘0’ in the username field.

    Yes, it has the same transaction ID.

    However, I want to make clear that the wrong extra ‘0’ (or just byte) in the USERNAME does not just appear in duplicated requests. In fact, sometimes the ICE does never connect because all the ICE Binding Requests sent by Edge are replied with “WRONG MESSAGE-INTEGRITY” (probably because all of them have that extra byte). Sometimes it does not happen, sometimes yes.

    Are you aware of the conditions that cause this to happen readily?

    No, it happens randomly within my private environment. I cannot yet provide a URL to test it. I’ve done many checks and I’m unable to figure out a proper way to reproduce the problem. It seems just random.

  • Microsoft Edge Team

    Changed Assigned To from “Steven K.” to “Shijun S.”

  • Thank you for being flexible on using this issue.

    Appreciate the added clarification.  I will look at a couple more packets in that capture to see if it is the same error or very similar.

    I will setup an environment like your private environment to reproduce it internally.  Can you give me some extra details about it?  What STUN and TURN servers are you using?  Any other tips would be nice.  I am happy to learn about the Jitsi projects. :)


  • Microsoft Edge Team

    Changed Status to “Confirmed”

  • Hi Steven. I’m adding Edge support to Jitsi-meet so by using my fork you can test it. Basically I’ve coded a RTCPeerConnection shim for Jitsi in Edge.

    Steps to install the environment. NOTE: I run these steps in a Macbook, so the Macbook launches a local web server and them I access it from Edge (in the same local network). However, for that to work a valid TLS certificate (pointing to the private IP of the Macbook) is required. So you may try these steps directly in a Edge machine.

    1. Clone the jitsi-meet app:

    $ git clone https://github.com/jitsi/jitsi-meet.git
    $ cd jitsi-meet/
    $ npm install

    1. Clone my fork of lib-jitsi-meet and enter the “edge-pc” branch:

    $ git clone https://github.com/ibc/lib-jitsi-meet.git
    $ cd lib-jitsi-meet/
    $ git checkout edge-pc
    Edit modules/RTC/ortc/RTCPeerConnection.js and, in line 48, after super(), add:

        window.PC = this;

    $ npm install

    1. Hack to make jitsi-meet depends on the local lib-jitsi-meet dependency:

    $ cd jitsi-meet/node_modules/
    $ rm -rf lib-jitsi-meet/
    $ mv PATH_TO/lib-jitsi-meet .

    1. Change the URL of the Jitsi-videobridge server to use a server for testing Edge:

    $ cd jitsi-meet/
    Edit webpack.config.js and replace “https://beta.meet.jit.si” with “https://edge.jitsi.net” in line 13.

    1. Compile the app:

    $ cd jitsi-meet/
    $ make all

    1. Run the local web server:

    $ cd jitsi-meet/
    $ ./node_modules/.bin/webpack-dev-server --https --open --host
    Or, if you have a valid (non auto-signed) TLS certificate pointing to the private IP of this machine:
    $ ./node_modules/.bin/webpack-dev-server --https --open --host --key PATH_TO_KEY --cert PATH_TO_CERT

    1. A web app will be open in https://localhost:8080. So, instead of that, open the following room URL in both Edge and Chrome:

    After that, both browsers will join the multimedia room (this is not P2P audio/video) through a Jtsi-videobridge SFU running in the edge.jitsi.net host.

    Note that, in order for the app to really connect (ICE, DTLS, etc) to the SFU, at least two participants must join the same room.

    In order to reproduce the issue, try reloading the web in Edge. You can check the ICE status in the console as follows:

    > PC._iceTransport.state

    When the ICE problem reported in this issue happens, that will remain in “checking” state rather than "completed".

    Sometimes, it’s easier to reproduce the issue by having two different Chrome/Firefox browsers already in a room, and then joining it with Edge.

    You can take network traces in the Edge machine to inspect the wrong STUN requests.

  • NOTE: I expect to have a full public environment ready this week, so you will be able by just opening a URL in Edge (without having to locally deploy everything). Will update when done.

  • Hi, here the public URL to test the environment:


    Just join with different browsers, reload Edge sometimes, etc, until it fails to connect (due to the ICE issue reported above).

  • Microsoft Edge Team

    Changed Assigned To from “Shijun S.” to “Frank L.”

    Changed Title from “Edge may produce wrong ICE Binding requests (wrong USERNAME length)” to “Edge may produce wrong ICE Binding requests (wrong USERNAME length)”

    Changed Status from “Confirmed” to “Fixed”

  • Hi Iñaki,

    I wanted to let you know that this has been fixed in a development build and should be in the next insider fast release of Windows 10, I.e. after 16281.

    Appreciate the very detailed submission and the help getting this issue identified and fixed,


You need to sign in to your Microsoft account to add a comment.

Sign in