Commit graph

31 commits

Author SHA1 Message Date
6689b8b252
ims-pdn-up: retry the profile lookup, never reuse a stale APN-string bearer
The ims profile lookup ran the moment ModemManager listed the modem, which
on a cold boot can be while it is still enabling; qmicli's error was
discarded, so a failed lookup read as "no profile" and the script fell back
to the APN-string request, which is the one the modem refuses under an
IPv4 attach. Every refused attempt left a disconnected apn=ims bearer
object behind, and the next restart's "reuse a stale disconnected bearer"
step matched it by APN and reconnected it: ten refusals again, no way out
but a reboot that happens to win the race (O2 UK field report; the same
lost race seen on a KPN unit, where the fallback merely connects).

Log qmicli's error and retry the lookup after the registration wait, fall
back to the APN string only when the list has no such APN, reuse a
disconnected bearer only when it has this run's shape and delete leftover
APN-string ims bearers when connecting by profile index, match the APN
case-insensitively, and on call-already-present adopt the connected bearer
instead of asking the modem again.

Ten field shapes replayed against a mock ModemManager (shipped script
5/10, this one 10/10); on the FP6 a warm restart adopts the live PDN and
a cold boot connects by profile index and registers.
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
587b06b583
ims-pdn-up: connect the ims bearer by profile index, not by APN string
All checks were successful
package / package (push) Successful in 1m33s
On carriers whose attach PDN is granted IPv4-only (Odido, Swisscom, O2 UK
so far) the modem refuses every AP-side IPv6 bearer request made by APN
string with pdn-ipv6-call-disallowed before it reaches the air, so the
ims PDN never came up and imsd looped. A request made by 3GPP profile
index is treated as the IMS-class call the modem's own engine makes and
is exempt: it goes on the air as IPv6 and the network grants it. That is
the path 81voltd uses.

Look the ims profile up by APN in the modem's profile list and create the
bearer with profile-id=<index>,ip-type=<type>; fall back to the APN string
when no such profile exists. A profile-indexed bearer reports no APN, so
the reuse match accepts the profile id too. New knobs in /etc/imsd.env:
IMS_APN (default ims) and IMS_PROFILE_ID (default: looked up; "none"
forces the APN-string path).

Verified on KPN with the wall induced by a forced IPv4 attach: the
APN-string request is refused, the profile-indexed request connects, a
second run reuses the bearer, imsd registers over it; attach and mobile
data untouched.
2026-09-17 13:45:19 +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
c5cba2e7ff tests: dial a documentation-style number in the CODECS offer scenario 2026-09-08 19:51:24 +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
452634683c packaging: cross-compile for the FP6's own cores
The phone is one SoC, 4x Cortex-A520 + 4x Cortex-A720, and the package is
built for nothing else, so build for it: -march=armv8.6-a+fp16fml+aes+sha3+sm4
-mtune=cortex-a720 instead of the generic Armv8 baseline. That is gcc's own
-march=native expansion on the phone, re-based on armv8.6-a so clang can
express the same set; 8.6 is the highest level whose mandatory set the phone
exposes (8.7 would assume WFxT, 9.x SVE2 - neither is in its hwcaps, and
SVE2 code would SIGILL). Same string as the fp6-img aports and kernel.
2026-09-06 00:02:31 +02:00
1987275a54 packaging: drop the aport; fp6-img installs the published apk
All checks were successful
package / package (push) Successful in 1m55s
fp6-img no longer builds imsd from source: its images install the apk this
repo's package CI publishes to the registry (pinned version + sha256), so
the image and 'apk upgrade' carry the same binary and APKBUILD.binary is
the only imsd packaging left. The two payload files the aport carried
(kde-modem-daemon skel override, systemd preset) move up to packaging/,
where build-package.sh now takes them from.
2026-09-02 16:08:21 +02:00
d5aaf57e49 sdp: offer AMR narrowband after AMR-WB
Our offer listed AMR-WB alone. A call we place TO a landline then depends
on the far side transcoding up to wideband; a gateway that will not is
entitled to refuse. AMR narrowband is the 3GPP-mandatory codec every IMS
core and PSTN gateway can answer, so it goes second, with telephone-event
at the 8 kHz clock beside the existing 16 kHz one. AMR-WB stays first, so
a mobile-to-mobile call negotiates exactly what it did before; if the
network does answer AMR, the engine already starts the media leg on the
answered codec.

Byte pins in tests/Sdp and tests/Messages re-pinned (INVITE body 323 ->
466 bytes).

NOTE FOR RELEASE: this changes the MO INVITE on the path the arranged 112
calls used. One bench MO call on KPN before it ships.
2026-09-02 03:21:06 +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
daaba2d657 engine/sdp: accept AMR-NB and G.711 offers; name the offered codecs on 488
An incoming INVITE whose offer carried no AMR-WB was refused with 488
before ringing. A landline caller arrives through the PSTN gateway, which
offers narrowband — AMR (NB) and/or G.711 — so every landline call was
refused, deterministically. Field report 2026-09-01 (Telia Norge): a
doctor's office called twice, both 488; a mobile caller rang fine.

