SBC Manager — NAT Traversal and Media Handling
The NAT Problem in VoIP
NAT breaks SIP because SIP messages embed private IP addresses in headers (Via, Contact, SDP). When a device behind a router signals its private IP (192.168.1.10), the far side can't send RTP media back to that address — the classic cause of one-way or no audio.
How the SBC Solves NAT
- SIP header rewriting — the SBC rewrites Contact/Via to the observed public IP and its own addresses, so internal topology is completely hidden from carriers.
- RTP anchoring — media streams are anchored through the SBC, which rewrites the SDP media address to its own SIP IP. Media can always be delivered regardless of the NAT environment on either side.
- Symmetric RTP — the SBC detects the actual source port of the far end's RTP stream (which may differ from what was signaled due to NAT) and adjusts dynamically, resolving one-way audio.
On dual-NIC appliances, make sure the SIP IP under Settings → Network is the public address carriers should see — it is the address used in rewritten signaling and anchored media.
Media Profiles and Codecs
Codec policy is managed per trunk (ordered codec list on the trunk form) and via Provision → Media Profiles for reusable media settings. Keep the codec list on each trunk limited to what the peer actually supports, in your order of preference — a common interop baseline is ulaw first for NANPA carriers.
When the two legs of a call cannot agree on a codec, Asterisk transcodes in real time. Transcoding adds a small amount of latency and consumes CPU proportional to concurrent transcoded calls, so prefer matching codec lists end-to-end where possible.
DTMF
Use RFC 4733 (rtp telephone-event) DTMF wherever supported. In-band DTMF does not survive transcoding to compressed codecs.
Troubleshooting Audio
- One-way audio — almost always NAT/firewall: confirm the RTP port range is permitted from the carrier under Settings → Firewall, and the SIP IP is set correctly.
- No audio — run Diagnostics → Packet Capture on the SIP interface and confirm RTP is arriving; check the SDP addresses in the capture.
- Poor quality — check jitter/loss on the capture and confirm the expected codec was negotiated (visible in the SDP).