Critical escalation! AI bot loops ignoring details. This is blocking production deployment for an assisted living facility – residents can't reliably transfer calls to staff/emergency. Safety-critical! Setup: Telnyx BYOC, +13177401923, TCP configured ("transport": "TCP" in API). Problem: All warm/cold transfers instant dial_busy (0ms) – no dialing occurs. Root Cause (Telnyx Engineers Confirmed): Telnyx sends TCP INVITE ✅ Retell Record-Route forces transport=udp ❌ In-dialog messages switch to UDP → transfers fail Logs: "x-lk-transport": "udp" despite TCP config Telnyx Trace: textRecord-Route: Via: SIP/2.0/TCP 192.76.120.10 Telnyx: "We're sending TCP correctly. Retell's Record-Route is forcing UDP." Contradiction: Docs state UDP unsupported for Telnyx BYOC, yet Retell forces it. Verified: TCP config/API correct E.164 formatting Propagation wait Both transfer types fail Sample Calls: Inbound: call_e1855e206be2f3dd4e42cfb68b9 Transfer: call_e4d6ef0c599ab736f4310c97 (dial_busy) Questions: Why UDP in Record-Route when TCP configured? Separate setting for Record-Route transport? Known Telnyx TCP incompatibility? Workaround or fix ETA? Willing to share full SIP traces/packet captures or debug live. Please escalate ASAP – lives depend on reliable transfers! 🙏 🚨 Also: I attached the GET requests to the Retell.ai API using curl https://cdn.discordapp.com/attachments/1459005249145540652/1459005249351323901/curl_get_requests.txt?ex=69796f06&is=69781d86&hm=b17678c62d4700daa56e37a07c125ebeca9d76be4f5316db71ee8332c6fe79a5&

The issue is clear: Retell is forcing UDP in the Record-Route header even though you've configured TCP, which breaks mid-dialog messages (like transfers) with Telnyx. The core problem: Retell's SIP proxy isn't respecting your TCP transport configuration for in-dialog routing, despite TCP being required for Telnyx BYOC. Quick question: Are you using Retell's managed SIP infrastructure, or do you have any custom SIP proxy/routing between Telnyx and Retell? This will help determine if there's a configuration workaround or if Retell needs to fix their Record-Route header handling on their end.

Ok I will share it with the team to fix this issue.

Thanks for escalating this to the team on Jan 9th, appreciate you passing it along! Just checking in for any update/ETA on the BYOC TCP/UDP issue (Retell forcing transport=udp in Record-Route despite TCP config → instant dial_busy on all transfers, Telnyx confirmed Retell-side). Still blocking production rollout for an assisted living facility project to improve resident care quality. Call IDs for reference: inbound call_e1855e206be2f3dd4e42cfb68b9 / transfer call_e4d6ef0c599ab736f4310c97 Happy to share more SIP traces, packet captures, or debug live if needed. Any progress from engineering? Thanks again!