BUPT Niki 's space

Youth is limited, wisdom is infinite, use short youth to learn infinite wisdom

2011-03-01 11:14

[Transfer] NAT configuration of asterisk

http://www.asteriskguru.com/tutorials/sip_nat_oneway_or_no_audio_asterisk.html

This article has said everything that should be said, as much as you can understand!

1. sip.conf:

Externip: Configure your public network address in the [general] context attribute, so that when sending a sip message, this address will be used to replace the host address in the message header, and the peer will send a response message to this address after parsing the message.

Nat: This attribute determines how asterisk handles user connections. Personal understanding is to configure the way astersik handles received messages.

a） nat=route

Asterisk obtains the destination address from the received rtp packet, and sends the rtp packet to this address instead of the per-media address negotiated in SDP.

b） nat=no

In the default configuration, according to rfc3581, asterisk will add the rport and received fields to the via field as the reply acceptance address.

http://hi.baidu.com/caoyaping/blog/item/18f15c6e724e6fd781cb4ad8.html

c） nat=never

Asterisk does not add rport to the via domain, nor will it handle it in the way of route. ?

d） nat=yes

========================================= Turn to an article about nat, the original address cannot be played Open ===============

STUN is a NAT penetration method stipulated in RFC3489 . It uses an auxiliary method to detect the IP and port of NAT . There is no doubt that it played a huge role in traversing early NATs and will continue to have a place in ANT penetration.

The STUN detection process requires a STUN server with a public network IP. The UAC behind the NAT must cooperate with this server and send several UDP data packets to each other. The UDP packet contains information that UAC needs to know, such as NAT external network IP, PORT and so on. UAC judges its own NAT type by whether it gets the UDP packet and the data in the packet .

Assume there are UAC (B), NAT (A), and SERVER (C), the IP of UAC is IPB, the IP of NAT is IPA, and the IP of SERVER is IPC1 and IPC2. Please note that server C has two IPs, and you will understand why two IPs are needed later.

(1) NAT detection process:

STEP1: B sends a UDP packet to the pot1 port of C's IP1. After C receives this packet, it will write the source IP and port of the received packet into the UDP packet, and then send the packet back to B through IP1 and port1. This IP and port are also the external network IP and port of NAT (if you do not understand, then please read the principle and classification of NAT in my BLOG ), that is to say, you have obtained the external network of NAT in STEP1 IP.

Friends who are familiar with the working principle of NAT can know that B must receive the UDP packet returned by C to B (if you don't know, read my other articles). If in your application, after sending a packet to a STUN server, you do not receive any response packet from STUN, there are only two possibilities: 1. The STUN server does not exist, or you got the wrong port. 2. Your NAT rejects all UDP packets passing from the outside to the inside (this is our company's NAT ).

When B receives this UDP, he compares the IP in this UDP with his own IP. If they are the same, it means that he is on the public network. The next step is NAT to detect the firewall type. I don’t want to say more . If they are not the same, it means that there is NAT , and the system performs STEP2 operation.

STEP2: B sends a UDP packet to IP1 of C, and requests C to return a UDP packet to B through another IP2 and PORT (different from IP1 of SETP1) (Now I know why C has two IPs, although it is not yet understand why, hehe).

Let's analyze it, if B receives this data packet, what does it mean? It means that NAT does not reject any incoming packets, and does not filter any data packets. This is the full cone NAT in the STUN standard . Unfortunately, there are too few full cone nats , which also means that it is unlikely that you will receive this packet. If not received, then the system performs STEP3 operation.

STEP3: B sends a data packet to port2 of IP2 of C. After receiving the data packet, C writes the source IP and port of the received packet into the UDP packet, and then sends the packet back to b.

Same as step1, B can definitely receive this response UDP packet. The port in this package is the data we are most concerned about, let's analyze it below:

