So a previous post of mine I detailed the installation and use of IIS ARR with Windows 2012 as an alternative to using Forefront TMG as your reverse proxy solution. Microsoft posted a NextHop article a few days later detailing the same information.
So if you have been using IIS ARR you most likely have found that everything was working great however you may have run into a small issue with iOS devices (see the screenshot to the right). The issue is due to how iOS does notifications and we are getting a timeout from the reverse proxy.
A little background:
In the previous mobile client for iOS and Windows Phone they leveraged the Office 365 for push notifications. In the Lync 2013 iOS mobile client they use a native iOS feature called VoIP Socket. What is happening under the hood is the Lync Client is sending a “hanging get” to the Lync Server and specifically to the UCWA application that was introduced in CU1. This hanging get last for at least 10 minutes and is refreshed so the server knows the client is still alive – essentially a presence registration is occurring in Lync. So what is happening is that the IIS timeout is causing issues with the hanging get. So if you are seeing the problem to the side, I would suggest changing your timeout from 180 or 200 seconds to 960 seconds (16 minutes). This will ensure your client doesn’t timeout on the “hanging get” that is associated with push notification.
Once I review the logs I’ll post the relevant parts of the logs showing where the timeout is happening.
Lastly, for completeness I should note that only the Windows Phone Mobile clients still use the Office 365 for push notifications. The new Android client runs in the background and does the notifications differently.
UPDATE: Here is the UCWA application creating the timeout values:
CEventChannelManager.cpp/270:Creating UCWA event channel request with Remote timeout=900, Local timeout=920