Hey, AT&T missed-call forwarding recently stopped working with our AI answering service.
Setup: AT&T forwarding → Twilio conference → LiveKit Cloud agent.
Calls connect, but neither side can hear the other. This worked before.
We checked one call’s PCAP: RTP flows both ways, PCMU/8000, both sides sendrecv. The agent greeting shows in the transcript, but no caller speech.
Could this be related to the September 2 carrier codec incident? I know that report only mentioned LiveKit-issued numbers.
Probably not that incident. The status page says the upstream carrier reverted the codec change and calls were normal again as of 21:10 UTC on Sep 2, and it was scoped to LiveKit-issued numbers only, with no other SIP providers affected. The symptom was also one-way (caller not hearing the callee), not silence in both directions. Yours is on Twilio and it is two-way, so it looks like a different problem.
The useful next step with your PCAP is to stop looking at whether RTP flows and start looking at what is inside it. Open it in Wireshark, go to Telephony → RTP → RTP Streams, pick a stream and play it. Packets arriving at the right payload type does not mean the payload contains speech.
If the caller’s stream is silent, the problem is upstream of LiveKit and the Twilio conference is where I would look. If it has real speech but the agent still transcribes nothing, then it is a decode problem on the LiveKit side and worth a support ticket with the PCAP attached.
One quick isolation test: point Twilio straight at your LiveKit SIP URI and skip the conference for a call or two. If audio works, the conference leg is the cause and that narrows it a lot.
FYI the RTP stream does not contain audio in the PCAP you download from the LK cloud dashboard, it’s just the RTP headers.
Agree, after investigation that incident was confined 100% to LiveKit numbers
I’d also be interested in the results of this
If you could provide a call ID, starting SCL_ the team can take a look.
Good to know about the dashboard PCAP, thanks for the correction. That kills the listen-to-the-stream step for the LK capture.
The Twilio side can still give you payload though. Add record="record-from-start" to the <Conference> verb for a test call, with recordingStatusCallbackEvent="in-progress completed absent" so you get told either way.
Two things in Twilio’s docs make this more useful than just having audio to listen to. Recording only begins once the first two participants are bridged, and hold music is never recorded. So if you get the absent callback and no recording at all, the conference never actually bridged, and that is your answer without listening to anything.
Which would point at startConferenceOnEnter. A participant waiting for the conference to start sits there hearing hold music, and their audio does not reach anyone else. From a packet capture that looks exactly like what you described: RTP flowing both ways, correct payload type, and nobody able to hear anyone. Worth checking what that flag is set to on both legs, especially since this used to work.
@Sai_Mandava the SCL_ ID alongside that would give the team both halves.
I don’t think any of that is the issue because unconditional call forwarding works, it’s just conditional call forwarding to my Twilio number.
This has been working for years and it did stop working on Sept 2, the same time the Livekit phone number incident happened. AT&T must have done some change. Is it possible you can connect me with a team mamber who can help me resolve this issue? Twilio is on it too but it’s all slow.
I have confirmed it to be an AT&T/carrier issue. I tried forwarding the call to a google voice number and even an audio recording and the call forwarding is still silent on my end.
Thank you for confirming