Apr 6, 2026Read time: 24 minutes

FusionPBX Push Notifications for Mobile Softphones

FusionPBX push notifications are the single most misunderstood piece of a production mobile softphone deployment. Without them, your field technician's phone sits silent while the customer call rolls to voicemail — not because anything is wrong with SIP, but because iOS killed the app thirty seconds after it went to the background. If you have ever watched a perfectly configured extension work flawlessly on a desk phone while the same credentials on a mobile softphone miss every other inbound call, push notifications are almost certainly the missing piece.

This guide is written for PBX administrators, ITSPs, and MSPs who run FusionPBX (or FreeSWITCH directly) and need mobile softphones that actually ring. You will learn:

Why SIP keep-alives fail on modern mobile operating systems
The three architectural paths to push notification delivery — and how to choose between them
FusionPBX-specific configuration pitfalls around ring groups, Fail2Ban, and SIP profiles
iOS PushKit and CallKit compliance rules that can get your softphone app rejected or silently broken
Multi-tenant considerations for ITSPs and MSPs
A complete troubleshooting reference table
A worked example configuring SessionTalk Softphone with FusionPBX

Why SIP Keep-Alives Are Not Enough on Mobile¶

Before diving into solutions, it is important to understand why the problem exists at all. SIP was designed for always-on endpoints — desk phones, softphones on desktop operating systems, and servers. Mobile operating systems have a fundamentally different relationship with background processes.

What iOS and Android Actually Do to Background Apps¶

iOS employs one of the most aggressive background app management models in the industry. When a SIP softphone moves to the background, iOS suspends it within seconds. The app cannot maintain a TCP or UDP socket. It cannot send SIP REGISTER refreshes. It cannot receive SIP INVITE messages. The app is, for all practical purposes, dead.

Starting with iOS 13, Apple mandated that VoIP apps use PushKit for incoming call notifications and CallKit for call display. Every VoIP push received via PushKit must immediately trigger a reportNewIncomingCall() to CallKit. If the app fails to do this — or does it too slowly — iOS will throttle and eventually stop delivering pushes entirely. This is not a guideline; it is enforced at the operating system level.

Android takes a slightly different approach through Doze mode. When the device is stationary with the screen off, Android defers all background network activity, pauses background services, and batches alarms. A SIP softphone maintaining a persistent connection will have its socket silently dropped during Doze. The OS-approved mechanism for waking an app is Firebase Cloud Messaging (FCM), which can deliver high-priority messages even during Doze, temporarily granting the app network access and partial wakelocks.

The bottom line: on both platforms, the operating system will kill your SIP registration. No amount of keep-alive tuning, battery optimization whitelisting, or partial wakelock tricks will produce reliable results in production.

The Role of APNS and FCM in a SIP Call Flow¶

Apple Push Notification Service (APNS) and Firebase Cloud Messaging (FCM) serve as a bridge between the SIP world and the mobile push world. The call flow works like this:

The softphone registers with the PBX and provides a device token (an APNS or FCM token that uniquely identifies the device)
When the softphone goes to the background, something must maintain awareness of the device token and the SIP registration
When an incoming call arrives, the PBX (or a proxy) must send a push notification through APNS or FCM to wake the device
The softphone wakes, re-registers with the PBX, and receives the SIP INVITE
On iOS, the app must immediately report the incoming call to CallKit so the native call screen appears

Here is the critical gap: FusionPBX and FreeSWITCH do not natively store or use device tokens. They have no built-in mechanism to send APNS or FCM push notifications. This gap is what the three architectural paths below are designed to fill.

The Three Architectural Paths: A Decision Framework¶

There is no single correct way to add push notifications to a FusionPBX deployment. The right choice depends on your operational resources, compliance requirements, multi-tenancy needs, and budget. Here is a quick decision tree:

Choose Path 1 if you want the fastest deployment with minimal server changes and can accept a per-user recurring cost.
Choose Path 2 if you need full control over push infrastructure, have on-premises data residency requirements, and have the engineering capacity to maintain a push gateway.
Choose Path 3 if you want zero server-side infrastructure changes and are comfortable selecting a softphone that handles push internally.

Path 1 — Third-Party Push Proxy (Recommended for Most Deployments)¶

A third-party push proxy sits between your FusionPBX server and the APNS/FCM services. The softphone registers with the proxy, which maintains the SIP registration on your PBX and sends push notifications when incoming calls arrive.

Ringotel with FusionPBX

Ringotel has become one of the more popular push proxy options for FusionPBX deployments. FS PBX (the enhanced FusionPBX distribution) includes native Ringotel integration under Default Settings > Mobile Apps, making setup straightforward. Ringotel supports multi-tenant FusionPBX systems out of the box with unlimited domains at no additional cost. When a device is added, updated, or deleted in FusionPBX, Ringotel is notified and updated in real time.

For standard FusionPBX installations (version 5.1+), the integration requires configuring the mobile app settings in Default Settings and linking your Ringotel account. The Ringotel app handles push notifications, and the platform provides a cloud-based provisioning system for deploying softphones at scale.

Acrobits SIPIS with FusionPBX

Acrobits Cloud Softphone and Groundwire use the SIPIS (SIP Infrastructure Service) push proxy. SIPIS maintains the SIP registration on your PBX from Acrobits' cloud servers. When a call comes in, SIPIS sends a push notification to wake the softphone.

There is a critical Fail2Ban gotcha with SIPIS: the SIPIS servers register on behalf of many users from a small set of IP addresses. To your FusionPBX server, this looks like a single IP making dozens or hundreds of REGISTER requests — exactly the pattern Fail2Ban is designed to block. You must whitelist the SIPIS IP addresses by resolving all.sipis.acrobits.cz and adding every returned IP to your FusionPBX Advanced > Access Controls and Fail2Ban ignore list. At the time of writing, this includes IPs in the 159.65.x.x, 162.243.x.x, 165.227.x.x, and 167.99.x.x ranges — verify these against current Acrobits documentation before applying, as IP assignments change as Acrobits scales its infrastructure.

Note that adding the FQDN all.sipis.acrobits.cz to Fail2Ban's ignoreip directive will not work — Fail2Ban requires explicit IP addresses. You will need to script periodic DNS resolution or manually update the list when Acrobits adds new SIPIS nodes.

Path 1 Pros:

Fastest to deploy — often under an hour
No APNS/FCM certificate management on your side
Vendor handles push infrastructure reliability

Path 1 Cons:

Per-user recurring cost
SIP traffic routes through a third party
Vendor dependency for a critical call path component
Fail2Ban whitelisting required (especially for SIPIS)

Path 2 — Self-Hosted Push Gateway (Maximum Control)¶

For organizations that need full control over their push notification infrastructure — whether for data residency, compliance, or simply to avoid vendor dependency — a self-hosted push gateway is the answer. This path requires significantly more operational investment.

Flexisip in Push Gateway Mode

Flexisip, developed by Belledonne Communications (the team behind Linphone), is the most mature self-hosted option. It can be deployed specifically in push gateway mode alongside an existing FreeSWITCH or FusionPBX installation. Flexisip implements RFC 8599 (Push Notification with the Session Initiation Protocol), which defines how SIP user agents and servers communicate push notification parameters.

In this architecture, Flexisip sits as a SIP proxy in front of your FusionPBX server. Mobile clients register through Flexisip, which stores their device tokens. When FreeSWITCH sends an INVITE for an incoming call, Flexisip recognizes that the target device requires a push notification, sends it via APNS or FCM, waits for the device to wake and re-register, then forwards the INVITE.

The administrator is responsible for managing APNS authentication keys (.p8 files) or certificates, FCM server keys, Flexisip server maintenance and monitoring, and TLS certificates for the Flexisip proxy.

One important caveat: when FreeSWITCH processes SIP REGISTER messages from clients that include push notification parameters in the Contact URI (as defined by RFC 8599), it must pass these parameters through without stripping them. Some FreeSWITCH configurations or modules may modify Contact headers in ways that break push parameter propagation. Verify that your Sofia SIP profile preserves the full Contact URI.

