QuadChroma · Blog

A second call during a call: how QC-Phone Plus handles call waiting without delivering calls

By Robert Brandt, QuadChroma

Published 29 October 2026. Status: design. QC-Phone Plus is in development and not yet available.

This is part 2 of "Fetch, don't deliver", which describes how QC-Phone Plus brings incoming SIP calls to a sleeping iPhone. The text below refers to the steps and sections of part 1.

A second call for the same SIP account can arrive while the user is already talking: during a call fetched from the server, a call that the phone placed directly through the provider, a call over the mobile network or a call in another app. The second call is handled like any other call. As in step 1, the server holds at most one unanswered call per account, so a further call while one is still ringing gets 486 Busy Here. How many answered calls an account can have at the same time is a server setting, one or two. With one, a second call during a call fetched from the server gets 486 Busy Here, and during any other call the phone only records a missed call. With two, the following applies, and a third call gets 486 Busy Here.

• The second call is announced with exactly the same message and over the same channel as any call, to every active device, including the one on which the first call runs. Neither the message nor its delivery says that a device is busy or that a call is waiting, and the message contains no count of calls. The phone never tells the server that it is on a call. The server only knows the calls whose SIP dialog it keeps itself, and only in memory.
• The phone alone decides from its own state that this is a second call. Until the user taps, it sends nothing about the second call and never rejects it on its own. Only the first call carries on as before, at its usual pace: its audio, its status request and its signalling. The announcement triggers none of this traffic and does not change its pace, and the status request of the first call reports only events of the first call.
• While the second call rings, a network change triggers no request of its own; only the status request of the first call is set up again after an error, as without a second call. If the first call ends in that time, the phone sends only what ends it. Everything else waits at least until the user has tapped or the second call has ended.
• If the phone cannot offer the second call, for example because two calls are already running, a call is still being set up, the device key cannot be read or the server allows only one call per account, it only records a missed call and contacts no one. The phone learns that setting from the server's replies when it sets up or checks its setup, never from an announcement.
• If the user answers, the phone fetches the second call over HTTPS exactly as in step 4. It names a line number, 1 or 2, that it chooses itself and that no other call fetched from the server uses; every later request about this call names the same line. The server keeps the calls of a device for the same account apart by this number. The number never comes from the announcement and is never assigned by the server; the server refuses a line that is still in use and offers no other. Each fetched call has its own status request, which the server watches separately.
• The server never parks the second call until the first one ends and never announces it again. It keeps the call only as long as the provider lets it ring; there is no separate deadline for a second call, only the same protection timer as for any call. If the first call ends while the second one rings, the server sends nothing new.
• If the user declines the second call, the server rejects it as described under "When the call is not answered", and the first call is not affected. If the second call ends or another device answers it, the other devices get the silent message as for any call. On a device with a running call, this message only stops the ringing and never ends the running call.
• The phone offers only the choices of the operating system: hold and answer, end and answer, or decline. With hold and answer, it closes the microphone of the first call at the tap and fetches the second call at once, without waiting until the hold is confirmed. If the hold fails, the microphone of the first call stays closed as long as the second call exists. Holding a call fetched from the server is the phone's own new offer for that call's line, which the server passes on to the provider only within that call's dialog.
• While a second call is involved, every hold is silent, whatever the hold-music setting and also after switching between the calls: no music, no announcement and no message to the second caller or to the party on hold. This applies to every call that the app holds, with or without the server, also when the other call runs over the mobile network or in another app. If the first call is already on hold with music when the second call rings, the phone switches the music to silence locally, without new signalling. The second caller only hears ringing; what a provider or the mobile network itself plays to a held party is outside the app and the server.
• The second call stays an incoming call from start to finish. Calls fetched from the server are never merged into a conference.

Text licence: CC BY 4.0.