If the port is the same as the port in step1, then you can be sure that this NAT is a CONE NAT , otherwise it is a symmetric NAT . The reason is simple: according to the rules of symmetric NAT , when any of the IP and port of the destination address changes, then NAT will reassign a port to use, and in step3, corresponding to step1, we changed the IP and port. Therefore, if it is a symmetric NAT , the two ports must be different.

If in your application, the PORT is different at this point, congratulations, your STUN is dead. If they are different, only the restrict cone and port restrict cone remain. The system uses step4 to detect the type.

STEP4: B sends a data request packet to a port PD of C's IP2, asking C to return a data packet to B with IP2 and a port different from PD.

Let's analyze the result: if B receives it, it means that as long as the IP is the same, even if the port is different, NAT allows the UDP packet to pass. Obviously this is restrict cone NAT . If not received, nothing else to say, port restrict NAT .

(2) How does SIP use STUN

Personally, I think this is a question that is not worth asking, but many people ask me, so I will mention it briefly. In fact, this is a very simple problem. SIP obtains the external network IP of NAT and the external network port of the SIP signaling monitoring port through STUN, replaces the IP and port in the contact header in the SIP registration packet, and then registers . This ensures that the registrar can find you when someone calls you. What I need to remind you is that if NAT finds that a connection has no activity for a period of time, it will close the mapping, so you must send a data packet out at an interval to keep alive.

In addition, when you want to establish RTP communication with others, don't forget to change the IP and PORT in your SDP to public network IP and PORT.

================================================================================================

The following is an explanation of the NAT penetration problem generated by the SIP protocol ; and a solution is proposed.
1. There are roughly 4 types of NAT .
a) Full Cone
b) restricted cone restricted cone
c) port restricted port restricted cone
d) symmetric
where a, b, c are also called asymmetric NAT .

2. The SIP terminal is behind NAT , and there may be problems in its work. The reason is that the path taken by SIP signaling is different from the path taken by media streams.

3. Full Cone NAT
Any PC on the Internet can send data packets to the IP:port pair; and NAT maps this IP:port pair (on the public network) to the IP:port pair on the intranet (on the private network) ).

4. Restricted cone NAT
PCs outside the NAT , only those PCs that have been in contact with PCs in the intranet can come in through this mapping. For example, if I contact PC(a) through a machine on the intranet with an IP address of 10.1.1.1:123, then PC(a) can also contact me through this NAT mapping. But PC(b) does not work.
10.1.1.1:123 — NAT —> 202.70.65.78:10000 —— pc(a)
If pc(b) also sends data to 202.70.65.78:10000, then no data will be sent to 10.1.1.1:123.

Additional note:
If I have also contacted pc(b), then pc(b) can also come in.
10.1.1.1:123 — NAT —> 202.70.65.78:10000 —— pc(b)
If pc(b) also sends data to 202.70.65.78:10000, then the data is sent to 10.1.1.1:123.

5. Port restricted Cone NAT
In addition to the conditions in 4, it is not only to detect the source IP address of pc(a), but also to detect whether its port is the same as before.
10.1.1.1:123 —> NAT —->202.70.65.78:10000 —–> pc(a)[213.123.324.34:8000]

This NAT will only accept traffic from IP address 213.123.324.34 on port 8000, and let it go to 10.1.1.1:123.

6. Symmetrical NAT This is the simplest relationship description
10.1.1.1:1000 --- NAT ---> 200.123.123.34:1234 ---pc(a)
10.1.1.1:1000 --- NAT ---> 200.123.123.34: 2222—-pc(b)
The IP:port pair of NAT is different for each external program. Therefore, each external program has its own mapping ( IP:port pair assigned by NAT ). In the first three, multiple external programs may share a NAT IP:port pair.

7. Problems with RTP
In the RTP message body, there are some information needed by UA to communicate successfully. This kind of message text is called SDP message.

