The original link (also reproduced) http://blog.csdn.net/yetyongjin/article/details/6881491. I have modified some typos.
SIP
What kind of problems do you encounter from the private network to the public network? 1. Address translation of the package.
2. SIP address translation inside SIP messages.
3. The RTP address translation in the SDP in the SIP message.
The existing structure of the network is complex, SIP service providers are not necessarily network providers, it is difficult to ask customers to use only some way of nat&firewall. How do you find a solution for SIP applications that can meet a variety of networks?
NAT and Firewall
the basic principleFirst, there are several ways of NAT:
Full Cone: When a host in a private network sends a packet to the public network, its local address and port is {A:b},nat will convert its private address {A:B} to the public address {x:y} and bind. Any package can be sent to the host's {A:B} address via address {x:y}, and Nat will convert the address {x:y} of any incoming package sent to {x:y} to {a:b}.
partial/restricted Cone: When a host in a private network sends a packet to the public network, its local address and port is {A:b},nat will convert its private address {A:B} to the public address {x:y} and bind. Any package can be sent to the host's {A:B} address via address {x:y}, but Nat is bound to {a:b}| only for the first package destined for {x:y} {X:y}<->{c:d}, where {c:d} is the source address and port of the package. In other words, only packages from {C:D} can communicate with host {A:B}.
The difference between partial and restricted cone is that the partial binds only the IP address of the incoming packet, and restricted cone binds the incoming packet IP address and port. That is the case described above.
Symmetric Cone: When a host in a private network sends a packet to a host on the public network, {A:B}->{C:D}. NAT converts its address {a:b} to {x:y} and binds it to {a:b}| {x:y}<->{c:d}. NAT only accepts incoming packet from {C:D} and forwards it to {A:B}. In other words, if a host inside a private network sends a packet to the outside, it must know the other's public IP and port. But if the other side is also in a private network, it is difficult to know each other's public IP and port.
Thus, symmetric cone conditions are the most stringent, partial/restricted cone second, full cone conditions least stringent.
Here's a look at Firewall's basic strategy:
Firewall will determine whether all packages are from inside (Inside) or outside (Outside). Generally, all packets from inside are allowed to be sent out. Generally, packets from outside are allowed to come in, but this connection must be initiated by inside. In general, all connections initiated by outside are prohibited from being sent in. In general, Firewall will allow several trusted outside hosts, and they can initiate the establishment of a connection and contract it in.
All NAT and firewall are processed and filtered for the TCP/IP layer, while the address of the SIP application is at the application level. So there must be other ways to solve the problem.
for different NAT types, you can have different solutions.
1. UPnP
2. External Query
3. STUN
4. ALG
The top 3 are the SIP Client (including UA and proxy) that acquires its own public address and port before invite by some means or protocol. The SIP client is required to provide additional support and is not suitable for all NAT modes.
ALG (Application Layer Gateway) adapts to all NAT modes and does not require any additional support from the SIP client. It handles and modifies SIP signaling in the application layer to make transparent conversion of addresses.
The following is a detailed description of the solution for ALG in a case.
SIP ALG Solution
ALG modifies the SIP address and port inside the SIP message and the RTP address and port in the SDP message, where the RTP address and port are to be obtained from the RTP proxy request, and the RTP proxy allocates its own idle address and port, and maintains a mapping relationship with the call. The address and port assigned to both sides of the call are bound so that the RTP connection addresses of both sides of the call are RTP proxies, which are brokered by the RTP proxy and sent to the true destination. Let's say that there are two SIP clients to communicate with, Ada and Bob, who are behind their own NAT servers, respectively:
Of these, two NAT servers are symmetric cone methods.
The signaling process is as follows:
1.Ada initiation 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 to convert its private address into a public address, and bind, because is the use of symmetric cone way, so also bind the destination IP address.
{192.168.1.10:5060}| {128.96.41.1:5678}<->{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 the invite and finds that its packet has a different IP address and SIP IP address, so it is judged to be NAT, so it modifies its associated SIP IP address.
and check whether its body contains SDP information, if it is, and there is a RTP address, SIP ALG will go to RTP proxy request a public network RTP address to replace the original RTP address.
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 constantly sends a registration package to SIP ALG, its NAT server always retains such a binding for it, {10.0.0.12:5060}| {128.96.63.25:5566}<->{128.97.41.56:5060}. Therefore, the Invite,bob sent by SIP ALG can be received.
Bob returns a $ OK containing the 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 (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. Sent to sip ALG.
6.SIP ALG accepts this and finds that its packet has a different IP address and SIP IP address, so it is judged to be NAT, so it modifies its associated SIP IP address.
and check whether its body contains SDP information, if it is, and there is a RTP address, SIP ALG will go to RTP proxy request a public network RTP address to replace the original RTP address.
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, the RTP proxy maintains a connection binding for this session
{128.97.44.5:3000|128.97.44.5:3002}
8.Ada receives a OK, it thinks the other's RTP address is 128.97.44.5:3002. will establish a connection with it.
And Bob thinks the other's RTP address is 128.97.44.5:3000. will establish a connection with it.
9. When the 3002 port of the RTP proxy receives the packet, it can obtain the ADA's RTP public IP from the package address.
When the 3000 port of the RTP proxy receives the packet, it can get Bob's RTP public IP from the package address.
Thus, the RTP proxy forwards the packet received by Port 3002 to Bob's RTP public IP.
Similarly, the RTP proxy forwards the packets received on port 3000 to the ADA's RTP public IP.
In this way, a connection to a call is successfully established.
Deployment of SIP ALG because all RTP packets are required by RTP Proxy Anyway, all MS must have the ability to modify the SDP, and only sip ALG needs to have the ability to modify the SIP message. Let the user configure their own proxy is what, to avoid the public network SIP client also through SIP ALG, resulting in unnecessary consumption.
Supplemental If SIP ALG discovers that the address of the invite packet is consistent with the SIP address, it will not modify the package, which it considers to be from the public network, or that the SIP client has the ability to traverse NAT. But it modifies the IP address of its SDP.
Issue:1. If the SDP describes simplex work, the RTP connection cannot be established because the RTP proxy always has no way of knowing the RTP public IP of the Silent party.
2. Each time the RTP connection is established, the RTP packet of one party may lose several, until RTP proxy learns the other party's RTP public IP.
3. Whether any RTP packets should be forced to pass the RTP Proxy, whether they are from the public network, can be directly connected. I think so, because the calling party does not know the network environment of the called Party.
4. If multiple RTP proxies are balanced, how can we ensure that the proxy that assigns the IP to the calling party is the same as the proxy that assigns the IP to the called party? (They must be the same proxy)
Can add a header, such as RTP proxy, this header only SIP ALG know.
5. If the SIP message is encrypted, the IP address of its SIP cannot be modified.
Go SIP Traversal Nat&firewall Solution
