1. Push Notifications
Apple and Windows mobile operating systems
have restrictions on which applications can run in the background of
the operating system. With this restriction in place, both Apple and
Microsoft provide a hosted service that enables developers to deliver
push notifications to devices. These notifications are used to notify
users of application activity even when the application is not open,
such as receiving an instant message (IM). The latest versions of
Microsoft and Apple mobile operating systems enable VoIP applications
to run in the background for the purpose of receiving calls. For the
Lync 2013 clients that will be delivered after the initial release of
Lync Server 2013, it is assumed that these clients will take advantage
of that functionality and the Push Notification Service will still be
used for instant messaging notifications.
In Lync Server 2010 and 2013, push
notifications are delivered to mobile devices through a federated
connection to the Microsoft Push Notification Clearing House. This
service lives in the Office 365 cloud service, and acts as an
intermediary between a Lync Server deployment and the Apple and
Microsoft Push Notification Services for mobile devices. Organizations
that want to enable push notifications will federate with the Office
365 service specifically for push notifications, and the MCX service
will deliver push notification requests to that service.
When a mobile client
registers and push notifications are enabled, the MCX service also
registers a push notification identity for that user. The state of that
user is maintained in the MCX service, and when a message is sent to
that user, the MCX service initiates a request to the unique push
notification ID, ultimately ending up at mobile endpoint as a
notification. The details of this process are outlined in the following
section.
2. Protocol Flow
Understanding how Mobility Services
function in detail will help with deploying and troubleshooting Lync
Mobile. Administrators should be familiar with the expected behavior in
common scenarios. This section covers the most common scenarios in Lync
Mobile.
3. Sign-In
The sign-in process is a very involved
process, especially with the new LyncDiscover and Mobility Services.
The following list provides each step of the LyncDiscover process. Figure 1 provides an overview of the LyncDiscover process.
Figure 1. LyncDiscover process.
1. The client first queries the DNS records for LyncDiscoverinternal and then LyncDiscover.
2. The client connects to the appropriate URL, including the SIP URI of the user as part of the URL.
3. The LyncDiscover
service responds with the full LyncDiscover service URL and web ticket
service URL for users to request server information.
4.
The LyncDiscover service requires the client to authenticate and
receive a valid web ticket. The client performs authentication with the
web ticket service before attempting to interact with the LyncDiscover
service again.
5. When the client has
a valid web ticket, it sends a full request to the LyncDiscover
service. If the message is valid, the LyncDiscover service returns
connectivity information for that client and user.
At this stage, a client will have
authenticated with the web ticket service, essentially authenticating
with Active Directory. Also, the client will have received the Mobility
Service URL and the FQDN for a Front End Server and associated Edge
Server for SIP connectivity. Next, the mobile client must register
against the Mobility Service URL. Figure 2 outlines the registration process for a Lync 2010 mobile client to the MCX service.
Figure 2. Lync 2010 Mobile Client Registration Process.
The following list outlines the Lync 2010 Mobile Client registration process:
1. The mobile client initiates a registration request to the MCX service. The MCX service requests a valid web ticket.
2. The mobile client
sends another registration request with the web ticket authentication.
At this stage a session is created on the Front End Server for this
mobile device and user. A unique ID is created to specifically identify
the endpoint.
3.
The client begins receiving in-band settings from the server. This
includes services such as the address book service, group expansion,
and policy settings that apply to the mobile endpoint.
4. The client starts
to process the contact list for that user. This includes downloading
the contact list objects, subscribing to presence, and downloading
photos. These requests are all similar to the Lync desktop client;
however, the requests are made in XML messages over HTTPS to the MCX
service.
At this stage the Lync mobile client
will act much like any other Lync client. The key difference is the
format in which messages are delivered to clients.
