Why Some Softphones Must Stay Open to Receive Calls

People expect a phone app to ring whenever a call comes in, the way the built-in Phone app does. Some SIP softphones meet that expectation and some do not. The difference is not carelessness. It comes from how SIP delivers calls, how modern operating systems treat background apps, and whether a particular app and server have the extra infrastructure needed to bridge the two. This post explains the mechanics and what you can do about them.

How does a SIP call reach a softphone?

Two steps have to happen, both defined in RFC 3261.

Registration. When a softphone starts, it sends a REGISTER request to the server. The request says, in effect, "extension 201 can be reached at this IP address and port, over this transport, for the next hour". The server stores that binding. Before it expires, the softphone sends another REGISTER to refresh it. If the refresh never arrives, the binding expires and the server forgets how to reach the device.

Incoming INVITE. When someone dials extension 201, the server looks up the binding and sends an INVITE to the stored address. The softphone answers with a ringing response, the user picks up, and media starts flowing.

Both steps assume the softphone is running, connected to the network, and listening on the registered address. For a desk phone plugged into power and Ethernet, that is always true. For a battery-powered device running a general-purpose operating system, it often is not.

Transport matters too. Over UDP, the server sends the INVITE to the registered address and hopes it gets through NAT. Over TCP or TLS, the server uses the connection the client opened, which only works while that connection is alive. Either way, if the app is suspended, nothing arrives.

Why do operating systems suspend apps?

Battery life and performance. If every app could run indefinitely in the background, a phone would be flat by lunchtime.

iOS

Apple's documentation on preparing an app to run in the background describes the model. When an app leaves the foreground, it gets a few seconds to finish work and is then suspended. A suspended app does not execute code. Its network sockets are not serviced. From the SIP server's point of view, the device has gone silent: REGISTER refreshes stop and INVITEs go unanswered.

There are specific exceptions for audio playback, navigation, and a handful of other categories, but keeping a SIP socket open indefinitely is not one of them. An active call can continue in the background because it counts as audio, but a registered-and-waiting app cannot.

macOS

The Mac is more permissive. An app can keep running when its window is closed, stay in the menu bar and keep its SIP registration alive. SIPdia does this. The limit is sleep: when the Mac goes to sleep, network connections stop and the registration lapses. A Mac that is awake with the app running will ring. A Mac that is asleep will not.

How do push notifications solve this?

The platform owner runs a notification service that can wake an app. On Apple platforms the relevant framework is PushKit, which has a notification type specifically for VoIP. When a VoIP push arrives, iOS launches or wakes the app, the app reports the incoming call to the system, and the system shows the call screen even on the lock screen. The app can then register with the SIP server and accept the INVITE.

The flow looks like this:

1. The app obtains a device token from PushKit and sends it to the SIP server during registration.
2. The app is suspended. Its SIP binding may expire.
3. A call arrives. The SIP server notices that the device is unreachable, or that it should be woken, and hands the token to a push gateway.
4. The push gateway asks Apple's push service to deliver a VoIP push to the device.
5. iOS wakes the app. The app re-registers and the server sends the INVITE.

RFC 8599 standardises step 1 and step 3. It defines SIP parameters that let a client tell the server which push service it uses and what its token is, so the server knows how to wake it.

Why is a push gateway needed?

Step 4 is the hard part. Apple's push service only accepts requests from a server that holds the app developer's push certificate or key. The SIP server itself, a PBX in an office for example, does not have that credential and generally does not speak the push service's API. Something has to sit between them.

That something is a push gateway. It is a server run by the app's developer or by a provider. It receives a signal from the PBX or SIP proxy, looks up the device token, and sends the push on the developer's behalf. Building and running one means:

• Hosting a service that is always available, because a missed push is a missed call.
• Handling device tokens for every user.
• Updating the PBX or proxy so it knows how to call the gateway when a device is unreachable. Not every PBX supports RFC 8599, and configuring one that does is non-trivial.
• Managing the developer's push credentials securely.

Providers that sell their own softphone with their own hosted PBX can do all of this because they control both ends. An app that connects to any SIP server, including a PBX in someone's office, cannot assume the server has a push-capable component. Many such apps therefore do not have push at all, or only offer it through the developer's own proxy service.

Where does SIPdia stand?

SIPdia does not have push notifications for incoming calls at the moment.

• iOS and iPadOS: the app must be open to receive calls. It unregisters about 20 seconds after leaving the foreground. While a call is active it continues in the background. Missed-call local notifications are shown for calls that arrived while the app was open but not answered. A PushKit implementation with a push gateway is the planned next step.
• macOS: the app keeps running when the window is closed and stays registered, with a floating incoming-call window and a menu bar icon. A sleeping Mac misses calls.

This is stated plainly on the platform pages because it changes how you should use the app.

What does forward-on-no-answer do?

Most PBX systems let an extension set call forwarding on no answer through a feature code. When the extension does not pick up within a set time, the PBX sends the call elsewhere: a mobile number, another extension, or voicemail.

For a softphone without push, this is the practical workaround. Set no-answer forwarding to your mobile number or to voicemail before you close the app or let the Mac sleep. Callers still reach you, or reach a mailbox, instead of hearing endless ringing.

SIPdia exposes this under Settings > Feature Codes. The forwarding controls (all, busy, no answer) and Do Not Disturb are part of SIPdia Premium, and the codes default to common Asterisk-style values (*52 and *53 for no answer, for example) that you can edit to match your PBX.

Practical advice

• On iOS, keep the app in the foreground while you expect calls, or set no-answer forwarding.
• On macOS, keep the Mac awake during working hours or set no-answer forwarding before you step away.
• Ask your PBX administrator or provider whether they support RFC 8599 push, so you know what is possible when apps add it.
• Do not assume a softphone will behave like the built-in Phone app without checking its documentation.

Next steps

Read SIP registration explained for the protocol side, and see how the behaviour differs on the iPhone and Mac platform pages.