Both phones were waiting for the other one.

Take a call. Put it on hold to answer another. Finish the second call and return to the first.

That sequence worked right up until someone needed to hear someone else.

In the calling app we were working on, the screen returned to the original conversation and sat there retrying. The person on the other end still saw a held call. There was nothing obvious for them to do.

Both phones were waiting. Each had a reason.

One call, two different accounts of what happened

The phone that took the second call had closed its original audio connection. Returning to the first call meant arranging a new one.

The original caller’s phone still had its old connection and remembered having already done the setup. As far as it was concerned, the other person was simply on hold.

The returning phone expected the caller to start the setup. The caller believed it already had.

This is a deadlock: progress depends on an action that nobody is going to take. A retry button doesn’t help if it just repeats the waiting.

Our first repair depended on lucky timing

We initially had the returning phone ask the caller to reconnect. That helped when the timing lined up.

But the request could arrive before the caller was connected to the channel carrying those requests. Worse, we treated a failed request as a reason to stop recovery. Something intended to help reconnect the call could now prevent it.

There was a better signal already in the system. When a participant rejoined, the caller received an event named peer_ready. It reached the phone that actually needed to start the setup.

We used that event to make the caller clear its old setup state and negotiate a fresh connection. The returning phone’s request stayed as a delayed fallback; its failure would no longer stop the process. Manual Retry was changed to enter the same recovery path.

In WebRTC, the technology carrying the call’s audio, this involved a fresh offer with an ICE restart. That asks the devices to establish a working network path again instead of relying on the old one.

A call screen isn’t proof of a call

Getting back to the right screen was only part of recovery. We needed to follow the connection through setup, find a usable audio path, and hear the other person.

That sounds obvious from the outside. Inside the software, there are several points where something can be marked “active” before anyone can hear anything.

The question that untangled this one was small enough to write beside the diagram: which phone has to move next, and what will make it move?