locked
Issue with sharing content in a meeting with federated partners RRS feed

  • Question

  • So I have been battling an issue all day, and I am finally just done with it. I cannot share content with external users (outside of my organization) either federated or not, when they connect to a meeting on our installation.

    To help make this a little more clear, lets say I create a Skype meeting and send it to 5 different attendees from 3 different companies.

    Users A and B are from Company 1 and can connect to the meeting.  However neither of them can participate in sharing.  Audio and video is working, but not desktop sharing. 

    Users C and D are from Company 2.  User C is in my office and can connect to the meeting as well as see all presentations.  Basically everything is normal for User C.  User D is outside of my physical site and has the same issues as Users A and B.

    User E is from my company and everything works for them regardless of location.  If they are behind my firewall or not there isn't an issue sharing a desktop, or participating in a presentation. 

    The only pattern that I have found so far is this happens only with users on Office 365, however I cannot prove that because all 4 other users are all using O365.  I am looking to test this with another on premise installation, but as of right now I can't. 

    I receive an error in the CLS stating ms-client-diagnostics: 26; reason="A federated call failed to establish due to a media connectivity failure where one endpoint is internal and the other is remote"; 

    I see this as an inbound message which tells me that it is coming from O365, however I am not positive at this point in time.   I have pulled the logs from the client (O365 user) and found the same error in an out direction from the O365 user to my meeting leader. 

    I have opened every service on the firewall to remove any blocked ports as the issue, however I am seeing an ICEWarn=0x320 in the S4 messages.  I thought this was an antivirus program so I uninstalled it on the front end.  I then thought it was a web filter issue with the FW so I added a new policy that removes the web filtering for outbound communications from all of my Skype servers.  I have setup inbound policies that open every port, and outbound policies that do the same.  I have tested by using the Skype web app and it works flawlessly no matter the location of the client using it (i.e User A from Company 1 uses Skype web app instead of the locally installed desktop application).  I have also used telnet to connect to every possible port I can find documentation on, even the ones that are documented by third parties, but not specifically by MS.  All of the ports respond. 

    My environment is Edge in Site 1 and standard front end in site 2 connected by an IPsec VPN.  All routes are setup, and I even added more routes just to see if this would resolve anything, however it didn't. 

    At this point I am lost and need to get this fixed.  I have a contact in Belgium that will hopefully help me test this later this week, but if anyone has any suggestions I am all ears. 

     

    Tuesday, November 7, 2017 10:28 PM

All replies

  • Hi rhelms20,

    Would you please tell did the issue appear on the specific skype meeting or all skype meeting had this issue?
    When userA and userB try to share desktop, are there any error messages?
    Did you mean that all users homed on Office 365 had this issue, and the users homed on SFB on premise works fine right?

    For your issue, You need to double check ports for Edge External.
    For Edge External interface:
    Make sure the following ports open: SIP/MTLS/5061 (in/out), SIP/MTLS/5061 (in/out), RTP/TCP/50K range (out)
    More details:
    http://technet.microsoft.com/en-us/library/gg425891(v=ocs.14).aspx


    Regards,

    Alice Wang


    Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, November 8, 2017 7:14 AM
  • I'd double check your firewall ports as already suggested.
    For desktop sharing it will be using the AV edge so make sure you have port 443 open both ways, and the TCP/UDP ports in the 50 000 to 50 999 range - again both ways.

    Are you using dedicated public IP's for each service on your edge (Access, Web Conferencing and AV) or are you using a single IP for all of these services?
    Wednesday, November 8, 2017 2:50 PM
  • Alice,

    Yes your understanding is correct.  Everyone on premise works fine regardless of whether or not they are behind our firewall or outside of our network. 

    I have checked all of the ports and they are indeed open.  I have used telnet to connect to the edge access interface, as well as ran wireshark to verify the traffic is open.  I also tested other ports to the AV and Webconf IP addresses.  I am not seeing any traffic on my firewall to the webconf ip address when trying to share content.  is this normal?

    thank you for your responses. 

    Wednesday, November 8, 2017 5:47 PM
  • Paul,

    I agree that it must be a port issue because if User A is sitting on my wi-fi everything works as it should.  I thought the 50k range was for backwards compat with OCS? 

    At least that was my understanding based on the following, and many other, articles

    https://techcommunity.microsoft.com/t5/Skype-for-Business-Blog/Simplified-port-requirements-for-Skype-for-Business-Online/ba-p/77094

    Thank you for trying to point me in the right direction

    Wednesday, November 8, 2017 5:51 PM
  • Another development on this issue.  According to the trace logs the invite that is inbound has quite a few candidates, but the outbound 200 OK message only shows 2 candidates.  Both candidates show as the internal IP address for my front end server.  When I receive the BYE with the error code stated above the RemoteSite shows as 10.120.2.xx (My FE servers IP).  So with that I think the issue has to do with ICE and STUN right?  Something there isn't communicating correctly or I have a mis configuration in my topology that isn't very noticeable. 
    • Edited by rhelms20 Wednesday, November 8, 2017 6:01 PM
    Wednesday, November 8, 2017 6:00 PM
  • Hi rhelms20,

    Would you please tell did the issue appear on the specific skype meeting or all skype meeting had this issue?

    Sorry Alice I just realized that I did not answer this.  It doesn't matter what meeting it is, it just has to do with what participants.  In the same meetings internal users have no issue, as well as remote clients that are part of my Skype installation. 

    Thursday, November 9, 2017 12:06 PM
  • No, these ports should be opened.  The above article is only for SFB Online.  For on premise it's still recommended to open these port ranges.
    Thursday, November 9, 2017 12:47 PM
  • Can you do an open port comparison of the two sites?

    Thanks

    Carl Ediker

    Thursday, November 9, 2017 12:56 PM
  • This ended up being an issue with our fortigate firewalls.  One was on a different minor version than the other, and although FG support said it would not cause this issue, they were wrong.  I updated the code on the FW's and everything started communicating correctly.  

    Thanks for the information and help everyone provided. Hopefully this helps others figure out their issue.  

    Monday, February 26, 2018 4:06 PM
  • Hi

    We are also experiencing the same issue where a external federated partner would share screen and after a few secs it would drop. We also have fortgate FWs, please can you provide some more details of what the issue was on the FW, also which Fortigate FW are you using and the version you went from and to.

    thanks

    Dave 

    Tuesday, September 25, 2018 4:20 AM
  • Hi Dave,

    Is this issue resolved. If so, please let us know what you have done from your side to fix the issue.

    Regards,

    AJ

    Friday, July 5, 2019 12:12 PM