The problem is that the SIP endpoint (UA) may not know anything about NAT . Therefore, the IP address contained in the SDP usually uses an internal IP address, that is, the IP known by the SIP terminal. In this way, when the communicating party wants to communicate with the SIP terminal, it checks the IP address in the SDP message, but gets nothing because the internal IP address is used here.

Here is an example to illustrate:

INVITE sip:[email protected]:5060 SIP/2.0.
Record-Route: <sip:143.248.130.35;ftag=3a7ceb24a6ac50c4;lr=on>.
Via: SIP/2.0/UDP 143.248.130.35;branch=z9hG4bK758e.976609c7.0.
Via: SIP/2.0/UDP
192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d.
From: "Iqbal" <sip:[email protected]>;tag=3a7ceb24a6ac50c4.
To: <sip:[email protected]>.
Contact: <sip:[email protected]:1024>.
Supported: replaces.
Call-ID: [email protected].
CSeq: 8717 INVITE.
User-Agent: Grandstream HT487 1.0.5.18.
Max-Forwards: 16.
Allow: IN
VITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
Content-Type: application/sdp.
Content-Length: 343.
.
v=0.
o=040618 8000 1 IN IP4 192.168.20.3.
s=SIP Call.
c=IN IP4 192.168.20.3.
t=0 0.
m=audio 38660 RTP/AVP 0 8 4 18 2 15 99.
a=sendrecv.
a=rtpmap:0 PCMU/8000/3.
a=rtpmap:8 PCMA/8000/3.

The title header of a SIP message, similar to the header header of an email. Looking from the back to the front, starting from the From line, you can see the first Via line, which is the IP address that the SIP terminal thinks, such as 192.168.20.3. But the SIP proxy server is smart, it knows where the message is sent from, it adds the rport and received flags:
Via: SIP/2.0/UDP
192.168.20.3;rport=1024;received=223.178.140.109; branch=z9hG4bK34efcab2403aa20d.

That is to say, the SIP proxy server knows that the public network address of the SIP terminal sending the message is 223.178.140.109:1024.
In this way, the SIP proxy server can communicate with the SIP terminal because it knows the public network address of the SIP terminal.

However, poor old RTP gets blocked because it has a header like this:
v=0.o
=040618 8000 1 IN IP4 192.168.20.3.s
=SIP Call.c
=IN IP4 192.168.20.3.t
=0 0 .m
=audio 38660 RTP/AVP 0 8 4 18 2 15 99.
a=sendrecv.
a=rtpmap:0 PCMU/8000/3.
a=rtpmap:8 PCMA/8000/3.

The SIP terminal expects to receive RTP data from the port port m=38660 and the IP address IP c= 192.168.20.3, and this 192.168.20.3:38660 is the destination address where the communicating party tries to send RTP data.

This is why the ringing of a SIP phone can always be heard, but there is no sound when it is answered.

8 The solution is to tell the SIP terminal not to work so stupidly, but to find a way to know the port mapping assigned to itself by NAT .

And put the IP address of the public network: port into the SDP message. In this way, the SIP terminal asks NAT ..... Or ask a certain server on the public network, what is the mapping assigned to itself by NAT .

9 Ask NAT . This method is to use the UPnP protocol, and refer to the UPnP information.

10 Ask a server on the public network. Such as STUN server.
The SIP terminal sends a detection packet to the server on the public network. The server on the public network will send back a packet containing detailed information about NAT . With this information, the SIP endpoint will know if it is behind NAT or not . This detection method can be used for the above four kinds of NAT , and all are effective. For example, a SIP terminal sends a data packet from 10.1.1.1:1000, and the SDP message contains m=1000 and c=10.1.1.1. However, if the SIP terminal performs NAT detection first, it will know that NAT will allocate the IP of the public network: the port is 212.134.123.23:12345. Then the SIP terminal directly writes m=12345 and c=212.134.123.23 in the SDP message.

The problem arises because the port assignments for NAT are dynamic and therefore subject to change. In this way, after sending the NAT detection message, the SIP message will be sent out very soon. Moreover, the port used by the SIP terminal to send data is the same as the port used to receive data.

Note restricted cones (including port-restricted cones) NAT , which don't let incoming messages in unless the SIP endpoint sends a packet to it first. Therefore, the SIP terminal needs to send a data packet to the other party first. In this way, the data from the other party in the future can enter the NAT (however, there is no need to worry about this operation, there is a way).

The above approach will not work behind a symmetric NAT . Because, for symmetric NAT , it changes every time when it is assigned to the external IP:port of the SIP terminal (different parties are different). That is, the IP:port obtained when the SIP terminal detects NAT is different from the IP:port assigned when it sends a SIP message later. In this way, the voice data from the other party cannot come in, because the other party cannot obtain the correct IP:port.

11. The process described above is actually the process of solving problems when using the STUN protocol. That is, the SIP terminal sends a NAT detection packet to the STUN server.

12. The solution to symmetrical NAT is to put a server on the public network that relays voice streams. The server that relays the voice stream is sometimes an Out Bound proxy. Note that the server that relays the voice stream may become a bottleneck. Since the voice has to go through the server that relays the voice stream, the path increases and the sound quality will deteriorate. Therefore, it is troublesome for SIP to work in symmetrical NAT .

However, most of the current NATs can do "virtual server port forwarding", which means forwarding the ports needed for SIP work to SIP terminals. If the "virtual server port forwarding" is done on the NAT device, the NAT will reserve the port required for SIP work, which is dedicated to the SIP terminal, so that the SIP terminal is equivalent to being behind a Full Cone NAT . STUN works without problems. The number of ports required by the SIP terminal is determined in this way, one port is used for SIP signaling, such as 5060. The number of RTP ports depends on the number of calls. One call requires 2 RTP ports. For each additional call, 2 more ports are required.
A SIP phone that supports only one call requires NAT to map 3 ports.
The first three types of NAT can be collectively referred to as asymmetric NAT . For asymmetric NAT , STUN protocol can be used to pass through NAT .

The best way to solve the NAT problem is to change the symmetrical NAT into a complete cone NAT through port forwarding . This should be the first solution. There is no way to map the port, and then think of other ways. Of course, it is recommended that you do not buy a broadband router that cannot map ports, such a router is too bad.

===================================================================================

2. Case

2.1. Asterisk acts as a server, outside nat, and voip phone is inside nat.

2.1.1. The call comes from the phone terminal behind nat, and asterisk sends the media to the private network ip

If the voip phone does not use stun or other mechanisms to obtain its public network address (and write the public network address into the invite message), asterisk sends the media to the private network address, which is discarded by the router, resulting in a one-way call.

This happens when the calling user configures nat=never, or nat=no, or nat=rfc3581 in sip.conf. It has nothing to do with the type of nat.

Then only nat=route is available, that is, after the caller sends the media to asterisk, asterisk returns to rtp according to the original route. (How does asterisk obtain the route of rtp?)

2.1.2. Call from phone behind nat, asterisk sends media to wrong port

The voip phone can detect its own public network ip and write it into the invite header, and asterisk knows the ip address of rtp.

If the nat type is Cone (full cone, restricted cone), the port where nat forwards rtp to asterisk is not the media port of the original voip phone, asterisk sends rtp according to the original port . At this time, nat does not know to whom to forward the rtp packet received from asterisk (cone is the internal network ip: port corresponds to the external network ip: port, one-to-one correspondence).

Nat=route or nat=yes can solve this problem.

If there is only one phone behind Senat, port mapping can be done, and the rtp port used by the phone can be used for internal and external network mapping.

If there are multiple phones behind nat, you can assign the non-overlapping rtp port range to each phone, and then do port mapping separately. (?)

Using symmetric nat or stun server can also solve this problem

So slow~~~ so tired~~~

#asterisk gateway

Report Browse (643) Comments