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.
21 thoughts on “Lync Mobility Media Paths”
Great post Jeff !!
nice post, valuable information
Thank you Jeff for a good a blog post with clear and good pictures
Great post Jeff !!!
Jeff, Thanks for a great post! I wish Microsoft would document this stuff. So would we just need AV edge to be accessible from the wireless or do we need webconf and access as well?
Just the external A/V FQDN. The mobile clients do not use the Access Edge service as they are not a SIP clients. The Web Conferencing service is as also not used for supported content scenarios (e.g. iPad content receive) as that is delivered through the UCWA service via the reverse proxy.
Great article, as usual. Very useful in helping to understand this quite complex scenario. Only a little notice: the sentence in the first paragraph should be corrected as follows: " the fact that *2010* mobile clients are effectively hardcoded to always connect to the external UCWA service in Lync". Am I right?
Marco, my statement is correct; it should be 2013 clients. The Lync 2010 clients do not even use the UCWA service, they are MCX clients and can use either the internal or external MCX service.
Hi Jeff. Great article. Can I ask a dumb question here ? If I have internal clients separated by a firewall so that they can't make a direct UDP connection, the media goes through the internal A/V edge interface correct ? How does media traffic leave the internal AV edge interface and go back inside the network when the firewall diagram on technet just shows having only inbound 3478 and inbound 443 ports to open ? That's the part which is a little bit confusing for me ? Don't we need to add some outbound firewall rules for media to travel to inside of network ? Thanks in advance.
For mobile clients this does not happen, but for standard clients this can (both using internal Edge interface). The way that the Edge server handles this is a bit too complex for an answer in this format, so I suggest watching this excellent TechEd session for your answer: http://channel9.msdn.com/Events/TechEd/NorthAmeri…
Hi Jeff, I have a question
We use Corporate Wi-fi network in our company and Users going away to internet over web proxy. Lync mobility users use https connection to connect this corporate network but calling is unsuccesfull because of A/V ports can’t pass over web proxy, Is there any solution for this ?
Most of hotels give internet conntection to their customers by web proxy thats why our users can’ t use their Mobile device for A/V call during at hotel or corporate network. Because A/V media ports are blocked by hotels web proxy . How can we overcome this issue? İs it posible to send all of the traffic on HTTPS port?
Thanks in advance.
Media can fall back to using 443 via TCP so even if all other ports are blocked it should still work.
Excellent article Jeff.
Hi Jeff. Great post.
I have a question about mobile clients combined with SBAs. Say that we have a central site with a standard FE server with an Edge and a couple of branch offices with SBAs due to PSTN regulations. Desktop clients will use the SBA as their primary Lync registrar and the central pool as their backup.
What happens when a mobile client belonging to a user in a branch office registers either on the internal network or Internet? What will be the signaling path? To the SBA or central pool? I suppose there are no changes in the media path, as they it has to use the same Edge server.
As mobile clients are web clients (and not SIP clients) they can only communicate directly with a Front End pool, they are not compatible with any SBS/SBA. All signaling will go to the account’s primary FE pool server.
hi Jiff, Great post.
I have a question, we worked with two or more customers that does not allow the internal wireless to go to External interface of edge only internal, although the mobility working good and after the media go to through Edge internal interface not external, is it normal behavior or there is update in Lync media paths?
Hi Jeff, Read all your articles, they are so informative
Been through a few Lync deployments for customers as well as our own internal deployment. We engaged a UCC VAR to assist us and everything works great. We use Lync 2013 FE, TMG Reverse Proxy, Lync Edge, Lync SSRS, Lync OWAS. Internally and externally we have connectivity with all devices, except:
At all of the locations, Lync Mobile App on iPhone and\or Android will not connect over corporate Wifi that has access to all the local LAN network. Lync Mobile works fine externally, all certs are correct, all DNS is correct internally and externally.
We even hairpin traffic to allow the outside interface to be accessible from the inside, and we can ping it from the internal LAN.
We are at a huge standstill with 3 separate clients. Do you have any thoughts on getting Lync Mobile 2013 to work on an internal LAN. Do you know if this is any thing with DNS via lyncdiscover or lyncdiscoverinternal?
We put on logging on each client and it looks like the first place it is going to is
Apr 8, 2015 8:54:44 AM ERROR
Connection to https://lyncext.domainname.net refused
The lyncext is part of our SSL cert for lyncext, SIP, meet, dialin, lyncdiscover, owas
externally when I browse that site, we get a
403 – Forbidden: Access is denied.
You do not have permission to view this directory or page using the credentials that you supplied.
Thanks in advance, Adam
I did a lab test and the result is a bit different from what you stated here.
The mobile client actually tries to connect to the internal interface of the edge server before trying external interface. I observed both clients (1 internal desktop client and 1 internal mobile client) established TCP connection to AV edge internal IP while the call is in on going. Your second diagram is accurate only if the mobile client cannot connect to AV edge internal.
The mobility client behavior may have changed since this older article was written; I have not gone back an tested this since the original article was posted with any of the new mobile clients.
If you have Lync 2013 client on a PC and you also have Lync in your mobile. Without setting up simultaneous ring, which would ring first fi someone tries to call you using their own Lync client?
The server will ring all signed-in clients simultaneously. All things being equal they should ring at the same time but network availability, latency, etc all play a part in this.