Getting Rid of SIP NAT Problems
The Problem
SIP Endpoints in a consumer environment are often behind a NATted DSL router. This means they use a private IP address and mechanisms to allow SIP signaling and the voice data’s separate RTP data stream to cross the NAT router and use the outside public IP address are needed.
There are a couple of mechanisms:
- Client side (with server support): STUN, ICE
- Server side: SBCs
- NAT router: SIP ALGs
- SIP addition: rport (RFC 3581)
- Have the SIP client integrated to the NAT router and expose all necessary ports on the single common public IP address (does not allow UA flexibility)
I have a Grandstream GXP-2020 in use, which supports 6 SIP accounts. Why would need one so many SIP accounts? As long as not all subscribers are reachable by SIP and all those networks are interconnected, we still need PSTN break-outs and ideally those are as close as possible to the PSTN POP. Furthermore there are private SIP networks, which can not be reached from outside (or only via PSTN). For this reason its useful to have a couple of SIP lines at hand, to be used depending on the destination, and to allow easy and cheap reachable from everywhere as well.
I have a German and a Thai SIP account, providing me local PSTN numbers of both countries and accordingly local tariffs and reachability.
Unfortunately many of the commercial SIP providers try to keep their garden walled and therefore outgoing and/or incoming SIP traffic is blocked (SIP can be used only from the SIP endpoint to the SIP provider). Thats why I have another line which provides pure SIP services, without any PSTN gateway, to allow free incoming and outgoing SIP calls.
The forth line finally is registered to my employers SIP PBX.
All of those SIP accounts need to have different NAT traversal methods in place. Some work well, some are not so reliable. Everything is configurable on the phone, sometimes port forwarding on the NAT router is needed. All together, some admin work and testing is necessary for each new SIP account.
The Solution
Of course the best would be to have an own public IP address for the IP phone to let us forget all those NAT traversal problems and workarounds. And this is what I did.
