Media connectivity failure when both endpoints are internal

Published by

Paul Bloem

on

12/01/2014

An interesting issue I had recently when trying to connect an audio call to a federated partner.

IM and Presence were working but no audio or video. The attempt states connecting and then fails. A quick trip to the monitoring server, looking at the BYE for the call in questions the Diagnostic header 25 is found

Reason= “A federated call failed to establish due to media connectivity failure when both endpoints are internal” & ICEWarn=0x40003a0

Certainly a strange error since I am trying the call from the LAN at company A to a Lync user on the LAN at Company B, certainly not both internal.

Grabbing the Lync Logs from the Lync client I was keen to seen the candidate negotiation and more importantly the selected candidate pair as this would reveal the path that was selected for the audio. Perhaps that would help me understand why the error reports both users as internal

Using snooper to open the logs I start a search for a=remote-candidate (that’s the marker for the selected candidate)

The last OK message for the call in question should show the selected candidate.

Just after the a=crypto there should be an a=remote-candidate…BUT its missing!

Right, so what reasons could cause ALL the candidates to fail?

Perhaps there are ports blocked
Could be routing
Maybe a topology error

My vote goes to routing as the error states that both endpoints are intenal and that sounds like some funky routing getting the candidate logic all confused.

So, what does the Edge Server consider internal and external?

Checking the Edge server I found the following:-

Internal facing interface

IP 10.20.30.10 Subnet 255.255.255.0 Default Gateway None

External facing Interface

IP 10.20.20.10/11/12 Subnet 255.255.255.0 Default Gateway 10.20.20.1

No problems there, so checking the persistent static route I find the following:-

Notice how in this instance the Netmask defined as a Class B actually includes the Internal and External facing IP’s of the Edge Server and thus the confusion in the error messages.

Once this was corrected the traffic flow was no longer an issue