Direct Push is a feature that’s built into Microsoft Exchange Server 2010. Direct Push keeps a mobile phone current over a cellular network connection. It sends notification to the mobile phone when new content is ready to be synchronized to the mobile phone.
Overview of Direct Push
In order to use the Direct Push feature, the mobile phone or other mobile device must be Direct Push capable. A mobile device qualifies to have the Direct Push when:
o It has Windows Mobile 5.0 with the Messaging and Security Feature Pack (MSFP) or a later version of Windows Mobile.
o It is produced by Microsoft Exchange ActiveSync licensees and is designed specifically to be Direct Push compatible.
Direct Push is by default enabled in Exchange 2010. Mobile phones that support Direct Push issue a long-lived HTTPS request to the server running Microsoft Exchange. The Exchange server monitors activity on the user’s mailbox and sends a response to the device if there are any changes, such as new or changed e-mail messages or calendar or contact items. If changes occur within the lifespan of the HTTPS request, the Exchange server issues a response to the device that states that changes have occurred and the device should initiate synchronization with the Exchange server. The device then issues this request to the server. When synchronization is complete, a new long-lived HTTPS request is generated to start the process again. This guarantees that e-mail, calendar, contact, and task items are delivered quickly to the mobile phone, and the device is always synchronized with the Exchange server.
How does Direct Push work?
Direct Push operates in the following way:
1. A mobile phone that’s configured to synchronize with an Exchange 2010 server issues an HTTPS request to the server. This request is known as a PING. The request tells the server to notify the device if any items change in any folder that’s configured to synchronize in the next 15 minutes. Otherwise, the server should return an HTTP 200 OK message. The mobile phone then stands by. The 15-minute time span is known as a heartbeat interval.
2. If no items change in 15 minutes, the server returns a response of HTTP 200 OK. The mobile phone receives this response, resumes activity (known as waking up), and issues its request again. This restarts the process.
3. If any items change or new items are received within the 15-minute heartbeat interval, the server sends a response that informs the mobile phone that there’s a new or changed item and provides the name of the folder in which the new or changed item resides. After the mobile phone receives this response, it issues a synchronization request for the folder that has the new or changed items. When synchronization is complete, the mobile phone issues a new PING request and the whole process starts over.
Direct Push depends on network conditions that support a long-standing HTTPS request. If the carrier network for the mobile phone or the firewall doesn’t support long-standing HTTPS requests, the HTTPS request is stopped.
The following steps describe how Direct Push operates when a mobile phone’s carrier network has a time-out value of 13 minutes:
1. A mobile phone issues an HTTPS request to the server. The request tells the server to notify the device if any items change in any folder that is configured to synchronize in the next 15 minutes. Otherwise, the server should return an HTTP 200 OK message. The mobile phone then stands by.
2. If the server does not respond after 15 minutes, the mobile phone wakes up and concludes that the connection to the server was timed out by the network. The device reissues the HTTPS request, but this time it uses a heartbeat interval of 8 minutes.
3. After 8 minutes, the server sends an HTTP 200 OK message. The device then tries to gain a longer connection by issuing a new HTTPS request to the server that has a heartbeat interval of 12 minutes.
4. After 4 minutes, a new e-mail message is received and the server responds by sending an HTTPS request that tells the device to synchronize. The device synchronizes and reissues the HTTPS request that has a heartbeat of 12 minutes.
5. After 12 minutes, if there are no new or changed items, the server responds by sending an HTTP 200 OK message. The device wakes up and concludes that network conditions support a heartbeat interval of 12 minutes. The device then tries to gain a longer connection by reissuing an HTTPS request that has a heartbeat interval of 16 minutes.
6. After 16 minutes, no response is received from the server. The device wakes up and concludes that network conditions cannot support a heartbeat interval of 16 minutes. Because this failure occurred directly after the device tried to increase the heartbeat interval, it concludes that the heartbeat interval has reached its maximum limit. The device then issues an HTTPS request that has a heartbeat interval of 12 minutes because this was the last successful heartbeat interval.
The mobile phone tries to use the longest heartbeat interval the network supports. This extends battery life of the device and reduces the amount of data transferred over the network. Mobile carriers can specify a maximum, minimum, and initial heartbeat value in the registry settings for the mobile phone.