NOIILE
The last article focuses on the technical principles of crossing NAT. It is mainly to be deployed.
We know that Stun can stroke three types of NAT other than Symmetric. The NAT of the Symmetric type needs to be solved by using an ALG.
Although ALG can solve all types of NAT issues, if all call media communication needs to be transferred by ALG, it is bound to bring a very heavy burden to ALG, and even affect the quality of voice communication, illustrate delay or other QoS The problem.
Therefore, a problem is proposed to minimize the burden on the ALG.
The type of NAT can be divided into two categories: Symmetric and ASYMMETRIC. Therefore, network communication will have the following structures: Caller Callee
AskMMETRIC ßà asymmetric
SYMMETRIC ßà asymmetric
AskMMETRIC ßà symmetric
SYMMETRIC ßà symmetric
In the first case, it can be easily solved by Stun.
The second three situations, although Stun can not solve, but can also be solved by non-ALG's means. The Symmetric type NAT can only receive IP addresses and ports from it request. For example, A is a Symmetric type, B is a non-symmetric type. B can fill in the correct IP address and port in its own SDP (the correct point here means that you can really contact the IP address and port), but a can't, because the port is when A sent the first package to B A port is dynamically allocated by NAT Server. Therefore, B must not be packaged by the SDP information of A, but when b receives the RTP package from A, it can know the NAT Server IP address and port from the IP header of the RTP package. Therefore, B re-modify its socket, turn the target address and the port to the address and port in the IP header from the RTP package of A. Through this, you can solve this type of call problem.
That is, only the fourth case is not solved by ALG.
Therefore, according to the NAT type of the call, choose whether or not to pass through the ALG.
But how do you know the NAT type of the call?
Suppose all UA supports Stun, you can detect your own NAT type.
The initiator can add a NAT-TYPE header field in the Invite message, indicating what type of NAT yourself.
Then, each SIP UA is required to provide its own NAT type when registering your own registration server.
Thus, when INVITE arrives at the Proxy of the target UA, it can be known to the NAT type of both sides, which is obtained which one in four cases.
Therefore, the proxy of the target UA is determined whether or not the ALG is required to be transferred. When the target UA's Proxy receives an Incoming Invite Message, it determines the NAT type of the call. When both the NAT type belongs to SYMMETRIC, the ALG is requested to perform RTP transit. It is ignored by other types.
