locked
Lync 2010 External Phone Calling Issue RRS feed

  • Question

  • Hello:

    We have having an issue with our Lync setup, specifically when external users are trying to make a phone call.   For example, if someone at home tries to call someone here at corporate thru Lync what is happening is:

    1) Call is placed
    2) Signal is getting to the phone and it rings
    3) Callee tries to answer the phone and the audio is never established.

    Running packet traces finds that the traffic at the point of answering is trying to go back out using the private address of the home user (ie if the users WAN address is 70.80.90.100 and their private address is 192.168.1.100) the traffic.  Obviously this doesn’t work as its not routable and there is a Deny error in the Cisco confirming this.   In the Lync Edge Server setup I see the Audio/Video Edge service external FQDN and internal FQDN say not set.  Is this related?   Ive found an article that states these need to be set to "av.yourdomainname.org" for the external and the internal should be "srv-lyncedge.yourdomainname.org".   IM, desktop sharing, etc all seem to work fine.   The article also states that this is possibly a bug and should always be set to Not Set.  I have also gone into the Topology Builder and for the A/V Edge service i am seeing:

    FQDN: av.yourdomain.org, NAT Enabled, IP 192.168.X.9, NAT-Enabled public IPv4 address 98.XXX.XXX.128 (which is outside of our assigned range, which starts at 98.xxx.xxx.129), Port 443, Protocol TCP.   

    Thanks,

    Joe


    Wednesday, April 15, 2015 2:48 PM

Answers

  • Yes, if we're talking about the edge section of the topology builder and internal-external audio between users is broken anyway, which it should be if that's incorrectly set.

    Please remember, if you see a post that helped you please click "Vote As Helpful" and if it answered your question please click "Mark As Answer". SWC Unified Communications

    This forum post is based upon my personal experience and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    • Marked as answer by Joseph Bucar Thursday, April 16, 2015 8:02 PM
    Thursday, April 16, 2015 3:16 PM

