Uploaded image for project: 'FreeSWITCH'
  1. FreeSWITCH
  2. FS-11011

Two routable interfaces result in no media when using Chrome

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: New
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 1.8, 1.6.20
    • Fix Version/s: None
    • Component/s: mod_verto
    • Labels:
      None
    • CPU Architecture:
      x86-64
    • Kernel:
      Linux
    • Userland:
      GNU/Linux
    • Distribution:
      Debian
    • Distribution Version:
      Debian 8 jessie
    • Compiler:
      gcc
    • FreeSWITCH GIT Revision:
      tags/v1.6.20 and v1.8-fsa
    • GIT Master Revision hash::
      -
    • FSS Support Agreement Customer Number and Company name:
      FSA-CafeX

      Description

      When using Chrome on a machine with multiple interfaces that can route to freeswitch (connected via both wifi and wired for example) the webrtc media connections do not always establish. On my own machine using Chrome 64 on Linux it will always fail with ice marked as failed when both wired and wifi are connected, but people on other OSs are reporting it working some of the time.

      Looking at a wireshark (attached with traffic not between the endpoint and the freeswitch box filtered out) I'm seeing chrome sending stun binding requests to freeswitch from both local IPs for both m-lines, then freeswitch sending a dtls hello (which is ignored as it's too early as the 4 packet stun exchange hasn't completed), then freeswitch starts to send binding successes to one of the ip/ports for each m-line, and eventually, around 800ms later freeswitch starts sending binding requests to the ip/port too, and a second after the first dtls hello, sends them again on the timer. DTLS hellos continue to be sent but chrome never responds.

      I had assumed a chrome bug which only happened when not bundling media as this works with out legacy webrtc product, but even fiddling with our legacy code to get it to not bundle it still works in the same scenario. With freeswitch even in a working scenario there is the ~800ms delay between an initial DTLS hello and freeswitch sending stun binding requests, but then on the second hello chrome responds to the dtls. In our legacy product the main difference from freeswitch I see is we send stun binding successes to one ip/port for each m-line before sending the dtls hello, and that goes out at the same time as the stun binding requests (although really even there the hello goes out a little too early as the 4 packet exchange hasn't completed, but chrome seems ok with it as the hellos don't need to be resent).

      Mostly tested with 1.6.20, I also tried this with the 1.8 FSA branch which fails too.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                mikej Mike Jerris
                Reporter:
                ebunyan@cafex.com Eric Bunyan
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated: