One-way audio on a Twilio voice call means the RTP (Real-Time Protocol) media stream is flowing in one direction but not the other: the signaling layer (SIP) completed successfully (the call connected), but the media path is asymmetric. This is a network-layer problem that occurs in the RTP transport path between the two endpoints, not in Twilio's signaling infrastructure. The cause is almost always a NAT traversal failure, a firewall rule that blocks RTP in one direction, or an SDP (Session Description Protocol) address mismatch.
Why One-Way Audio Happens
NAT (Network Address Translation) creates one-way audio when a SIP endpoint behind a NAT device advertises its private IP address in the SDP media description (the c= contact line and the m= media line's IP): Twilio (or the remote party) sends RTP to the private IP address, which is unreachable from outside the NAT, so audio flows only from Twilio to the endpoint (which knows Twilio's public IP from the received SDP) while audio from the endpoint to Twilio never arrives because Twilio cannot reach the private IP. A firewall that allows outbound UDP traffic (so the endpoint can send audio to Twilio) but blocks unsolicited inbound UDP traffic (so Twilio's audio to the endpoint is dropped) produces the opposite: Twilio receives the endpoint's audio but the endpoint cannot receive Twilio's audio. An SBC (Session Border Controller) or PBX that performs SDP manipulation and changes the media IP address to an incorrect value (for example, replacing the correct public IP with a loopback address or with an IP on the wrong network interface) causes one-way or no audio by directing media to an unreachable address. Asymmetric codec negotiation, where the two endpoints agree on different codecs for each direction of the call due to a bug in the SDP offer/answer process, also produces one-way audio (one direction uses a supported codec, the other uses an unsupported one that is silently discarded).
How to Diagnose One-Way Audio
Enable Twilio's Call Insights for the affected call by navigating to Console, then Monitor, then Insights, then Voice and clicking on the specific Call SID: the Insights view shows RTCP (RTP Control Protocol) statistics including packet counts for both directions of the media stream, which tells you immediately whether packets are flowing in both directions or only one. In the Call Insights RTCP view, look at the packets-sent and packets-received counts for each leg of the call: if Twilio sent 1,000 packets to your endpoint but received 0 from it, your endpoint's outbound audio is being blocked or misrouted; if Twilio sent 0 packets to your endpoint but received 1,000 from it, the inbound path to your endpoint is broken. Capture SIP messages during a failing call using your PBX or SBC's SIP trace function and examine the SDP offer and answer exchange: compare the IP address in the c= line of your endpoint's SDP with its actual public IP address, which you can find by checking what IP your PBX appears as from the internet (using a service like whatismyip). Check your PBX's NAT settings: most PBX platforms have a NAT configuration section where you specify the public IP address to use in SDP, and either the wrong public IP or a missing NAT configuration causes private IP addresses to leak into SDP.
How to Fix One-Way Audio
For NAT traversal issues on a PBX or SBC, configure the correct public IP address in the NAT settings: in FreePBX this is under Settings, then Asterisk SIP Settings, then External IP; in 3CX this is under Settings, then Network; in Asterisk it is the externip or externaddr setting in sip.conf or pjsip.conf. For firewalls blocking inbound RTP, open the RTP port range (typically 10,000 to 20,000 UDP for most PBX systems, confirm with your PBX documentation) for inbound traffic from Twilio's media IP ranges, which are published in Twilio's documentation under the Voice IP addresses section. For SBC-side SDP manipulation issues, review the SBC's SDP transformation rules and disable any rule that modifies the c= line media IP address: the SBC should pass through the PBX's correctly natted public IP without additional modification. Enable STUN (Session Traversal Utilities for NAT) on your PBX if NAT configuration is complex or changes frequently: STUN allows the PBX to dynamically discover its public IP and insert it correctly into SDP, eliminating manual IP configuration and ensuring SDP always contains the correct current public IP.
When to Call a Specialist
If the Call Insights RTCP data shows packets flowing in both directions but callers still report one-way audio, the issue may be at the codec layer rather than the network layer: both endpoints are sending packets but one is sending a codec the other cannot decode, producing silence on one side despite active packet flow. A specialist can analyze the SDP offer and answer from the SIP trace and identify whether a codec mismatch exists and configure the PBX to prefer a mutually supported codec. For enterprise SBC deployments with complex topology (PBX behind SBC behind firewall behind NAT), diagnosing one-way audio requires packet capture at multiple points in the network path to identify exactly where the media stream breaks: a specialist has the tools and experience to conduct this multi-point capture efficiently. You should also escalate when one-way audio affects only calls to specific geographic regions or carrier destinations but not others, as this pattern suggests a carrier-side media path issue rather than a local NAT or firewall problem.
Conclusion
One-way audio is a media path problem caused by NAT traversal failure, firewall asymmetry, or SDP address misconfiguration: diagnosing it requires RTCP packet count data from Call Insights and SIP trace analysis to identify the broken direction and its cause. If one-way audio is affecting your production calls, contact our team and we will diagnose and fix the media path issue within the hour.
Ready to Transform Your Business Communications?
Get a free consultation with our VoIP experts and discover how we can help you save costs, improve efficiency, and scale your business.
Comments (0)
Join the discussion and share your thoughts (AI-moderated for quality)
Be the first to comment
No comments yet. Share your thoughts below.