FreeSWITCH mod_apn / freeswitch-PushNotificator

For those who want push notification handling directly inside FreeSWITCH without an external proxy, the mod_apn module from the freeswitch-PushNotificator project (maintained by sem32 on GitHub) is an option. This module creates a push_tokens database table, stores device tokens from SIP REGISTER messages, and sends APNS push notifications when a call targets an unregistered device.

This is an advanced option. The module requires ODBC database connectivity, has limited community support, and was primarily designed for APNS (iOS). FCM (Android) support requires additional work. It is suitable for developers comfortable building and maintaining custom FreeSWITCH modules, but most production deployments will find Flexisip more maintainable.

Multi-Tenant Considerations for Path 2

Flexisip supports per-domain APNS and FCM credentials, which maps well to FusionPBX's domain-based multi-tenancy model. Each tenant domain can have its own push notification certificates, allowing ITSPs to offer white-labeled softphone apps with isolated push credentials.

Path 2 Pros:

No vendor dependency for push delivery
On-premises data residency
Full control over push payloads and timing
RFC 8599 compliance (with Flexisip)

Path 2 Cons:

Significant operational overhead
You own APNS/FCM certificate lifecycle management
Flexisip + FreeSWITCH integration can be complex (known issues with push delivery when FreeSWITCH is the backend)
Requires SIP proxy expertise

Path 3 — Native App with Built-In Push (Zero-Infrastructure Option)¶

The third path eliminates server-side push infrastructure entirely. Instead, the softphone vendor operates the push notification pipeline as part of their product. The PBX administrator's only job is to create a standard SIP extension.

SessionTalk Softphone

SessionTalk Softphone is the primary example of this architecture. SessionTalk operates its own push notification infrastructure — when the softphone goes to the background, it unregisters from the PBX and a push instance maintained by SessionTalk registers in its place. When an incoming call arrives, the PBX sends the INVITE to the push instance, which sends a push notification via APNS or FCM to wake the device. The device wakes, connects to the push instance, and the call is bridged.

This architecture is fully PushKit and CallKit compliant on iOS — incoming calls appear as native phone calls with the standard iOS call screen. On Android, FCM high-priority messages ensure delivery even during Doze mode. SessionTalk supports multiple SIP accounts per device and is available on macOS, Windows, iOS, and Android.

From the FusionPBX administrator's perspective, there is nothing special to configure. A standard SIP extension with TLS transport works. No Fail2Ban whitelisting is needed because the push instance registers from SessionTalk's infrastructure and behaves as a normal SIP endpoint.

Groundwire (Acrobits)

Groundwire uses SIPIS automatically when the app is backgrounded, which technically makes it a hybrid of Path 1 and Path 3. The user purchases Groundwire and SIPIS is included, but the administrator still needs to whitelist SIPIS IPs on their FusionPBX server. This is a key distinction from the true zero-infrastructure approach.

Path 3 Pros:

No server-side push infrastructure to manage
No APNS/FCM certificates to maintain
Fastest setup for administrators
No Fail2Ban whitelisting (for SessionTalk)

Path 3 Cons:

Tied to a specific softphone vendor
Push infrastructure reliability depends on the vendor

Decision Matrix Summary¶

Ethernet cables plugged into network switching equipment in a data centre or server room — Configuring push notifications in FusionPBX requires IT administrators to correctly set up SIP transport, firewall rules, and gateway credentials at the network level.

FusionPBX-Specific Configuration Considerations¶

Regardless of which path you choose, several FusionPBX settings directly affect push notification reliability. Getting these wrong is the difference between a deployment that works in testing and one that falls apart in production.

SIP Profile Settings That Affect Push Reliability¶

TLS Transport

Use TLS transport for mobile clients, not UDP. Mobile networks aggressively manipulate UDP traffic — carrier-grade NAT devices reassign UDP port mappings unpredictably, and some carriers block or throttle SIP traffic on standard UDP ports. TLS over TCP provides a reliable, encrypted transport that survives NAT traversal far better than UDP on cellular networks.

