Commit graph imsd/implementations
Author SHA1 Message Date
b986eb3750
ofonod: GNOME Calls backend over org.ofono for Phosh and GNOME Mobile
imsd-ofonod presents imsd on the system bus as an oFono modem — Manager at
/, Modem + VoiceCallManager at /imsd, a VoiceCall object per call — which
is what GNOME Calls' bundled ofono provider drives; Calls, Phosh and GNOME
Shell run unmodified. org.gnome.Calls is not a seam a third party can
provide (Calls exports it, nothing feeds it), and Calls' provider plugins
link private headers, so org.ofono is the only D-Bus contract available.
Pure GDBus translation of net.catcrafts.IMS1, no core, like imsd-dialerd.

Packaged as the opt-in imsd-ofono subpackage: the daemon, its unit
(Conflicts=ofono.service), the system-bus policy and a gschema override
that points Calls at the ofono provider instead of mm (the ModemManager
origin would offer the modem's CS voice path, which carries no audio on
these phones). The policy grants root send_destination=org.ofono: under
dbus-broker a broadcast is checked against the sender's send policy for
every name the receiver owns, so without it imsd's call signals never
reach the daemon.

Verified on a Fairphone 6 with GNOME Calls 50.0: outgoing and incoming
calls with audio both ways, answered and hung up through
org.gnome.Calls.Call. Known Calls-side gap documented in the README: after
the VoiceCallManager interface is withdrawn and re-added, Calls keeps the
old origin's CallAdded handler and eventually crashes.
2026-09-20 16:07:46 +02:00
738f3940ee
imsd 0.3.6
All checks were successful
package / package (push) Successful in 1m37s
2026-09-19 21:36:57 +02:00
52736295a1
ipsec: build the SAs from the Security-Server mechanism the UE selects
A P-CSCF may answer the challenge with every mechanism it supports and
attach the SPIs and ports to the one it applied. O2 UK's core lists six
ipsec-3gpp entries with q-values, md5 first, and marks the fourth (sha1,
no ealg). imsd took the first ealg= anywhere in the header - the 3DES of
an entry the P-CSCF had not selected - and installed SAs the far end
could not decrypt: every protected packet after the 401 was dropped at
its IPsec layer, over TCP and UDP alike, with nothing to answer.

The 401 handling now parses the Security-Server as a mechanism list
(commas outside quotes, parameters on semicolons, names and values
case-insensitive) and selects the highest-q ipsec-3gpp mechanism that
matches what Security-Client offered (RFC 3329 2.3.1, TS 24.229
5.1.1.5.1): alg equal to ours, ealg (absent = null) equal to the offer.
The SPIs and ports are per registration and come from the entry carrying
them. When no entry matches the offer, the entry carrying the SPIs is
installed as listed and the journal says so; hmac-md5-96 becomes
hmac(md5) with IK as the key. A single-mechanism header selects itself:
on KPN the SAs are the same as before (unit-pinned argv, verified on the
phone). An answer that cannot be used - no ipsec-3gpp entry, a missing
spi/port, an alg, ealg, prot or mod the kernel cannot be handed - defers
the bring-up on the throttle schedule with the reason, before the AKA is
spent, instead of a fatal that would restart imsd every RestartSec with
an initial REGISTER each time; spi-s=0 stays the throttle deferral.
Repeated Security-Server header lines are joined into the one list
Security-Verify echoes.

The journal shows the Security-Server line, the selected mechanism, the
SA parameters, and any ip xfrm command that fails (keys masked) at every
fresh registration - the silence this bug produced had no line to read.
2026-09-19 21:36:57 +02:00
78c83b1bf0
imsd 0.3.5
All checks were successful
package / package (push) Successful in 1m40s
2026-09-17 16:22:22 +02:00
5c89dcb033
sip: UDP for the protected leg, TCP first with a fallback
imsd's protected leg (the second REGISTER and everything after it) was
TCP only. A P-CSCF that never answers the TCP connect on its protected
server port (O2 UK: the SYNs leave ESP-protected, nothing comes back)
left the unit looping with no way forward, although the SAs, the
listener sockets and the firewall rule already covered UDP.

