My FreeSWITCH Server Is Behind NAT — Which SIP and RTP Addresses Should I Configure?
Understand sip-ip, ext-sip-ip, rtp-ip and ext-rtp-ip, then test LAN and Internet calling without guessing which address FreeSWITCH should advertise.
FreeSWITCH learning series · Part 15 of 30
Understand sip-ip, ext-sip-ip, rtp-ip and ext-rtp-ip, then test LAN and Internet calling without guessing which address FreeSWITCH should advertise.
What this question really means in a working FreeSWITCH system
FreeSWITCH has local bind addresses and externally advertised addresses because those solve different problems. sip-ip/rtp-ip are where the host listens; ext-sip-ip/ext-rtp-ip are what remote peers may need to see. If those values are wrong, Contact/Via or SDP can advertise unroutable private addresses. Test signaling and media independently, and do not let SIP ALG silently rewrite a path you are trying to reason about.
Start with the mental model
For NAT, FreeSWITCH needs to know two truths: the local address it binds to and the address external peers can actually reach. SIP signaling and RTP media each have their own advertised address settings.
| Setting | Question it answers | Common mistake |
|---|---|---|
sip-ip | Where does this profile listen locally? | Putting public IP on a private interface |
ext-sip-ip | What signaling address should remote peers see? | Leaving stale public IP |
rtp-ip | Which local address handles media? | Binding wrong NIC |
ext-rtp-ip | What media address should remote peers send to? | Advertising RFC1918 address externally |
Work through it from zero
Write down LAN IP, public IP, router/NAT role, carrier/endpoint locations and whether public IP is static.
sip-ip and rtp-ip describe local interfaces/addresses FreeSWITCH uses.
ext-sip-ip and ext-rtp-ip help FreeSWITCH place reachable public addresses in SIP/SDP where appropriate.
Map the SIP listener(s) and configured RTP range, not every UDP port.
Consumer routers often rewrite SIP inconsistently; prove whether ALG helps or harms instead of assuming.
LAN success and Internet success exercise different paths.
What beginners usually confuse
- Confusing SIP port forwarding with RTP port forwarding.
- Using “auto” discovery in a fixed enterprise design without verifying the resolved value.
- Testing only with devices on the same NAT.
How to know you are actually finished
- Prefer explicit, documented addresses on appliances with known network design.
- Monitor public-IP changes if they can occur.
- Keep telephony routes separate from Internet/default-route changes.
How to use this in a real implementation
For this FreeSWITCH task, use a bounded test built around this objective: understand sip-ip, ext-sip-ip, rtp-ip and ext-rtp-ip, then test lan and internet calling without guessing which…. 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 Identify network topology 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 understand sip-ip, ext-sip-ip, rtp-ip and ext-rtp-ip, then test lan and internet calling without guessing which…. 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 identify network topology 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 understand sip-ip, ext-sip-ip, rtp-ip and ext-rtp-ip, then test lan and internet calling without guessing which…, 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 understand sip-ip, ext-sip-ip, rtp-ip and ext-rtp-ip, then test lan and internet calling without guessing which…, 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 My FreeSWITCH Server Is Behind Nat Which Sip And Rtp Addresses Should I Configure 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.