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.
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.
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.
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).
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>
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
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>
