How SIP Intercom Broke During the Switch Between Wi‑Fi and LTE

We integrated Asterisk into PDP Mobile for digital intercoms and resident camera viewing: the SIP client registers in the app, calls go through Asterisk, and camera video is delivered as an HLS stream.

In the normal case, everything looked fine: the app was active, the network was stable, an incoming call from the intercom opened the call screen, and the camera could be viewed live at the same time. In the admin panel, we added a map of the building’s cameras so that during an incident the operator could quickly pick the right angle instead of searching through a list.

The problems started where mobile connectivity usually reminds you it exists: the phone went into the background, Wi‑Fi switched to LTE, the network disappeared for a few seconds and came back.

What broke in testing

The most annoying scenario looked like this: the SIP client had already registered, the call came in, but the client state and the session state diverged. For the user, this showed up clearly: the call might not recover after a network loss, the video next to the call would freeze, and after bringing the app back from the background, the camera screen had to be opened again.

We tested HLS separately as well. The camera stream is not for archival use, but for what is happening right now by the entrance or in the yard. So “the image will load eventually” is not good enough. If the connection drops or the phone switches between Wi‑Fi and LTE, the player should not get stuck in a perpetual loading state. It needs to understand that the stream must be reopened.

The camera map in the admin panel had a similar risk, but for the operator. During an incident, the speed of choosing the right angle matters: building, entrance, camera. If the stream hangs after a network failure, the operator sees an old frame and assumes the camera is working. That is worse than an explicit error.

Where we initially looked in the wrong place

Asterisk was the first suspect. When SIP registration, calls, and sessions are involved, you naturally start looking at telephony logs: REGISTER, INVITE, dialog state, timeouts. There is indeed plenty to check there, but some of the cases could not be explained by the server side alone.

Then we looked at HLS separately: the playlist, segments, and how the player behaves on interruption. That was useful too, but the picture was still fragmented. SIP and HLS behaved like two independent subsystems, even though for the resident it is one scenario: the intercom rings, they see video, and they decide what to do.

A real example: the same test passed on the office Wi‑Fi and fell apart when leaving the building, when the phone switched over to LTE. In the logs, this did not look like “the intercom broke,” but like several small events at different times: the network changed, the app received a different lifecycle state, the player lost the stream, and the SIP session stayed in the old state.

What turned out to be the cause

The cause was at the intersection of the mobile lifecycle and network sessions.

You cannot handle the SIP client, the call, and the HLS player as if the network were constant and the app were always on screen. For a web interface, that model is sometimes tolerable. For a mobile intercom, it is not: the user may minimize the app, take another call, step out of the elevator, lose Wi‑Fi by the entrance, and come back on LTE while the call is still active.

We separated states that had previously been easy to mix up:

• SIP client registration;
• active call and its session;
• application state: active, background, return;
• network state: connected, lost, Wi‑Fi/LTE switch;
• HLS stream state: playing, buffering, requires reopening.

After that, it became much easier to write the handlers. If the network changes, check the SIP registration and the current call state. If the app returns from the background, do not treat the old frame as live video; validate the stream again. If HLS gets stuck on the old connection, reopen the view instead of waiting for endless buffering.

What we changed in the implementation

In the Asterisk integration, we kept explicit handling of SIP client registration, call management, and sessions. On the mobile side, we added handling for edge cases: connection loss, app backgrounding, return, and switching between Wi‑Fi and LTE.

For cameras, we added a separate HLS stream recovery flow. It was important not to mix this with the SIP call itself: video can disappear temporarily, but that does not always mean the call should be dropped. And conversely, a successful SIP call does not guarantee that the camera is currently delivering a live stream.

In the admin panel, the map of cameras in the building became part of the operator workflow. The operator selects the angle by object, not by an abstract list of streams. During network failures, the interface must show the current viewing state so that a frozen frame is not mistaken for live video.

After these fixes, the intercom stopped depending on an ideal test setup. The next layer of checks is different phone models and how they behave with background restrictions, because that is where the most boring, but expensive, bugs usually show up.