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.
VoIP Phone getting it's own public IP
Fortunately my ISP allows several PPP sessions, not sure if intentionally or this is a bug. :)
Instead of connecting my Grandstream to my internal LAN and let it run over the NAT router, I connected it the DSL modem, e.g. the PPPoE interface. Sometimes DSL modem and router are in the same box, in the case the PPPoE interface is not available and this solution can not be applied. In my home network, I use a separate NAT router (WRT54GL) an the interconnection between the DSL modem and the WAN port of the WRT runs through a switch. This is the PPPoE reference point.
The Grandstream is connected to the PPPoE reference point and needs to get the same PPP credentials configured as the NAT router. Fortunately this phone supports PPPoE. Now the the Grandstream starts a second PPP session, in addition to the one of my WRT router proving all the rest of my Internet connectivity.
The outcome is that the Grandstream gets its own public IP address. I could disable all NAT traversal tricks, the registrations are fast and reliable. Especially one account which did not work satisfactorily before, works now without any problem!
Conclusions
I am quite happy with the new configuration. Some concerns remain:
- I am not sure if multiple PPP sessions are wanted by my ISP. Protocol analysis showed that the first PPP authentication requests by my Grandstream were with NACK and "max PPP sessions exceeded". But after some attempts, the PPP establishment was successful. Just now I also could not reproduce the initial failure.
A second PPP session does not give me more bandwidth, it still shares the same physical link, and my subscribed BW is configured to the DSL modem connection speed as determined by the Access Concentrator. Negative impact for the ISP here is that another of the scarce IP addresses is consumed plus one more concurrent PPP session, increasing AC and RADIUS load. - Now one of my devices is directly exposed to the Internet, without the protecting NAT in between. A bit disturbing is that there is one open Telnet port on the Grandstream, which I can not disable and I don't know what it is good for. Of course the admin web interface needs now a more secure password than "admin" as it is also exposed to the public.
On the other that's what IPv6 is meant for: Giving each and every device a public IP address and avoiding all the NAT workarounds. Obviously we will need a good firewall in future as the "natural" NAT, acting as kind of firewall, disappears.
I think exposing my IP phone to the Internet is a small risk. - Having my IP phone using a separate PPP connection makes it impossible to a apply any kind of QoS to prioritize VoIP packages over the other uplink traffic. This is an option if a common router is being used. Nevertheless, such congestion has rarely been a problem. With reasonable DSL uplink speeds, the VoIP traffic uses only a tiny fraction of this and I don' expect QoS to become a problem.