locked
Application/Desktop Sharing to federated conference sometimes not working RRS feed

  • Question

  • Hey together,

    I encounter a very strange with our SfB deployment...
    When our users will be invited to a conference hosted by another company the application/desktop sharing is not working
    The strange this is, this problem do not encounter everytime. I have tested a few conferences which were hosted by some other companies where everything was working properly and I did not had any problems there.
    And in some other cases the desktop sharing never worked - I always receive the error "due to network issues...." Other participants from other companies did not had any problems with the sharing - just me..

    Even in the conferences where Sharing is not working Audio is working without any problem. In each case we never had issues with the Audio portion of the conference.

    First of all I thought this was a problem on the federated site but if I connect to the conference from outside with a STUN candidate and will not leverage my Edge server to relay the media, it was working fine.. So there must be something strange with our Edge Server.

    I always receive the following error:

    25; reason="A federated call failed to establish due to a media connectivity failure where both endpoints are internal"

    ICEWarn=0x4000320

    When we hosted the conference in our deployment everything worked well..
    I have read something about a routing problem - because the error message is not right, or?
    I have added all of my client subnets manually to the persistent route list and removed the route for the external interfaecs - no luck...

    Sharing between our colleagues from internal to external is working fine - no problems so far.

    I have checked the client logs from a working sharing and a not working sharing - Everything looks good - i can see the relay candidates from both, my client and the federated site. In the error case my client will not send a second invite with the final candidates. Instead there is a "bye". The only difference I mentioned so far is, that in the "Bye" message of the error there is no "Remote Address" listed.

    I dont really know where I have to look at.. Do you have any ideas.

    Our deployment: 1 edge pool with 2 servers -> 1 server is always offline
    each edge server has 3 external interfaces and 1 internal interface
    HLB: NetScaler (for the internal and external interface as well)

    Thanks in advance and greets,
    Markus

    Monday, March 13, 2017 9:51 AM

Answers

  • Hi together,

    I might have found the solution for this problem.

    We use NAT in our Deployment and there was not SNAT for the external AV Interface for Port 443.
    We have set up the FW rules with the planning tool and there is no entry for 443 SNAT. But in MCs Technet and some other websites they recommended to create this rule.

    After we have set up the rule it startetd to work without any issues.(up to now)

    I just wanted you to know about the solution. Was quite easy in the end, but I never thought about a FW problem, because I checked everything with the planning tool...

    Greets,
    Markus

    • Marked as answer by Markus_95 Thursday, July 20, 2017 9:10 AM
    Thursday, July 20, 2017 9:10 AM

