locked
Lync External to Internal Video Call is not getting connect but external to External and Internal to Internal working RRS feed

  • Question

  • Hi Experts,

    We are using Lync server 2010 and now we have problem to connection Audio Video Call from Internal to External Client. Always getting massage Call was Not Cpmlited or Call was not complited due to Network problem.

    Internal to Internal Working

    External to External working 

    Meeting URK is working we can connect through Meeting URL.

    I have checked all the setting Including EDGE server Firewall DNS Records. but all seems ok.

    Please Suggest the me the Solution.

    Thanks:

    Amit Sharma


    Friday, August 10, 2012 2:54 PM

Answers

  • This indicates that peer to peer media is functional for internal clients and possibly even STUN media is working for external-to-external calls, but you are unable to utilize TURN for media proxying through the Edge Server.  Unless you are testing external clients in the same networks and they are also transmitting media directly between each other.

    Take a look at this blog article to make sure you have accounted for the proper ports and protocols in your deployment:
    http://blog.schertz.name/2012/07/understanding-lync-edge-server-ports


    Jeff Schertz | Microsoft Solutions Architect - Polycom | Lync MVP

    • Proposed as answer by Kent-Huang Friday, August 17, 2012 1:53 AM
    • Marked as answer by Kent-Huang Tuesday, August 28, 2012 7:09 AM
    Monday, August 13, 2012 12:31 AM
  • Hi,

    When one user is internal and one user is external , they will attempt peer to peer. The external user will hit TCP 5061 to the Access Edge Server and will be provided with either UDP 3478 or TCP 443 for the Audio/Video Edge. UDP 3478 is preferred even if the connection test for TCP 443 and UDP 3478 were successful in testing. Because this is technically peer to peer, the internal user will NOT connect to the MCU on the Front End but will instead connect directly to the A/V Edge Server’s Internal NIC over UDP 3478 or TCP 443 as well.  The Front End A/V MCU will not be used in this scenario.  When you add a 3rd person to the conversation, the external user will connect to the Front End Server’s A/V MCU in which the A/V Edge will proxy this data for the user, and the internal users will connect to the Front End A/V MCU instead of the Internal Edge NIC.

    You can do a netstat -an to see your server listening on UDP 3478 and utilize netcat which can attempt telnet to UDP by using netcat -u host 3478.

    Here is a good article about Lync server ports and audio/media negotiation for you to understand the media connection more clearly.

    http://www.shudnow.net/2010/12/06/lync-server-2010-port-ranges-and-audiomedia-negotiation/

    Regards,

    Kent


    Regards,

    Kent Huang

    TechNet Community Support

    ************************************************************************************************************************

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question.


    • Edited by Kent-Huang Monday, August 13, 2012 8:33 AM
    • Proposed as answer by Kent-Huang Friday, August 17, 2012 1:53 AM
    • Marked as answer by Kent-Huang Tuesday, August 28, 2012 7:09 AM
    Monday, August 13, 2012 8:33 AM
  • Actually the internal Lync user does not connect to the internal Edge interface over TCP5061.  The Front End server actually talks to the Edge server on behalf of the client in order to retrieve MRAS credentials and details.  This information is passed back to the client via the FE and contains the configured ICE information (FQDN and ports).

    As usual the signaling is always client-to-FE and the proxied media would be client<>Edge<>client.


    Jeff Schertz | Microsoft Solutions Architect - Polycom | Lync MVP

    • Proposed as answer by Kent-Huang Friday, August 17, 2012 1:54 AM
    • Marked as answer by Kent-Huang Tuesday, August 28, 2012 7:09 AM
    Monday, August 13, 2012 12:05 PM

All replies

  • I know that you say that you have checked all the firewall rules but I would double check because it sure sounds like a firewall issue. What you need to focus on is the AV service. Confirm that inbound TCP 443 is open and inbound/outbound UDP 3478 are open.
    Friday, August 10, 2012 3:53 PM
  • You should check your Firewall Settings for the EDGE Server again. Internal to internal and external to external Clients use peer to per calls for the A/V stream. So your Problem occurs that the traffic could not path through the Lync Edge.

    Ports are describe in the post from Alanmad, which should as Minimum opened on the public A/V and private IP of the Edge for A/V traffic. 


    regards Holger Technical Specialist UC

    Sunday, August 12, 2012 6:30 PM
  • This indicates that peer to peer media is functional for internal clients and possibly even STUN media is working for external-to-external calls, but you are unable to utilize TURN for media proxying through the Edge Server.  Unless you are testing external clients in the same networks and they are also transmitting media directly between each other.

    Take a look at this blog article to make sure you have accounted for the proper ports and protocols in your deployment:
    http://blog.schertz.name/2012/07/understanding-lync-edge-server-ports


    Jeff Schertz | Microsoft Solutions Architect - Polycom | Lync MVP

    • Proposed as answer by Kent-Huang Friday, August 17, 2012 1:53 AM
    • Marked as answer by Kent-Huang Tuesday, August 28, 2012 7:09 AM
    Monday, August 13, 2012 12:31 AM
  • Hi,

    When one user is internal and one user is external , they will attempt peer to peer. The external user will hit TCP 5061 to the Access Edge Server and will be provided with either UDP 3478 or TCP 443 for the Audio/Video Edge. UDP 3478 is preferred even if the connection test for TCP 443 and UDP 3478 were successful in testing. Because this is technically peer to peer, the internal user will NOT connect to the MCU on the Front End but will instead connect directly to the A/V Edge Server’s Internal NIC over UDP 3478 or TCP 443 as well.  The Front End A/V MCU will not be used in this scenario.  When you add a 3rd person to the conversation, the external user will connect to the Front End Server’s A/V MCU in which the A/V Edge will proxy this data for the user, and the internal users will connect to the Front End A/V MCU instead of the Internal Edge NIC.

    You can do a netstat -an to see your server listening on UDP 3478 and utilize netcat which can attempt telnet to UDP by using netcat -u host 3478.

    Here is a good article about Lync server ports and audio/media negotiation for you to understand the media connection more clearly.

    http://www.shudnow.net/2010/12/06/lync-server-2010-port-ranges-and-audiomedia-negotiation/

    Regards,

    Kent


    Regards,

    Kent Huang

    TechNet Community Support

    ************************************************************************************************************************

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question.


    • Edited by Kent-Huang Monday, August 13, 2012 8:33 AM
    • Proposed as answer by Kent-Huang Friday, August 17, 2012 1:53 AM
    • Marked as answer by Kent-Huang Tuesday, August 28, 2012 7:09 AM
    Monday, August 13, 2012 8:33 AM
  • Actually the internal Lync user does not connect to the internal Edge interface over TCP5061.  The Front End server actually talks to the Edge server on behalf of the client in order to retrieve MRAS credentials and details.  This information is passed back to the client via the FE and contains the configured ICE information (FQDN and ports).

    As usual the signaling is always client-to-FE and the proxied media would be client<>Edge<>client.


    Jeff Schertz | Microsoft Solutions Architect - Polycom | Lync MVP

    • Proposed as answer by Kent-Huang Friday, August 17, 2012 1:54 AM
    • Marked as answer by Kent-Huang Tuesday, August 28, 2012 7:09 AM
    Monday, August 13, 2012 12:05 PM