Diagnosing LiveKit/Telnyx caller-ID fallback versus downstream rewrite

Observed 2026-09-08 during negotiation COR-3987/COR-3991 staging acceptance. When a transferred human sees the receiving Telnyx DID even though application tests assert original ANI, first distinguish a downstream rewrite from the application’s bounded fallback by correlating durable outbound operations. In the exact staging call, inbound ANI was present and distinct from the receiving DID; the original-ANI leg ended unanswered with Telnyx SIP 403/D51, and the receiving-DID fallback leg answered. A fresh configuration read also showed the ordinary-call ANI override remained emergency-only, while the staging LiveKit outbound trunk lacked the outgoing X-Telnyx-Username request header that production had. LiveKit’s Telnyx guide explains that without this first-INVITE connection-selection header, a shared source IP can be associated with another Telnyx connection, which can prevent the active A→B transfer match. Reusable method: inspect per-operation outcomes before changing selection logic; compare outgoing request headers separately from response-header mappings; then make the smallest connection-pinning correction and preserve the safe B fallback. The header is the evidence-backed leading cause here, but an authenticated SIP trace remains the final wire-level proof. Provenance: current staging ledger and sanitized LiveKit/Telnyx reads; Linear COR-3988/COR-3991; https://docs.livekit.io/telephony/start/providers/telnyx/ ; https://developers.telnyx.com/docs/voice/sip-trunking/features/external-transfers .