Freeze one incoming attempt and the exact user action
Record the timestamp and timezone, called identity, Blink account, Blink platform and version, registered contacts, intended simultaneous or sequential destinations, forwarding and voicemail policy, the button or key the user pressed, the first final SIP response on every branch, any CANCEL requests and the final caller treatment. Redact credentials, authorization values and personal numbers before sharing evidence.
Separate four symptoms: only Blink stops ringing, all registered devices stop, forwarding or voicemail never starts, or the caller receives an unexpected busy or decline treatment. Those outcomes can share one visible click but occur at different call-control boundaries.
Map the Blink control to the response it documents
Blink documents Reject as a 603 response intended to stop its own alert, other devices registered for the same account, and server forwarding or voicemail. It documents Busy as 486, with other devices and server routing left available. Pressing Escape only silences the local alert and sends no SIP decision.
Do not infer which control was used from the caller display alone. Preserve the Blink event or SIP trace and the proxy or PBX branch result from the same Call-ID and time window.
Interpret 486 and 603 at the fork boundary
RFC 3261 scopes 486 Busy Here to the contacted end system and says the user may still be available elsewhere, including voicemail. A 603 Decline is a global 6xx response used when no other endpoint should answer. For a stateful proxy, receipt of a 6xx should cancel pending client transactions and prevent new branches.
That protocol model explains why one Blink Reject can stop parallel phones, but it does not prove every PBX maps buttons, branches or voicemail identically. Identify the component that received the response and the component that issued each CANCEL.
Prove the account, contact and server policy are the intended ones
Blink can hold multiple SIP accounts and lets the user select an account for outbound sessions. For the failed inbound attempt, match the Request-URI and registered contact to the intended account rather than the currently selected outbound identity. Then enumerate every live contact and server-side destination for that address.
A gray registration indicator means failed or in-progress registration, but a solid indicator only establishes that account registration. It does not prove another device is registered, that a forwarding rule is enabled or that voicemail is eligible after a particular response.
Test the three choices without changing routing mid-test
With an authorized non-sensitive test call and a fixed server configuration, compare three separate attempts: Busy, Reject, and Escape. For each, retain the Blink action, response or absence of response, branch cancellations, which other destinations continued, and the final caller result. Also let one attempt expire without user action so timeout handling is not confused with Escape.
If 486 still suppresses every other destination, inspect the PBX response map and route policy. If 603 does not stop other branches, confirm the response reached the responsible proxy and that those branches belong to the same fork. Change only the earliest proven mismatch, then repeat the bounded matrix. No Blink client, SIP account, PBX, forwarding rule, voicemail destination or live call was tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Blink incoming-call alert choices ↗
- Blink SIP accounts and registration state ↗
- Blink main interface and outbound account selection ↗
- Blink audio-call controls and preferences ↗
- Blink platform-specific changelog ↗
- RFC 3261 SIP response and proxy-branch behavior ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.