Baresip: modular SIP client deployment guide

Pin the 4.12.0 core, libre and selected package

The upstream release page identifies Baresip 4.12.0 as the latest core release at review, released September 30, 2026. The matching libre repository also publishes 4.12.0. The stable-install guide says libre must be installed first and directs source builders to the latest stable libre release. Record both versions rather than treating baresip --version, a package label or a repository branch as the complete runtime.

The project currently lists Android 8 or later, macOS 11 or later, iOS 10 or later, Linux kernel 4 with glibc 2.31 or later, and Windows 10 or later as source-project targets. Those are not one common package, user interface or support arrangement. Pin the Baresip core, libre library, distribution package or source commits, compiled options, operating system and update owner together; preserve the accepted artifacts and tested rollback path.

Treat the libre security update as runtime evidence

Libre 4.12.0's official release record includes security advisory GHSA-rp4v-6hwc-3w8j. The public release notice establishes that the library release carries the fix; it does not identify the libre build embedded in a distribution package, mobile wrapper, graphical front end or locally built Baresip binary.

Inventory the loaded library and package provenance on every maintained artifact. Use the package maintainer's advisory and supported update path where applicable, or rebuild and retest an exact source set. Do not infer remediation from a Baresip application version alone, and do not claim exposure or exploitability for a deployment that was not inspected.

Authorize outbound custom SIP headers explicitly

Baresip 4.12.0 adds a documented release feature for custom X- headers on outbound calls. A header can carry routing, tenant, feature or diagnostic data into signaling, but the release note does not define a provider contract, trusted consumer, privacy purpose or safe value for a deployment.

Name the generating configuration, allowed header names, value source, destination, retention and removal condition. Confirm the PBX or provider accepts the field without exposing credentials, personal data or internal topology, and inspect the actual outbound request. A successful call does not prove that an intermediary preserved, consumed or ignored the header as intended.

Treat accounts and configuration as credential-bearing state

The project documents an accounts file in the configuration path and creates one user agent for each account line. Account parameters can carry the SIP identity, authentication user, password, outbound proxy, transport and media-encryption choices. Protect the file and its backups as secrets, restrict local access and define who can issue, rotate and revoke each account.

This is local configuration, not proof of a central fleet-provisioning service. If another tool generates or distributes the files, document that separate trust path, validate its permissions and test removal of a lost or retired workstation. Registration confirms a binding; it does not validate calling permissions, inbound routing, emergency identity or media.

Inventory the modules that are actually loaded

Baresip exposes capabilities through modules. The current project material lists separate modules for audio drivers, codecs, video, NAT traversal, control interfaces, recording and protected media. A capability in the repository is not necessarily compiled, installed, loaded or usable with the selected PBX.

Capture the built and loaded module list, selected audio input and output, codec policy, DNS behavior and any STUN, TURN or ICE path. Test the exact headset and workstation after login, sleep, wake, network change and application restart. Keep command or control interfaces bound and authorized according to their documented exposure rather than enabling them for convenience.

Treat global configuration and account policy as different state

Baresip's current configuration reference separates the global config file from the accounts, contacts and uuid files in the selected configuration directory. The -f option can select another directory. Record the effective directory, file ownership, permissions, generated source and process arguments; editing a remembered ~/.baresip is not evidence that the running process loaded it.

Global settings such as sip_listen, certificate and CA files, audio devices, module paths and call_max_calls remain distinct from per-account registrar, authentication, outbound proxy, transport and media policy. The documented default maximum of four calls is a local admission control, not a PBX licence, carrier concurrency entitlement, workstation performance result or promise that four media sessions are usable. Preserve the loaded value and observed rejection behavior separately.

Verify signaling and media protection separately

The project lists TLS signaling and SRTP-family media options, including DTLS-SRTP, ZRTP and SDES. These are distinct mechanisms. An available module does not show which SIP transport was used, whether certificate verification succeeded, which media key exchange was selected or whether the far end accepted it.

Set an explicit policy for the selected account, then inspect the registration and one call. Confirm the transport, certificate result, SDP offer and answer, negotiated media protection and failure behavior when the required mode is unavailable. Do not describe the PSTN or another downstream leg as encrypted from evidence limited to the client-to-PBX segment.

Bound availability, diagnostics and support

For a desktop deployment, inbound calling depends on the Baresip process, account state, workstation, audio subsystem, network and PBX path remaining usable. The core documentation does not establish a mobile push-registration relay or promise locked-screen delivery. Treat mobile wrappers and their background behavior as separate products requiring their own release, privacy and lifecycle evidence.

Run a bounded pilot covering registration, inbound and outbound calls, early media, answer, hold, transfer, DTMF, voicemail indication, audio-device changes, restart, sleep and network transitions. Preserve only the diagnostic interval needed, redact credentials and personal calling data, and return logging to its normal level. Define who supports the selected package and how users reach an alternate calling path. No package, build, dependency, user interface, credential, account, PBX, audio device, registration, call limit, transport, protected-media mode, emergency behavior, background delivery, availability or call quality was tested for this guide.

Use one evidence path when an account loads but registration or audio fails

The Baresip registration and audio diagnostic follows the selected configuration directory, compiled and loaded modules, account User-Agent, REGISTER transaction, SDP, RTP and audio devices without treating an existing account line as proof of registration or usable media.