{"id":23,"date":"2026-04-07T16:23:07","date_gmt":"2026-04-07T16:23:07","guid":{"rendered":"http:\/\/localhost:8080\/knowledge-base\/push-notifications-in-siperb\/"},"modified":"2026-05-27T10:39:56","modified_gmt":"2026-05-27T10:39:56","slug":"push-notifications","status":"publish","type":"post","link":"https:\/\/www.siperb.com\/kb\/push-notifications\/","title":{"rendered":"How Push Notifications Work in Siperb"},"content":{"rendered":"\n

Push notifications are the mechanism Siperb uses to deliver incoming calls to mobile devices reliably \u2014 even when the app is closed, the screen is locked, or the device has been idle for hours. This article explains how the system works at an architectural level.<\/p>\n\n\n\n

The problem push notifications solve<\/h2>\n\n\n\n

SIP is a stateful protocol. Receiving an incoming call requires your device to be actively registered with the PBX at the moment the call arrives. On a desktop or server, maintaining a persistent registration is straightforward. On a mobile device, it isn’t.<\/p>\n\n\n\n

iOS and Android are both designed to aggressively suspend and terminate background processes to preserve battery life and system resources. A SIP softphone running in the background will lose its registration within minutes — sometimes seconds. When a call arrives, there is nobody home.<\/p>\n\n\n\n

The platform-correct solution is push notifications. Rather than keeping the app alive, the OS keeps a single, system-managed connection open to Apple’s or Google’s push infrastructure. When a wake-up signal arrives, the OS restarts the app, which re-registers with the PBX and completes the call.<\/p>\n\n\n\n

How Siperb implements push notifications<\/h2>\n\n\n\n

Siperb’s proxy maintains a persistent SIP registration on behalf of your mobile device. When your phone goes idle and loses its direct registration, the proxy stays registered with your PBX. Your PBX continues to see a live endpoint for your extension at all times.<\/p>\n\n\n\n

When an incoming call arrives for your extension, the sequence is:<\/p>\n\n\n\n

    \n
  1. Your PBX sends a SIP INVITE to Siperb’s proxy.<\/li>\n\n\n\n
  2. The proxy identifies the target device and dispatches a push notification via the appropriate platform provider — Apple APNs for iOS, Google FCM for Android.<\/li>\n\n\n\n
  3. The platform’s push infrastructure delivers the notification to the device. The OS wakes the Siperb app, even from a locked screen or suspended state.<\/li>\n\n\n\n
  4. The app establishes a connection, re-registers with the proxy, and call signalling continues. From the user’s perspective, the phone simply rings.<\/li>\n<\/ol>\n\n\n\n
    \"Architecture<\/figure>\n\n\n\n

    Call audio never passes through push infrastructure.<\/strong> The push notification is only the wake-up signal. Once the device is awake and registered, audio flows directly between the device and your PBX (via Siperb’s transcoding layer if needed).<\/p>\n\n\n\n

    iOS \u2014 Apple APNs with PushKit<\/h2>\n\n\n\n

    On iOS, Siperb uses Apple’s PushKit<\/strong> framework rather than standard notification push. PushKit is Apple’s dedicated VoIP push channel and is treated with significantly higher priority than standard notifications:<\/p>\n\n\n\n