In your FusionPBX SIP profile (typically the external profile), ensure TLS is enabled and that your TLS certificate is valid and not expired. Mobile clients that fail TLS handshake will silently fall back to UDP on some softphones, which defeats the purpose.

NAT Handling

Push-registered clients present a unique NAT challenge. When a device wakes from a push notification, it establishes a new network connection with a potentially different public IP and port than its previous registration. Your FreeSWITCH Sofia profile should have aggressive-nat-detection enabled, and NDLB-force-rport should be set appropriately. These settings help FreeSWITCH correctly route media to the device's current network address rather than the stale address from a previous registration.

Registration Expiry

For push-enabled softphones, the registration expiry value matters differently than for always-on endpoints. A typical range of 300 to 3600 seconds works. Shorter expiry means more frequent re-registrations (which burn more battery if the softphone is handling its own keep-alives), while longer expiry means stale registrations linger if the push mechanism fails. For Path 3 softphones like SessionTalk that maintain a push instance registration, this is less critical since the push instance handles re-registration independently.

Push Wake Latency and Early Media

Push notification delivery is not instantaneous. APNS and FCM typically deliver within 1 to 3 seconds, but the device then needs to wake the app, re-register with the PBX, and signal readiness to receive the INVITE. Total wake latency of 2 to 5 seconds is normal. This has implications for early media — if your dialplan sends ringback to the caller immediately, the timing usually works fine. But if you rely on the endpoint to generate ringback, the caller may hear silence during the push wake period.

Ring Groups and Queues with Push-Registered Members¶

This is one of the most common deployment-breaking configuration mistakes, and it is entirely avoidable.

Ring Group Timeout

FusionPBX ring groups have a per-member timeout setting. The default is often 15 or 20 seconds. With push-registered mobile members, this timeout starts counting the moment FreeSWITCH sends the INVITE — but the push notification, device wake, and app re-registration all consume 2 to 5 seconds of that window. If the ring group timeout is 15 seconds, the user has only 10 to 13 seconds to notice the phone ringing and answer. Worse, if the push is slightly delayed (network congestion, FCM batching), the timeout can fire before the phone even rings.

Recommendation: Set ring group member timeout to 25 to 30 seconds minimum for any member that uses a push-registered mobile softphone.

If the ring group includes both desk phones and mobile softphones, consider using a staggered ring strategy where the desk phone rings first and the mobile softphone rings with a 3 to 5 second delay. This accounts for push wake latency without making desk phone callers wait longer.

Queue Agent Latency

For call queues with mobile softphone agents, the same push wake latency applies. Factor the additional 2 to 5 seconds into your max-wait-time and agent timeout settings. If agents are exclusively on mobile softphones, increase the agent timeout to at least 30 seconds.

Unanswered Push Behavior

When a push notification is delivered but the user does not answer, the PBX should send a CANCEL to the softphone and proceed to the next step in the failover chain — typically voicemail. Verify that your ring group or queue failover correctly handles this scenario. Some push implementations may not cleanly process a CANCEL if the device woke but the user dismissed the call notification.

Fail2Ban and Firewall Considerations¶

Fail2Ban is essential for protecting your FusionPBX server from SIP brute-force attacks, but it is the number one cause of push notification failures in production deployments.

The core problem: push proxies (SIPIS, Ringotel, Flexisip) appear to your FusionPBX server as a single IP address making many SIP REGISTER requests on behalf of multiple users. This pattern is indistinguishable from a brute-force registration attack. Without explicit whitelisting, Fail2Ban will ban the proxy IP, and every mobile user behind that proxy will lose incoming calls simultaneously.

Acrobits SIPIS Whitelisting

Resolve all.sipis.acrobits.cz and add all returned IPs to: (1) FusionPBX Advanced > Access Controls — add each IP to the appropriate access control list associated with your external SIP profile; (2) FusionPBX Event Guard — ensure SIPIS IPs are not flagged; (3) Fail2Ban jails.conf — add IPs to the ignoreip directive, separated by spaces.

SIPIS IPs change occasionally as Acrobits adds or removes nodes. Automate this with a cron job that resolves the DNS, compares against your current whitelist, and updates Fail2Ban and FusionPBX ACLs when changes are detected.

