I have a customer with following solution:

1 Lync Front-End
1 Lync Edge
1 TMG Reverse proxy
3 external IP (sip, webconf, av)

Edge server are placed in a DMZ sone, with 3 network ip in DMZ and 1 in local network. I have used Joakim Silverdrake blog post for Lync and TMG.Joakim Silverdrake Blog

Customer has same internal and external domain name.

Problem:

Federated users cannot make AV calls to my customer Lync users, but can see precense and make IM conversation. Whiteboard also works.

AV conference with 3 users from my customer Lync SIP domain works as normal. (with external and local users)

OCSTestconnectivity with AV = OK

Logging:

I have tried to log the problem with Lync Logging Tool and Snooper on Lync Clients. Also Logging Tool on SIPStack on Edge server.

On Lync Clients i get the following message:
After ACK message, i get an BYE sip:user@federateddomain.com and connection is broken. And only error message i receive is "A federated call failed to establish due to a media connectivity failure where both endpoints are remote"

SIPStack on Edge server is blank in Snooper.

Hope anyone can guide me to a solution for this problem.

• Edited by Holtiz Wednesday, September 19, 2012 8:08 AM

Usually this means connectivity problem.  Check if you have TCP 50,000-59,999 ports opened.

Thank you.

You have also to check the NAT has configured correctly.

Make sure UDP 3478 is bidirectional and also Firewall is forwarding source IP to Edge AV. If you look at the BYE message, it will provide an ICEWarn code, you can look this up in the Chapter 9 - External User Resource Kit chapter to determine the error.

http://www.microsoft.com/en-us/download/details.aspx?id=22644

Cheers,

Jeff C

0x4000000

TCP-TCP connectivity checks failed over the TURN Server. <o:p> </o:p>

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 isnt expected and may result in an ICE protocol failure.

My error message is:

CSeq: 3 BYE
User-Agent: UCCAPI/4.0.7577.4103 OC/4.0.7577.4103 (Microsoft Lync 2010)
 ms-client-diagnostics: 27; reason="A federated call failed to establish due to a media connectivity failure where both endpoints are remote";CallerMediaDebug="audio:ICEWarn=0x4000322,LocalSite=x.x.x.x:56352,LocalMR=10.160.50.13:56423,RemoteSite=x.x.x.x:64199,RemoteMR=x.x.x.x:56919,PortRange=1025:65000,LocalMRTCPPort=56423,RemoteMRTCPPort=56919,LocalLocation=1,RemoteLocation=1,FederationType=1"
Content-Length: 0

I have noticed that LocalMR is mye AV Edge server DMZ IP. Can this be the problem?

I have tried to make an AV conference to another federated partner, and he could hear me, and i could see him. I have checked every rules in TMG, and everything looks correct.

I have also testet with internal Lync users from external computer that i not member of the local domain. It works with 3users. That i find very strange!

Error message is from Office365 account to on-premise edge server.

I have a rule that opens for OCS 2007 users on port 50000-59999 inbound.

• Edited by Holtiz Thursday, September 27, 2012 6:34 AM

When you say LocalMR is DMZ IP, this is the internal Private IP or the Public IP?

Make sure you have defined the AV Public IP in topology for NAT-Enabled Public IP if you are truly NAT'ing the Edge role.

Everything is pointing to TURN failure, so it is the external IP or firewall or you have firewall issues internally to TCP 443 and UDP 3478.

Thanks,

Jeff C

LocalMR is my AV Edge IP in my DMZ zone. (It is NAT from public AV edge IP to AV edge DMZ)
Three external IP are natted to DMZ zone, with following IP.

SIP.domain.com -  NAT to 10.160.50.11
WEBCONF.domain.com - NAT to 10.160.50.12
AV.domain.com - NAT to 10.160.50.13

Anyone got an idea why it works perfectly with domain.com users from remote location? And when it works that way, shouldn't they use the same ports and edge server as an federated partner? 

When you have 2 organizations federated, the firewall will generally block the client from connecting to the remote UDP ports, so the negotiation is Edge to Edge using relay. UDP 3478 bidirectional and TCP 443. If you run wireshark on both edge servers, you should see connection attempts from UDP 3478. Also verify you see the public IP as the source on incoming STUN, TURN, Media packets not a NAT'ed IP from the firewall. With an external client, the NAT can generally be detected by STUN and all ports are not blocked as in a company environment.

From the error provided previously it looks like a port 443 issue, but that would point to a desktop sharing session not audio. You mention TMG. TMG is not your firewall for the Edge, is it? Do you have a firewall or filtering application such as RiverBed or websense which may be filtering TCP 443 traffic? A local A/V or internet security application on the client? If so, can you bypass and disable, then try?  

Cheers,

Jeff C

• Marked as answer by Lisa.zhengMicrosoft contingent staff, Moderator Monday, October 08, 2012 2:21 AM

Hello I had the same issue. I found the reason, it's on the TMG. Check the rule responsible for port 443 and 3478 from external to the external leg of the TMG and check that "Requests appear to come from the Forefront TMG computer" is checked.

Please let me know if it helps you.

I have tried to do what you said Aahreno, but same problem persist. Nothing changed.

AV from Office 365 to customer (remote) user, and it works great. (PC to PC)
If I invite another user to a conference, the federated user gets disconneted exactly when the other user connects. If i try this with three customer (remote) users, it works fine.

TMG is used as a firewall and reverse proxy. WAN, DMZ, LAN. Edge server has one NIC in DMZ and one NIC in LAN.

So troubleshooting edge to edge connectivity, maybe look for:

1. On your edge server, run netmon and see if the source IP and PORT are not being changed. From what I understand if you source IP and the source port are changed it will break FTURN (Federated Turn). Send a UDP packet from an internet IP:3478 to EDGE:3478  while running netmon. See if the IP and the PORT are changed.

2. Even though A/V can flow over TCP if UDP does not work, you can't rule out that there could be an issue with using TCP. So potentially two issues.

Problem was solved after removing Microsoft TMG as firewall, and only use it for reverse proxy.
Cisco ASA solved the problem.

• Marked as answer by Holtiz 16 hours 18 minutes ago