SIP Traversal Nat&firewall Solution

What are the problems with SIP from private network to public network?

Address translation of the package.

SIP address Translation inside the SIP message.

The RTP address translation in the SDP inside 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 to find a SIP application solution that can meet a variety of networks.

Fundamentals of NAT and firewall

First, 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) and its private address {A:B} is converted to the public address {x:y} and bound. 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 the fracture 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:

L Firewall will tell if all the packages are from inside (Inside) or outside (Outside).

L Generally, allow all packets from inside to be sent out.

L General, allow packets from outside to come in, but this connection must be initiated by inside.

L General, prohibit all connections initiated by outside in the package.

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.

L UPnP

L External Query

L STUN

L 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 initiated the 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 determined 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 that the IP address of the packet and the SIP IP address are different, it is determined that it is a NAT, so it will be related to the SIP IP address modification.

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}