Freeze one missed call and compare the foreground path
Record one authorized incoming attempt with timestamp and timezone, called SIP identity, Bria plan, iOS or Android build, operating-system version, device, network, account and foreground, ordinary background, locked or exited state. Preserve the PBX or provider trace, Bria account state and the user-visible notification result before signing out, deleting the account or reinstalling the app.
Repeat the same call with Bria in the foreground. Bria's current Push Service reference says a failure that occurs in both foreground and background is likely outside the push path. Keep foreground registration, Push Service registration, notification, app wake, tunneled INVITE, alert, answer and media as separate outcomes.
Confirm the current client, account authority and push enrollment
At review, Bria's current iOS and Android release pages both identify 6.23.5 dated August 20, 2026. Record the installed build and distribution channel rather than treating that documentation value as proof of device state. Confirm whether the SIP account is administered in Bria Portal or locally, whether Use Push Notifications is enabled, whether the account itself is enabled and whether operating-system notification permission remains granted.
Bria documents a Test Push Service control that checks device communication with the Bria Push server and APNs or FCM. A passed test is narrower than a successful inbound call: it does not prove that the push server registered the intended SIP identity, that the PBX routed an INVITE to its Contact, or that the later secure call tunnel completed. Protect device and account identifiers in shared evidence.
Match the registration mode to the SIP server capability
Write down whether the PBX or provider supports multiple simultaneous registrations and call forking for this account. Bria documents Continuous and Standard for multiple-registration services, and Single Device Takeover and Single Device Emulation for single-registration services. Preserve the selected mode and the foreground-to-background transition rather than changing modes until the server behavior is known.
The modes create different evidence. Continuous keeps the Push server registered and can produce both a direct and Push-server INVITE while Bria is foregrounded. Standard can create a short overlap. Single Device Takeover transfers ownership without a prior unregister. Single Device Emulation deliberately avoids overlap but can create a short interval with neither side registered. Duplicate, missing and transition-time calls therefore require different diagnoses.
Follow the Push server registration and exact Contact route
Confirm that the Bria Push server can reach and register to the SIP service through the approved public or provider-supported path. A private PBX may require the separate Push Service SIP Proxy setting and narrowly authorized access from the vendor's current published service list. Do not expose a PBX broadly or copy an old address list without the current owner's review.
Bria documents a unique Contact URI for each SIP account and device. Compare the successful REGISTER Contact with the incoming INVITE Request-URI and the PBX's address-of-record mapping. If the service removes the distinguishing hash or does not route to that Contact, the Push server may be unable to select the device. Treat Disable Hash Token, Insert RInstance and proxy controls as interoperability exceptions requiring provider evidence, not generic fixes.
Separate notification delivery, wake-up tunnel and SIP timing
For the affected call, correlate the PBX INVITE, Push server receipt, APNs or FCM request, device notification, Bria wake-up and the secure WebSocket tunnel that Bria documents for relaying the INVITE. A visible notification does not prove the SIP request reached the app, and a successful Test Push Service result does not prove that a real INVITE selected the correct account and device.
Preserve the first provisional or final SIP response and the cancellation time. Bria documents Auto Send 180 as an optional Push-server response for services that cancel before the client wakes and creates its tunnel. That control addresses one timing boundary; it is not proof of user alerting, answer or media, and it should not replace evidence about a missing Contact or failed push submission.
Correct one owner, then test call and media stages separately
Correct only the first demonstrated divergence: account or notification state, failed Push Service test, unsupported registration mode, unreachable Push-server path, wrong proxy, lost Contact identity, premature cancellation or app release. Preserve the previous configuration and rollback. Do not shorten timers, enable NAT Emulation or toggle advanced interoperability controls without evidence from the affected path.
Retest foreground, background, locked or exited state, restart and one approved network transition. Record registration owner, notification, wake, WebSocket tunnel, INVITE, 180, alert, answer, SDP and both media directions separately. Bria's troubleshooting guide treats no audio or one-way audio as a later network boundary and notes a specific NAT Emulation check only when the symptom occurs on Push-registered calls. This workflow is documentation-derived and was not reproduced on a customer or laboratory system.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Bria iOS Push Service registration and troubleshooting reference ↗
- Bria Android push-notification setup and test ↗
- Bria iOS SIP account and Push Service settings ↗
- Bria iOS registration, audio and diagnostics troubleshooting ↗
- Bria current iOS release notes ↗
- Bria current Android release notes ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.