The Call Connects but Nobody Can Hear Anything — How Do I Debug FreeSWITCH Audio?
Separate SIP signaling from RTP media and diagnose one-way or no-audio calls using SDP addresses, RTP ports, codecs, NAT evidence and packet captures.
FreeSWITCH learning series · Part 13 of 30
Separate SIP signaling from RTP media and diagnose one-way or no-audio calls using SDP addresses, RTP ports, codecs, NAT evidence and packet captures.
What this question really means in a working FreeSWITCH system
If SIP establishes a call but audio is absent, stop debugging the dialplan and inspect SDP/RTP. Compare the IP/port each side advertised with the address packets actually use. One-way audio often means only one direction is routable. Codec negotiation can also produce a connected call with unusable media when transcoding assumptions are wrong. A packet capture is evidence; ‘the firewall looks open’ is not.
Start with the mental model
SIP establishes the conversation; RTP carries most of the audio. A call can be perfectly established while the SDP points media at an unreachable address or a firewall blocks the negotiated ports.
| Symptom | Likely evidence | Do not assume |
|---|---|---|
| No audio both ways | No RTP / wrong SDP / blocked range | That SIP is broken |
| One-way audio | One advertised address/path is wrong | That codecs are always the cause |
| Robotic/choppy audio | Loss/jitter/CPU/transcode/ptime | That bandwidth alone explains it |
| Audio starts then stops | NAT timeout/session/media policy | That registration failed |
Work through it from zero
Do not debug RTP until SIP has produced a connected call on both legs.
Record the connection address, media port, codec list and selected codec.
For one-way audio, identify which direction is missing and follow only that RTP path first.
Confirm advertised addresses are reachable and the configured RTP range is allowed in both directions.
A common codec must exist or FreeSWITCH must transcode; CPU and licensing may matter for some codecs.
A short authorized capture can prove whether packets enter/leave each interface.
What beginners usually confuse
- Opening all UDP ports instead of the configured RTP range.
- Changing codec order before proving packets are flowing.
- Ignoring that A-leg and B-leg can advertise different networks.
How to know you are actually finished
- Draw both media directions.
- Monitor packet loss and jitter under load.
- Avoid unnecessary transcoding when end-to-end codec compatibility exists.
How to use this in a real implementation
For this FreeSWITCH task, use a bounded test built around this objective: separate sip signaling from rtp media and diagnose one-way or no-audio calls using sdp addresses, rtp ports, cod…. Observe one state change at a time, save the evidence, and only then move to the next layer.
- Capture the exact runtime evidence related to Confirm the call answered before changing the next layer.
- Keep a known-good test number/endpoint and repeat the same call after each configuration change.
- Record SIP response codes, context/destination decisions and media observations separately; they answer different questions.
- If you cannot explain which file/module owns the behavior, stop and locate that ownership before editing more configuration.
Continue from here
After this article: use the next link that matches the unresolved part of separate sip signaling from rtp media and diagnose one-way or no-audio calls using sdp addresses, rtp ports, cod…. Start the FreeSWITCH learning series · Use the SIP → dialplan → RTP troubleshooting ladder · Continue into real-time AI media streaming
Questions a careful reader usually asks next
Should I change several FreeSWITCH files at once?
Not while learning or troubleshooting. Prove confirm the call answered first, then change one layer and repeat the same test so you know what caused the new behavior.
Is a successful CLI command enough proof?
No. For separate sip signaling from rtp media and diagnose one-way or no-audio calls using sdp addresses, rtp ports, cod…, confirm the live SIP, dialplan or media behavior that the command was intended to affect. A parser or CLI success only proves the command was accepted, not that the call path now behaves correctly.
Where should business logic live?
For separate sip signaling from rtp media and diagnose one-way or no-audio calls using sdp addresses, rtp ports, cod…, keep low-level signaling/media truth in FreeSWITCH, while customer, campaign and business state stays in the application layer unless the telephony engine genuinely needs it for call execution.
References and further reading
Protocol and configuration facts for The Call Connects But Nobody Can Hear Anything How Do I Debug FreeSWITCH Audio are grounded in the current FreeSWITCH Users Manual and, where Asterisk is compared, Asterisk's official documentation. Community tutorials are included only as credited learning aids.
- FreeSWITCH Users Manual — authoritative project documentation for the FreeSWITCH behavior/configuration referenced above.
- FreeSWITCH Getting Started — authoritative project documentation for the FreeSWITCH behavior/configuration referenced above.
- FreeSWITCH — SIP Profiles with Sofia — authoritative project documentation for the FreeSWITCH behavior/configuration referenced above.
Want to see API-driven CRM + Telecom workflows in action? Try the WhatsApp bot or explore the demos.
Comments (0)
Be the first to comment.