Draw signaling and media as separate paths
SIP signaling can remain anchored on FreeSWITCH while RTP uses a different topology. Draw the a-leg and b-leg addresses from the accepted SDP, the observed packet sources and destinations, and the component that owns NAT translation. Do not infer RTP flow from dialog state.
A call can answer with silent, one-way or misdirected media, so answer and audio require separate evidence.
Choose full, proxy or bypass media for the workload
In the normal media path FreeSWITCH terminates and processes RTP. Proxy-media arrangements keep RTP flowing through the server with less media interpretation, while bypass media instructs endpoints to exchange RTP directly and leaves signaling on FreeSWITCH. Bypass therefore requires the endpoints to reach one another.
Recording, conferencing, media bugs, transcoding, DTMF handling and NAT assistance can change which mode is suitable. State the needed features before optimizing the path.
Negotiate codecs on each leg
FreeSWITCH negotiates each call leg using its applicable codec preferences and the remote offer. A common codec can permit media to pass without transcoding; different negotiated codecs can require the relevant modules and processing. A codec listed in documentation or configuration does not prove that the module loaded or that either leg selected it.
Retain each SDP offer and answer, selected codec, clock rate, packetization and direction instead of reporting one call-wide codec label.
Resolve advertised and observed addresses
Profile rtp-ip and ext-rtp-ip values, NAT discovery and far-end Contact or SDP rewriting influence the addresses advertised. Current documentation warns that auto-nat depends on a compatible local NAT-PMP or UPnP gateway and is unsuitable for many cloud or enterprise environments.
Compare configuration with the actual SDP and packet capture. Changing firewall policy, advertised addresses and media mode together destroys the evidence needed to locate the fault.
Keep media security leg specific
Each leg can negotiate a different transport and security mode. A protected browser or endpoint leg does not prove the provider leg uses SRTP, and a certificate does not prove an accepted crypto suite or received packets. Record the SDP crypto or DTLS attributes, handshake evidence and packet protection for each leg.
Do not downgrade security merely to make audio appear; isolate certificate, signaling, keying and RTP reachability failures.
Test required features and failure behavior
For the intended topology, verify two-way speech, DTMF, hold, music, recording, transfer and conferencing as applicable, then test one unreachable-media or codec-mismatch case. Correlate FreeSWITCH UUIDs with endpoint and packet evidence and restore temporary tracing.
One successful call is not a capacity or quality benchmark. No media path or call was tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- FreeSWITCH introduction and core concepts ↗
- FreeSWITCH codecs and negotiation ↗
- FreeSWITCH codec reference table ↗
- FreeSWITCH media handling ↗
- FreeSWITCH no-audio and one-way-audio troubleshooting ↗
- FreeSWITCH SIP trace and CDR reading ↗
- FreeSWITCH SIP profiles with Sofia ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.