All replies

  • Where do you see external FQDN and internal FQDN saying not set? 

    If that NAT enabled IP is 98.XXX.XXX.128  and your range starts at .129, do you own the IP you're using?  Are you using a single IP for your external edge, or three public IPs?

    Can you resolve av.yourdomain.org from the outside?

    Can you resolve the lync edge pool name from the inside and does it point to the internal IP of the edge server?

    Can clients communicate with the internal edge pool name on port TCP/443 and UDP/3478 or are there any firewall restrictions?

    Can external clients communicate with 98.XXX.XXX.128 on TCP/443, UDP/3478, TCP/50000-59999 and UDP/50000-59999 per https://technet.microsoft.com/en-us/library/gg425891.aspx


    Please remember, if you see a post that helped you please click "Vote As Helpful" and if it answered your question please click "Mark As Answer". SWC Unified Communications

    This forum post is based upon my personal experience and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Wednesday, April 15, 2015 4:08 PM
  • Anthony:

    No we do not own that IP we are using.  .148 appears to be the AV External IP address and its possible the previous admin mistyped it.  We are using three public IPs. 

    >> Can you resolve av.yourdomain.org from the outside?

    Yes it pings from outside.

    >> Can you resolve the lync edge pool name from the inside and does it point to the internal IP of the edge server?

    Yes to both.

    It would probably be more helpful as well to see the firewall deny message.  Ive tried to post an image but it says until my account is verified I cant.   From the Cisco Log:

    172.xxx.xxx.103   53488    192.168.43.221 32436  Deny udp src inside: 172.xxx.xx.103/53488 dst outside:192.168.43.221/32436 by access-group "acl_in2out" 

    Where .103 is the internal Lync Server IP and the 192 address is the actual private address of the external client.

    Is some sort of NATing not happening?   

    I have also now noticed on the Lync Edge server that the Lync Server Access Edge service will not start.  Every time I try to start it I get a 

    The Lync Server Access Edge service terminated with service-specific error %%-1008124915.  Same for Web Conferencing Edge except the error number is %%-2147467259.

    Thanks,

    Joe 



    Wednesday, April 15, 2015 4:19 PM
  • So, if you're using three IPs, those three private IPs should be laid out in the topology builder with the NAT for the AV edge specified as well.

    What does AV resolve to and ping from the outside, is it the .128?

    I wouldn't worry about ACLs in general right now, none of this will work until you get your edge properly configured.

    If it's easier, post the results of ipconfig /all on your edge, and a screenshot of the edge config from your topology builder and we can take a look.


    Please remember, if you see a post that helped you please click "Vote As Helpful" and if it answered your question please click "Mark As Answer". SWC Unified Communications

    This forum post is based upon my personal experience and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Wednesday, April 15, 2015 7:03 PM
  • Anthony:

    I am waiting verfication on my account so I cant post a screen shot now.   Is there some way I can get them to you?  

    Thanks,

    Joe

    Wednesday, April 15, 2015 7:26 PM
  • Hi,

    From your description above, the external user try to connect to internal IP of the Edge Server, it can be the issue of route. Please double check the route firstly.

    Please also check the certificate of the Edge Server external interface, make sure all Edge external services’ FQDN in the public certificate SAN list.

    Best Regards,
    Eason Huang  


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

    Eason Huang
    TechNet Community Support

    Thursday, April 16, 2015 2:59 AM
  • Eason:

    The external clients are using the external address to connect.  The signaling obviously works as the phone rings the problem happens when someone answers the audio doesnt look like its routing back out the public ip, it is using the private address of the external client.  Looks to be correct to me.   The certificate is below:

    Thanks,

    Joe

    Thursday, April 16, 2015 1:52 PM
  • Anthony:

    Below are the screen shots your requested.

    Thursday, April 16, 2015 1:54 PM
  • Ok, so with those settings in place, and appropriate replication, you should now be able to start services.  You'll need to edit the public IP to match what you're NATing for the AV since you don't own .128.  The certificate looks OK, but you won't need a cert for av.xxx.org and you have lyncdiscover in there, which would go on your reverse proxy, but if you're using the same certificate for your reverse proxy you'd also need more SANS.

    Also, for each NAT, the 98.x.x.x to 192.168.50.7 for SIP, make sure it's bi-directional.  Inbound traffic to 98. should hit 50.7 and outbound traffic initiating from 50.7 should look like that unique IP.

    Run get-csmanagementstorereplicationstatus and see if replication to your Edge reports as true.

    If it doesn't show True, then we'll do it manually.  From a front end run "export-csconfiguration -filename edge.zip" and copy that file to your edge.  On your edge run "import-csconfiguration -filename edge.zip -localstore".

    Do all of your services start then?  If so, the next step is double checking all ports.


    Please remember, if you see a post that helped you please click "Vote As Helpful" and if it answered your question please click "Mark As Answer". SWC Unified Communications

    This forum post is based upon my personal experience and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Thursday, April 16, 2015 2:23 PM
  • Anthony:

    Running the get-csmanagementstorereplicationstatus command shows True.

    Ive attached my firewall rules to see you feel they look ok?

    Thanks,

    Joe

    Thursday, April 16, 2015 2:39 PM
  • That's good for the external access edge interface if you're not using XMPP.  However, if it's just the call we're concerned with, we'll want to see the rules for the internal interface to the internal networks, and also the rules for the AV Edge which should map to 148.

    Please remember, if you see a post that helped you please click "Vote As Helpful" and if it answered your question please click "Mark As Answer". SWC Unified Communications

    This forum post is based upon my personal experience and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Thursday, April 16, 2015 2:45 PM
  • Anthony:

    Can I safely change the 98.xxx.xxx.128 address to 98.xxx.xxx.148 in the setup without causing any downtime in the phone system?

    Thanks,

    Joe

    Thursday, April 16, 2015 3:11 PM
  • Yes, if we're talking about the edge section of the topology builder and internal-external audio between users is broken anyway, which it should be if that's incorrectly set.

    Please remember, if you see a post that helped you please click "Vote As Helpful" and if it answered your question please click "Mark As Answer". SWC Unified Communications

    This forum post is based upon my personal experience and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    • Marked as answer by Joseph Bucar Thursday, April 16, 2015 8:02 PM
    Thursday, April 16, 2015 3:16 PM
  • Just want to thank Anthony for all the help in getting this issue straightened out.   It turned out to be

    several different things, including:

    1) Bad address in the Topology Builder for the External AV Edge server

    2) Issue with Certificate on the Edge Server

    3) Services not starting due to the Certificate issue

    4) Bad External DNS entry which was causing the external clients to appear as internally connected clients even when they were for sure external.   Removal of the entry out of the external DNS caused the proper Internal/External server names to populate.

    Thanks,

    Joe

    Thursday, April 16, 2015 8:05 PM