Baresip-studio: Forking, Provisioning, and the Wear OS Build

Note: I am not the maintainer of baresip-studio. That project is maintained by the baresip-studio team. I've forked it and extended it for my own infrastructure and hardware targets. Over the last couple of weeks I have been iterating on a personal fork of baresip-studio — the Android SIP client built on top of the baresip library — and I've spent quite a few hours this morning pushing the Wear OS side of it further. The upstream project remains the canonical source; I'm carrying a fork with additional capabilities that suit my own use cases.

What I've added in my fork:

1. Provisioning support — the app can now be configured via a baresip:// provisioning URI. The URI bundle is RSA/AES encrypted, decrypted inside the app, and the resulting configuration is written directly to baresip's on-disk format. That means the same provisioning flow used for the phone app carries across to Wear as well.

2. Wear OS build — the bigger piece of work this morning was a standalone Wear OS module. The watch app runs the native baresip NDK stack directly, with its own JNI bridge and foreground service keeping the SIP stack alive. The motivation is simple: a SIP client that lives on the watch, not a companion to a phone app. Early this morning I was debugging the SIP registration loop, DNS source ordering, and the foreground service lifetime so that the stack actually reaches the registration stage and holds it across the watch's aggressive background restrictions.

What's working on Wear so far:
- Native libwearbaresip.so loads cleanly; re_main() runs on a background thread from the FGS.
- DNS servers are injected via net_use_nameserver() before ua_init, which eliminates the ENOTSUP [95] that was blocking registration.
- Local interface addresses are enumerated and passed to the stack so baresip can bind a source socket.
- The dialer UI, in-call screen, and a manual Register button are in place for debugging the registration handshake.
- baresip:// provisioning intent handling is wired in and writes valid baresip-format config files.

What still needs attention:
- TLS trust-store: my Asterisk server presents an expired/self-signed CA. Pinning the CA on the watch trust store or disabling sip_verify_server temporarily is on the short list.
- Call audio routing on Wear — no Telecom/ConnectionService path here, so audio needs AAudio + Bluetooth HFP.
- Network change handling and retry logic for transient registration failures.

The heavy lifting this morning was proving the SIP registration path on the watch end-to-end. That part is now visible: the stack reaches registration, and the remaining problems are well-scoped. I'll keep iterating and will write more once audio and TLS are locked down.