Announcement

Collapse
No announcement yet.

We couldn't connect to the presentation because of network issues

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • We couldn't connect to the presentation because of network issues

    Desktop sharing or presentation during conference calls are not working when internal users with Lync 2010 clients are connecting to external users. If the client is S4B 2013/2016 on the internal user side, everything is working fine.

    Here's what I'm getting in the Lync client logs:

    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";CallerMediaDebug="application-sharing:ICEWarn=0x900029,LocalSite=172.x.x.x: 60037,LocalMR=10.x.x.x:3478,RemoteSite=132.245. 112.9:50057,RemoteMR=132.245.112.44:59085,PortRang e=60001:60040,RemoteMRTCPPort=59085,LocalLocation= 2,RemoteLocation=1,FederationType=1"

    I also noticed that the public IP addresses our two Lync Edge servers and the NAT Public IP address of the affected clients are not shown in the candidate list in the INVITE packet sent by them to the remote client. All the candidates are "typ hosts" and are private IP addresses which are non-routable.
    UDP 3478 and TCP 443 are open from internal client network to internal interface of Edge servers (we have two). Persistent static routes are setup properly in the edge servers so that they can reach back the clients.

    Please help. Thanks.
    Last edited by kevindd992002; 10th August 2016, 04:21.

  • #2
    Please help.

    Comment


    • #3
      If your request is urgent and requires immediate assistance then please call the local Microsoft Office who will more than gladly accept your credit card in lieu of payment.

      All users on this forum are answering questions in their own free time and for no money. If, and when, someone answer who may have the skillset to assist then they will be free to answer.

      Start looking at firewalls and how they could potentially affect this

      https://social.technet.microsoft.com...csconferencing

      Comment


      • #4
        Originally posted by wullieb1 View Post
        If your request is urgent and requires immediate assistance then please call the local Microsoft Office who will more than gladly accept your credit card in lieu of payment.

        All users on this forum are answering questions in their own free time and for no money. If, and when, someone answer who may have the skillset to assist then they will be free to answer.

        Start looking at firewalls and how they could potentially affect this

        https://social.technet.microsoft.com...csconferencing
        I already checked our firewalls and all the required ports are open. I was bumping the thread because it has been more than one day since I posted it.

        Comment


        • #5
          Please do NOT bump it again - it is against the forum rules and just serves to annoy the members who give up their free time to help. Lync/SFB is a relatively specialist area so people will only help IF they feel they can.

          Have you run the tests at the remote connectivity analyser (testconnectivity.microsoft.com) as that often gives you useful help
          Have you considered upgrading the 2010 clients as they seem to be the root of your problems
          Tom Jones
          MCT, MCSE (2000:Security & 2003), MCSA:Security & Messaging, MCDBA, MCDST, MCITP(EA, EMA, SA, EDA, ES, CS), MCTS, MCP, Sec+
          PhD, MSc, FIAP, MIITT
          IT Trainer / Consultant
          Ossian Ltd
          Scotland

          ** Remember to give credit where credit is due and leave reputation points where appropriate **

          Comment


          • #6
            Originally posted by Ossian View Post
            Please do NOT bump it again - it is against the forum rules and just serves to annoy the members who give up their free time to help. Lync/SFB is a relatively specialist area so people will only help IF they feel they can.

            Have you run the tests at the remote connectivity analyser (testconnectivity.microsoft.com) as that often gives you useful help
            Have you considered upgrading the 2010 clients as they seem to be the root of your problems
            Sorry about that, I'm used to other forums wherein they allow a 24-hour interval bump in case the thread gets stumbled upon by other newer ones.

            Yes, no errors in remote connectivity analyser. Upgrading would be the last resort as we have thousands of client computers scattered all over the world. We need to know the root cause.

            Comment


            • #7
              Just to confirm desktop sharing works fine for S4B 2015 & 2016 clients internally or externally but not for Lync 2010 clients when external (EG on the Edge)? Tell us a bit more about your setup. What server version of Lync/S4B are you connecting to? Has your current configuration ever worked for Lync 2010 clients? How are you load balancing your Edge DNS or HLB? Are any of these clients using a VPN?
              Looking at your error msg if only the host candidate is being returned then there's either something wrong with your Edge server/pool configuration or you have a firewall preventing STUN/TURN candidates from being returned. That being said if a fw was the issue id expect the S4B clients to be affected too (assuming the S4B clients are connecting from the same subnet/network), as ICE negociation to my knowledge is the same in both clients. The RCA won't help you in troubleshooting this issue. Use the ICE warning flag decoder instead.

              https://gallery.technet.microsoft.co...coder-97058ef3

              ICEWarn=0x900029
              Last edited by scurlaruntings; 29th July 2016, 15:00.

              Comment


              • #8
                The issue is that internal Lync 2010 clients cannot share their desktop to external partners (usually using Office 365). I initially thought only Lync 2010 clients are affected. I have "some" users that when their Lync 2010 clients are upgraded to S4B 2015, everything works out just fine. But now I also have S4B 2015 clients experiencing the same issue.

                Our Lync server is 2010. I don't think it ever worked for Lync 2010 clients in the past. We have to Edge servers that are DNS-load balanced. None of these clients are using VPN.

                I just checked the ICE warning code and got multiple possible errors but in general it says the TURN server is unreachable. I can confirm that I can reach the Edge (TURN) servers through ports 443 and 3478 though. Another possible reason (based on what that ICE warning code results) is that multiple TURN servers are configured and it says that this flag is expected. So I'm not really sure if this flag is an error or not.

                What do you think?

                Comment


                • #9
                  Here's a test that I did to further isolate the issue. I have two test machines, one in the Philippines and one in Mexico. The one in the Philippines is using S4B 2016 and the one in Mexico is using S4B 2015 (w/ Lync 2013 interface). I used the same account (mine) so they're connecting to the same set of Edge (TURN) servers in the US. The one in the Philippines can share just fine to external partners but the one in Mexico fails with the error described in this thread. Both test machines can connect to the same set of Edge servers @ ports 443 TCP and 3478 UDP.

                  Here's what I got from the BYE event from the Lync client logs of the Mexico test machine though:

                  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";UserType="Callee";MediaType="application-sharing";NetworkErr="no error";ErrTime="0";RTPSeq="0";SeqDelta="0";RTPTime ="0";RTCPTime="0";TransptRecvErr="0x0";RecvErrT ime ="0";TransptSendErr="0xc0044003";SendErrTime="3 679 782182317";InterfacesStall="0x0";InterfacesConnChe ck="0x0";MrDnsE="av01ch.ingrammicro.com";MrResE=" 1 ";MrDnsI="uschezocs.corporate.ingrammicro.com" ;MrR esI="1";MrDnsCacheReadAttempt="0";ICEWarn="0x90002 9";ICEWarnEx="0x0";LocalSite="172.x.x.x:60026"; LocalMR="10.x.x.x:443";RemoteSite="132.245.112. 9:1763";RemoteMR="132.245.112.39:54441";PortRange= "60001:60040";RemoteMRTCPPort="54441";LocalLoc atio n="2";RemoteLocation="1";FederationType="0";Netw or kName="corporate.ingra";Interfaces="0x2";BaseInter face="0x2";BaseAddress="172.26.5.184:60004";IceRol e="1";RtpRtcpMux="1,FirstHopRTTInMs=0";MediaDllV er sion="5.0.8687.149";MrDnsE="av01ch.ingrammicro.com ";MrResE="1";MrDnsI="uschezocs.corporate.ingra mmic ro.com";MrResI="1";MrDnsCacheReadAttempt="0";LyncA ppSharingDebug="SharerChannel:0x0; Memory Usage: totalUsedVirtual=664, availableVirtual=1383;StartupTime: 2016-08-10T01:38:10.572Z;"

                  I'm not sure why it is connecting to 10.x.x.x:443 though and not through port 3478. Does this: TransptSendErr="0xc0044003" mean anything to you?
                  Last edited by kevindd992002; 10th August 2016, 04:21.

                  Comment


                  • #10
                    This is weird enough that it is probably worth raising a support case with Microsoft - I appreciate it costs you (unless you have some as part of an agreement) but IIRC they refund if it turns out to be a bug, and they have the experts to help you
                    Tom Jones
                    MCT, MCSE (2000:Security & 2003), MCSA:Security & Messaging, MCDBA, MCDST, MCITP(EA, EMA, SA, EDA, ES, CS), MCTS, MCP, Sec+
                    PhD, MSc, FIAP, MIITT
                    IT Trainer / Consultant
                    Ossian Ltd
                    Scotland

                    ** Remember to give credit where credit is due and leave reputation points where appropriate **

                    Comment


                    • #11
                      Originally posted by kevindd992002 View Post
                      Here's a test that I did to further isolate the issue. I have two test machines, one in the Philippines and one in Mexico. The one in the Philippines is using S4B 2016 and the one in Mexico is using S4B 2015 (w/ Lync 2013 interface). I used the same account (mine) so they're connecting to the same set of Edge (TURN) servers in the US. The one in the Philippines can share just fine to external partners but the one in Mexico fails with the error described in this thread. Both test machines can connect to the same set of Edge servers @ ports 443 TCP and 3478 UDP.

                      Here's what I got from the BYE event from the Lync client logs of the Mexico test machine though:

                      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";UserType="Callee";MediaType="application-sharing";NetworkErr="no error";ErrTime="0";RTPSeq="0";SeqDelta="0";RTPTime ="0";RTCPTime="0";TransptRecvErr="0x0";RecvErrT ime ="0";TransptSendErr="0xc0044003";SendErrTime="3 679 782182317";InterfacesStall="0x0";InterfacesConnChe ck="0x0";MrDnsE="av01ch.ingrammicro.com";MrResE=" 1 ";MrDnsI="uschezocs.corporate.ingrammicro.com" ;MrR esI="1";MrDnsCacheReadAttempt="0";ICEWarn="0x90002 9";ICEWarnEx="0x0";LocalSite="172.x.x.x:60026"; LocalMR="10.x.x.x:443";RemoteSite="132.245.112. 9:1763";RemoteMR="132.245.112.39:54441";PortRange= "60001:60040";RemoteMRTCPPort="54441";LocalLoc atio n="2";RemoteLocation="1";FederationType="0";Netw or kName="corporate.ingra";Interfaces="0x2";BaseInter face="0x2";BaseAddress="172.26.5.184:60004";IceRol e="1";RtpRtcpMux="1,FirstHopRTTInMs=0";MediaDllV er sion="5.0.8687.149";MrDnsE="av01ch.ingrammicro.com ";MrResE="1";MrDnsI="uschezocs.corporate.ingra mmic ro.com";MrResI="1";MrDnsCacheReadAttempt="0";LyncA ppSharingDebug="SharerChannel:0x0; Memory Usage: totalUsedVirtual=664, availableVirtual=1383;StartupTime: 2016-08-10T01:38:10.572Z;"

                      I'm not sure why it is connecting to 10.x.x.x:443 though and not through port 3478. Does this: TransptSendErr="0xc0044003" mean anything to you?
                      Port 3478 is used for media. Signalling is established on 443 for external/remote users. Ensure you have the correct ports open at all sites where users are connecting remotely. As the errors you're seeing indicate a firewall related issue where either ports are being blocked TCP/UDP or something within the network (IPS/IDS/3rd party AV etc) is interfering with SIP traffic. Seeing as you can login from the Mexico site its likey that port 3478 UDP is being blocked by your Mexico local fw.

                      Comment

                      Working...
                      X