Linphone SIP-account registration: lifecycle, state and evidence

Inventory one account and every independent input

Record the exact Linphone application, Liblinphone build, operating system, package channel, account object and first failure time. Keep the SIP identity address, authentication username or user ID, realm or domain, secret or HA1, proxy or registrar address, outbound route list, transport, registration enablement and expiry as separate facts.

A user-facing address can differ from the authentication username, and a proxy address does not establish the route or transport actually selected. Preserve the effective AccountParams rather than reconstructing them from a status icon or a provisioning document.

Treat registration as an ordered account lifecycle

The current Liblinphone RegistrationState model exposes None, Progress, Ok, Cleared, Failed and Refreshing. Preserve the ordered callback sequence with timestamps and callback messages. None means no registration is in progress, while Cleared follows successful unregistration; they are not interchangeable failure labels.

Progress and Refreshing are transitional evidence, not success or failure by themselves. Ok records a successful registration transaction for that account at that time. It does not prove inbound reachability, background wake, calling, media or emergency-service behavior.

Separate registrar discovery, route and transport evidence

Start with the configured server address and route list, then preserve DNS discovery, selected destination, source interface, transport, TLS name and trust result for the actual transaction. AccountParams can hold server, routes, transport and registration settings separately; a correct identity does not repair a wrong route or failed trust path.

A timeout, name-resolution failure, unreachable destination, transport reset or certificate error occurs before registrar authentication can succeed. Keep those boundaries distinct from a terminal SIP response.

Interpret authentication challenges in transaction context

A 401 or 407 challenge is a normal request for credentials and is not by itself a terminal authentication failure. Liblinphone AuthInfo matching considers username or user ID, realm or domain, password or HA1 and algorithm. Preserve the challenge, selected AuthInfo, retry and final response without exposing secrets.

Repeated challenges can reflect missing or mismatched AuthInfo, realm selection, algorithm support or rejected credentials. A credential callback proves only that the Core requested information; it does not prove that the registrar accepted the next REGISTER.

Use failure reason and ErrorInfo without flattening state

For a Failed account, retain the Account error reason and detailed ErrorInfo alongside the last state callback, SIP response and transport chronology. Informational callback text, a library reason enum, a terminal registrar response and a network error describe different layers and should not be collapsed into one message.

Protect logs before sharing them. Redact passwords, HA1 values, authorization headers and private identifiers while retaining timestamps, account labels, destination, state order, response class and correlation needed to reproduce the boundary.

Verify refresh, replacement and later service behavior separately

Adding an enabled account to the Core starts registration, while refresh requests, expiry, network changes and contact replacement create later transactions. Confirm whether the previous contact was cleared, replaced or left to expire and whether the account returns to Ok after the selected network path is stable.

Then test authorized inbound reachability, background wake or push, outbound calling, media and emergency behavior as separate acceptance stages. Registration Ok proves none of those later outcomes. No application, account, REGISTER exchange, packet, media stream or call was inspected or tested.

Keep Linphone package state outside registration state

The Linphone guide separates the 6.2.4 artifact and profile from identity, route, authentication, REGISTER state, refresh and completed call behavior.