This is an article moved there from noiile ~
What kind of problem is SIP encountered from private network to public network?
The address translation of the package.
SIP address translation in the SIP message.
RTP address translation in the SDP in the SIP message.
Network existing structures are complex, and the SIP service provider is not necessarily a Network provider. It is difficult to request customers only using some way NAT & FireWall. How to find a SIP application solution that meets a variety of networks?
Basic principle of NAT and FireWall
First, several ways of NAT:
Full Cone: When the host in a private network sends a package to the public network, its local address and port are {A: B}, and NAT will convert its private address {A: B} to the public network address {x: Y } And bind. Any bag can be sent to the {A: B} address of the host by address {x: y}, and NAT will convert any incoming package sent to {x: y} into {A: Y}. B}.
Partial / Restricted Cone: When the host in a private network sends a package to the public network, its local address and fracture are {A: B}, and NAT will convert its private address {A: B} to the public address {x And bind. Any bag can be sent to the host's {A: B} address via address {x: y}, but NAT is just a package that is first sent to {x: y} {A: B} | {X: y} <-> {C: D}, where {C: D} is the source address and port of the package. That is, only the package from {C: D} can communicate with the host {A: B}.
Partial and Restricted Cones are the IP address of Partial only bind the IP address of the incoming packet, and the Restricted Cone will bind the IP address and port of the incoming packet. That is, the situation described above.
Symmetric Cone: When the host in a private network sends a package to a host host, {a: b} à {C: D}. NAT converts its address {A: B} into {x: y} and binds it into {A: B} | {x: y}. NAT only accepts incoming packet from {C: D}, forward it to {a: b}. That is, if the host in the private network wants to send a package out, it must know the other party's public network IP and port. But if the other party is in a private network, it is difficult to know the other party's public network IP and port.
It can be seen that the Symmetric Cone condition is the most stringent, and the Partial / Restricted conte is the least strict.
Let's take a look at the basic strategy of FireWall:
l FireWall will judge that all packages are from internal (inSide) or OUTSIDE.
l General, allow all packages from inside.
l General, allowing the package from Outside to, but this connection must be initiated by INSIDE.
l General, prohibiting all connects from the package initiated by Outside.
l General, FireWall will allow several trusted Outside hosts, they can initiate establish a connection and package it in.
All NAT and FireWall are processed and filtered below the TCP / IP layer, while the address of the SIP application is at the application layer. So you must use other ways to solve this problem.
For different NAT types, there can be different solutions.
l UPnP
l External Query
l stun
l alg
The first three are all applying their own public network addresses and ports before INVITE, or protocols, by SIP Client. The SIP Client provides additional support and is not adapted to all NAT methods. Alg (Application Layer Gateway) Adapts to all NAT methods and does not require SIP Client to do any additional support. It processes and modifications to the SIP signaling of the Application layer, resulting in a transparent conversion address.
The ALG solution is described in detail below for a case.
SIP ALG solution
ALG Modify the SIP address and the RTP address and port in the port and the port and SDP messages in the SIP message, where the RTP address and port are requested to be requested to RTP Proxy, and RTP Proxy assigns its own idle address and port, and keeps mapping with this CALL relationship. Binds the address and port of the call to the call, so that the RTP connection address of the call between the calls is RTP Proxy, which is transferred from RTP Proxy to a real destination.
Suppose that there are two SIP Client to communicate, Ada and Bob, they are located behind their NAT Server:
Two NAT Server are Symmetric Cone.
Its signaling process is as follows:
1. ADA initiates signaling, INVITE BOB.
IP Packet IP Address:
From: 192.168.1.10:5060
TO: 128.97.41.56:5060 (SIP ALG)
SIP MSG IP Address:
From: 192.168.1.10:5060
TO: 128.97.41.56:5060
SDP Body IP Address for RTP:
192.168.1.10:10024
2. After NAT Server, NAT converts its private address to the public address, and binds, since it is used to use the Symmetric CONE mode, the IP address of the purpose is also bound.
{192.168.1.10:5060 }| {128.96.41.1:5678}.com {128.97.41.56:5060}
IP Packet IP Address:
From: 128.96.41.1:5678
TO: 128.97.41.56:5060 (SIP ALG)
SIP MSG IP Address:
From: 192.168.1.10:5060
TO: 128.97.41.56:5060
SDP Body IP Address for RTP:
192.168.1.10:10024
3. SIP ALG accepts this invite, discovers the IP address of its package, and the SIP IP address, it is determined that it has been modified by NAT, which is modified by the relevant SIP IP address.
And check if its Body is included in the SDP information, if yes, and there is an RTP address, the SIP ALG will request a public RTP address to replace the original RTP address to replace the original RTP address to RTP Proxy.
IP Packet IP Address:
From: 128.97.41.56:5060
TO: 128.96.63.25:5566
SIP MSG IP Address:
From: 128.96.41.1:5678
TO: 128.96.63.25:5566 (Address of the next hop)
SDP Body IP Address for RTP:
128.97.44.5:3000
4. Because Bob sent a registered package to SIP ALG, its NAT Server always retains such bindings, {10.0.96.63.25:5566} <-> {128.97. 41.56: 5060}. Therefore, the invite, Bob, which is sent by the SIP ALG, can be received. Bob returns 200 OK, including SDP information.
IP Packet IP Address:
From: 10.0.0.12:5060
TO: 128.97.41.56:5060
SIP MSG IP Address:
From: 10.0.0.12:5060
To: 128.97.41.56:5060 (the address of the next hop)
SDP Body IP Address for RTP:
10.0.0.12:10002
5. NAT Server modifies the IP address of its package. Send to SIP ALG.
6. SIP ALG accepts this 200 OK, discovers the IP address of its package, and the SIP IP address, it is determined that it is modified by NAT, which is modified by the relevant SIP IP address.
And check if its Body is included in the SDP information, if yes, and there is an RTP address, the SIP ALG will request a public RTP address to replace the original RTP address to replace the original RTP address to RTP Proxy.
IP Packet IP Address:
From: 128.96.63.25:5566
To: 128.96.41.1:5678
SIP MSG IP Address:
From: 128.96.63.25:5566
To: 128.96.41.1:5678 (Address of the next hop)
SDP Body IP Address for RTP:
128.97.44.5:3002
7. At this point, RTP proxy keeps such a connection binding for this session.
{128.97.44.5:3000 | 128.97.44.5:3002}
8. ADA received 200 ok, it believed that the RTP address of the other party was 128.97.44.5:3002. Will establish a connection.
Bob believes that the RTP address of the other party is 128.97.44.5:5:3000. Will establish a connection.
9. When the 3002 port of RTP Proxy receives a package, it can get the ADA RTP public IP from the packet address.
When the RTP Proxy's 3000 port receives a package, it can get BOB's RTP public IP from the packet address.
Thus, RTP Proxy will forward the 3002 port to the BOB RTP public IP.
Similarly, RTP Proxy will forward the 3000 port to the RTP public IP of the ADA.
In this way, a call is successfully established.
SIP ALG deployment requires all RTP packs through RTP Proxy, so all MS must have the ability to modify SDP, and only SIP ALG needs to have the ability to modify the SIP message. Let users configure their proxy, avoiding the SIP Client of the public network, has also caused unnecessary consumption. Supplement If the SIP ALG discovers the address of the Invite package, it will not modify this package, it thinks this package is from the public network, or the SIP Client has the ability to cross the NAT. But it will modify its SDP IP address. Issue: 1. If SDP describes single work, RTP connection cannot be established, because RTP Proxy has never known the silent RTP public IP. 2. Each time the RTP connection is established, the RTP package of a part may drop several until RTP Proxy knows the other RTP public IP. 3. Whether to force any RTP packages to pass through RTP Proxy, whether they are from the public network, they can be connected directly. I think, because the calling party does not know the name of the called party. 4. If multiple RTP proxy is balanced, how do I guarantee that proxy allocates IP's proxy and proxy assigns IP to the called party? (They must be the same proxy) to add a header, such as RTP Proxy, this header only has SIP ALG awareness. 5. If the SIP message is encrypted, the IP address of its SIP cannot be modified. Refer to "SIP, NAT, AND FIREWALLS", Fredrik Theernelius, May 2000
"Cisco - VoIP Traversal of Nat and FireWall, Cisco Systems, Inc.
