Blink softphone: platform tracks, SIP accounts and negotiated protection

Choose the exact product, platform and channel

AG Projects describes Blink as a desktop SIP client for Linux, macOS and Windows, but its first-party release evidence is not one synchronized family version. At review, the changelog listed Windows 6.0.3 dated February 28, 2025 and Linux 6.0.6 dated January 28, 2026. The Mac App Store listing from AG Projects exposed Blink Pro 7.1.6 and required macOS 14.6 or later, while the vendor's changelog landing page still summarized stable Blink Pro 7.0.0 dated May 7, 2026 and a separate beta 9.4.0 dated June 6, 2026.

Treat that difference as a distribution boundary, not a reason to choose the largest number. Record product, operating system, store or repository, version, architecture, stable or beta channel and retrieval date. Keep Blink SIP client, Blink Pro for Mac, its beta, Blink Classic and Blink WebRTC distinct; the WebRTC client has separate SylkSuite dependencies and does not establish the desktop SIP package's behavior.

Own the SIP account and discovery path

Blink requires a SIP account from a provider or PBX. Its Windows/Linux manual documents local entry of a SIP address in user@domain form and a password, with RFC 3263 DNS discovery followed by an advanced server override when the provider does not publish the required records. Multiple accounts can be configured.

This is evidence for local account setup, not a fleet provisioning service. Define how credentials are delivered, rotated and removed from a workstation, and document any provider-specific proxy or number-format requirement separately.

Scope features to the service behind the account

The vendor lists audio and video, transfer, conferencing, messaging, presence, file transfer and screen sharing, but these use different protocols and server dependencies. AG Projects describes RTP for audio and video, MSRP for session messaging and file transfer, SIP SIMPLE for presence, VNC for screen sharing, and RLS or XCAP for buddy-list management. Treat each as a client capability that still requires the selected build, compatible peer or service, account entitlement and an accepted operating test.

The Mac App Store listing and vendor pages are capability descriptions, not evidence that every provider supports them. Test call transfer, DTMF, voicemail indication, conferencing, messaging, file transfer and screen sharing separately. PSTN access, calling identity and emergency calling belong to the SIP provider or PBX; Blink does not establish telephone-number reachability or location delivery.

Verify signaling and media protection independently

AG Projects advertises ZRTP end-to-end audio protection in Blink, while the SIP SIMPLE stack and tools document RTP, SRTP and ZRTP media modes. The current Blink Pro Mac notes also mention TLS CA certificate updates and enabling TLS server verification by default in an earlier 6.2.5 release. Signaling certificate validation and media protection are separate controls, and a changelog entry is not proof of the selected build's policy or one call's negotiation.

Confirm the account's signaling transport, certificate chain, server-name validation, media mode, peer support and negotiated result. ZRTP availability does not prove that every peer supports it, and an encrypted client-to-PBX leg does not establish protection beyond the PBX or through the telephone network. Define whether calls must fail when required protection cannot negotiate and run that failure test only with an authorized account.

Convert release notes into bounded acceptance checks

Blink Pro Mac 7.0.0 notes mention a universal binary, automatic switching to a newly inserted audio device, H.264 restoration, TLS CA updates and fewer DNS lookups. The separate 9.4.0 beta notes mention PJSIP 2.17, H.264 by default, video fixes, logging changes and camera release. These are change descriptions for specific tracks, not proof that another platform contains them or that the behavior succeeds with a selected PBX.

For the exact candidate, test registration, inbound and outbound calling, hold, attended and unattended transfer, DTMF, microphone and speaker selection, device insertion and removal, video if in scope, sleep and wake, VPN or network changes, DNS failure, restart, logging controls and credential revocation. Do not carry a beta behavior into the stable Mac, Windows or Linux record.

Protect workstation evidence and retain rollback

Keep the original package source, version, operating-system build, architecture, file hash where available, account profile owner, acceptance record and rollback package. Use protocol and application traces only for a bounded capture window, redact credentials and reusable authorization material, and define how logs, message history, contacts, recordings and account secrets are removed when the workstation changes owner.

Desktop inbound calling depends on the selected client running with a usable network and SIP account state. It is not evidence for mobile push, locked-screen delivery, background execution after logout or a server-side failover path. No installation, package, update, operating system, SIP account, PBX, provider, registration, call, media, encryption, background-delivery or emergency behavior was tested for this guide.

Treat Reject, Busy and silent dismissal as different call-control actions

Blink documents Reject as 603, which can stop the other devices and later treatments for the account; Busy as 486, which leaves other locations and server routing available; and Escape as a local alert dismissal with no SIP decision. Use the Blink inbound-disposition diagnostic to correlate the button, response, branch cancellations and final caller treatment.

Treat a gray account indicator as a starting state

Blink documents a solid account indicator as successful registration and gray as failed or still in progress. That display does not identify whether DNS discovery, a manual proxy, transport setup, the first-hop network, authentication or the registrar is the earliest failing boundary. Preserve the exact SIP exchange before changing multiple settings.

Use the Blink registration diagnostic to distinguish no reply or 408 evidence from an explicit 503 response and its optional Retry-After. Registration success then remains separate from inbound ringing, outbound authorization and media.