The client flow now carries a transport. UDP binds the same protected
client port and connect()s the datagram socket to the P-CSCF's protected
server port, so the kernel delivers that peer's datagrams to it ahead of
the unconnected listener on the same port. One datagram is one message
(RFC 3261 18.3: a Content-Length that fits truncates, one that does not
fit discards the datagram, none means the rest of the datagram); a
receive error is logged and marks the flow dead; a message over the
single-packet ESP budget at the ims PDN's MTU is logged once per flow,
since the kernel fragments it and a P-CSCF may drop the fragments.
Every protected request's Via follows the transport; the challenge
stays UDP.

SIP_TRANSPORT selects the policy: auto (default) registers over TCP and,
after two unanswered connects, registers again over UDP (new challenge,
new SA pair) - but only on a phone whose state file does not record a
successful TCP registration, so an outage on a TCP carrier never becomes
a second initial REGISTER; a phone whose last registration was UDP goes
straight to UDP. tcp and udp force one. A connect refused locally
(EADDRNOTAVAIL: the 4-tuple still in TIME_WAIT from the previous flow)
keeps retrying and is not counted as silence; SO_ERROR results are
logged by name. The registration's transport is persisted so a warm
resume reconnects the same way, and the resume gives up after two
silences.

Two things the change exposed and fixes: an engine-fatal event exited 0
("exiting for systemd restart" with Restart=on-failure never firing),
and a fresh registration refused with the P-CSCF's fresh-SA throttle
(Security-Server spi-s=0) must not be retried by a 120-s restart loop,
since every attempt re-arms the ~20-min window - it is now waited out
in-process, growing on repeats, with D-Bus commands still served. A
resume the network refuses falls through to a fresh registration. A
retransmitted 200 OK to our INVITE is ACKed again and no longer starts
a second media leg.

Verified on KPN: resume over TCP after a binary swap, MT and MO calls
with media both ways, the throttle deferral and its self-recovery, the
UDP client path up to KPN dropping the datagram. The UDP success path
is a field test; SIP retransmission timers over UDP are not in this
change.
2026-09-17 16:22:22 +02:00
dce941e082 imsd 0.3.4
0.3.3 plus: our requests are signed with the registered public identity
instead of the IMSI-derived temporary IMPU (the caller-ID leak a Telia
P-CSCF exposed), the identity survives a warm resume, and DUMP_SIP also
keeps the last outgoing INVITE.
2026-09-08 20:38:14 +02:00
7978b94502 messages: sign our requests with the public identity, not the IMSI IMPU
Every request we originated — INVITE, CANCEL, both ACKs, in-dialog BYE and
friends — put the IMSI-derived temporary IMPU in From. 3GPP allows that
identity in REGISTER only; the same lesson was learned for the reg-event
SUBSCRIBE (480) and never carried to calls. Most P-CSCFs overwrite From
and hid it; a Telia node did not, and a reporter's IMSI appeared on the
callee's screen (field report 2026-09-01). A strict P-CSCF may reject the
INVITE outright.

CallerId(): the registered sip: public identity (P-Associated-URI), else
the tel: one, and the temporary IMPU only before either is learned. One
helper feeds all five builders, so a dialog's From never drifts. As UAS the
dialog's local URI is the INVITE's To (RFC 3261 12.2.1.1), stored on the
Dialog, so an incoming call's BYE is signed the way the network addressed
us. The identity is persisted in the state file and restored on warm
resume, so a call placed before the refresh 200 re-learns it cannot fall
back. DUMP_SIP now also writes the last outgoing INVITE
(imsd-invite-out.raw): the one request a field log could never show.

The byte-pinned INVITE fixture moves to the tel: identity its test context
knows; new scenarios cover the sip: identity, the tel: fallback, the
pre-learning case and the UAS BYE.

