La Inflación en el Segundo Trimestre de 2017

Network Address Translation (NAT) is a feature used by most networks to save Internet IP addresses. Usually, a company receives a small block if IP addresses and end users receive one IP address dynamically when

connected to the Internet. NAT solves the addressing problem by mapping internal addresses to external addresses. It keeps in the memory a mapping of internal to external addresses. This mapping is valid for a specific length of time after which the mapping is discarded. The mapping uses IP:port pairs for the internal and external addresses.

There are four kinds of NAT:

•

•

•

•

7.5.1 Full Cone

The first NAT, “Full Cone”, represents a static mapping from an external IP:port pair to an internal IP:port pair. Any external computer can connect to it using the external IP:port pair. This is the case in non-stateful firewalls implemented with the use of filters.

7.5 SIP NAT Traversal | 188

Figure 7.12 NAT Full Cone

7.5.2 Restricted Cone

In the restricted cone scenario, the external ip:port pair is opened only when the internal computer sends data to an outside address. However, the

restricted cone NAT blocks any incoming packets from a different address. In other words, the internal computer has to send data to an external computer before it can send data back.

7.5.3 Port Restricted Cone

The port restricted cone firewall is almost identical to the restricted cone. The only difference is that, now, the incoming packet has to come from exactly the same IP and port of the sent packet.

Figure 7.13 NAT Symmetric

The last type of Nat is called symmetric. It is different from the first three in that a specific mapping is done to each external address. Only specific

external addresses are allowed to come back by the NAT mapping. It is not possible to predict the external IP:port pair that will be used by the NAT device. With the other three types of NAT, it was possible to use an external server to discover the external IP address to use for communication. With symmetric Nat, even if you can connect to an external server, the discovered address cannot be used for any other device except for this server.

7.5.5 NAT firewall table

Need to send data before receiving

It is possible to determine the IP:port pair for returning packets

It restricts the incoming packets to the destination IP:port

Full Cone No Yes No

Restricted Cone Yes Yes Only IP

Port Restricted Cone Yes Yes Yes

Symmetric Yes No Yes

7.5.6 SIP signaling and RTP over NAT

Some of the biggest issues in NAT traversal are that you have to solve two problems. The first one is SIP signaling and the second one is audio (RTP). Most problems of one-way audio are NAT related.

7.5 SIP NAT Traversal | 190

An interesting thing about SIP is that when an UAC sends a packet, it embeds the IP address in the SIP “Contact” header field. Usually this is an internal (RFC1918) address and responses to this packet cannot be routed over the internet back to the UAC. When you put the statement “nat=yes” in the sip.conf file you are telling Asterisk to ignore the address contained in the “Contact” header field of the SIP header and use the source IP address and port in the packet’s IP header.

nat=yes

Now, it is necessary to keep the NAT mapping open. If NAT times out, Asterisk could not send an invite to the UAC. The UAC could send calls but could not receive. We can use the statement below to keep NAT open.

qualify=yes

Qualify will send a SIP packet using the OPTIONS method regularly. This will help to keep NAT open.

Even with SIP signaling resolved, now we have a challenge to pass RTP from one phone to another. If the user’s NAT is of the symmetric type, it is not possible to send packets from one UAC to another directly. In this case, we have to force the RTP thru Asterisk using:

Qualify sends an OPTION each 60 seconds and every 10th second when the host is not reachable. You can use “sip show peers” to see the latency for the peers.

canreinvite=no

These configurations are appropriate for most cases. However, it is possible to optimize the traffic using advanced techniques like STUN (Simple

Traversal of UDP over Nat), which is useful with full cone, restricted cone, port restricted cone, and ALG (Application Layer Gateway). Using these techniques, you do not need to do anything in Asterisk for Nat traversal. Sorry to say but, most firewalls today, even home DSL/Cable routers, are symmetric, making STUN unusable. ALG could solve the problem but it is not supported, not implemented, or buggy in most cases.

7.5.7 Asterisk behind NAT

Asterisk behind NAT

192.168.1.100 Asterisk 200.180.4.168 SIP (UDP 5060) RTP (UDP 10000->20000) defined in rtp.conf

Figure 7.14 Asterisk behind NAT

All scenarios above assume that the Asterisk server have an external (valid) Internet address. Sometimes the Asterisk server is implemented behind a Firewall with NAT. In this case, it is necessary to do some extra

configurations.

Step 1: Configure the firewall to redirect statically the UDP port 5060 to the Asterisk server.

Step 2: Configure the firewall to redirect statically the UDP ports from

10000 to 20000. If you want to restrict the number of opened ports, you can edit the rtp.conf file to change the rtp port range. Another way is to use an intelligent firewall that supports the SIP protocol to open dynamically the RTP ports.

; RTP Configuration ;

[general] ;

; RTP start and RTP end configure start and end addresses ;

rtpstart=10000 rtpend=20000