| Since summer 2024, Google has switched off the old push API. A new API was therefore implemented in V9.0.311, which is required for the delivery of push messages. |
If you do not receive any push notifications or no call singalization in the mobile app, the cause is often that something with the push configuration is not yet right.
Overview:
Legend for the yellow dots (see port overview documentation):
Configuration
Step 0 - DNS and proxy server and HTTP verbs (PUT, DELETE, ...)
DNS
Check whether the XPhone server can resolve all required server names in the public DNS. If, for example, the server names ‘mobile.c4b.de’, ‘api.push.apple.com’, ‘ https://fcm.googleapis.com/’ or ‘https://oauth2.googleapis.com’ cannot be resolved into IP addresses, no push messages can be delivered.
You can check this with the ‘nslookup’ command, for example. There must not be a timeout, as in this error example:
Proxy-Server
Which proxy settings apply on the XPhone server? If necessary, configure a proxy server in XPhone Administration and also activate this setting for the push service.
Conversely, it is also possible that an explicit exception has been configured for the XPhone Server so that it can bypass the proxy. In this case, it may be necessary to permanently switch off automatic proxy detection in Windows:
Special HTTP verbs (PUT, DELETE, ...)
There are reverse proxies or (web application) firewalls that do not allow all HTTP verbs. Normally GET and POST are allowed.
However, our mobile application also uses PUT and DELETE, especially for writing the DeviceToken required for push messages. If this token cannot be written to the XPhone database, no push messages are sent to the mobile device.
The mobile application may not even recognise the blocked HTTP verbs as an error. Reason: the reverse proxy or the WAF returns a ‘200 OK’ to the client.
If it is unclear whether the DeviceTokens have been stored correctly in the XPhone database, take a look at this table via the SQL Server Management Studio:
[XPDATA].[dbo].[EfUserPushNotificationDevices]
Step 1 - Installation on the IIS of the XPhone Connect server
The web application ‘IIS\Sites\Default Web Site\XPhoneConnect\PushProxy’ must be installed on the IIS of the XPhone server (even if available, not on the outsourced IIS).
In addition, the ‘PushProxy’ web application must run under the ‘XPhoneConnectPushProxy’ application pool (right mouse button → Advanced settings):
The application pool ‘XPhoneConnectPushProxy’ runs by default under the identity ‘ApplicationPoolIdentity’:
Depending on which authorisations are required for the firewall or possibly for a proxy server in the company in order to reach the services involved on the Internet, the identity of the application pool must be changed, e.g. to an authorised domain user. To do this, click on the button with the three dots (next to the red frame) and a dialogue for entering the new identity appears. As a rule, you will select a ‘User-defined account:’ and define the login information using the ‘Specify:’ button:
IMPORTANT: This account also needs write access to the directory ‘C:\Program Files\C4B\XPhone Connect Server\PushProxy’!
Background: The PushProxy must store the certificates it has obtained from ‘mobile.c4b.de’ in the file system:
Step 2 - Access of the XPhone Server service to the ‘PushProxy’ web application
This local HTTP access (port 80) should always work. By default, the XPhone Server tries to reach the PushProxy on this URL:
http://localhost/XPhoneConnect/PushProxy/
You can check the accessibility of the PushProxy service with the help of a ‘healthcheck’. To do this, enter this URL in the browser that is open on the XPhone Server computer:
http://localhost/XPhoneConnect/PushProxy/healthcheck
The result should be a white page and an HTTP response 200. If this is not the case, the following ‘ATTENTION’ notes will help.
A good starting point for the analysis are the ‘bindings’ set in the IIS for the default website:
In the example above, no restrictions are set with regard to host name or IP address for port 80. This is also the default. Depending on the settings in your system, it may not be possible to access the IIS with ‘localhost’. In such a case, please follow the ‘ATTENTION’ instructions:
ATTENTION (1): There are customers who always enforce SSL for local access to the IIS (i.e. on ‘localhost’). In this case, the XPhone server cannot reach the PushProxy on port 80. Remedy: Allow access via HTTP (port 80) for the PushProxy in IIS.
The event logs for the PushProxy module helped with the analysis (Detailed debug messages). It states that HTTP is not permitted because HTTPS is mandatory.
ATTENTION (2): Some customers set in IIS (also on the IIS running on the XPhone server) that every HTTP request is automatically redirected to HTTPS. HSTS is then activated and the ‘Redirect HTTP to HTTPS’ checkbox is ticked:
(The ‘HSTS...’ item can be found in the right-hand menu bar if the ‘Default Web Site’ is selected in the IIS).
Our push mechanism cannot cope with this without further ado. The XPhone server searches for the PushProxy on ‘http://localhost/xphoneconnect/pushproxy/’ by default. Due to the forced redirection to HTTPS, it can no longer reach it there.
To solve this, the correct URL for the PushProxy must be entered in the atlas.xml file. Add the new attribute ‘proxyBaseAddress’ to the existing <PushNotificationSettings> section and enter the correct URL for the PushProxy:
<PushNotificationSettings
proxyBaseAddress="https://servername_not_localhost/xphoneconnect/pushproxy" ... />
ATTENTION (3): In one customer case, neither the URL ‘http://localhost/...’ nor the URL ‘http://127.0.0.1/....’ were accessible on the IIS of the XPhone server. In this scenario, the XPhone server was running on an outsourced data centre. The exact causes were not investigated.
Remedy: just as in the previous ATTENTION (2), it helped to set the entry in atlas.xml (local IP address not equal to localhost and not equal to 127.0.0.1).
ATTENTION (4): In some IIS installations the feature ‘IP and domain restrictions’ is activated:
In this case, make sure that the XPhone Server service has sufficient access authorisations for the ‘PushProxy’ web application. As a rule, all local IP addresses must be authorised.
If the feature is installed but not configured, it can behave like a kind of blacklist and also block access to the localhost address.
An indication of this case is that the regular XPhone Connect administration interface cannot be accessed via localhost. Here it helps to simply uninstall the feature again.
Important: Clarify with the customer beforehand whether the feature was installed intentionally and for a specific reason and if this is the case, check the access authorisations instead.
Step 3 - Access to https://mobile.c4b.de/pushconfig
The service account of the XPhone Connect Server must be able to access the URL https://mobile.c4b.de/pushconfig. To do this, port 443 must be open in the firewall.
Calling this URL must display this login screen. This ensures accessibility. You do not have to be able to log in (the credentials are ‘secret’).
The PushProxy retrieves the access tokens for logging into the Apple / Google Push Service from there. It saves these tokens locally in the directory ‘C:\Program Files\C4B\XPhone Connect Server\PushProxy’. To do this, it needs write permissions to this directory!
The authorisations must be assigned to the technical Windows user ‘IIS APPPOOL\XPhoneConnectPushProxy’:
If these authorisations are missing, the tokens cannot be saved and as a result no push messages are sent to the Apple / Google Push Service.
Step 4 - Access of the ‘PushProxy’ web application to the push services
The firewall must be configured so that all ports of the push services from Google and Apple are accessible.
If you have a tool at hand (e.g. Postman) with which you can make HTTP POST calls, you can check the accessibility of the services as follows:
For IOS:
URL: http://localhost/XPhoneConnect/PushProxy/applepush/sendpush
Body:
{
"DeviceToken":"35bcc4a98613f55788bf7c3db77c1ec5e48eb7a66577ab2de9fd05173d1c4b6e",
"Payload":"{\"aps\":{\"alert\":\"Push-Test\", \"sound\":\"default\", \"badge\":10}, \"data\":{\"MessageType\":\"IM\"}}",
"Priority":10,
"Topic":"com.c4b.mxphoneconnect",
"PushType":1,
"Id":"2c3d2bce-fd41-42bb-a96c-8e5d0196b4b9",
"Secret":"C$B"
}
For Android:
URL: http://localhost/XPhoneConnect/PushProxy/androidpush/sendpush
Body:
{
"Secret":"C$B",
"DeviceToken":"eWtIimAzQyiicOLAXvvSaJ:APA91bH15qf9ab9NsSwSD7STfsWC3rtnLBVgsnaEiIvJDszr85ii7-flpBwy3vxBFQ7KcYPR82VgTr7IxpEsD1clJtEnMXtepS_ltbr-giOdi_plX2b0kOy9Q11mIYXokggjDn3Um4a9",
"Id":"2c3d2bce-fd41-42bb-a96c-8e5d0196b4b9",
"Priority": 10,
"Body":"Push-Test",
"Badge": 3,
"App": "XPhoneMobile",
"Payload": {"MessageType": "IM"}
}
Important: A valid DeviceToken for is obtained from the logs of the mobile client. Search there for a subscriptionId (source PushNotifications):
The token is everything inside the square brackets (without the brackets) from the screenshot above. Note: For Android, the tokens contain more characters, e.g:
eWtIimAzQyiicOLAXvvSaJ:APA91bH15qf9ab9NsSwSD7STfsWC3rtnLBVgsnaEiIvJDszr85ii7-flpBwy3vxBFQ7KcYPR82VgTr7IxpEsD1clJtEnMXtepS_ltbr-giOdi_plX2b0kOy8Q11mIYXokggjDn3Um4a9
In this way, you can send a ‘real’ push notification to your iPhone.
If successful, you will receive a ‘200 OK’ and the push message ‘Push test’ on your mobile phone:
Using CURL instead of Postman
If you don't have Postman to hand, you can also carry out the PushProxy test using the CURL tool installed by default. Depending on the smartphone operating system, use the following batch files:
Android: https://github.com/C4BCSMORG/tmp/raw/main/androidpush.bat
IOS: https://github.com/C4BCSMORG/tmp/raw/main/applepush.bat
Attention: CURL is only supplied by Microsoft from Windows Server 2019 onwards. If your server is still based on Windows Server 2016, please install CURL first.
You can find the download at: https://curl.se/windows/
Edit the batch file (right-click > Open with editor) and add the DeviceToken (see above). Here is an example:
@SET _DEVICETOKEN=35bcc3a98613f55778bf7c3db77c1ec5e48eb7a66577ab2de9fd05553d1c4b6e @SET _MESSAGE=Push-Test @ECHO PushProxy Test @ECHO ==============
[...]
Then save the file and execute it on the XPhone server. You will receive a result as follows, from which you can see the error / success messages:
Step 5 - Function test
Set up the XPhone Connect Mobile app on a smartphone (Android, iOS) and connect to an XPhone user account (‘Mobile User’).
Activate the push notifications in the mobile app (hamburger menu → Settings → Push notifications).
This mobile user must now close all running XPhone Connect desktop clients and the mobile app on the smartphone. Note: as long as a desktop client is still running, no push messages are sent!
Scenario 1: another XPhone user sends an IM message to the mobile user. The mobile user must receive a push message about this within a short time.
Scenario 2: The Mobile User sets his Office line as the active device. He is now called by another XPhone user or by an external subscriber on his office number. A short time later he should receive a push message about a missed call.
If both tests are successful, Push has been set up correctly.
Relevant URLs:
https://help.c4b.com/xphone-connect-9/doc/en/admin/config/feat/mobile.html#push-benachrichtigungen
https://help.c4b.com/xphone-connect-9/doc/en/admin/start/sys-req/infrstrctr.html#inst-mobile-push
Comments
0 comments
Article is closed for comments.