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.

Category:
Lync

Join the conversation! 5 Comments

  1. 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.

  2. 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

  3. 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???

Comments are closed.