The parser now recognises PCMA/PCMU by rtpmap name or by static payload
type (a G.711 offer may carry no rtpmap line at all, RFC 3551 §6), matches
encoding names case-insensitively (RFC 4566 §6), and prefers
AMR-WB > AMR > PCMA > PCMU with octet-aligned first within AMR — a mobile
caller offering everything still lands on AMR-WB. The engine accepts any
codec the media leg plays and answers at the offer's own payload type with
the DTMF clock matching the codec (8 kHz for narrowband). A refused offer
now logs what WAS offered ('offered: 18 G729, 101 TELEPHONE-EVENT'), so a
field journal answers 'which codec did the gateway want' without a raw SIP
dump.

The media leg gains the matching codecs in the next commit.
2026-09-02 03:11:11 +02:00
4558f2afd8 ci: PACKAGE_TOKEN is an org-level secret now
All checks were successful
package / package (push) Successful in 1m51s
2026-09-02 00:39:40 +02:00
87376ccd9c ci: cross-compile with crafter-build instead of pmbootstrap chroots
All checks were successful
package / package (push) Successful in 1m50s
The pmbootstrap approach needed the privileged pmos runner, which only
fp6-img can reach. This repo already had the right flow: make-sysroot.sh
+ crafter-build --target=aarch64-alpine-linux-musl + APKBUILD.binary —
unprivileged, so it runs in an alpine:edge container on the ordinary
arch-latest runner, and minutes instead of qemu-chroot hours. The test
suite runs natively; the aarch64 binaries are further exercised by
fp6-img's chroot 'make check' whenever an image builds.

APKBUILD.binary gains the pmOS integration payload the canonical aport
ships (systemd subpackage, enable preset, wants symlink, config-gated
drop-in, kde-modem-daemon skel override) — required before this pipeline
may publish a version users upgrade to, or the upgrade would strip those
files. pkgver now follows implementations/main.cpp (sed'd by the CI, and
bumped to 0.3.1 in the file).
2026-09-02 00:29:40 +02:00
e85136982c ci: build and publish the apk from this repo
Some checks failed
package / package (push) Has been cancelled
A package workflow on the pmos runner: pmbootstrap cross-builds the
aarch64 apk(s) from packaging/aport/ at the pushed commit and uploads
them to the Forgejo Alpine registry, so a daemon release reaches
installed phones via plain 'apk upgrade' without an fp6-img image run.
Releases are gated by pkgver: the registry 409s an already-published
version and the workflow moves on, so ordinary pushes are no-ops until
the aport bumps pkgver/pkgrel.

fp6-img is unchanged: images still build imsd from a pinned checkout of
this repo, from the same aport.

Needs the PACKAGE_TOKEN secret on this repo (or org-wide) to publish;
until then the workflow builds and skips the upload.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-09-01 23:20:04 +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
e5911c09c2 ims-pdn-up: log mmcli errors, gate on registration, configurable ip-type
Three hardenings, each of which cost a field-debugging round-trip:

- Every mmcli failure now lands in the journal verbatim (create-bearer
  and connect stderr were swallowed, making 'connect attempt N failed'
  undecodable — no-service and interface-in-use looked identical).
- Connect attempts are gated on network registration (up to
  IMS_REG_TIMEOUT, default 300 s): the 10x10 s window is shorter than
  some carriers' post-boot attach (~2 min measured), so every attempt
  could burn out before the network was even attached. The settled
  modem/packet-service state is logged either way.
- Bearer ip-type is configurable via IMS_IP_TYPE in /etc/imsd.env
  (default ipv6); the bearer find/reuse now matches ip-type too, so a
  config change cannot silently reuse a stale bearer of the old type.

TimeoutStartSec grows 600->900 to cover the registration gate.

Tested on the FP6 dev phone (KPN): clean-state bring-up in 4 s;
gate + timeout path with modem disabled; per-attempt error lines on a
real contested-PDN failure (second ims PDN while one is connected);
idempotent reuse + REGISTERED (fresh) via systemd.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-09-01 18:10:04 +02:00
9267c02c9f 112 tested 2026-08-18 14:26:01 +02:00
693afd0369 added more carriers 2026-08-13 17:33:58 +02:00
db8b025d0e added second verified working carrier 2026-08-12 15:44:52 +02:00
65a123f467 readme change 2026-08-12 14:25:09 +02:00
10379586b5 Add a make build path for distro packaging
Mirror the crafter-build pipeline in a plain GNU Makefile — precompile
the libc++ std module and the Imsd partitions in dependency order,
archive imsd-core, link the three executables with the same clang/
libc++ flags — so distributions can build from source without
packaging crafter-build first. make check runs the same 7 suites;
make install stages the binaries plus the packaging/ files under
DESTDIR/PREFIX.

Rewrite packaging/APKBUILD from a documentation skeleton into a real
source-build APKBUILD on top of it (Alpine's llvm-runtimes ships the
std module sources since 22.x). project.cpp remains the canonical
build description.

Assisted-by: Claude:claude-fable-5
2026-08-07 21:27:29 +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