locked
Lync sharing failed to connect due to network issues - Edge RRS feed

  • Question

  • Hi All,

    I've published Lync Edge. However, Share Desktop, Share App is not working from External Users.

    Is there a way I can validate that is a networkinf issue?

    Regards


    Regards. José Osorio.
    Monday, January 9, 2012 11:04 PM

All replies

  • If I upload a PPT it works. The problem is when I want to share my desktop or any other program.

     

    Which logs do I have to trace in Lync Edge and Front-End?

     

    I have this log in remote User:

     

    ms-client-diagnostics

    : 23; reason="Call failed to establish due to a media connectivity failure when one endpoint is internal and the other is remote";CallerMediaDebug="application-sharing:ICEWarn=0x800029,LocalSite=192.168.137.1:10529,LocalMR=201.234.125.223:3478,RemoteSite=172.20.15.20:24931,PortRange=1025:65000,LocalLocation=1,RemoteLocation=2,FederationType=0"

     


    Regards. José Osorio.

    Monday, January 9, 2012 11:42 PM
  • Hi Jose,

    the log from the remote user, so your internal client IP is 172.20.15.20.  if so i cannot see the remote MR sent by the internal client, i guess the internal client fails to discover its media relay

    what ports are open between Lync client and the internal edge interface? you need to have 3478 UDP and 443 TCP open from your internal network to Edge internal interface

    do you have bandwidth policy configured?

    Do you have any firewall or HTTP proxy between internal clients and Internal edge interface?. if so can you verify that F/W or proxy doesn't do deep SSL inspection?

    BR,

    Tuesday, January 10, 2012 7:26 PM
  • Hi M.Wahab,

     

    Thanks for your reply,

     

    Yes, Internal Client IP is 172.20.15.20

    Internal Clients (172.20.x.x) can't telnet 443 or 3478 to Internal Edge Interface (192.168.26.62).

    There is a firewall between them.

    Is that neccesary?

    I said that because Lync Edge Interface (192.168.26.62) has established communication with Lync Front-End (192.168.26.60)

     


    Regards. José Osorio.
    Thursday, January 12, 2012 5:59 PM
  • Jose,

    internal client must be able to

    - resolve internal edge interface FQDN

    - comunicate with internal edge interface on ports 443 TCP and 3478 UDP (Please note 3478 is UDP and you cannot test it using telnet, google   for UDP test tool you will find many)

    Lync front end can communicate with Lync edge doesn't mean that the media will be established since the media flows directly from the client to the internal edge interface

    Hope this will help

    BR,

    Thursday, January 12, 2012 6:33 PM
  • Hi Jose,

    This issue usually occurs because one or more of the following conditions are true:

    ·          Port 443 or ports 50000-59999 are blocked.

    ·          Traffic to or from meet.lync.com is blocked.

    Please confirm. And here’re two similar posts (Post A & Post B) for reference, hope helps.


    Noya Liu

    TechNet Community Support

    Friday, January 13, 2012 5:46 AM
  • Hi Noya,

     

    How do I test Meet URL?

    My URL is:

     

    https://lync.contoso.com/contoso.com/Meet


    Regards. José Osorio.
    Friday, January 13, 2012 6:51 PM
  •  

     

    Hi Jose,

     

    Your ICE warning flag is indicating multiple network-level warnings... 

    (note these are bit-level flags, so there can be more than one).

    I've highlighted the ones that pertain to 0x800029:

    ICE Protocol Warning Flags

    Description

    Actions for the Administrator

    0x0

    There were no failures or the ICE protocol was not used.

    None.

    0x1

    TURN server is unreachable.

     

    This flag is not expected. Administrator need to ensure that the right ports (443/3478—by default) are open on the firewall or the TURN server is running. This may result in an ICE protocol failure.

    0x2

    An attempt to allocate a UDP port on the TURN server failed.

    This flag may be expected if the client is behind a UDP blocking firewall. This may result in an ICE protocol failure.

    0x4

    An attempt to send UDP on the TURN server failed.

     

    This flag may be expected if the client is behind a UDP blocking firewall. This may result in an ICE protocol failure.

    0x8

    An attempt to allocate a TCP port on the TURN server failed.

     

    This flag isn’t expected. The administrator needs to check the firewall policy, and ensure that Audio/Video Edge service is reachable. If the client is behind an HTTP proxy, the administrator needs to ensure that the proxy isn’t failing the TLS attempt. This failure may result in an ICE protocol failure.

    0x10

    An attempt to send TCP on the TURN server failed.

     

    This flag isn’t expected. The administrator needs to check the firewall policy, and ensure that Audio/Video Edge service is reachable. If the remote client is behind an HTTP proxy, the admin needs to ensure that the proxy isn’t failing the TLS attempt. This failure may result in an ICE protocol failure.

    0x20

    Local connectivity failed. (local UDP for audio/video and local TCP for application sharing and file transfer).

     

    This flag can occur if the direct connection between clients isn’t possible due to NAT/firewalls. This may result in an ICE protocol failure.

    0x40

    UDP NAT connectivity failed.

     

    This flag can occur if the direct connection between clients isn’t possible due to NAT/firewalls. This may result in an ICE protocol failure.

    0x80

    UDP TURN server connectivity failed.

     

    This flag can occur if one of the clients is behind a UDP blocking firewall/HTTP proxy. This may result in an ICE protocol failure.

    0x100

    TCP NAT connectivity failed.

     

     

    This flag is expected. If local-to-local connectivity succeeded, the TCP NAT connectivity check may not have been tried. Or there is no direct TCP connection possible. TCP NAT connectivity failing may result in an ICE protocol failure.

    0x200

    TCP TURN server connectivity failed.

     

     

    This flag is expected. If local-to-local connectivity succeeded, the TCP TURN connectivity check may not have been tried. Or one side didn’t have TURN server allocation. If connectivity checks were successful for the rest of the call, ignore this ICE protocol warning. Otherwise, investigate why the TCP path was not possible. TCP TURN server connectivity failing may result in an ICE protocol failure.

    0x400

    Message integrity failed in connectivity check request.

     

     

    This flag isn’t expected. If the admin sees this flag, it indicates some security attack. This may result in an ICE protocol failure.

    0x1000

    A policy server was configured.

     

    This flag is expected if there is a bandwidth policy configured on the call link. If there is a call failure with this flag, increase the allocated bandwidth on the failed link. This flag isn’t indicating any ICE protocol failure, simply that there was a bandwidth policy applied to this call.

    0x2000

    Connectivity check requested failed because of a memory problem or other reasons that prevented sending packets.

     

     

    This flag is unexpected and may indicate that a computer is over capacity This may result in an ICE protocol failure.

    0x4000

    TURN server credentials have expired or are unknown.

     

     

    This flag is unexpected and may indicate that Audio/Video Edge service authorization service is down. This may result in an ICE protocol failure.

    0x8000

    Bandwidth policy restriction has removed some candidates.

     

     

    If there is an ICE protocol failure with this flag set, this indicates that the policy server topology is misconfigured. In this configuration the policy was configured to route over another connection, but the other connection failed. (Possibility of internal NATs in the org). This flag may result in an ICE protocol failure.

    0x10000

    Bandwidth policy restriction decreases the bandwidth.

     

     

    This flag indicates that the bandwidth being used on this call isn’t optimal quality (may be using a narrow-band codec or may not be capable of HD video). This flag does not indicate any ICE protocol failure.

    0x20000

    Bandwidth policy keep-alive failed.

     

    This is unexpected. The call continues but the bandwidth used by this call may not be reported properly to the Bandwidth Policy Core Service. This can occur because the policy server or the TURN server have failed. This flag does not indicate any ICE protocol failure.

    0x40000

    Bandwidth policy allocation failure.

     

    This flag is indicating that the policy server rejected the client to use a media path through two Audio/Video Edge services (relay to relay). This may result in an ICE protocol failure.

    0x80000

    No TURN server configured.

     

    This flag is indicating that there was no TURN server configured or there is a Domain Name System (DNS) resolution failure, resulting in a communication issue between the client and the TURN server. This may result in a protocol ICE failure.

    0x100000

    Multiple TURN servers configured.

     

    This flag is expected. This is indicating that there were multiple TURN servers configured (due to DNS load balancing). This flag does not indicate any ICE protocol failure.

    0x200000

    Port range exhausted.

     

    This is indicating that the administrator manually configured ports on the client or the media server. A/V needs a minimum of 20 ports per call to start the call. Application sharing/file transfer needs a minimum of 3 ports. The port range being exhausted may result in an ICE protocol failure.

    0x400000

    Received alternate server

    .

    This is indicating that the TURN server is overloaded or preventing new connections. This may result in  an ICE protocol failure if the alternate server isn’t running

    0x800000

    Pseudo-TLS failure.

     

    This is indicating that the HTTP proxy is performing deep Secure Sockets Layer (SSL) inspection and failing the connection with the TURN server. This is not supported by Microsoft and may result in an ICE protocol failure.

    0x1000000

    HTTP proxy configured.

     

    This is indicating that the HTTP proxy is configured This flag does not indicate any ICE protocol failure.

    0x2000000

    HTTP proxy authentication failed.

    This is indicating that the HTTP proxy failed the authentication. This isn’t expected and indicates that the HTTP proxy didn’t recognize the user’s credentials or authentication mode. This may result in an ICE protocol failure.

    0x4000000

    TCP-TCP connectivity checks failed over the TURN Server.

     

    This is indicating that TURN TCP-TCP connectivity check was tried and it failed. The failure indicates that port 443 was not opened on the firewall. If one of the TURN servers was 2007 A/V Edge Server. The administrator needs to open ports from 50,000 through 59,999 TCP to all external Audio/Video Edge services in the environment. This flag isn’t expected and may result in an ICE protocol failure.

    0x80000000

    Use candidate checks failed.

     

    This is indicating that after receiving some packets the client didn’t receive the rest of the packets. This may happen on a client because of a third Winsock layered service providers (LSPs). These LSPs should be removed. This flag isn’t expected and may result in an ICE protocol failure.


    Mark A. Gutowski
    Saturday, January 14, 2012 9:59 PM
  • Create a Meet Now meeting, copy the URL and use this to test from an internet computer. The URL will provide a Meeting page, but it willnot have a user/meeting so it will highlight the meeting url is not valid.

     

    <noscript id="noScriptContent"></noscript>



    <label id="errorTextLabel" style="color: #ff0000; font-weight: normal;">Error: Meeting URL is not valid.</label>

     

    • Proposed as answer by Noya Lau Wednesday, February 1, 2012 4:00 AM
    Sunday, January 15, 2012 5:21 AM
  • I added *.meet.lync.com to my Trusted Sites and reconnected to my meeting. Now it works!

    Thank you!

    Wednesday, November 12, 2014 5:19 PM