Ringotel Whitelisting

Obtain the current SIP IP ranges from Ringotel's documentation and add them to your ACLs before the first REGISTER arrives. If you enable Ringotel integration and the first registration attempt is blocked, Ringotel may retry with backoff, creating a confusing troubleshooting scenario.

Flexisip Self-Hosted Whitelisting

If you run Flexisip on a separate server, whitelist its IP in FusionPBX ACLs and Fail2Ban before enabling the push gateway. Since you control Flexisip, this is a single, stable IP to manage — one of the advantages of the self-hosted approach.

General Rule: Any time you place a SIP proxy between mobile clients and your FusionPBX server, whitelist that proxy's IP before the first registration attempt.

iOS Compliance: PushKit, CallKit, and What Happens If You Get It Wrong¶

This section is critical reading for anyone deploying SIP softphones on iOS. Apple's requirements are strict, and non-compliance results in broken incoming calls — not just App Store rejection.

The iOS 13+ Mandate Every SIP Admin Needs to Know¶

Since iOS 13, Apple has enforced the following rule: every VoIP push notification delivered via PushKit must immediately result in a CallKit reportNewIncomingCall() invocation. There are no exceptions.

This means the app must receive the push notification, immediately (within a few seconds) report an incoming call to CallKit, and CallKit then displays the native iOS incoming call screen.

The race condition here is important to understand. The push notification arrives before the SIP INVITE. The app must report the call to CallKit — including caller ID — using only the information in the push payload. If the push payload does not contain the caller ID, the user sees Unknown Caller on the native call screen. The SIP INVITE (which contains the full From header with caller ID) arrives after the push, and compliant apps update the call information when the INVITE is processed.

If a softphone app receives a PushKit VoIP notification and does not call reportNewIncomingCall(), iOS will log the violation. Accumulate enough violations and iOS stops delivering VoIP pushes to the app entirely. The user's phone goes silent with no error message, no log entry they can access, and no obvious indication of what went wrong.

Apple has continued to strengthen enforcement of PushKit/CallKit requirements across successive iOS releases and has introduced developer-facing diagnostics in recent beta cycles to help app developers identify violations before they reach production. Ensure your chosen softphone app has been actively maintained and tested against the latest iOS releases.

What Compliant Looks Like in Practice¶

Path 1 (Ringotel/SIPIS):

The push proxy is responsible for including caller ID in the push payload. The softphone app receives the push with caller information and reports the call to CallKit immediately. Verify with your vendor that their push payload includes the caller ID from the P-Asserted-Identity or From header.

Path 2 (Flexisip):

Flexisip passes caller information in the push payload. However, the softphone app must implement PushKit and CallKit correctly on the client side. If you are using Linphone with Flexisip, this is handled. If you are using a different softphone, verify its PushKit/CallKit implementation independently.

Path 3 (SessionTalk):

SessionTalk Softphone is fully PushKit and CallKit compliant. Incoming calls appear as native phone calls with the standard iOS call screen, including caller ID. The SessionTalk push infrastructure includes caller information in every push payload.

Multi-Tenant FusionPBX Deployments: ITSP and MSP Considerations¶

FusionPBX's domain-based multi-tenancy model adds complexity to push notification deployments. ITSPs and MSPs managing multiple tenant domains need to consider credential isolation, provisioning efficiency, and firewall management across tenants.

Domain Isolation and Push Credential Separation¶

FusionPBX isolates tenants by domain. Each domain has its own extensions, dial plans, and configurations. Push notification credentials should follow the same isolation model.

Path 1 (Ringotel):

Ringotel supports multi-tenant systems with unlimited domains at no additional cost. Per-organization configurations allow each tenant to have isolated mobile app settings while sharing the same FusionPBX infrastructure.

Path 2 (Flexisip):

Flexisip's per-domain APNS and FCM credential support maps directly to FusionPBX's domain model. Each tenant domain can have its own push notification certificates, which is essential if tenants use white-labeled softphone apps with their own App Store listings and unique APNS/FCM credentials.

Path 3 (SessionTalk):

Each tenant's users simply configure SessionTalk with their own extension credentials on the appropriate domain. No PBX-side push configuration changes are needed per tenant, making this the simplest multi-tenant approach.

Provisioning at Scale¶

Manually configuring SIP credentials on every user's mobile phone does not scale. All three paths support various provisioning automation methods.

QR Code Provisioning:

SessionTalk, Ringotel, and Groundwire all support QR code-based provisioning. The administrator generates a QR code containing encoded SIP credentials (extension, domain, password, transport settings), and the user scans it with the softphone app. The account auto-configures in seconds. This is the most user-friendly approach and eliminates the most common support call: I typed my password wrong.

Provisioning URL / Auto-Configuration URI:

Some softphones support a provisioning URL that the device fetches to pull its configuration. This can be integrated with FusionPBX's device provisioning system and is useful for automated deployment pipelines.

Cloud Provisioning for MSPs:

For MSPs managing 10 or more tenant domains, cloud-based provisioning platforms (offered by SessionTalk and Ringotel) provide centralized management. Administrators can deploy, configure, and manage softphone installations across macOS, Windows, iOS, and Android from a single dashboard. Changes propagate to devices automatically.

Per-Tenant Firewall and ACL Management¶

In a multi-tenant deployment, firewall and ACL management can become complex if each tenant uses a different push proxy.

Consolidated proxy: If all tenants use the same push proxy (e.g., all use Ringotel), you have a single set of IPs to whitelist.
Mixed proxies: If tenant A uses SIPIS and tenant B uses Ringotel, you need to whitelist both sets of IPs.
Self-hosted Flexisip: Running a single Flexisip instance for all tenants means only one IP to whitelist on FusionPBX — a significant operational simplification.
Path 3 (SessionTalk): No whitelist management needed, regardless of how many tenants are deployed.

Troubleshooting Reference: Common Push Notification Failures on FusionPBX¶

The following covers the most frequently encountered push notification issues on FusionPBX deployments.

Symptom: Push works initially but stops after 24–48 hours

Likely Cause: APNS token expiry or FCM token rotation not handled. Where to Look: Push gateway logs. Fix: Ensure token refresh is implemented in your gateway; restart push service if needed.

Symptom: iOS shows Unknown Caller on incoming call screen

Likely Cause: Caller ID not included in push payload. Where to Look: Push proxy configuration. Fix: Enable P-Asserted-Identity passthrough on your PBX; verify proxy includes caller info in payload.

Symptom: Calls ring desk phone but never wake mobile softphone

Likely Cause: Push proxy IP blocked by Fail2Ban. Where to Look: FusionPBX Event Guard, /var/log/fail2ban.log. Fix: Whitelist all proxy IPs in ACLs and Fail2Ban ignoreip.

Symptom: Push arrives but call drops immediately after answer

Likely Cause: NAT rebinding failure after push wake — device has new IP/port. Where to Look: FreeSWITCH Sofia logs. Fix: Enable TLS transport; verify aggressive-nat-detection is enabled in Sofia profile.

Symptom: Android push works perfectly; iOS fails entirely

Likely Cause: APNS certificate expired or wrong environment (sandbox vs. production). Where to Look: Push gateway APNS error logs. Fix: Rotate the .p8 key or certificate; verify environment matches your app build.

Symptom: Ring group sends to voicemail before user can answer on mobile

Likely Cause: Push wake latency (2–5 seconds) exceeds ring group member timeout. Where to Look: FusionPBX ring group timeout setting. Fix: Increase member timeout to 25–30 seconds.

Symptom: SIPIS registers successfully but incoming calls still go to voicemail

Likely Cause: SIPIS IP blocked by Fail2Ban after initial registration. Where to Look: Event Guard, Fail2Ban log. Fix: Whitelist all IPs returned by all.sipis.acrobits.cz; check Event Guard entries.

Symptom: Push notification delivers but app opens to an empty screen (no call)

Likely Cause: PushKit/CallKit violation — app not reporting call to CallKit. Fix: Switch to a PushKit/CallKit-compliant softphone.

Worked Example: Configuring SessionTalk Softphone with FusionPBX¶

This section walks through a complete setup of SessionTalk Softphone with FusionPBX. The goal is to demonstrate what a zero-infrastructure push notification deployment looks like in practice. For a full overview of SessionTalk's capabilities, see the SessionTalk Softphone features page at https://www.sessiontalk.co.uk/softphone.

Hand holding a smartphone displaying a control panel interface representing mobile push notification management — Once FusionPBX push notifications are correctly configured, incoming SIP calls trigger instant alerts on iOS and Android devices — even when the softphone app is in the background.

FusionPBX Extension Setup¶

No special push notification settings are required on the FusionPBX side. Create a standard SIP extension:

Navigate to Accounts > Extensions and click Add
Set the extension number and password as you normally would
Under the extension settings, configure Transport: TLS, Codecs: Opus (preferred), G.722, G.711u (in priority order), SRTP: Enabled (required when using TLS transport)
Enable Voicemail if desired — SessionTalk supports MWI (Message Waiting Indicator) notifications via push, so voicemail indicators appear on the mobile device without maintaining a persistent SIP subscription
Save the extension

That is the entire PBX-side configuration. No push proxy IPs to whitelist. No APNS certificates to upload. No Fail2Ban exceptions to add.

SessionTalk App Registration¶

On the user's iOS or Android device:

Install SessionTalk Softphone from the App Store or Google Play
Open the app and tap Add Account
Enter your Username (the extension number, e.g. 1001), Domain (your FusionPBX server's FQDN, e.g. sip.example.com), Password (the extension password), and Transport: TLS
No outbound proxy is needed — SessionTalk connects directly to the FusionPBX server for registration and manages the push pipeline independently
The account will register and show as online

Background Test: Lock the device or switch to another app. Wait 30 seconds for the softphone to move to background and the push instance to take over. Call the extension from another phone. On iOS, the native CallKit incoming call screen should appear within 2 to 3 seconds. On Android, the push notification triggers the incoming call screen with similar latency.

Multi-Tenant Provisioning via QR Code¶

For MSPs and ITSPs deploying SessionTalk across multiple tenants:

The administrator generates a provisioning QR code containing the SIP credentials and server settings
The user opens SessionTalk and scans the QR code
The account auto-configures — no manual entry of server addresses, ports, transport settings, or codecs
The provisioning QR can encode multiple accounts for users who need to register on several tenant domains simultaneously

This eliminates the most common deployment bottleneck: end-user configuration errors. A QR code scan takes under 10 seconds and produces a correctly configured account every time.

Cloud Provisioning¶

For larger deployments, SessionTalk offers cloud provisioning with centralized management across all platforms — macOS, Windows, iOS, and Android. Administrators can push configuration changes to deployed devices without requiring user interaction. This is particularly valuable for MSPs managing fleets of devices across multiple organizations, where visiting each device or walking each user through manual configuration is impractical.

Conclusion¶

FusionPBX push notifications for iOS and Android softphones come down to three architectural choices: a third-party push proxy for fast deployment, a self-hosted push gateway for maximum control, or a native app with built-in push for zero infrastructure overhead. Each path has legitimate use cases, and the decision matrix above should guide your selection based on your specific operational requirements.

Two configuration mistakes break more push notification deployments than everything else combined:

Fail2Ban blocking push proxy IPs — always whitelist before enabling any push proxy
Ring group timeouts too short for push wake latency — set mobile member timeouts to 25 to 30 seconds minimum

iOS PushKit and CallKit compliance is non-negotiable. If your chosen softphone does not properly implement PushKit and CallKit, incoming calls will silently fail on iOS with no obvious diagnostic trail. This is not a theoretical risk — it is the most common cause of it worked in testing but fails in production on iOS.

Ready to stop patching push notification workarounds? SessionTalk Softphone works with FusionPBX out of the box — no push gateway, no Fail2Ban whitelisting, no APNS certificate management. Start your free trial of SessionTalk today at https://sessiontalk.co.uk and have push notifications working on iOS and Android in under 15 minutes.