Basic VoIP Configuration

In an ideal world our customers don’t need to know any of this! just choose one of our plans, receive your phones, plug them in and that’s it, you are now on RubixVoice’s cutting-edge redundant VoIP network. For those that want more information, we decided to write this article. Here we are going over the basic VoIP SIP phone.

SIP means “Session Initiating Protocol” and is an addressing, authentication, and switching method to establish data connections on the Internet. It is based on the Internet Protocol. However, when the SIP procedure was designed, the NAT packet filters were not considered (NAT = Network Address Translation). 

Today, and even though we have our preference of using FortiGate Next-Generation Firewall (NGFW), almost all commercially available routers and firewalls work with NAT packet filters. SIP devices transmit their IP addresses within the SIP data packets, and if the SIP phone is behind a router with a NAT packet filter, these are private IP addresses, RFC1918, for our technical readers! that are invalid on the Internet. In addition, with SIP, multiple ports and different ports in each direction of the connection are generally used to establish the connection and for each voice transmission. Unlike, for example, the IAX (Inter-Asterisk) protocol, which efficiently makes do with one port for all signaling and voice transmissions.

How to put a SIP phone into operation to make it work?

It is best to configure the basic VoIP SIP phone first without any “NAT”, “STUN”, “keep-alive” or “outbound proxy” options. If a public IP address is used, or if you are behind a router with a NAT packet filter that also rewrites the SIP and RTP packets, the SIP phone will immediately have an internationally reachable SIP address and everything will work. If your SIP phone registers with a SIP registrar, you can dial phone numbers through it. (The SIP registrar authenticates it and transfers the call according to the phone number to other SIP addresses or a SIP to the landline gateway of a phone company).

Independent of a SIP registrar, they can call any other SIP address from their SIP address. As long as they are registered at a SIP registrar they can be reached via this registrar. In some circumstances not only via their registration number at this SIP registrar but also via a regular landline number, which is switched to the SIP registrar by a telephone company. Registering your SIP phone with a SIP registrar is especially advantageous if you operate your SIP phone at different locations or if your IP address changes from time to time, e.g. + with dial-up connections (modem, ISDN, DSL). Then you can always be reached via the SIP registrar.

Testing of basic VoIP SIP Functions

At least as long as you also get a working SIP address behind a NAT router. At least the following should be tested (as we do during our on-boarding process):

• outgoing call to a landline number (via the gateways to which the SIP registrar switches)
• incoming call from a landline (via the gateways of the SIP registrar)
• outgoing call to another SIP phone (which is not behind the same router)
• incoming call from another SIP phone
• once right after the SIP phone has registered with the SIP registrar and then just before the registration has to be renewed – if possible choose a period of time when the IP address does not change (T-DSL forced disconnection)

SIP configuration

If your NAT router is not able to implement SIP/RTP connections automatically even with the latest updates, you can try to configure the SIP phone or a SIP registrar in such a way that the SIP phone remains reachable behind the NAT router, or you can manually configure a fixed forwarding at the NAT router. If you do not know what kind of NAT configuration the SIP phone is behind, the SIP phone can determine this itself using a STUN server.

Behind some NAT routers, the SP IP Phone itself can establish its certain reachability by periodically sending packets out. However, this dynamic keeping of ports open only helps with those NAT routers that periodically forward packets from different IP:port combinations to the private network in response to an outgoing packet. (You should probably replace or update such devices for security reasons).

With NAT packet filters that let more in than out (asymmetric NAT), it may be sufficient for certain reachability with “symmetric RTP” if the SIP VoIP phone writes the externally used address into the SIP packets instead of its own address from the private network. The addresses to which the NAT router converts the outgoing packets can be obtained by the SIP phone from the STUN server, but they are also written into the response packets by many SIP registrars as “VIA received” information. (Since the VIA received information is updated with every regular packet from the SIP registrar, IP address changes (DSL forced disconnection) may be detected faster than with STUN queries, which some SIP phones perform only once after power-on).

Scalability

But no matter how the basic VoIP SIP phone learns of its external address, if the NAT packet filter is doing its job properly, this address is only reachable from certain IP: port combinations. STUN should be able to detect and report this situation, and the rewriting of addresses in the SIP packets and the keep alive should also be automatically omitted by the SIP phone if there is no NAT. If you know that you are behind a proper symmetric NAT packet filter (e.g. behind one of our FortiGate firewalls) you don’t even need to activate the STUN procedure. (For Linux routers there is SIP NAT support or “connection tracking” and also SIP/RTP outbound proxy programs that can run on the router).

A more centralized “solution” is to run all connections not only through a SIP exchange server (registrar) but also mandatory through an (outbound) RTP proxy server of a provider (to build in real detours). If a connection is constantly kept open between these SIP and RTP servers and the SIP phone, the SIP phone can be reached via these servers. But basically, you are not reachable from everywhere and you are not independent of the provider. So what you need with proper symmetric NAT packet filters is either SIP support that automatically opens ports for RTP packets from addresses that are currently being connected to via SIP, or a static forwarding of the ports that your SIP phone uses for SIP and RTP communication.

What a SIP NAT trace graph looks like.