“Call failed to establish due to a media connectivity failure when one endpoint is internal and the other is remote” – Calls from an external Lync user to an internal Lync user fail. The callee endpoint rings and the caller hears a ring-back tone, but the call is immediately dropped when the callee answers. This is the issue I was asked to troubleshoot for a client recently. In this instance the internal problem users were all located at an international branch office, whilst internal users at the main UK site remained unaffected. At the time I already had a federated contact in my contact list for the branch site, so I recreated the problem;
“Call failed due to network issues”… ah yes, something is broken.
Lync tracing already enabled on my client, I fired up the UccApilog in snooper and find the failed call. (I’ve omitted addressing and user details from all screenshots).
Selecting the ‘BYE’ message in the trace displays the information that we’re after.
The ms-client-diagnostics gives us the reason for the failure – Call failed to establish due to a media connectivity failure when one endpoint is internal and the other is remote, with the ICE warning error code listed underneath (0x2e0). This error code essentially means that the two peers were unable to communicate with one another. Immediately after the ICE warning there’s something missing though.
We have LocalSite followed by LocalMR, then we have RemoteSite which should be followed by RemoteMR… but it’s not. We’ve got an Edge routing problem, there’s no RemoteMR because it can’t be retrieved based on the RemoteSite address which in this case is 172.18.0.132. This address is on a different subnet to our main UK site, you can see where this is going…
Jump onto the Edge server and try to ping 172.18.0.132 – fail. In short the Edge server either doesn’t know how to get to the 172.18.0.0 subnet, or something is blocking it.
Route Print from a command prompt on the Edge server and I can see that there is no static route listed for the 172.18.0.0 subnet. Ah phew, it’s any easy one and I shouldn’t have to spend half a year troubleshooting firewall configuration. I add the route…
Once the route is added I can ping anything on the 172.18.0.0 subnet from the Edge. I retry the same call again, and everything works as planned – crystal clear conversation with someone on the other side of the world, and no ‘Call failed due to network issues’ error in sight. Looking at the BYE message from the successful call we can see that we’re now retrieving a RemoteMR address.
Naturally this would have all been avoided with correct Edge server configuration and testing in the first place, but if you find yourself expanding your Lync environment to remote offices residing on additional subnets, don’t forget to go back to your Edge and add static routes for them.