All replies

  • Hi Markus,

    Did the issue just appear on the specific SFB client ?

    According your error message, it may be something wrong with the federation between your company and other company.

    For troubleshooting this issue, please try the following methods:
    1. If the issue only appeared on the specific SFB client, please try to clear SFB cache files and test again.
    2. Make sure that your firewall is configured properly for the Edge, the web conferencing edge service was configured to use port 444 , make sure the port 444 is open on your external firewall.
    3. Use get-CsConferencingConfiguration to check the application sharing port is correct: http://technet.microsoft.com/en-us/library/gg412969.aspx

    Moreover, please also use Microsoft remote connectivity analyzer check if there are any error messages.
    https://testconnectivity.microsoft.com/


    Regards,

    Alice Wang


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

    • Proposed as answer by Alice-Wang Wednesday, March 15, 2017 8:29 AM
    • Unproposed as answer by Markus_95 Thursday, March 23, 2017 8:12 PM
    Tuesday, March 14, 2017 6:33 AM
  • Hi alice,

    thanks for your reply and sry. for the delay of my answer.

    1. The remote connectivity analyzer tells me that everything is configured properly.

    2. We have set up the Conferencing Configuration for the appsharing to use 40 ports.
        Port Range: 20080 - 20119

    3. Our Edge Web Conf Service is configured to use port 443 as well as the AV and Access Edge Service      because we have an unique IP address for each service.

    4. The problem seems not to appear on specific clients, I have deleted my cache but this did not help to resolve the issue.

    Must be something between the federation but I dont know what...

    Greets,
    Markus

    Wednesday, March 22, 2017 9:03 AM
  • Good evening,

    I have tested a few things and monitored everything with the Network Monitor from Microsoft.
    As I mentioned above, the Audio portion is always working fine, when I run the trace on the Edge Server, I can see the following Ports:

    When I start the application sharing (which will not work) I can see the following ports:

    I think this is OK, isnt it? My Edge Server tries to connect via Port 443 to one of the high level Ports of the other Edge, right?

    This is how it looks like when I initiate the application sharing from my computer (remote) which will work.
    My computer directly communicate with the edge of the other site.

    Any ideas?

    Greets,
    Markus

    Thursday, March 23, 2017 8:18 PM
  • I wanted to share my own experience -

    We had a similar issue, and I discovered that there were static routes missing between the Edge server and the internal network (not all subnets were included in the routes).  There was a misperception that the Edge server only talked to the FE servers, but in reality, Microsoft documentation shows that the clients do send traffic directly to the edge servers in these scenarios.  Thus, you may need static routes (or your remote federated partner may need static routes) in order for the edge server to reach the clients. 

    Thursday, March 23, 2017 10:27 PM
  • Hi,

    our static routes are ok, I have checked them some time before and manually set up for each client subnet a separate route. In the past I had one private address range covered with one static route "/8". Some people told me that it could be a problem when the network of the external interfaces of the edge is within this range thats why I removed the "big" entry and create for each subnet a new entry. But unfortunately this did not work...

    I also have read about symmetric and asymmetric routing from the external interaces (with NAT). Maybe this could be reason for the problem.

    But I have to check this first.

    Greets,
    Markus

    Friday, March 24, 2017 7:08 AM

  • I think this is OK, isnt it? My Edge Server tries to connect via Port 443 to one of the high level Ports of the other Edge, right?

    your AV Edge tries to communicate (from TCP 50,000-59,999 ) with AV Edge on other side (to tcp 443). so check, if outgoing traffic is allowed. Also you have to allow all incoming traffic to your tcp 443 on AV Edge (you can download and see it here https://www.microsoft.com/en-us/download/details.aspx?id=46448 )

    >>My computer directly communicate with the edge of the other site.

    Can you deny direct traffic from your pc to other edge and do test again? The best way to communicate with federated users, is when traffic goes yourPC - your Edge - other Edge - other PC. in your situation it can work like that: PC - other Edge - other pc. But it's very strange that audio works with federated users, because ports range for AV and sharing are the same.

    Also you can collect logs (run Start-CsClsLogging) and explore it with Snooper.

    Friday, March 24, 2017 7:40 AM
  • Hi!

    thanks for the explanation!

    Yeah for sure, as soon as I am connected to our network of the company I make use of the scenario you described above and the desktop sharing is not working anymore...

    I have checked the logs with snooper and there is definitely a problem with the TCP checks.
    All kind of candidates are present but in the final invite I only see one UDP candidate for the application sharing.

    I have the following candidate list in the first invite for sharing:

    m=applicationsharing 54992 TCP/RTP/AVP 127

    --------------- There are only TCP candidates present

    a=x-mediabw:applicationsharing-video send=8100;recv=4000
    m=applicationsharing 54992 TCP/RTP/AVP 127

    --------------- There are only TCP candidates present

    a=rtcp-rsize
    a=label:applicationsharing-video

    --------------- There are UDP and TCP candidates present and one of the UDP candidates will be choosen.

    very strange problem...

    Greets,
    Markus

    Monday, March 27, 2017 6:40 AM
  • Hi,

    I have set up a second infrastructure and will take a look at it.

    If I found out the issue, I will let you know!

    Greets,
    Markus

    Friday, May 19, 2017 6:10 AM
  • Hi together,

    I might have found the solution for this problem.

    We use NAT in our Deployment and there was not SNAT for the external AV Interface for Port 443.
    We have set up the FW rules with the planning tool and there is no entry for 443 SNAT. But in MCs Technet and some other websites they recommended to create this rule.

    After we have set up the rule it startetd to work without any issues.(up to now)

    I just wanted you to know about the solution. Was quite easy in the end, but I never thought about a FW problem, because I checked everything with the planning tool...

    Greets,
    Markus

    • Marked as answer by Markus_95 Thursday, July 20, 2017 9:10 AM
    Thursday, July 20, 2017 9:10 AM