Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

Firewall/NAT Configuration

See [http://en.wikipedia.org/wiki/Network_address_translation] for explanation of terminology in this section.

If your ITSP is checking if the remote port matches the SDP specified in call setup signaling, then you must allocate the
ports statically and map internal port to external port. i.e. you need
full cone with static outbound ports and one to one mapping of internal
to external ports. You cannot, in that case, tolerate any randomization
of ports from the NAT. The packet would be rejected ejected by the ITSP.
Following standard terminology, confiugre your NAT with work with full cone
and static outbound ports. Your NAT should implement port preservation.

If your ITSP is doing NAT compensation and does not care about remote
port for packets that it receives matching the SDP media port, and you are not concerned about remote worker support,
you can an get away with a simpler configuration. In such cases, you don't need to have anything but a
symmetric NAT. Further, if your firewall allows inbound traffic on ports
that have sent outbound traffic, you should not need to open up the RTP
port range either. Only the signaling port 5080 would need to be opened
up. This would be the case for many low cost ITSPs such as les.net and
voip.ms. These are pretty simple to configure and should work with most DSL routers with minimal effort.

Note that SipXbridge does NAT compensation for both media and signaling (i.e.
it will send packets first to the remote address before packets are
received in order to open up the pinhole).

...

If you are using Linux firewall / NAT, the following IP Tables settings may be handy. '''

Note that many good references for IP Tables are available and these should be consulted for authoritative advice.
'''

SipXbridge assumes symmetric NAT port mapping. That means an internal port must be mapped to an identical external port and vice versa. Without such a mapping some sipXecs components will not work. Not all NATs will lend themselves to such mapping.

Some ITSPs work without any special NAT configuration needed. They work by
ignoring the SIP/SDP port information -- relying instead on the remote
address and port of the incoming datagram (SIP/RTP) packet. Such ITSPs require no special NAT
configuration (other than the normal IP Tables forwarding rules for symmetric NAT)
and will expect you to use local addresses in all your call setup signaling.

Other ITSPs
are more particular. They will expect you to provide a valid port in
your call setup signaling and only send RTP packets to the specified ports. To cover
such cases, you need to configure your NAT/Firewall, appropriately. You need to set up port forwarding in
the port range that sipxbridge uses.

...

Here, my sipxbridge runs on 192.168.5.75 and accepts inbound signaling on port 5080 and symmetrically maps UDP traffic going both ways in the port range 30000:31000

It is possible in versions 4.4 and later to allow sipxbridge to listen for inbound SIP trunking on port 5060 while simultaneously listening for SIP Proxy requsts. This is done by enabling the bridge-proxy-relay setting in Server -> Services -> SIP Proxy.

Adtran firewall settings

ip rtp firewall-traversal

...