In a previous article discussing Lync Mobility an important behavior of the 2013 mobile clients was pointed out which was the fact that 2013 mobile clients are effectively hardcoded to always connect to the external UCWA service in Lync.  Since this means internally connected mobile clients will hairpin all signaling traffic through a reverse proxy service, it also means that the same hairpining effect is observed in TURN media relays sessions proxied by the Edge Server.

When dealing with internally connected desktop Lync clients and devices these will always open connections directly to the internal Edge interface in order to utilize the ICE/STUN/TURN capabilities of the Edge Server.  So in the event that the Edge server must relay media for an internal to external call scenario then the typical media path is from the internal client to the internal Edge interface, through the Edge Server and out its external interface, and finally on to the external client.  Or when two internal clients which are separated by a firewall attempt to establish peer to peer media each of these internal clients will connect to the internal Edge Server interface for relay assistance.

But with Lync 2013 mobile clients this story is different.

First, a recap of what the previous article explained.  Any internally connected 2013 mobile clients will leverage the external UCWA URL which in a properly configured environment should cause the client to resolve and connect to a reverse proxy service.  The actual data path can vary here depending on the network configuration.  The connection could be directed out a corporate firewall to the Internet and back in through a different firewall to the reverse proxy server connecting back into the external web service on the Lync Front End server. Or this traffic could be purposely directed to the internal interface of a reverse proxy server listening for the same traffic as on the external interface, which would shorten the trip distance but still be routed to the external web services.  Either way the registration traffic and all connectivity between the 2013 mobile client and the Lync Front End server is hairpinned in some fashion.

How does this behavior impact media traffic then?  Simply that all connectivity between internal mobile clients and the Edge server will follow the same logic, meaning that these clients will connect to the external interface of the Edge Server just as if they were external clients.  It does not mean that all media is hairpinned though.  All Lync clients will still attempt direct connections so in the event of internal peer calls or when joining conference calls on the Lync AVMCU media will still be able to be routed directly as long as that traffic path is not filtered in a way to prevent this from happening.  In cases where the Edge Server must step-in to assist in relaying the media then the internal mobile clients will be taking the long way around to the external Edge interface.

Internal Peer Call Scenarios

As depicted in the following diagram an internally connected mobile client will perform Autodiscover locally (1) and then use the supplied external UCWA FDQN to locate the published external web services (2).  When attempting to establish media between the internal mobile client and another internal Lync client the media will still flow directly between them (3) if allowed by the network.

In the event that the internal Lync clients are unable to negotiate media directly (1), as happens when an internal firewall is filtering the majority of high ports, then the clients will rely on the Edge Server to tunnel the media for them.  The mobile client will connect to and send its media session to the external Edge interface (2) while the standard desktop Lync client will simply connect directly to the internal Edge interface (3).

By comparison if the scenario above was between two desktop Lync clients then the media would be flowing entirely through the internal Edge Server interface and nothing would be hairpinned.

Internal to External Peer Call Scenario

When looking at calls between internal mobile clients and actual external or federated clients the mobile client acts no differently.  Clearly directly establishing a media session in these scenarios is not possible so the Edge Server must be utilized in some fashion.  If TURN is required for media establishment then the mobile client sends its media to the external Edge interface just as in the previous media relay scenario.

This behavior follows the easy to remember theme that Lync 2013 mobile clients are always treated as external clients regardless of the actual network location they connect from.  Internally connected mobile clients will never attempt to connect directly to the internal Edge interface because they are acting as external clients and will use the external Edge FQDN just as an actual external client would.