Why Asterisk and FreeSWITCH Can't Deliver Calls to Sleeping Phones — And the Three Ways to Fix It

“Users keep missing calls the moment they lock their phones.” If you run an Asterisk or FreeSWITCH deployment and you have heard this complaint more than once, you are not alone. The root problem is that neither Asterisk nor FreeSWITCH supports SIP push notifications natively, and modern mobile operating systems aggressively kill idle network connections to save battery. Without SIP push notifications on Asterisk and FreeSWITCH, your PBX sends an INVITE to a registration that expired minutes ago, the call fails silently, and the user never knows someone tried to reach them. This article explains exactly why that happens, walks through the RFC 8599 standard that was designed to solve it, and lays out three actionable paths so ITSPs, MSPs, and PBX administrators can fix the problem for good.

Why Mobile OSes Are the Adversary, Not Your PBX¶

Before blaming your PBX software, it helps to understand the real culprit. Both Apple and Google have spent years tightening background execution limits to extend battery life and protect user privacy. The result is an environment that is fundamentally hostile to long-lived SIP registrations.

iOS: The PushKit Mandate That Changed Everything¶

Prior to iOS 13 (released September 2019), VoIP apps on iPhone had a privileged status. They could maintain persistent background TCP connections, send SIP keep-alives, and wake themselves when an INVITE arrived. Apple tolerated this because VoIP apps declared a special background mode.

iOS 13 changed the rules entirely. Apple mandated that any app receiving a PushKit VoIP notification must immediately report the call to CallKit and display the native incoming-call screen. If the app fails to do so within a short window, iOS terminates it. Repeat offenders get their PushKit entitlement revoked entirely, meaning the app can no longer receive VoIP pushes until the user reinstalls it.

Starting in April 2020, Apple required all App Store submissions to be compiled against the iOS 13 SDK, making this mandate universal. The practical consequence for SIP is stark: a traditional SIP INVITE that arrives over a background TCP socket will never surface to a backgrounded iOS app. The only reliable path to the user is through Apple Push Notification service (APNs) via PushKit, followed by a CallKit presentation. If your PBX cannot trigger that APNs push, the call is lost.

Android: Doze Mode and the Disappearing Registration¶

Android's battery management story is less of a single mandate and more of a slow tightening across releases. Android 6.0 (Marshmallow) introduced Doze mode, which defers background CPU and network activity when the device is stationary with the screen off. Android 8.0 (Oreo) added background execution limits. Android 12 tightened restrictions on foreground services. Each subsequent Android release has tightened these restrictions further, meaning SIP registrations expire even sooner on newer devices.

During Doze sleep, apps lose network access entirely except during brief, infrequent maintenance windows. SIP keep-alives cannot leave the device, and the registration on your PBX expires. When a call comes in, the PBX has no valid contact for the user.

To make matters worse, OEM battery management layers from Huawei (EMUI), Xiaomi (MIUI/HyperOS), and Samsung (One UI) impose their own restrictions on top of stock Android. These layers can kill apps aggressively regardless of user-configured battery optimization exceptions. Asking every end user to navigate three layers of OEM battery settings is not an enterprise-scalable strategy.

The solution on Android is Firebase Cloud Messaging (FCM). FCM high-priority messages bypass Doze restrictions and wake the app reliably. But your PBX has to be able to send that FCM message in the first place, and that is where the gap lies.

RFC 8599: How Push Notifications Are Supposed to Work in SIP¶

RFC 8599, published in May 2019 by the IETF, defines a standardized mechanism for integrating push notifications with the Session Initiation Protocol (SIP). The idea is elegant: the SIP User Agent (UA) tells the registrar which push notification service to use, and the registrar fires a push before forwarding the INVITE.

Here is how it works at a high level:

1. Registration with push parameters. The SIP UA includes new URI parameters in the Contact header of its REGISTER request: pn-provider (which push service, e.g., apns or fcm), pn-param (app-specific parameters like the APNs topic), and pn-prid (the Push Resource ID, which is the device token).
2. Registrar stores push data. The SIP registrar parses and persists these parameters alongside the normal binding.
3. Push-then-INVITE on inbound call. When an INVITE arrives for a UA whose registration has expired or that is marked as sleeping, the registrar dispatches a push notification via APNs or FCM, places the INVITE in a holding bucket, and starts a timer. The push wakes the app, which sends a fresh REGISTER. The registrar detects the new binding and forwards the INVITE.

An example Contact header with RFC 8599 parameters looks like this:

Contact: <sip:user@192.168.1.100:5060;transport=tls;
pn-provider=apns;
pn-param=com.example.voip;
pn-prid=ae32f0a1b...devicetoken...c9e2>

What RFC 8599 requires from your PBX is not trivial. The registrar must parse and persist the pn-* URI parameters, hold valid APNs and FCM credentials, orchestrate the push dispatch, wait for the re-registration, and then route the INVITE. Neither Asterisk nor FreeSWITCH does any of this out of the box.

Asterisk and SIP Push Notifications: The Honest Status Report¶

What Asterisk Does Not Do Natively¶

As of Asterisk 22 (the current Long Term Support release) and Asterisk 21 (now in security-fix-only mode through October 2026), there is no native RFC 8599 implementation. The PJSIP-based registrar (res_pjsip_registrar) does not parse, store, or act on pn-provider, pn-param, or pn-prid URI parameters in the Contact header. When a mobile user's registration expires because iOS or Android suspended the app, and an inbound call arrives, Asterisk sends the INVITE to the last known contact. It fails. The caller hears silence or a generic error. The mobile user sees nothing.

There has been community interest in adding push notification support to Asterisk. Threads on the Asterisk Community forums have discussed it for years. But as of April 2026, no official module or patch has been merged into the Asterisk codebase.

Community workarounds do exist. The most common approach involves writing an ARI (Asterisk REST Interface) or AGI (Asterisk Gateway Interface) script that intercepts failed call attempts, calls out to a separate push notification service, waits for re-registration, and then retries the call. While this can work for a handful of users, it is fragile, difficult to maintain, and does not scale to hundreds or thousands of endpoints. Error handling is manual, timing is tricky (send the INVITE too early and the registration has not landed yet; send it too late and the caller has hung up), and every Asterisk upgrade risks breaking the custom integration.

What Asterisk Can Do With Help¶

The proven architecture for adding push to an Asterisk deployment is to place a SIP proxy in front of Asterisk that handles RFC 8599 at the edge. Kamailio and OpenSIPS are the two most common choices. The proxy intercepts REGISTER requests, extracts and stores push parameters, and when an inbound call arrives for a sleeping device, fires the push and holds the INVITE until re-registration completes. Only then does it forward the INVITE to Asterisk, which sees a perfectly normal SIP transaction.

The other option is a commercial push gateway that sits between Asterisk and the push infrastructure, abstracting away APNs and FCM credential management. We will explore both options in detail in the Three Paths section below.

FreeSWITCH and Push Notifications: Closer, But Still Not There Without Work¶

FreeSWITCH Native State¶

FreeSWITCH's mod_sofia module is highly extensible via the Event Socket Layer (ESL), which means you can subscribe to registration events, intercept call routing, and inject custom logic. However, extensibility is not the same as built-in support. FreeSWITCH has no native RFC 8599 registrar. Out of the box, it behaves exactly like Asterisk when a mobile registration expires: the call fails.

mod_apn: The Community Module¶

The most well-known community effort is the freeswitch-PushNotificator project (commonly referred to as mod_apn). This module listens to sofia::register events, parses the Contact header to extract push tokens, and stores them in a database. When FreeSWITCH generates a call to a target that has stored tokens, mod_apn dispatches a push notification, waits for the device to re-register, and then passes the call through.

On paper, this sounds like exactly what you need. In practice, there are significant limitations:

• APNs API concerns. The module was originally built against Apple's legacy binary APNs protocol. Apple has deprecated this in favor of the HTTP/2-based APNs provider API. While there have been community updates, maintenance is inconsistent, and ensuring compatibility with the latest iOS versions requires manual verification of the certificate chain and HTTP/2 endpoint configuration.
• No native FCM support. The module focuses on Apple push. Android FCM support either requires a separate integration or a fork of the project.
• Community maintenance. The project is maintained by individual contributors, not by the FreeSWITCH project itself. Updates are sporadic, and production-critical issues may go unresolved for months.
• Manual certificate management. You are responsible for provisioning, deploying, and rotating APNs certificates and FCM credentials on the FreeSWITCH server.

Kamailio as a FreeSWITCH Front-End¶

Just as with Asterisk, the most production-proven pattern for FreeSWITCH at scale is to deploy Kamailio or OpenSIPS as a front-end SIP proxy. The proxy handles RFC 8599 registration, push dispatch, and re-registration timing. FreeSWITCH operates behind the proxy as the media and application server, unaware that push is involved. This architecture is used in production by several large service providers and is well-documented in the Kamailio and OpenSIPS communities.

Three Paths to Solving SIP Push Notifications on Asterisk and FreeSWITCH¶

Now that we have established the problem and why your PBX cannot solve it alone, let us look at the three realistic paths forward.

Path 1 — Open-Source SIP Proxy Layer (Kamailio, OpenSIPS, or Flexisip)¶

This path places a SIP proxy in front of your existing Asterisk or FreeSWITCH deployment. The proxy becomes the RFC 8599-compliant registrar.

Kamailio has a community-developed push notification module and the flexibility to implement RFC 8599 logic using its native scripting language. However, a full production implementation requires significant custom configuration, including routing logic for push dispatch, timer management for re-registration waits, and integration with APNs and FCM APIs.

OpenSIPS introduced RFC 8599 support in its 3.1 LTS release in 2021. It provides a more structured approach with dedicated modules for push notification parameter parsing and dispatch. The OpenSIPS blog has a detailed two-part series on the implementation.

Flexisip, developed by Belledonne Communications (the team behind Linphone), offers the most complete RFC 8599 implementation of the three. It supports both APNs and FCM, handles token management, and can operate in a "Push Gateway" mode specifically designed for organisations that already have a third-party SIP server. For teams without deep SIP proxy experience, Flexisip offers an easier deployment path than Kamailio or OpenSIPS.

Pros:

• Open source with no per-user licensing fees
• Full protocol control and customisation
• Proven at scale when properly resourced
• PushKit and CallKit compliant when correctly configured

Cons:

• High operational overhead: you are now running and maintaining a SIP proxy cluster in addition to your PBX
• APNs and FCM credential management falls entirely on your team
• Proxy high availability, load balancing, and scaling are your responsibility
• Weeks to months of deployment time depending on team experience

Path 2 — Commercial Push Gateway¶

Several commercial products exist specifically to bridge the gap between SIP servers and mobile push infrastructure.

MizuVoIP Push Gateway (MPUSH) is a standalone push proxy that sits between your SIP server and APNs/FCM. It provides a management API for token provisioning and handles the push dispatch lifecycle.

2600Hz Pusher is part of the Kazoo platform but illustrates the commercial gateway pattern: a dedicated service that manages push tokens, credentials, and dispatch independently of the PBX.

The commercial gateway pattern works like this: the softphone client registers push tokens with the gateway (either directly or via the SIP REGISTER). When a call arrives and the PBX cannot reach the mobile endpoint, the gateway dispatches the push, the device wakes and re-registers, and the PBX completes the call normally.

Pros:

• The vendor manages APNs and FCM credentials, including rotation and renewal
• Support contracts provide a safety net for production issues
• Faster deployment than a full SIP proxy build-out (days to weeks)

Cons:

• Per-seat or per-transaction licensing adds recurring cost that scales with your user base
• Vendor dependency: if the vendor sunsets the product or changes pricing, you have limited options
• Integration testing is still required between the gateway, your PBX, and each softphone client
• You are adding another component to your infrastructure that requires monitoring and maintenance

Path 3 — Cloud-Provisioned Softphone With Centralised Push¶

This path takes a fundamentally different approach. Instead of retrofitting push support onto your PBX, you choose a softphone client that owns the entire push lifecycle end-to-end.

The key insight is that push notifications are a joint responsibility between the client and the server. A cloud-provisioned softphone maintains its own cloud push relay service. The softphone app registers its push token with the vendor's cloud infrastructure, not with your PBX. When a call arrives, the softphone vendor's relay handles the APNs or FCM dispatch. Your PBX only ever sees normal SIP REGISTER and INVITE transactions. It does not need to know that push is involved.

This means:

• APNs and FCM credentials live with the softphone vendor. Your team never touches APNs certificates, never worries about annual certificate expiry, and never manages FCM OAuth 2.0 service accounts.
• Zero per-device push configuration on your PBX. No Asterisk dialplan changes. No FreeSWITCH ESL scripts. No SIP proxy deployment.
• Over-the-air provisioning. Devices are configured remotely, and push works from the moment the app is installed and provisioned.

SessionTalk follows this model. Push notifications are handled centrally through SessionTalk's cloud infrastructure. ITSPs and MSPs provision users via a management portal or API, and the softphone handles PushKit on iOS and FCM on Android without any changes to the underlying Asterisk or FreeSWITCH deployment. For providers managing hundreds or thousands of endpoints across multiple resellers, this eliminates an entire category of operational complexity.

Side-by-Side Comparison Table¶

Criterion | Path 1: OSS Proxy | Path 2: Commercial GW | Path 3: Cloud Softphone

Asterisk changes: None | None | None

FreeSWITCH changes: None | None | None

APNs/FCM management: Your team | Vendor | Softphone vendor

Per-user cost: Low | Medium to High | Subscription

Time to deploy: Weeks to Months | Days to Weeks | Hours

Operational complexity: High | Medium | Low

Scale suitability: High (if resourced) | Medium | High

iOS PushKit compliant: Yes (if configured) | Yes | Yes

Android FCM compliant: Partial | Yes | Yes

Softphone Client Compatibility: Not All Apps Handle Push the Same Way¶

Even if you get the server side right, a non-compliant or poorly integrated softphone client will still miss calls. Push is a two-sided equation, and the client must handle its half correctly: receiving the push, waking promptly, re-registering with the PBX, and presenting the call via CallKit (iOS) or the appropriate notification channel (Android).

Note: SessionTalk is our product. The table below reflects our assessment of publicly available information about each client's push capabilities.

Softphone | iOS PushKit / CallKit | Android FCM Push | Push Infrastructure | Cloud Provisioned

Acrobits: Yes | Yes | SIPIS (proprietary cloud) | Yes

Counterpath Bria: Yes | Yes | Bria Cloud relay | Partial

Grandstream Wave: Limited | Yes | GS cloud | Partial

Linphone: Yes (Flexisip required) | Yes (FCM required) | Flexisip gateway | No

SessionTalk: Yes | Yes | Centralised (vendor-owned) | Yes

Zoiper (paid): Yes | Yes | Self-configured | No

A few points worth noting:

• Zoiper requires ITSPs to configure their own push infrastructure. This puts you back on Path 1 or Path 2 regardless of which softphone you chose.
• Linphone requires a Flexisip server for push. If you are already planning to deploy Flexisip as your proxy (Path 1), this pairing works. Otherwise, it adds a dependency.
• Grandstream Wave has had reported inconsistencies with iOS PushKit delivery, particularly on newer iOS versions.
• Free and open-source clients generally require self-hosted push infrastructure, which means the operational burden falls entirely on the ITSP or MSP.

ITSP and MSP Considerations: Managing Push at Scale¶

If you choose Path 1 or Path 2, you are taking on push infrastructure management. Here is what that entails at scale.

APNs Certificate and Token Management¶

Apple offers two authentication methods for APNs: certificate-based and token-based (JWT).

With certificate-based authentication, your VoIP certificate expires annually. When it lapses, every single iOS user on your platform stops receiving calls silently. There is no graceful degradation, no warning to end users, just silence. Best practice is to set 60-day calendar alerts for certificate renewal and automate the rotation process wherever possible.

Token-based authentication (using a signing key and JWT) does not expire in the same way, as the signing key itself does not have an expiry date. However, tokens can be revoked, and you still need to manage the key securely. For most ITSPs, token-based APNs authentication is the recommended approach as of 2026.

FCM Key Rotation¶

Google deprecated the legacy FCM server key API and shut it down in July 2024. The FCM HTTP v1 API uses OAuth 2.0 for authentication, which means you need a Google Cloud service account, and your push infrastructure must handle short-lived access tokens.

If your deployment is still referencing legacy FCM server keys anywhere in your configuration, push to Android devices is already broken. Migration to FCM v1 is not optional; it is mandatory.

Multi-Tenant Considerations¶

If you operate a single Asterisk or FreeSWITCH cluster serving multiple resellers or brands, push credential management becomes significantly more complex. Each reseller who white-labels the softphone app needs isolated APNs credentials tied to their own App Store listing and isolated FCM credentials tied to their own Firebase project.

Path 1 (OSS Proxy) and Path 2 (Commercial Gateway) both require per-tenant credential isolation at the proxy or gateway layer. This means additional configuration, additional certificate management, and additional monitoring for every tenant you onboard.

Path 3 solves this by design. The softphone vendor manages credentials centrally. White-label variants are handled within the vendor's infrastructure, and your multi-tenant PBX cluster remains unchanged.

Monitoring and Alerting¶

Push infrastructure introduces a new category of failure modes that do not appear in traditional SIP monitoring. You should track:

• Push delivery failure rate: the percentage of push dispatches that result in an error response from APNs or FCM
• Registration bounce rate post-push: how often a push is delivered successfully but the device fails to re-register within the expected window
• Call completion rate on mobile versus desk phones: a divergence between these metrics is the earliest indicator of push problems
• Per-token feedback: APNs provides a feedback service that reports invalid tokens; FCM returns error codes for unregistered devices

Log push dispatch attempts and outcomes separately from SIP logs. When a user reports missed calls, you need to trace the push lifecycle independently of the SIP transaction to pinpoint where the failure occurred.

Troubleshooting Matrix¶

When push notifications are not working, the symptoms can be maddeningly vague. Here is a structured troubleshooting matrix covering the eight most common failure modes.

Symptom | Likely Cause | Where to Check | Fix

iOS users miss all calls when phone is locked: PushKit not wired up; app not triggering CallKit | APNs delivery logs; softphone CallKit integration | Use a PushKit-compliant softphone; verify CallKit presentation

Android users miss calls after approximately 15 minutes idle: Doze mode has expired SIP registration | FCM delivery receipt; registration expiry timer on PBX | Enable FCM push wake; whitelist app in battery settings

Push worked, then stopped for all iOS users simultaneously: APNs certificate has expired | APNs error response (HTTP 403) | Renew certificate immediately; implement 60-day renewal alert

Push works for some users but not others: Mix of device types; push token not refreshed after app update | Per-token APNs feedback service; FCM error responses | Force re-registration on all devices; ensure token refresh on app launch

Calls fail after push is received by device: App wakes but INVITE arrives before re-registration completes | SIP trace on PBX showing INVITE timing; registration log | Add post-push delay on proxy; tune registrar wait timeout

FCM push delivered but Android device still misses call: App killed by OEM battery management (Huawei, Xiaomi, Samsung) | OEM battery management logs; device-specific settings | Apply OEM-specific app whitelist; provide user guide for each OEM

Kamailio or OpenSIPS push fires but call drops: Backend INVITE sent before new registration has landed | Kamailio or OpenSIPS debug log; SIP trace showing timing | Increase t_wait_for_register timeout value

No push on FreeSWITCH with mod_apn: HTTP/2 APNs endpoint not configured; certificate mismatch | mod_apn log output; APNs HTTP response code | Update to HTTP/2 APNs endpoint; verify full certificate chain

Conclusion¶

Mobile push notifications are not a nice-to-have feature for SIP deployments serving iOS and Android users. They are a hard requirement. Here are the four key takeaways from this guide:

1. The problem is the OS, not your PBX. iOS and Android aggressively suspend background network activity, making traditional SIP registrations unreliable on mobile devices.
2. RFC 8599 defines the solution, but Asterisk and FreeSWITCH do not implement it. Neither platform has native push support, and community workarounds are fragile at scale.
3. Three viable paths exist, ranging from open-source SIP proxy deployments to commercial gateways to cloud-provisioned softphones. The right choice depends on your team's operational capacity and scale requirements.
4. Push is a client-plus-server problem. Even a perfect server-side implementation fails if paired with a non-compliant softphone client.

For ITSPs and MSPs who need SIP push notifications working reliably on Asterisk and FreeSWITCH without deploying proxy servers, managing APNs certificates, or debugging OEM battery settings, the fastest path is a cloud-provisioned softphone that handles it all.

Stop losing calls to sleeping phones. Start your free trial of SessionTalk today and get push notifications working on every mobile device your team manages — no proxy servers, no certificate rotations, no missed calls.