Bench-verified on KPN 2026-09-08: outgoing INVITE From is the registered
sip: identity, call accepted and carried; caller ID at the far end
unchanged.
2026-09-08 20:37:47 +02:00
8526b9af0f imsd 0.3.3
All checks were successful
package / package (push) Successful in 1m48s
0.3.2 plus the media fix: the audio user is resolved once and thread-safely,
so an answered call can no longer land its PipeWire helpers in the wrong
runtime directory and play static.
2026-09-08 20:06:58 +02:00
b8d439246a media: resolve the audio user once, thread-safely
SpawnPw() looked the desktop user up with getpwnam() — one static buffer —
from the mic thread and the playout thread at the same instant. When the
race made both lookups fail, uid stayed 0 and both pw helpers were started
with XDG_RUNTIME_DIR=/run/user/0, where no PipeWire session lives: pw-record
hit EOF at once, pw-play never connected, and a call that was up with RTP
flowing both ways was answered into static (tx_mic=0 rx_played=0 qdrop=883,
dev phone 2026-09-08 20:01, first time in years of calls — timing).

AudioUid() resolves AUDIO_USER once under std::call_once with getpwnam_r and
a private buffer, complains when the user does not exist, and logs the
session the helpers are aimed at on every call, so a field journal answers
"where did the audio go" directly.
2026-09-08 20:06:58 +02:00
69d8b2a716 imsd 0.3.2
All checks were successful
package / package (push) Successful in 1m46s
Landline callers ring. The media leg plays AMR narrowband and G.711
(PCMA/PCMU) as well as AMR-WB, the engine accepts any of them from an
inbound offer (case-insensitive names, static G.711 payload types) and
names the offered codecs when it still has to refuse with 488. An inbound
INVITE is validated before it is announced to the UI, so a refused call no
longer flashes the dialer. Our own offer lists AMR narrowband after AMR-WB,
so a call to a landline no longer depends on the network transcoding up.
CODECS=<list> restricts and orders the codecs offered and accepted, for
bench work against networks that transcode every caller to AMR-WB.

Bench-verified on KPN 2026-09-08: PCMA and AMR-NB in both directions, the
default incoming path still AMR-WB, a mobile caller's offer still answered
with octet-aligned AMR-WB.

Packaging: cross-compiled for the FP6's Cortex-A520/A720 cores; the aport
is gone, fp6-img installs this repo's published apk.
2026-09-08 19:52:02 +02:00
37ec8660b7 engine/sdp: CODECS override for the codecs we offer and accept
KPN's interconnect gateway transcodes every caller up: a G.711-only
fixed-line INVITE reached the phone offering PCMA, PCMU, AMR and AMR-WB
(bench call 2026-09-08), so the AMR-WB-only build rang and the narrowband
path — the one the Telia field report hit with 488 — cannot be reached on
the air through KPN by any caller.

CODECS=<list> (comma-separated over AMR-WB, AMR/AMR-NB, PCMA, PCMU) makes
the list both the codecs offered on an outgoing call and the acceptance
preference for an inbound offer, in that order: CODECS=PCMA takes G.711
A-law out of the mixed offer above, CODECS=PCMA,PCMU sends a G.711-only
offer toward the network. Unset, nothing changes — the default offer
bytes and the AMR-WB > AMR > PCMA > PCMU preference stay pinned. The
daemon logs an active override at startup.
2026-09-08 17:53:26 +02:00
a064b5deff imsd: validate an incoming INVITE before announcing it to the UI
OnIncomingInvite() posted CallAdded, then ran the engine's OnInvite(),
which is where the offer is validated. For a refused offer (488) the bus
saw CallAdded -> CallStateChanged(terminated) -> CallDeleted within one
Execute() — a 24 ms burst — while the engine comment three lines above the
488 promised the refusal lands 'before the UI ever rings'.

Field report 2026-09-01: kde-telephony-daemon reacted to the CallAdded by
launching Plasma Dialer as a lock-screen overlay, which came up half a
second later to an empty call list and never left; the user rebooted.

Run OnInvite() first and announce the call only if the machine survived
it. A refused call is answered and dropped with no bus events at all
(Execute(actions, announce=false)); the journal keeps the record — caller
and reason are already logged.
2026-09-02 03:18:58 +02:00
649923d36f media: play AMR narrowband and G.711 as well as AMR-WB
imsd-media spoke exactly one codec, AMR-WB. A landline caller reaches the
IMS core through the PSTN gateway, which offers narrowband — AMR (NB)
and/or G.711 — so with the engine now accepting those offers the media leg
has to play them.

CODEC (set by the daemon from the negotiated SDP) selects AMR-WB (the
default, unchanged), AMR, PCMA or PCMU. AMR narrowband rides the same RFC
4867 payload code as AMR-WB with its own frame-size table (RFC 4867 table
1) and libopencore-amrnb dlopen'd like the wideband pair — same package as
the AMR-WB decoder, no new dependency; AMR_MODE defaults to 7 (12.2 kbit/s)
for it. G.711 is the ITU-T table codec, raw samples in the payload, digital
zero as keepalive. The narrowband path runs pw-record/pw-play at 8 kHz and
steps the RTP clock by 160 per frame.

Two test seams so the leg can be driven against a synthetic RTP peer with
no PipeWire and no network: MIC_SRC=<file> feeds raw PCM through the
encoder in real time instead of pw-record, PCM_DUMP=1 writes the decoded
downlink to <out>.pcm. --selftest now covers both AMR tables (both payload
formats) and G.711 (digital zero, idempotence over the full 16-bit range,
1 kHz sine SNR >= 30 dB for both laws).

Verified on the workstation with a Python gateway stand-in for PCMA, PCMU
and AMR (octet-aligned and bandwidth-efficient): uplink RTP shape (pt, seq,
ts step 160, payload sizes 160 / 33 / 32) and a 440 Hz mic tone recovered
from our packets by an independent decoder; a 1 kHz gateway tone recovered
from our decoded downlink. The AMR-WB default path keeps its legacy
keepalive shape (ts step 320, FT0 payloads 19/18 bytes).
2026-09-02 03:18:58 +02:00
17e0f6b53a packaging: own the apk aport (transferred from fp6-img); version 0.3.1
packaging/aport/ is now the canonical apk packaging, moved here from
fp6-img so the daemon and its package live and version together —
fp6-img's build.sh consumes this directory instead of carrying its own
copy (it pins _commit and generates the source tarball, as before).

0.3.1 ships the ims-pdn-up hardening (visible mmcli errors, registration
gate, configurable ip-type) and the TimeoutStartSec bump that goes with
it.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-09-01 18:24:37 +02:00
f2a404855f Emergency calling, stage 1: urn:service:sos with a digits fallback
Classify 112/911 (plus EMERGENCY_NUMBERS) at Dial. A classified call
INVITEs urn:service:sos over the existing registration and, on any
non-2xx final not caused by the user hanging up (including the
setup-timeout CANCEL paths), retries once as a plain INVITE of the
dialled digits — the pre-0.3.0 behavior, so classification can never
place a call worse than the status quo. The reverse edge: a 380
Alternative Service whose body carries the emergency indication
upgrades an unclassified call to the sos URN; a bare 380 stays an
error, since promoting an arbitrary redirect would put a
non-emergency call through to a PSAP. An emergency dial preempts an
in-progress call, and an answer racing a deadline-initiated CANCEL is
taken instead of BYE'd (user-initiated CANCEL races still BYE).

No emergency registration, no emergency PDN, no CS fallback, no
SIM-less calling, no AML — and no carrier has confirmed the sos path
end-to-end. The README warning states exactly that.

Assisted-by: Claude:claude-fable-5
2026-08-03 09:27:03 +02:00
6e77823933 imsd 0.2.7 — initial public snapshot
Userspace VoLTE/IMS daemon for mainline Linux phones (developed on the
Fairphone 6): a GLib-free core (SIP, SDP, USIM AKA, IPsec SA setup, RTP
media, call engine) behind a GDBus control daemon, a standalone AMR-WB
media leg, and a Plasma Dialer backend. C++26 modules built with Crafter
Build; the tree is clean under the project's house-style linter
(crafter-build lint) across all three build products.

Assisted-by: Claude:claude-fable-5
Signed-off-by: Jorijn van der Graaf <jorijnvdgraaf@catcrafts.net>
2026-07-22 23:04:21 +02:00