Huh you say..that’s what I said too.

The Problem

Audio and Video failing between federated partners. This only happens when the B-Party user was internal. I also found that when the B-Party called the A-Party the media worked.

The Monitoring server reveals as follows:-

ms-client-diagnostics: 25; reason=”A federated call failed to establish due to a media connectivity failure where both endpoints are internal” Diagnostic ID: 25 states:- “A federated call failed to connect because a media path could not be established between the two internal endpoints. This failure can be caused by network performance issues affecting the endpoints or an endpoint being unable to use the A/V Edge Server. Correlation of such failures with individual networks, endpoints or A/V Edge Server can indicate potential deployment issues.”

The Diagnostic Header 25; reason=”A federated call failed to establish due to a media connectivity failure where both endpoints are internal”; UserType=”Callee”; MediaType=”audio”; ICEWarn=”0x40003a0″; LocalSite=”192.168.99.33:20008″;LocalMR=”60.234.48.202:54594″; RemoteSite=”10.57.210.11:20003″;RemoteMR=”122.56.25.147:54376″; PortRange=”20000:20039″; LocalMRTCPPort=”55223″; RemoteMRTCPPort=”54376″; LocalLocation=”2″; RemoteLocation=”2″; FederationType=”1″; NetworkName=”ucsorted.com”; Interfaces=”0x6″; BaseInterface=”0x2″; BaseAddress=”192.168.99.33:20018; MrDnsU=”lyncedge01.ucsorted.com”; MrResU=”0″

Finding the underlying issue

The federated environment is as follows:-

Following the call setup using Snooper I can see the initial INVITE from the A-Party with 8 possible candidates.

Next we see the response from the B-Party in a 183 Session Progress message. The B-Party offers 5 possible candidates.

We should now see a message containing “a=remote-candidates” to identify the selected and tested candidate pairs.

In my trace, this is missing! Instead I find a BYE message with the following ms-client-diagnostics:-

The Diagnostic Header 25; reason=”A federated call failed to establish due to a media connectivity failure where both endpoints are internal”

I did notice the reference to LocalLocation=”2″; RemoteLocation=”2″; Having compared this to a successful federated audio call I cant say that this has any relevance since the same location ID’s were present.

Generally when the candidate negotiation fails we are facing a path issue. Be that blocked ports or routing.

I have come across this issue before see http://ucsorted.com/2014/01/12/media-connectivity-failure-when-both-endpoints-are-internal/

This time, however, the underlying cause of failed candidate negotiation was something I hadn’t encountered (yet).

My edge server was configured with external facing IP’s in the DMZ with NATted Public IP’s for each. Checking the NAT using whatsmyIP I discovered that the result was not what I expected. Cycling through all 3 IP’s on the Edge server I found that the routing was not symmetric!

Arrghh! Such a simple issue!

Asymmetric verses Symmetric simply refers to the paths that data takes on a round trip.
Symmetric routing – Send and receive traffic via the same Public IP.
Asymetric Routing will send on one IP BUT return traffic arrives from a different IP (this is no good for Audio and Video in Lync\Skype for Business)

Solution

Once the routing was corrected to symmetric the audio was successful.

This time the nominated candidate pair for Audio and video was present. Looking into the final INVITE from the Callee (B-Party) to the Caller (A-Party).

The Callee is stating that it will use candidate pair 3 to get to the Caller and that it plans to do so via the remote-candidate.

In response (OK Message), the caller states its intention to use the following candidate pair:-

Now the Caller states that it will use candidate pair 6 to get to the caller and that this will be done via its remote-candidate.

Summary

It seems to me that when the candidate negotiation fails the default assumption is that the endpoints must be internal. I can understand that reasoning since you would only expect to negotiate candidates so that you are able to traverse the Edge infrastructure.

However, it can lead you down the wrong path.

Phew!..and now that’s sorted