Push Notifications Overview
When your cluster is enabled for Push Notifications, Cisco Unified Communications Manager and the IM and Presence Service use either the Apple, or Google cloud’s Push Notification service to send push notifications to compatible Cisco Jabber or Webex clients that run on iOS or Android devices. Push Notifications let your system communicate with the client, even after it has entered into background mode (also known as suspended mode). Without Push Notifications, the system may not be able to send calls or messages to clients that have entered into background mode.
The encrypted payload in the Push Notification includes the following PII information:
-
Display Name
-
Display Number
-
Hunt Pilot DN
Following table details the support matrix for Apple Push Notification Service (APNS) and Local Push Notification Service (LPNS).
Unified CM |
IM and Presence Service |
Cisco Expressway (is MRA is deployed) |
Cisco Jabber |
Webex App |
Mobile Operating System |
Comments |
|
---|---|---|---|---|---|---|---|
Apple—APNS Messaging |
11.5(1)SU2 |
11.5(1)SU2 |
X8.9.1 |
11.8.1 |
N/A |
12 |
Requires connectivity with Apple and Cisco cloud. |
Apple—APNS Calling |
11.5(1)SU3 |
11.5(1)SU3 |
X8.10.1 |
11.9.0 |
40.6 |
12 |
— |
Apple—APNS CallKit |
11.5(1)SU8 and 12.5(1)SU3 and 14 |
NA |
X12.6 |
12.9 |
40.6 |
13 |
— |
Apple—APNS China region |
12.5(1)SU3 and 14 |
12.5(1)SU3 |
X12.6 |
12.9 MR |
41.4 |
13 |
— |
Android— FCM |
12.5(1)SU3 and 14 |
12.5(1)SU3 |
X12.6.2 |
12.9.1 |
40.8 |
8.0 |
Requires connectivity with Google and Cisco cloud. |
Apple—LPNS |
14SU3 |
NA |
Not Supported |
14.2 |
43.6 |
16.5 |
Supported in WiFi deployment |
For Unified Communications Manager and IM and Presence Service deployments, Push Notifications are used by the following clients:
Communication Type |
Clients that Use Push Notifications |
Operating System |
Partner Cloud Service |
Local Push Connectivity |
---|---|---|---|---|
Calls |
Cisco Jabber on iPhone or iPad Cisco Webex on iPhone or iPad |
iOS |
Apple Push Notification service (in Apple cloud) |
Supported from Unified CM version 14SU3 and Webex App 43.6 or later or Cisco Jabber 14.2 or later. |
Calls |
Cisco Jabber on Android Cisco Webex on Android |
Android |
Android Push Notification service (in Google cloud) |
Not Supported |
Messages * |
Cisco Jabber on iPhone or iPad |
iOS |
Apple Push Notification service (in Apple cloud) |
Not Supported |
Messages * |
Cisco Jabber on Android |
Android |
Android Push Notification service (in Google cloud) |
Not Supported |
* For messaging, Webex App clients register to the Webex App cloud rather than the IM and Presence Service.
Note |
For minimum release information for specific Push Notifications features on both iOS and Android, see Minimum Releases and Feature Support for Push Notifications. |
How Push Notifications Work
At startup, Cisco Jabber clients that are installed on Android and iOS platform devices register to Unified Communications Manager and the IM and Presence Service while Webex App clients that run on Android or iOS register to Unified Communications Manager for calling and the Webex App cloud for messaging. In addition, the Jabber and Webex clients also register to the Google or Apple cloud, depending on which platform they are running. So long as the client remains in foreground mode, calls or messages can be sent to the client directly.
However, once the client moves to background mode (for example, this may happen to maintain battery life), the standard communication channels are unavailable, preventing direct communication with the client. Push Notifications provides an alternative channel to reach the clients through the partner clouds (Apple or Google).
Note |
Cisco Jabber and Webex App clients are considered to be running in suspended mode if any of the following conditions are true:
|
The above diagram displays what happens when Cisco Jabber for Android and iOS clients run in the background or are stopped. Because the standard channel is unavailable, the push notification is sent to the Push REST service in the Cisco cloud, which forwards the notification to the appropriate partner cloud (Apple or Google), which then forwards the push notification to the client. The client then reregisters to the on-premises deployment in order to accept the call or message.
The figure illustrates: (1) an MRA deployment where a Jabber client connects with an on-premises Unified Communications Manager and IM and Presence Service deployment through Expressway, and (2) a Cisco Jabber for Android or iOS client that connects directly to the on-premises deployment from within the enterprise network.
Note |
For Jabber users who have simultaneously logged in to Windows and iOS devices:
|
Push Notifications Behavior
The following table shows Push Notifications client behavior with on-premises deployments of Unified Communications Manager and the IM and Presence Service.
Note |
Webex App clients use the Webex App cloud for messaging rather than an on-premises IM and Presence Service. |
Note |
Webex App and Cisco Jabber on IOS will always display as a Video Call due to limitations in the Apple IOS CallKit. |
Cisco Jabber or Webex client is in... |
Running iOS12 |
Running iOS13 and above versions or Android |
||||
---|---|---|---|---|---|---|
Foreground Mode |
Voice and Video Calls Unified CM sends calls to Cisco Jabber or Webex clients directly using the SIP channel. In addition, Unified CM sends a Push Notification to clients that are in foreground mode. However, the Push Notification doesn't get used to establish the call—the standard SIP channel is used instead. Messages (Jabber only) The IM and Presence Service sends messages to Cisco Jabber directly using standard communication channels. The IM and Presence Service doesn't send Push Notifications to clients that are in foreground mode. |
Voice and Video Calls Unified CM sends calls to Cisco Jabber or Webex clients directly using the SIP channel. In addition, Unified CM sends a Push Notification to clients that are in foreground mode. However, the Push Notification doesn't get used to establish the call—the standard SIP channel is used instead. Messages (Jabber only) The IM and Presence Service sends messages to Cisco Jabber directly using the standard communication channel. The IM and Presence Service doesn't send Push Notifications to clients that are in foreground mode. |
||||
Background Mode |
Voice and Video Calls SIP channel is unavailable. Unified CM uses the Push Notifications channel. Upon receiving the push notification, the client reregisters to Unified CM and receives the SIP INVITE via the SIP channel. Messages (Jabber only) Standard channel is unavailable. The IM and Presence Service uses Push Notifications channel to send the IM notification to Jabber. When the user clicks the notification, the client moves to foreground mode, resumes the session with the IM and Presence Service, and downloads the message.
|
Voice and Video Calls SIP channel is unavailable for calls. Unified CM uses the Push Notifications ‘VoIP’ channel. Upon receiving the push notification, the client launches CallKit with Caller ID, reregisters to Unified CM, and receives the SIP INVITE via the SIP channel. The user can then answer the call. Messages (Jabber only) Standard channel is unavailable. The IM and Presence Service uses Push Notifications ‘message’ channel to send the IM notification to Jabber. When the user clicks the notification, the client moves to foreground mode, resumes the session with the IM and Presence Service, and downloads the message.
|
Apple Push Notification
Cisco Jabber and Cisco Webex clients that run on iOS (for example, Cisco Jabber on iPhone and iPad) receive Push Notifications from the Apple Push Notification service, which runs in the Apple cloud.
From Cisco Jabber 12.9 release, all new iOS applications and updates will be built using iOS 13 and above versions. Under iOS 13, Apple processes Push Notifications for suspended applications differently than it did with iOS 12:
-
Push Notifications under iOS 13 are delivered using a "VoIP" channel for calls and a separate "Message" channel for messaging. This is in contrast to iOS 12 where all Push Notifications traffic are delivered using the same channel.
-
Push Notifications is mandatory for Apple iOS clients as of August 2020.
-
The iOS client, upon receiving the notification, launches CallKit immediately to indicate an incoming call.
-
Push Notifications "VoIP" traffic includes caller identity information (Display Name, Number), which the client uses to populate the CallerID field in CallKit. If the External Presentation Name and Number is configured, Push Notification displays the customized identification Name and Number on the supported devices. If not, the original name and number of the calling party are displayed on the called party device.
-
Missed Call Notification: A second Push Notification is sent to the push-enabled device when the caller disconnects the outgoing call that is in progress. The Push Notification is also sent if the push-enabled device does not register an incoming call within 13 seconds.
-
Shared Line: When the Push Notification enabled device that has a shared line with another device receives the call, and the shared device answers the call, the Push Notification enabled device receives the second push notification stating the call has been answered from the other device.
-
Push Notifications of type "VoIP" are considered high priority and are delivered without delay.
Note |
See Minimum Releases and Feature Support for Push Notifications for detailed information as to which Push Notifications features are supported with which Unified CM release. |
The following image provides a breakdown of what happens when a VoIP Push Notification is sent under iOS13 and above versions.
Comparison of Push Notification Calling Experience for Cisco Jabber or Webex App Clients with iOS13 or Above Versions and APNS Changes
The following table describes the user experience behavior when the Client is upgraded and Server that is not upgraded or the Client is not upgraded and the Server is upgraded.
Locked Screen |
Unlocked Screen |
|
---|---|---|
Cisco Jabber 12.9 |
|
|
Cisco Jabber 12.8 and earlier |
|
|
Note |
There is no change in user experience behavior for message push notifications. |
Cloud Security for Push Notifications
Security is central to our push for Cisco Jabber and Cisco Webex architecture. All Push Notifications content is encrypted using a 256-bit Advanced Encryption Standard (AES) key that is defined by Cisco Jabber and Cisco Webex when the user signs in; the key could also be updated by the client periodically. All content sent as part of Push Notification is encrypted.
Cisco's cloud push service requires encrypted payloads and will reject anything that is not encrypted before transmission to the Apple or Google cloud. All communications with Cisco's cloud push service is secured using Transport Layer Security (TLS). This ensures that any content pushed through APNS is encrypted.
The PushRest service doesn't cache any payload that it gets from On-premise servers. The PushRest service is a proxy and passes the information to the Apple or Google cloud.
All Personal Identifying Information (PII) is encrypted. The only information outside of service details that isn't within the encrypted payload, but which is sent over a secure TLS connection is:
-
Push Target that is, the client (APNS or FCM as the case maybe)-generated token for a particular push session device, rotated occasionally or changed in subsequent sign-ins.
-
Tracking ID (client-generated ID for each messaged use in debugging if any issues occur)
iOS13 Push Notification (China Region)
Unified Communications Manager supports VoIP call Push Notifications for Cisco Jabber or Webex clients that are running on iOS13 or above version devices. In addition, the IM and Presence Service supports message Push Notifications for Cisco Jabber clients that run on iOS13 or above version devices. When we get any incoming call to a Push Notification-enabled device that is in the Mainland China region, the clients running on iOS devices cant show CallKit view due to regulatory requirements. Instead, a message notification with Caller-ID details such as name or number is displayed.
Cisco Jabber and Cisco Webex clients on iOS13 and above version in Mainland China region:
-
Can’t show CallKit view when it gets VoIP call Push Notification message.
-
The VoIP call Push Notification message causes the application to show a message toast with information about the incoming call and Caller-ID.
This allows the end-user to be assured of the caller's identity before answering the call. Tap on the message notification for the application to start and register with Unified Communications Manager. After successful registration, the Unified Communications Manager routes the incoming call to the application.
Note |
We recommend that the user quickly tap on the message notification on the Cisco Jabber and Cisco Webex client for Unified Communications Manager to route calls to the user. If the user doesn’t tap on the message notification within the set time (13 seconds), the incoming call doesn’t alert the receiver over a CallKit and a missed call message notification is sent to the user. China region Push Notification is for iOS devices only and the minimum release is 12.5(1)SU3. It’s not supported on Android devices. Cisco Jabber 12.9 MR is required. The IM and Presence Service Push Notification is not impacted by this regulation. |
Android Push Notification
As of 12.5(1)SU3, Unified Communications Manager supports VoIP Push Notifications for Cisco Jabber or Webex clients that run on Android devices. In addition, the IM and Presence Service supports messaging Push Notifications for Cisco Jabber on Android clients.
When there's an incoming call, the Unified Communications Manager Push Notification Service (CPNS) sends a push notification over the Google cloud to the Android clients that is running in suspended or background mode. After receiving the notification, the Cisco Jabber or Webex client registers back to Unified Communications Manager to receive the call.
Note |
|
Note |
As part of Cisco Jabber and Cisco Webex client user sign-in with Android push notifications service from the Google cloud, the subscriber services FCM (Firebase Cloud Messaging) and FCM: dev are supported. |
Push Notification in case of Unified Communications Manager Failover
Unified Communications Manager Group is a prioritized list of up to three redundant servers to which devices can register. Each group contains a primary node and up to two backup nodes. The order in which you list the nodes determine their priority with the first node being the primary node, the second being the backup node, and the third being the tertiary node.
In the Unified Communication Manager, device pools provide a common set of configurations for a group of devices and allow you to configure devices according to their specific location information. You can assign a device to a Cisco Unified Communications Manager Group through the Device Pool Configuration.
When Cisco Jabber or Cisco Webex clients move to the background or suspended state and the primary node on which clients are registered, goes out of network or crashes, then any calls made to the Cisco Jabber or Cisco Webex will trigger a Push Notification from the Unified CM.
Previously, Cisco Jabber or Cisco Webex tried to register to the node it had previously registered to, but the registration failed. Now, it subsequently tries to connect to the active nodes in its device pool to register back successfully. This process of discovering the current active node to which Cisco Jabber or Cisco Webex clients must register results in a loss of time.
The Unified Communications Manager Push Notification Service (CPNS) aims to avoid the loss or delay by helping Cisco Jabber or Cisco Webex register to the correct active node, whenever a Push Notification is sent. This Push Notification request contains the current active node information and enables the clients to quickly register back to the same node or to the current active node.
Note |
The active node is only included in the Push Notification from 12.5(1)SU3 release onwards. |
Proxy Support for Cloud Connection
For some deployments, you may need to use a proxy server to connect to the Cisco cloud. This is particularly true if your on-premise deployment is behind a company firewall that does not allow direct access to the cloud.
Unified Communications Manager supports the Cisco Web Security Appliance as an HTTPS proxy server. However, you can use any HTTP or HTTPS proxy server that supports one of the below call flows. Note that if you decide to use an HTTP proxy with authentication enabled, we recommend that you configure digest authentication for the proxy server for credential security.
Supported Call Flow for HTTPS Proxy
Supported Call Flow for HTTP Proxy
Capacity Requirements for Proxy Servers
Use the Proxy Server Capacity Calculator for Push Notifications to estimate capacities that your Proxy Server must be able to handle. Enter the information that applies to your deployment and the calculator outputs the number of transactions that your HTTP(S) Proxy server must be able to handle for Push Notifications deployments.
DNS Requirements for Proxy Servers
-
For the Unified Communications Manager to proxy server connection, if you use a FQDN address for the proxy server, DNS is used to connect to the proxy server. If the proxy server FQDN resolves to multiple IP addresses, Unified Communications Manager tries the first IP address and waits two seconds before moving on to the second address.
-
After sending a push notification, Unified Communications Manager waits five seconds for a confirmation before trying the second address.
-
For the proxy server to Cisco cloud connection, we recommend that you configure the proxy server with a low failover rate in order to speed up the failover process for connection failures.
-
If you are deploying the Cisco Web Security Appliance, the FQDN must map to the WSA’s virtual IP address.
Note |
The default Time To Live (TTL) for proxy IP addresses is one hour. As a result, if an IP address is changed, it may take up to one hour for that change to be available for DNS requests. |
Push Notifications High Availability for IM and Presence
Push Notifications High Availability provides failover and redundancy for Push Notifications-enabled IM and Presence sessions for Cisco Jabber Android and iOS clients. With this feature, the IM and Presence Service saves the IM session in the local in-memory database (IMDB), which gets replicated automatically to the in-memory database on the subcluster backup node. This ensures that the backup node has the session information and can take over the session without user action from the user.
IM History
When Push Notifications High Availability is configured, the Cisco Jabber user does not lose the chat history when failover occurs.
Unread Message Queue when Jabber is in Suspended Mode
For Push Notifications-enabled IM sessions, when a Cisco Jabber for Android and iOS clients moves into suspended mode, the IM and Presence Service sends Push Notifications to the clients, but stops sending unread instant messages, Presence updates, and other XMPP stanzas (for example, chat room invites). Instead, these messages are queued on the local server until the client clicks on a Push Notification, or reenters foreground mode.
There is a limitation involving the unread message queue for Push Notifications-enabled IM sessions where Cisco Jabber is in suspended mode. In some failover use cases, the unread message queue is lost. See "Redundancy and Failover Use Cases" for a description of when this occurs.
Redundancy and Failover Use Cases
The following use cases are covered by this feature:
-
Node failure (automatic failover)—If a node fails suddenly, the backup node takes over the IM session and Push Notifications continue to be sent to the Cisco Jabber user, this time from the backup node. Users can continue working without any user action or loss of IM history. However, the unread messages that were queued on the failed server while client was in suspended mode, and which had not yet been sent to the clients, are lost.
-
Node shutdown (manual failover)—If a node is shut down gracefully, the backup node takes over the IM session and Push Notifications continue to be sent, this time from the backup node. Users can continue working without any user action or loss of IM history. The unread messages that were queued on the original node, and which were waiting to be sent to the Jabber client, are lost temporarily when the backup node takes over. However, after the original node comes back up, and the user falls back to the original node, that message queue is retrieved, and is sent to the user.
-
Cisco XCP Router crash—If the Cisco XCP Router crashes suddenly, once the router comes back up, the node resumes the session and continues to send Push Notifications. The IM history is maintained, and Cisco Jabber users can continue working without any user action. However, the unread messages that were queued on the server prior to the router crash, and which had not yet been sent to the client, are lost
-
Cisco XCP Router restarts—If an administrator restarts the Cisco XCP Router, such as may happen after a configuration update, both the IM history and the unread message queue are maintained. Once the router restarts, the IM and Presence Service resumes sending Push Notifications. The unread message queue is sent once the Jabber client logs in again.
Note |
For voice and video calls, redundancy and failover is handled by Cisco Unified Communications Manager Groups. |
Supported Re-login Rate during HA Event for Push v3 Enabled Devices
This sections provides you the information about how to calculate the client relogin rate during HA event for PUSH v3 enabled devices depending on your deployment need.
This procedure assumes that you have 15,000 OVA and it is distributed in the following order:
-
2,000 users registered to the IM and Presence Publisher node are Push v3 enabled,
-
5,500 users registered to IM and Presence Publisher node directly are not Push enabled, and
-
7,500 users registered to IM and Presence Subscriber node directly and are not Push enabled.
In case of High Availability event, the supported failover rate should be 4 users/sec, or lower. You can achieve this rate using the following measurement:
If the client re-login lower limit is set to 200, then the client re-login upper limit should be set to 2075, so that the re-login rate is calculated in the following manner:
7500/(2075-200)= 4 users/sec
Note |
|