locked
Hosts file testing for new Edge pool - AV stream setup issues (UDP egressing wrong Edge server) RRS feed

  • Question

  • Good morning

    I am able to reproduce this issue, and I have packet captures to show the behavior of the failure. I am looking for an explanation for why this occurs, because I can't explain it.

    We have a new Edge pool with two servers.

    We have an internal workstation and an external workstation.

    The external workstation has a HOSTS file with entries pointed to the new Edge pool IPs:

    8.8.8.1 sip.domain.com

    8.8.8.2 webconf.domain.com

    8.8.8.3 av.domain.com

    8.8.8.4 sip.domain.com

    8.8.8.5 webconf.domain.com

    8.8.8.6 av.domain.com

    When we try to start any kind of AV stream (audio/video or app sharing), the setup fails if 8.8.8.6 is listed first in the HOSTS file, and it succeeds if 8.8.8.3 is listed first. 

    In a working scenario, from the Wireshark traces, we see the internal client send the invite to the external client, egressing 8.8.8.3 for STUN/TURN. The candidate list includes 8.8.8.3. The dynamic 50k-60k port range is punched open, and media establishes.

    When 8.8.8.6 is listed first, this breaks. From the wireshark traces, we see the internal client send the invite to the external client, egressing 8.8.8.6 for STUN/TURN. The candidate list includes 8.8.8.3. The dynamic 50k-60k port range is blocked on 8.8.8.3 because it egressed the "wrong" Edge server for the UDP session.

    My question is -- why is the invite egressing a different server based on the hosts entry of the external workstation? I would expect the Skype server application to decide which server sends the dynamic UDP port range invite, based on the candidate the internal server is offering... 

    Does anyone have any light they can shed on this? My only thought is the hosts file is inherently different than DNS A records, so that is causing this issue (in some way), but we really want a better understanding of why this is occurring before we can sign off on this as an expected failure and proceed to production.

    Friday, May 19, 2017 11:54 AM

All replies

  • what is your main issue with SFB ? something wrong with SFB client?
    Monday, May 22, 2017 8:07 AM