When the mobile clients were
introduced in Lync 2010, a new client architecture was also introduced.
Lync desktop clients communicate with Front End and Edge Servers using
the SIP protocol. To provide a better user experience on mobile
devices, Microsoft introduced a new communication method for mobile
devices. Lync mobile clients communicate over HTTPS to send XML
messages that are then translated into SIP messages on the server. This
allows for a lighter-weight protocol to be used on the devices, which
results in greater battery life, a seamless experience across device
platforms, and the capability to maintain connection state on mobile
devices. Additionally, a new server discovery mechanism was required
for mobile devices. Before Lync mobile, autodiscovery of Lync services
was done through DNS SRV records. However, DNS SRV records would point
directly to SIP services on Lync Servers; a new method was required to
direct mobile clients to the HTTPS web service for mobility. Figure 1 provides an overview of the architecture for Lync 2013 Mobility.
Figure 1. Lync Mobile architecture overview.
1. Understanding the LyncDiscover Service
The LyncDiscover service was introduced in
Lync Server 2010 to provide autodiscovery of Lync services to Lync
mobile clients. In Lync Server 2013, this service will also provide
autodiscovery of services to the Lync 2013 desktop and tablet clients.
The LyncDiscover service can be compared to the Exchange Server
Autodiscover Service. The simple principle is that users will connect
to a web address, authenticate, and then request the next server to
connect to for appropriate services. In Lync Server 2013, the
LyncDiscover service will provide web URLs for mobility as well as SIP
servers for clients such as Front End and Edge Servers. This enables organizations to simplify the deployment of Lync clients of all types.
The LyncDiscover service runs as a web
service on all Lync Front End and Director Servers. When mobility is
enabled in a 2010 environment, or on all 2013 environments, the
LyncDiscover IIS directory will be created. The goal of the
LyncDiscover service is to provide Lync clients with a valid home
server to register against. Requests to LyncDiscover are authenticated
before delivering service information using WebTicket authentication.
When a sign-in request is started by a client, the client will end the
requesting user’s SIP URI in the request. When the LyncDiscover
receives the HTTPS request from the client and validates the WebTicket
provided by the client, it will identify the home server of the
requesting user and then deliver critical information for client
registration to the client. This will include the following:
• Web service URL to connect to Mobility Services
• Front End Server FQDN for SIP client connectivity
• FQDN and port of the Access Edge Service associated with the Front End Server pool for remote SIP client connectivity
The LyncDiscover service operates on a static DNS entry. All clients will try to connect to LyncDiscover.<sipdomain> and LyncDiscoverinternal.<sipdomain>. For a user in the companyabc.com SIP domain, this FQDN would be LyncDiscover.companyabc.com.
Whereas the Lync 2013 desktop client will fail back to DNS SRV record
lookup for discovery, the mobile and tablet clients, including Windows
8, will only look for LyncDiscover. This service is absolutely critical
for any Lync deployments for client sign-in.
Caution
Mobile devices and desktops clients located on the internal corporate network can connect to the LyncDiscoverinternal
URL for server discovery. Because of this, it is important to identify
a certificate strategy for those clients that might not trust a private
certificate authority by default, such as smartphones.
2. Understanding the Mobility Service
To enable Lync 2010 mobile clients to
communicate with Lync servers, a new service was introduced in Lync
Server 2010. Mobile clients communicate over HTTPS with XML messages. A
service was introduced to translate traffic and allow these clients to
communicate with the Lync Server infrastructure that operates on SIP.
The MCX Service is the service responsible for translating mobile
communications into SIP communications that Lync Servers can
understand. In Lync Server 2013, a new service is introduced, the
Unified Communications Web API (UCWA); it is used to facilitate
communications from all HTTPS-based clients. This
service is open to developers, and is also responsible for providing
Lync Web App connectivity. Lync 2013 mobile clients will connect to the
UCWA service, and Lync 2010 clients will continue connecting to the MCX
service for legacy compatibility.
SIP traffic is often referred to as
chatty—chatty traffic can consume a lot of bandwidth and power. When a
mobile client is being deployed, it is critical that this client does
not decrease the increasingly precious battery life of mobile devices.
By implementing an HTTPS/XML-based client, Microsoft is able to achieve
the following:
• Standardize and simplify the clients across multiple platforms
• Decrease the frequency and size of traffic used when compared with SIP
• Decrease the battery drain of the mobile clients
• Increase session resiliency and session recovery time for mobile clients, which are often changing connection state frequently
The Lync Mobility Services act under a simple
concept: translate mobile XML messages to SIP messages that Lync
Servers can understand. This service acts much like a back-to-back user
agent (B2BUA), receiving a request from a mobile device and then
initiating another request over SIP and maintaining the state of the
two separate connections. The Mobility Services will perform
functionality such as updating presence, initiating calls, and issuing
push notification requests.
The Lync UCWA and MCX services are deployed
on all Front End Servers in the environment, and details on the actual
messages exchanged between clients and servers will be shown in the “Putting It All Together: Protocol Flow” section.
