Through reverse engineering here is my take on how Lync Mobility push notifications function for Apple and Windows Phone devices. This article assumes that push notifications is configured and the user is granted the policy to permit push notification (default). Push notifications is only applicable when the application is running in the background (inactive). When the Lync Mobile application is active, HTTPS communications via the Reverse Proxy is used. As you’ll see below, the reverse proxy continues to be the transport for IM conversations, and the push notification is simply the notification service for the device.
How it works
The following diagram shows how the Lync Mobile client functions with Lync Push Notifications.
1 | The device requests a push notification URI from the Push client service. |
2, 3 | The Push client service then negotiates with the Microsoft Push Notification Service (MPNS) or the Apple notification service and returns a notification URI to the Lync Mobile client application (2 and 3). |
4 | The Lync Mobile client application then sends the URI to the Lync front-end via the reverse proxy (HTTPS). |
5 | When the user then receives an instant message the internal Lync server, the Lync server knows the user is currently active for Push Notifications. The Lync server sends a SIP request via the Edge to the Microsoft Lync Push Notification Service (Push Notification Clearing House). This Lync Online clearing house forwards the request to the Microsoft Push Notification Service (MPNS) |
6 | The Microsoft Push Notification Service in turn routes the push notification to the Lync Mobile application running on a Windows Phone device (or an Apple device via the Apple notification service). |
Sending an Instant Message to a Push User
Take a scenario of a new Instant Message to a Lync Mobile user who is active for Push notifications. The Instant Message is generated from the Lync Front-end and an interception by the MCX Component initiates the SIP request to the Lync Online Clearing House (as shown in Step 5). The Lync Online clearing house receives the interpreted message using SIP and translates that to a HTTP request to the Microsoft Push Notification Service. The payload of this message includes the URI of the device (push notification URI) along with instructions for the Lync Mobile client. This includes information such as:
- The visual update to the Lync Mobile application tile (ie message count)
- A toast notification for the device with a preview of the message.
The Microsoft Push Notification Service sends a response code to the Lync Online Clearing House which converts back to SIP for a notification back to the Lync front-end via the Lync Edge. The message is delivered to the mobile device at the next possible opportunity. However, the Microsoft Push Notification Service does not provide an end-to-end confirmation that your push notification was delivered to the device. Hence the message notification back to the sender, though it is likely it was actually delivered to the device.
Attempt 1: IM Not Acknowledged Send an IM to a mobile user – Waiting for a response… |
Response not acknowledged by the mobile user |
Attempt 2: IM Acknowledged Send an IM to a mobile user – Waiting for a response… |
Response acknowledged by the mobile user (Lync client lauched/resumed) |
Looking at the SIP Stack, you see that in all cases the Lync front-end sends a simple message request to the Lync Online Clearing House. You can surmise that the message body in this request includes XML information pertaining to the new invitation, including:
- Importance
- Conference or Not
- Invitation Modality, eg Text, Call etc
- Message Body, eg “Hi Brendan”
- Timestamp
Peer: sipfed.online.lync.com:5061
Message-Type: request
Start-Line: MESSAGE sip:[email protected] SIP/2.0
From: “Brendan Carius”<sip:McxUsere70bc1dd4f9f40fead43db9502b00564brendan.carius@kloud.com.au>;epid=3470B22863;tag=b6d38c5ec0
To: <sip:[email protected]>
CSeq: 21319 MESSAGE
Call-ID: e16e70125be6482ea259f9a1e0bf06c9
Via: SIP/2.0/TLS 155.25.24.23:22360;branch=z9hG4bK3753723F.FE580C552FA25BA9;branched=FALSE;ms-internal-info=”djml34b0vzwRElFhOibGyaNltxs2YuxJMSXdKiHG2lPvxVDFj-w3gGawAA”
Max-Forwards: 68
Via: SIP/2.0/TLS 192.168.1.15:55243;branch=z9hG4bK6C6FDB33.5F9554A4FC3B7C7A;branched=FALSE;ms-received-port=55243;ms-received-cid=562400
Via: SIP/2.0/TLS 192.168.1.15:55241;branch=z9hG4bK2acd82a;ms-received-port=55241;ms-received-cid=13A0800
CONTACT: <sip: atl-edge-001.litwareinc.com;gruu;opaque=srvr:McxExternal:AbaS4im61lGvIsQfMHKgsQAA>;IsOutsideVoiceB2B;automata;actor=”attendant”;text;audio;video;image
CONTENT-LENGTH: 830
SUPPORTED: gruu-10
USER-AGENT: RTCC/4.0.0.0 McxService/4.0.0.0
CONTENT-TYPE: application/vnd.microsoft.lync.pushNotification+xml; charset=”Unicode (UTF-8)”
ms-asserted-verification-level: ms-source-verified-user=verified
Message-Body: —-****MESSAGE BODY DELETED****—-
$$end_record
And, the Response OK.
Peer: lyncse.kloud.net:55243
Message-Type: response
Start-Line: SIP/2.0 200 OK
From: “Brendan Carius”<sip:McxUsere70bc1dd4f9f40fead43db9502b00564brendan.carius@kloud.com.au>;tag=b6d38c5ec0;epid=3470B22863
To: “Push Notification Clearing House”<sip:[email protected]>;tag=f1cbe21fcc
CSeq: 21319 MESSAGE
Call-ID: e16e70125be6482ea259f9a1e0bf06c9
Via: SIP/2.0/TLS 192.168.1.15:55243;branch=z9hG4bK6C6FDB33.5F9554A4FC3B7C7A;branched=FALSE;ms-received-port=55243;ms-received-cid=562400,SIP/2.0/TLS 192.168.1.15:55241;branch=z9hG4bK2acd82a;ms-received-port=55241;ms-received-cid=13A0800
CONTENT-LENGTH: 0
CONTENT-TYPE: application/vnd.microsoft.lync.pushNotification+xml; charset=”Unicode (UTF-8)”
SERVER: RTCC/4.0.0.0 PnchApplication
ms-diagnostics-public: 30000;Reason=”Success”
ms-edge-proxy-message-trust: ms-source-type=DirectPartner;ms-ep-fqdn=atl-edge-001.litwareinc.com;ms-source-verified-user=verified;ms-source-network=federation
Message-Body: –
$$end_record
So as per above, the notification service simply sends a response to Lync to notify that the MS Push Notification Service successfully received the message. This does not indicate whether the device actually received the invitation.
This was an out of band message generated by the MCX application on the Lync Front-end based on a new instant message conversation being generated for the Lync Mobile user. Therefore we have the original SIP dialog between Alice and Bob still occurring. As per any SIP dialog, the initial INVITE responses are TRYING (100) then RINGING (180), assuming all is good.
In ATTEMPT 1, the Lync Mobile user does not acknowledge the new invitation. That is, the person misses the notification and does not launch the Lync Mobile client on the device. This results in a REQUEST TIMEOUT (408) response to the original SIP INVITE. The sender receives the warning of “This message may not have been delivered to….”.
However, in ATTEMPT 2 above, the Lync Mobile user does acknowledge the invitation and does launch the Lync Mobile client when they receive the Push Notification. In this case the response is a 200 OK rather than the timeout. Therefore the “waiting for response…” text is removed from the Instant Message conversation window and the Instant Message conversation is conducted.
The Push Notification service simply operates as a means of notifying the Lync Mobile client of a new invitation (instant message). The Notification Service provides the 1st line of the IM conversation and updates the Lync Mobile tile with a missed conversation / call count. The instant message conversation between to a Lync Mobile client user is always performed over HTTPS through the Reverse Proxy to the MCX Service on the Lync Front-ends.
Push Notification Synthetic Transactions
An initial test of the push notification service is to run a Test-csMcxPushNotification. To the cmdlet, simply pass the Lync Edge internal FQDN.
Test-CsMcxPushNotification -AccessEdgeFqdn “atl-edge-001.litwareinc.com”
If configured correctly, the result will return:
PS C:\> Test-CsMcxPushNotification -AccessEdgeFqdn “atl-edge-001.litwareinc.com”
TargetFqdn :
Result : Success
Latency : 00:00:00
Error :
Diagnosis :
Looking at the SIPStack on the Edge you will see an outbound request to the Push Notification clearing house (push.lync.com):
Trace-Correlation-Id: 999570620
Instance-Id: 000E445E
Direction: outgoing;source=”internal edge”;destination=”external edge”
Peer: sipfed.online.lync.com:5061
Message-Type: request
Start-Line: MESSAGE sip:[email protected] SIP/2.0
From: <sip:[email protected]>;epid=40CA3D275B;tag=00c7e644
To: <sip:[email protected]>
CSeq: 1 MESSAGE
Call-ID: 473648cd73334c94a11b8140d3bfaabd
Via: SIP/2.0/TLS 155.25.24.23:22321;branch=z9hG4bK9C46E3C8.30D9E486908D36CB;branched=FALSE;ms-internal-info=”bjLizr_XsA-roWQDzGqWJn-x8229wLtllPfCz1SYhZ2lCG5Nkww3gGawAA”
Max-Forwards: 69
Via: SIP/2.0/TLS 192.168.1.15:54018;branch=z9hG4bKbec5f4fe;ms-received-port=54018;ms-received-cid=55E500
CONTACT: <sip:atl-edge-001.litwareinc.com;transport=Tls>
CONTENT-LENGTH: 434
USER-AGENT: RTCC/4.0.0.0
CONTENT-TYPE: application/vnd.microsoft.lync.pushNotification+xml; charset=”Unicode (UTF-8)”
ms-asserted-verification-level: ms-source-verified-user=verified
Message-Body: —-****MESSAGE BODY DELETED****—-
$$end_record
In response, the Push Notification clearing house should respond with a successful processing of the synthetic transaction:
Trace-Correlation-Id: 999570620
Instance-Id: 000E445F
Direction: incoming;source=”external edge”;destination=”internal edge”
Peer: sipfed.online.lync.com:5061
Message-Type: response
Start-Line: SIP/2.0 200 OK
From: <sip:[email protected]>;tag=00c7e644;epid=40CA3D275B
To: “Push Notification Clearing House”<sip:[email protected]>;tag=8edaf7323d
CSeq: 1 MESSAGE
Call-ID: 473648cd73334c94a11b8140d3bfaabd
Via: SIP/2.0/TLS 155.25.24.23:22321;received=111.221.22.73;branch=z9hG4bK9C46E3C8.30D9E486908D36CB;branched=FALSE;ms-internal-info=”bjLizr_XsA-roWQDzGqWJn-x8229wLtllPfCz1SYhZ2lCG5Nkww3gGawAA”;ms-received-port=22321;ms-received-cid=15225400,SIP/2.0/TLS 192.168.1.15:54018;branch=z9hG4bKbec5f4fe;ms-received-port=54018;ms-received-cid=55E500
CONTENT-LENGTH: 0
CONTENT-TYPE: application/vnd.microsoft.lync.pushNotification+xml; charset=”Unicode (UTF-8)”
SERVER: RTCC/4.0.0.0 PnchApplication
ms-diagnostics-public: 30007;Reason=”Push Notification synthetic transaction succeeded“
ms-asserted-verification-level: ms-source-verified-user=verified
Message-Body: –
$$end_record
I hope that helps in understanding the function of the Push Notification service for the Lync Mobile client and assists you in troubleshooting any issues with the notification service.
I have installed the CU4 bits but haven’t configured Lync Mobile yet, however I do get the “waiting for a response” message between two users on the LAN now! Any idea why that happens?
Waiting for a response is standard behaviour. This will appear until the recipient acknowledges the IM or the dialog times out.
Hi !
Thanks for the great article ! very useful !
Encountered the following problem, and if possible please help.
Lync Mobility set, everything works fine, the Test-CsMcxPushNotification test are successful. But no the notifications on the phones :(. It seems that when a client Lync not assigned an notification URI.
In which the log components, and what better to look for ?
What could be useful in finding problems in this regard.
Thank you !
Konstantin
first check the sipstack trace to see if you see the push notification leaving your lync environment to ms.
Thank you for this, very informative and detailed expanation!!
I thought it was a problem with our configuration until I read this posting. Any word if Microsoft changed the content of this message back to the computer client in Lync 2013? Hopefully something that makes more sense and does not sound like the message was never received by the mobile user???