none
Lync A/V not working via Edge except for Federation RRS feed

  • Question

  • I have an interesting problem.

    Internal users can do audio/video/screen sharing just fine from the internal network.

    I can do A/V and screen sharing with my federated contacts just fine from my internal network.

    When I use Lync on an external network (from home, public wifi, or even 4G), I can see presence, IM back and forth with no issues, but I can not do Audio/Video or screen sharing. I can do the whiteboard/Q&A/etc. It connects the call but I don't see or hear the other internal participant, and then it disconnects after exactly 10 seconds.

    The 2013 Lync Mobile app has the same issue - I can IM, but cant use audio or video.

    Does anyone know where I should start? I currently have a mixed topology with Lync 2010 and 2013 front-end servers, and a Single consolidated 2010 Edge server, with 3 external IP's addresses NAT'd to 3 public addresses. I remember that this used to work, but since it is not a heavily used feature, I don't know when it stopped working. It may have stopped when I installed the 2013 FE servers but i'm not positive.

    Thursday, November 14, 2013 10:55 PM

All replies

  • Hi Saul,

    Does the issue happen only for you or for multiple users?

    Does the issue happen when two users having A/V both external?

    The issue may be related to A/V service of Edge server. Please double check if the ports UDP: 3478, TCP 443 and UDP/TCP 50,000-59,999 are opened.

    If the issue persists, please enable logging tool on Edge Server and Front End Server for troubleshooting.

    Best Regards,

    Eason Huang


    Eason Huang
    TechNet Community Support

    Friday, November 15, 2013 12:31 PM
    Moderator
  • Hi Saul,

    Does the issue happen only for you or for multiple users?

    Does the issue happen when two users having A/V both external?

    The issue may be related to A/V service of Edge server. Please double check if the ports UDP: 3478, TCP 443 and UDP/TCP 50,000-59,999 are opened.

    If the issue persists, please enable logging tool on Edge Server and Front End Server for troubleshooting.

    Best Regards,

    Eason Huang


    Eason Huang
    TechNet Community Support


    Thanks for the reply, I will try that. I would think if I could make successful video calls to federated partners, that those ports would be open. Is that not accurate?
    Friday, November 15, 2013 1:44 PM
  • It but only in the sense that it's function on one side of the edge server. The method in which the clients connect to each other is different when it's peer to peer (2 people). When an internal user connects with a remote user they both connect directly to the edge server and attempt to establish a connection on ports TCP 443 and UDP 3478. The internal user will connect to the internal Edge interface and the external user will use the external edge interface.

    So make sure that both these ports are accesible from both interfaces on the edge server. Often it's an issue with the internal routing of the edge internal interface.


    --Mike-- Network/Systems Administrator

    Friday, November 15, 2013 2:15 PM
  • Thanks, I will check that.

    Should I be able to ping my external interfaces on the edge server from my local workstation? Not the public addresses, but the external IP addresses in the DMZ?

    Friday, November 15, 2013 2:43 PM
  • Yes if they are public addresses. Also if your using NAT check your firewall to ensure it is allowing the communication in both directions. It can be a bit tricky on some firewalls with redirection.

    EDIT:: Sorry I mis read your question, No you should not be able to route to the external ip of the edge server, only the Public ip of the edge server from within the internal network. Those interfaces should be on separate subnets.


    --Mike-- Network/Systems Administrator


    • Edited by Moto-Mike Friday, November 15, 2013 2:49 PM
    Friday, November 15, 2013 2:47 PM
  • No, not unless for some reason you have them on the same subnet as your internal Edge / internal network or you have specified the static route on your local workstation.

    Can you advise of the ports that your public AV Edge IP is forwarding to your private AV Edge IP.

    If it once used to work, i'd advise checking your certificates.

    Check the firewall on your Edge server.

    Regards
    Ben

    Friday, November 15, 2013 2:51 PM
  • The external IP addresses are on different subnets than the Internal interface of the edge server, and they both are in different subnets than our Lync Clients.

    For instance:

    Public addresses:

    sipaccess.contoso.com - 70.25.4.125

    webconf.contoso.com - 70.25.4.126

    av.contoso.com - 70.25.4.127

    External addresses:

    192.168.250.125

    192.168.250.126

    192.168.250.127 (NAT Enabled in Topology)

    Internal addresses:

    edge.lync. local 192.168.200.90

    pool1.lync.local 10.254.8.55

    Lync client 10.254.110.63

    From the Lync client or pool, I can ping 192.168.250.125/126/127, and I can resolve edge.lync.local.

    Also, the test from testexchangeconnectivity.com passes all A/V tests.

    Friday, November 15, 2013 3:27 PM
  • Enable client logging from the client side, and enable sipstack logging from the edge server. Reproduce the issue. Then take a look at your sipstack logging for issues. If they are present we can use the cleint logging to further detail what's happening or not happening. I have a feeling this is an issue with the internal routing of your edge and client.

    Also was there a reason you didn't place the internal lync NIC on the same subnet as your FE pool?


    --Mike-- Network/Systems Administrator

    Friday, November 15, 2013 3:36 PM
  • I think it probably is Mike, but is using class A or B addressing internally; 10.254.x.x

    His Edge is sat between back to back firewalls I believe, or liad out that way logically anyway.


    Friday, November 15, 2013 3:45 PM
  • I think it probably is Mike, but is using class A or B addressing internally; 10.254.x.x

    His Edge is sat between back to back firewalls I believe, or liad out that way logically anyway.


    From my understanding that is true. I put it where the security team told me to put the interface :)

    There is a firewall on both sides of the edge server.  Is that not best practice?
    Friday, November 15, 2013 3:57 PM
  • An interesting test to prove this would be to do a 3 person conference with 2 internal users and one remote user. If I'm right the remote user should be able to use audio and video. What will happen is the conference will force all participants to route to the front end MCU instead of attmepting a P2P connection. If your routing is bad to your lync edge internal interface your client may establish a connection on the external interface. This will cause both participants to think they are outside the deployment and attempt a P2P connection without going through the edge which subsequently should fail for audio and video.

    --Mike-- Network/Systems Administrator

    Friday, November 15, 2013 3:59 PM
  • Not at all Saul, your Edge placement is absolutely correct.
    Friday, November 15, 2013 4:26 PM
  • 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";CalleeMediaDebug="audio:ICEWarn=0x12a,LocalSite=132.25.2.56:7948,LocalMR=92.203.246.127:3478,RemoteSite=12.254.113.186:23338,RemoteMR=92.203.246.127:52726,PortRange=1025:65000,RemoteMRTCPPort=52726,LocalLocation=1,RemoteLocation=2,FederationType=0,NetworkName=Corp_Guest,Interfaces=0x14,BaseInterface=0x4,BaseAddress=132.25.2.56:32996"

    132.25.2.56 = Public Wifi

    92.203.246.127 = av.contoso.com

    12.254.113.186 = internal Lync client

    Friday, November 15, 2013 9:09 PM
  • An interesting test to prove this would be to do a 3 person conference with 2 internal users and one remote user. If I'm right the remote user should be able to use audio and video. What will happen is the conference will force all participants to route to the front end MCU instead of attmepting a P2P connection. If your routing is bad to your lync edge internal interface your client may establish a connection on the external interface. This will cause both participants to think they are outside the deployment and attempt a P2P connection without going through the edge which subsequently should fail for audio and video.

    --Mike-- Network/Systems Administrator


    The 2 internal users can see and hear other just fine, external cannot.
    Friday, November 15, 2013 9:22 PM
  • Can you telnet to port 443 on your internal edge interface?
    Can you test the connection between 2 remote users?

    --Mike-- Network/Systems Administrator

    Monday, November 18, 2013 2:25 PM
  • Can you telnet to port 443 on your internal edge interface?
    Can you test the connection between 2 remote users?

    --Mike-- Network/Systems Administrator

    Yes, I can telnet over 443.

    2 remote users also fails.

    Monday, November 18, 2013 3:56 PM
  • How are your internal and external Edge NICS configured? Do you have the gateway address set on both or one and how is the dns configured for both of them?


    --Mike-- Network/Systems Administrator

    Monday, November 18, 2013 6:43 PM
  • How are your internal and external Edge NICS configured? Do you have the gateway address set on both or one and how is the dns configured for both of them?


    --Mike-- Network/Systems Administrator

    I have the gateway configured on the external facing interfaces.

    The internal interface has a persistent static route configured.

    I am just using a host file.

    Monday, November 18, 2013 7:13 PM
  • You have no DNS configured for the external NIC?

    If not you need to configure one. A public DNS like google will work.


    --Mike-- Network/Systems Administrator

    Monday, November 18, 2013 8:52 PM
  •  Looks like your external client is failing to complete a TURN request. Your ICE Warning flag, as well as your symptoms support this.

     Ensure you can hit your external A/V edge on port 3478, else your external client will be unable to negotiate a port allocation with that edge. If there is no media port allocated no media path will be established.

     I, personally, would test in this manner:

     Start a network cap on your external machine and fire up a call. Look to see whether your TURN requests on UDP port 3478 are responded to by the AV edge...

     Jon McClary

    Monday, November 18, 2013 10:24 PM
  •  Looks like your external client is failing to complete a TURN request. Your ICE Warning flag, as well as your symptoms support this.

     Ensure you can hit your external A/V edge on port 3478, else your external client will be unable to negotiate a port allocation with that edge. If there is no media port allocated no media path will be established.

     I, personally, would test in this manner:

     Start a network cap on your external machine and fire up a call. Look to see whether your TURN requests on UDP port 3478 are responded to by the AV edge...

     Jon McClary

    FYI, here is the test results from testexchangeconnectivity.com:

    Attempting to contact Audio/Video Lync Edge server av.contoso.com at TCP port 443. The Audio/Video Lync Edge server name, the TCP port, and the UDP Port 3478 on which it listens for Media Port requests are obtained from the Microsoft Office Communications Server when the test user signs in. This test determines if the Audio/Video Lync Edge server is properly accepting STUN/TURN requests for Media TCP ports in order for external voice and video calls to be enabled.

      The Audio/Video Lync Edge server is accepting requests for TCP Media ports.

    Tuesday, November 19, 2013 1:46 PM
  •  You can verify my earlier statement by looking at your ICE candidate list when your AV fails... 
     Look in snooper at the log, and search for 'candidate'... you should see a list of at least 6 entries similar to this:

    a=candidate:1 1 UDP 2140706431 192.168.1.101 39052 typ host
    a=candidate:1 2 UDP 2140705918 192.168.1.101 39053 typ host
    a=candidate:2 1 TCP-PASS 6656159 x.x.x.x 56276 typ relay raddr 192.168.1.101 rport 39041
    a=candidate:2 2 TCP-PASS 6656158 x.x.x.x 56276 typ relay raddr 192.168.1.101 rport 39041
    a=candidate:3 1 UDP 16648713 x.x.x.x 55824 typ relay raddr 192.168.1.101 rport 39050
    a=candidate:3 2 UDP 16648712 x.x.x.x 52421 typ relay raddr 192.168.1.101 rport 39051
    a=candidate:4 1 TCP-ACT 7086863 x.x.x.x 56276 typ relay raddr 192.168.1.101 rport 39041
    a=candidate:4 2 TCP-ACT 7086350 x.x.x.x 56276 typ relay raddr 192.168.1.101 rport 39041
    a=candidate:5 1 TCP-ACT 1664797951 y.y.y.y 39041 typ srflx raddr 192.168.1.101 rport 39041
    a=candidate:5 2 TCP-ACT 1664797438 y.y.y.y 39041 typ srflx raddr 192.168.1.101 rport 39041

     missing typ relay or typ srflx raddr means you're not successfully talking to your edge, and getting ports allocated, which is my suspicion. The best troubleshooting step from there is a network capture to verify whether you are getting responses to your TURN requests. I can't comment on the connectivity test website, as I haven't used it, but I have spent a lot of time troubleshooting edge issues in multiple environments... 


    Jon McClary

    Thursday, November 21, 2013 9:16 PM
  •  You can verify my earlier statement by looking at your ICE candidate list when your AV fails... 
     Look in snooper at the log, and search for 'candidate'... you should see a list of at least 6 entries similar to this:

    a=candidate:1 1 UDP 2140706431 192.168.1.101 39052 typ host
    a=candidate:1 2 UDP 2140705918 192.168.1.101 39053 typ host
    a=candidate:2 1 TCP-PASS 6656159 x.x.x.x 56276 typ relay raddr 192.168.1.101 rport 39041
    a=candidate:2 2 TCP-PASS 6656158 x.x.x.x 56276 typ relay raddr 192.168.1.101 rport 39041
    a=candidate:3 1 UDP 16648713 x.x.x.x 55824 typ relay raddr 192.168.1.101 rport 39050
    a=candidate:3 2 UDP 16648712 x.x.x.x 52421 typ relay raddr 192.168.1.101 rport 39051
    a=candidate:4 1 TCP-ACT 7086863 x.x.x.x 56276 typ relay raddr 192.168.1.101 rport 39041
    a=candidate:4 2 TCP-ACT 7086350 x.x.x.x 56276 typ relay raddr 192.168.1.101 rport 39041
    a=candidate:5 1 TCP-ACT 1664797951 y.y.y.y 39041 typ srflx raddr 192.168.1.101 rport 39041
    a=candidate:5 2 TCP-ACT 1664797438 y.y.y.y 39041 typ srflx raddr 192.168.1.101 rport 39041

     missing typ relay or typ srflx raddr means you're not successfully talking to your edge, and getting ports allocated, which is my suspicion. The best troubleshooting step from there is a network capture to verify whether you are getting responses to your TURN requests. I can't comment on the connectivity test website, as I haven't used it, but I have spent a lot of time troubleshooting edge issues in multiple environments... 


    Jon McClary

    Using the lync logging tool, which components should I log to get this output?
    Friday, November 22, 2013 5:57 PM
  • Did you ever get this sorted as I have the same issue

    ***Don't forget to mark helpful or answer***

    Thursday, May 15, 2014 2:09 PM
  • Where you ever able to solve this situation?  I'm currently struggling with this issue and am looking for any help at all on it.
    Saturday, October 4, 2014 6:20 AM
  • We are facing a similar issue. If the lync client, edge internal IP and frontend  were in the same VLAN of the Edgeserver there was no issue, but if the client was not in the same subnet the AV failed. Need to check if the switch blocking the STUN traffic from diiferent subnet
    Thursday, December 10, 2015 4:02 AM
  • Hello,I also encountered the same problem. How do you solve this problem?

    企业视频会议及信息化整体解决方案提供商(AD\Exchange\Lync\Sharepoint\CRM\OA等部署及维护、咨询及培训等) 微软统一沟通中国(一)群:222630797,Lync 中国群:319902245,Sharepoint 中国群:187736229,【QQ:185426445.联系方式:18666943750,18926905701】

    Friday, January 18, 2019 6:40 AM