Please note that Cisco has published a document covering CUCM IM&P 11.5(SU2) and Push Notifications here.
CUCM 11.5(1)SU2 released last week, and in addition to typical bug fixes it includes a major feature that all customers who use Jabber for iOS (iPad/iPhone) are recommended to deploy before September 2017.
The quick list of new features in CUCM 11.5(1)SU2 (release notes here):
- Cisco Meeting Server 2.x support for CUCM ad-hoc, meet-me, and Conference Now conferences.
- Cisco Spark Remote Device – allow your extension to also ring out to Spark as a soft phone (requires Expressway) without requiring an extra device license (as long as Spark-RD is not their only device).
- CUCM IM&P supports Skype for Business federation.
- CUCM IM&P Roster Cleanup (CLI command to purge contacts from buddy lists for contacts who are no longer present in the system — e.g. Employee leaves the company and should be purged from everyone’s buddy lists.
- CUCM IM&P support for dual MS SQL DB for persistent chat with high availability (instead of just supporting Postgres and Oracle).
- MRA support for Shared Lines on 78xx/88xx (requires Expressway X8.9)
- TLS 1.2 support for syslog.
- CUCM IM&P Apple Push Notification Service support for IM.
I’ll focus on the last feature since it will become the most important of the bunch for anyone running Jabber on iOS.
APNs for iOS IM and Call Notification
It is recommended to upgrade to IM&P 11.5(1)SU2 this summer. IM&P 11.5(1)SU2 adds support for Apple APNs. The primary reason for this is to save battery by stopping IM and VoIP apps from continually doing a keep-alive to their service. When the app is put into the background it will be completely terminated, this requiring APNs to wake up the app to receive IM/VoIP calls. All APNs notifications are encrypted all the way to the device.
For services like Cisco Spark Messaging, since it is a cloud-based service these back-end changes will be seamless to users. For customers running WebEx Connect/Messenger instead of CUP/IM&P as the back-end for Jabber, the changes will be handled there. [Note that for customers using Jabber to Jabber VoIP calls with Connect/Messenger on the back-end will NOT want to turn on APNs today as Jabber will be terminated on background and no calls will ring through unless Jabber is in the foreground. Keeping APNs off in Jabber will preserve the current behavior.]
APNs allow CUCM IM&P to send a notification to Apple to be pushed to the iOS device running Jabber if it is in the background or not running. CUCM 11.5(1)SU2, Jabber 11.8(1) and Expressway X8.9.1 are the first versions that will support this method of notification.
This release of CUCM 11.5(1)SU2 enables IM notification via APNs. A future release of CUCM IM&P is expected to add the Call notification via APNs which is expected to be released in the Summer.
Jabber IM Notification Scenarios
APNs is not required for ALL IM notifications. It depends on Jabber’s state on the iOS device.
If Jabber is in the foreground, notifications will come directly from IM&P to Jabber as is currently done. If Jabber is connected via MRA and in the foreground, notifications are relayed through Expressway as is currently done.
If Jabber is in the background or not running, notifications will come from IM&P, be sent to the Cisco Collaboration Cloud relayed to Apple APNs and then to the iOS device.
Once Jabber has been opened and is in the foreground, notifications will come directly from IM&P to Jabber.
Jabber APNs Flow
Because CUCM IM&P needs to be able to talk to Apple to send the notifications, CUCM will need to be able to talk to the Cisco Collaboration Cloud which will relay the notification to Apple. This may be an architectural change for some customers.
Upon initial release CUCM IM&P’s connection to the Cisco Collaboration Cloud will allow for two connection methods:
- Direct outbound access (can be through NAT)
- Connect via a corporate proxy server with authentication.
Unfortunately the initial CUCM IM&P release cannot communicate through Expressway. This is expected in a subsequent release of Expressway.
In typical customer deployments CUCM IM&P is only allowed to communicate with users on an internal network, or alternately it may be allowed to communicate with Jabber clients via Expressway MRA. In both of these cases IM&P itself will likely not have NAT or firewall rules setup. If a proxy server is not available, NAT and outbound firewall rules will need to be configured.
In some customer deployments done in the past CUPS/IM&P would be allowed to federate with other XMPP systems directly. In this case, firewall rules/NAT are likely setup already and will just require some fine tuning to allow CUCM IM&P to talk out to Cisco for notification relay. Note: Expressway started supporting XMPP federation proxy a few versions ago, so some customers may be relaying through Expressway and not directly NATing.
If a corporate proxy is available then CUCM IM&P will just need connectivity to the proxy and not directly to the internet.
IM&P will know whether Jabber is in the foreground and will determine if it should send the notification directly or via APNS.
CUCM and CUCM IM&P must be at 11.5(1)SU2 or newer. Jabber must be 11.8(1) or newer. iOS can be on 10.x and use APNs right now for IM notification. VoIP call notification via APNs will be deliviered in the future.
CUCM Publisher must have DNS resolution setup and working, then APN Service Enabled under Advacnced Features > Cisco Cloud Onboarding. Make sure to select “I want Cisco to manage the Cisco Cloud Service CA Certificate required for this trust” if you don’t want ot have to deal with manually importing the CA certs for Cisco Collaboration Cloud communications.
Onboarding will create a unique oAuth token which is automatically distributed to all nodes in the cluster for communication with the Cisco Collaboration Cloud to relay to APNs.
Firewall – Outbound access using TCP 443 to fos-a.wbx2.com, push.webexconnect.com, and idbroker.webex.com
Firewall – Outbound access for iOS devices to connect to Apple. If iOS devices are allowed out to the internet in your environment then no changes should be required. If your iOS deployment restricts communication to Apple (e.g. WiFi network that iOS uses is restricted to internal network onl), then outbound ports will have to be opened so that the iOS device can connect to Apple for APNs. TCP 5223 to 188.8.131.52/8 or on WiFi will fallback to TCP 443 to 184.108.40.206/8.
What does this mean to me?
If you’re running CUCM IM&P (aka CUP/CUPS) on-perm and Jabber for iOS and want IM notifications to still appear when Jabber is not in the foreground you are highly encouraged to CUCM 11.5(1)SU2 and Jabber 11.8(1) or newer before this Fall! These changes will NOT be back-ported into previous versions of CUCM/IM&P. I would suggest doing the heavy lifting of getting to SU2 now. Go through the setup to use APNs for IM notification. Jabber on iOS 10 will then use APNs for IM notification, and keep-alive API for call notification.
If you have Jabber users connecting via Expressway MRA, you will need to upgrade Expressway to X8.9.1 or newer before Fall.
If you are using SSO today with Jabber (where you are not allowing cached credentials in Jabber) and reauth is required for every re-launch of Jabber, then do not turn on APNs today. Wait until later this summer for Jabber and CUCM releases which will have a faster logon mechanism before turning on APNs. Otherwise when your iOS device receives an APN for an incoming call or message users would have to login via SSO and would likely miss the incoming call.
Given the significant effort required to upgrade a system between major versions, I am suggesting everyone begin planning their system upgrade now to get to 11.5(1)SU2. Then make the easier hop to SUx before the Fall 2017.