Skip to content

docs: instance ID on iOS, and which SIP server to run - #11

Merged
laconicman merged 2 commits into
mainfrom
docs/instance-id-and-own-server
Oct 4, 2026
Merged

laconicman merged 2 commits into
mainfrom
docs/instance-id-and-own-server

Conversation

@laconicman

@laconicman laconicman commented Oct 4, 2026 •

Copy link
Copy Markdown
Owner

Two new research docs and the pointers to them.

  • docs/Instance-ID.md — +sip.instance on iOS. Why it matters for a client that reconnects after every wake-up (Kamailio and Flexisip key bindings on it), why pjsua's host-name default is useless on iOS (localhost), and what went wrong in a production iOS client: identifierForVendor and UserDefaults both unavailable before first unlock, a racing config writer, a random fallback, and an SBC that refused the canonical UUID form. Proposed design: a device ID written once to the Keychain beside the SIP secrets, hashed per app and per account for the wire (D-INST-1…4), with two decisions left open. Includes the upstream decision behind pjsua: send a configured +sip.instance without SIP outbound too pjsip/pjproject#5313 and why pjsua cannot fix its default.
  • docs/Own-SIP-Server.md — which server to run for push and for a lab: Flexisip first (built-in APNs sender, INVITE parking, bindings keyed on the instance ID; certificate-only APNs auth, no Feature-Caps, AGPL), OpenSIPS second (complete RFC 8599 signalling, our own .p8 sender), Kamailio and Asterisk as measurement subjects. How to test push without Apple.
  • docs/Tech-Debt.md — OH-11: no instance ID of our own yet.
  • docs/Roadmap.md — a stored instance ID before push; Flexisip first.

Docs only; nothing is built yet.


Devin Review

- Instance-ID: why +sip.instance matters for a client that reconnects
  after every wake-up, why pjsua's host-name default cannot be used on
  iOS, what went wrong in a production client (identifierForVendor and
  UserDefaults before first unlock, a racing config writer, a random
  fallback, an SBC refusing the canonical form), and a proposed design:
  a Keychain-stored device ID written once, hashed per app and account.
  Links the upstream change, pjsip/pjproject#5313.
- Own-SIP-Server: Flexisip first (built-in APNs sender, bindings keyed
  on the instance ID; certificate-only, no Feature-Caps, AGPL),
  OpenSIPS second, Kamailio and Asterisk as lab subjects.
- Tech-Debt OH-11 (no instance ID of our own) and two Roadmap pointers.

@devin-ai-integration devin-ai-integration Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Devin Review found 1 potential issue.

Devin Review

Comment thread docs/Instance-ID.md Outdated
Comment on lines +157 to +159
A VoIP push in that window must still be reported to CallKit. The call can ring, but answering it
cannot register or accept the INVITE until the device has been unlocked once. The app has to fail
that answer cleanly and say why, not hang. An outgoing call does not arise there: the app cannot

@devin-ai-integration devin-ai-integration Bot Oct 4, 2026 •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔍 Pre-unlock ringing needs device verification

The proposed CallKit flow assumes iOS launches the app for a VoIP push before first unlock. U4 still lists that behavior as an open device test.

Devin Review


Was this helpful? React with 👍 or 👎 to provide feedback.

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in a8ce3d9: §4 and §5.1 now say that a VoIP push launching the app before first unlock is unverified, point at U4 in Push-vs-Active-Socket, and §5.3 lists it as the first thing to verify on a device. The storage design does not depend on it: any background launch in that window has to cope with the failures in §4.

@laconicman
laconicman merged commit dd96ea3 into main Oct 4, 2026
1 check passed
@laconicman
laconicman deleted the docs/instance-id-and-own-server branch October 4, 2026 11:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant