Push notifications are clickable pop-up messages that appear on your users’ browsers irrespective of the device they’re using or the browser they’re on. They serve as a quick communication channel enabling companies to convey messages, offers, or other information to their customers. Subscribers can be anywhere on the browser and still receive these messages as long as they’re online or have their browsers running on their devices.
The main purpose of the PNS service is to send push notifications to mobile devices when making calls and sending messages. These notifications wake up the application.
It is important to note that the device can be locked and the app not in the background, and push notifications should still wake up the application and serve the call.
gloCOM/Communicator mobile applications will not be shown as 'Online' within the Monitor page as they are 'Online' only when the application is opened. Once the application is closed, the Extension is no longer online, however, the functionality of making/receiving calls remains.
How do push notifications work in the backend?
Initially, after a call enters ari-dial through the asterisk Stasis function, all currently active devices for the callee extension are ringed. The application then sends a request to the local pns to send notifications to all registered devices for that extension expecting the number of devices as the response.
On startup pns, if both database connections are successfully established, will listen on the port specified in PROXY_ADDRESS for any incoming request and handle them depending on their type. The 2 main request types during run-time are:
/register: register ‘token’ to specified ‘extension’.
/push_call: send a push notification to all devices registered for the ‘to’ extension to indicate a call specified in with the ‘from’ value.
Other requests include:
/stop: Stop pns.
/confreload: Reload pns configuration.
/update: update an old token with a new one.
/delete: Delete a registered token.
In case the request is to send something to a device, e.g. push_call, an appropriate push request will be sent to the specified proxy server which will notify the specified device.
PNS service is connected with Ari-dial.
If the PNS service is not working, it will not affect any other service, just push notifications will not be sent to mobile apps.
The flow for incoming calls is always:
SIP Call → AGI → ARI Dial → PNS → PNS-PROXY → SNS → GOOGLE / APPLE SERVERS
The flow from a device is as follows:
DEVICE WAKES UP → SIP REGISTER → ARI PICKS UP NOTIFICATION → ARI DIALS NEW DEVICE
• PNS (Push Notification Service)
• PNS-PROXY (Push Notification Service Proxy on AWS)
• SNS (Simple Notification Service on AWS)
PNS Log file
/opt/pbxware/pw/var/log/pns/pns.log
The log file location is specified by the corresponding option in the log file. Information logged includes:
• Startup information
• Registration attempts.
• Number of registered tokens for an extension at the time when call push is received.
• Query execution status/errors.
• Payload delivery status.
PNS configuration file
/opt/pbxware/pw/etc/pns/pns.conf
• Push notification service is not running
If we notice that Push notifications are not running, we would check the following:
- Check the PNS process in the backend
the If you get the output as above, that would indicate that PNS service is not running and needs to be started. To start PNS you would run:
/opt/pbxware/sh/pbxware start pns
The output after starting PNS service should look like:
If you see the output as above where it shows that PNS is running, but you still get the X mark in GUI showing it is not running, you would need to manually kill the process.
On the screenshot above, we can see that PID for PNS is 26059 and 26060, so we would 'kill' those processes manually.
kill -9 26059 26060
After that, confirm that PNS is no longer running in the backend and start it with
/opt/pbxware/sh/pbxware start pns
If the service still do not show as Running in GUI, you would need to repeat the same process with the ari-dial service as PNS and ari-dial work closely for push notifications.
• Push notification not being sent to Huawei phones
One of the common problems is that push notifications are not being sent to specific devices. In this user case, push notifications are not being sent to Huawei phones. The main reason is that PBXware is using Google DNS for push notifications, and as Google does not have support for newer models of Huawei manufacturer, push notifications will not be sent.
Resolution: As this limitation affects all Google-dependent notifications and is not specific to PBXware/Communicator, there is no solution on the PBXware side.
As a workaround for Communicator/gloCOM installation, one can use the Gspace application (available in the Huawei AppGallery). Once you install Gspace, you can proceed to install any other Google applications.
However, please be aware that our push notifications rely on Google servers, so push notifications will not function on Huawei devices due to the lack of Google support and there is no available workaround for push notifications on Huawei phones.
• Blocking our push notification servers
One of the possible issues regarding the push notifications not being sent can be that certain firewall rules are blocking our push notification server.
Resolution: Please make sure that the following IP addresses are whitelisted on your firewall:
push2.eu-west1.aws.bicomsystems.com
push2.eu-west1.aws.bicomsystems.com/push
• Push notifications not being sent due to primary DNS
If a push notification is not being sent, one of the things to check would be DNS server that is set in two places in PBXware:
/etc/resolv.conf /opt/pbxware/pw/etc/resolv.conf
Usually, these files would only contain Google DNS which is 8.8.8.8 and that server would be set as primary. However, in some cases these files contain other DNS servers which can cause push notifications to fail.
Resolution: Navigate to the mentioned files and change the order of DNS servers:
• Push notification not being sent due to Transport
a If push notification is being sent from the PBXware and the Device is not receiving push notification, one of the things to check out would be Transport Protocol set on the Extension.
This issue is caused by the MTU Packet size, as default MTU size on our end is 1500. When using UDP, a packet is being sent from our end, however, UDP is not requiring the confirmation that the packet is received on the other end.
Once we switch transport to TCP, we will get the confirmation that the packet is received.
In computer networking, the maximum transmission unit (MTU) is the size of the largest protocol data unit (PDU) that can be communicated in a single network layer transaction. The MTU relates to, but is not identical to the maximum frame size that can be transported on the data link layer, e.g. Ethernet frame.
Larger MTU is associated with reduced overhead. Smaller MTU values can reduce network delay. In many cases, MTU is dependent on underlying network capabilities and must be adjusted manually or automatically so as to not exceed these capabilities. MTU parameters may appear in association with a communications interface or standard. Some systems may decide MTU at connect time.