SIP Trunking with sipXecs: Overview and Configuration

From SIPfoundry sipXecs IP PBX, The Open Source SIP PBX for Linux - Calivia

1 Introduction
2 Interoperable Internet Telephony Service Providers (ITSPs)
3 Required Parameters for different ITSPs
4 Required Parameters for dialing another sipXecs system
5 Functional Description
6 How to configure sipXbridge
7 Known limitations
8 HA Configuration
9 Troubleshooting
10 Problem reporting
11 Firewall/NAT Configuration
12 User Experiences
13 Design Overview

Introduction

Important note: sipXbridge is a new component of sipXecs that enables SIP trunking with Internet Service Providers (ITSPs) including NAT traversal. It became available in the 4.0 release. If you want to make sure it works with your favorite ITSP, test it, share the results, or even better provide a config template.

In a typical sipXecs deployment, sipXecs is connected to the enterprise LAN. The enterprise LAN typically has a firewall and Network Address Translator (NAT) that translates global addresses to private (non-routable) addresses. To be able to communicate between the PBX and the public network, we need an application level gateway or bridge. A new component was added to sipXecs called sipXbridge that provides this application level gateway functionality.

The sipXrbidge application is fully integrated into sipXecs and managed through sipXconfig. This makes it very simple for the admin to configure one or several accounts with Internet Telephony Service Providers (ITSPs) for the purpose of SIP trunking. The sipXbridge service can be installed on the same physical server as all the other sipXecs components, or it can be deployed on separate hardware. The choice is based on the need for scalability. In such a distributed setup several sipXbridge components can be added to sipXecs, each on its own physical server.

The sipXbridge service is implemented as a Back To Back User Agent (B2BUA) that enables NAT traversal and connectivity to an Internet Telephony Service Provider (ITSP). It anchors media and provides rewriting of the SIP / SDP headers so that packets can pass through the firewall / NAT and be routed from an ITSP to the sipXecs server via a NAT and vice versa.

Interoperable Internet Telephony Service Providers (ITSPs)

Following are the minimal requirements for interoperability :

Must support RFC 3261
Must support Re-INVITE (with and without SDP) for mid-call codec renegotiation.
Must support Session Timer.
Must support P-Asserted-Identity extension header to present correct caller ID during call forwarding and blind transfer operations and for anonymous calling.

While SIP interoperability in general has made significant progress, it is still required to test interoperability with each and every ITSP to make sure all the required features for successful SIP trunking work. the following is the current list of ITSPs that we were able to test against. This list highly depends on the availability of suitable test accounts. Should your preferred provider be missing and you would like to get it added, please say so on the sipx-dev mailing list. If you can provide a test account together with your request, then that would increase the chances of getting help with resolving interoperability issues.

CAVEAT : An entry in the table below does not guarantee that the ITSP is well behaved or of good quality. Careful testing has been performed on bandwidth.com, at&t, bt.com and cbeyond.net. An entry in the table indicates that somebody ( for example, member of the sipx user community ) has tried out the ITSP and has reported that it worked and has shared their settings.

att.com
bandwidth.com
bt.com
voxitas.com
sipcall.ch: sipcall is an ITSP in Switzerland. DID numbers in Switzerland are free.
CallWithUs: CallWithUs is an international VoIP provider offering SIP and IAX service
Cbeyond: Cbeyond is focused on small business and provides dedicated T1 service. They are also the initial supporter of the SIPconnect standard for SIP trunking.
voipuser.org: voipuser.org is a free ITSP service that offers you a fee did and limited outbound dialing privileges.
les.net: les.net is an ITSP in Canada. It can be configured to support North American 7-digit and 10-digit dialing.
eutelia.it
Vitelity.net
vitaltalk.com
Voip.ms
callcentric.com
simplesignal.com
bluesip.net
unlimitel.ca
flowroute.com
Nortel CS1K based systems.

The final user interface will provide a drop-down menu to select an ITSP. All necessary parameters will be auto-populated. In the mean time we will provide a table that indicates necessary settings to accomplish interoperability.

Here is a list of different international ITSPs.

Required Parameters for different ITSPs

Provider (ITSP)	Domain	ITSP Server Address	Global addr	Registrar	Reg On Init	Default Asserted Identity	SIP keepalive	RTP keepalive
bandwidth.com	ot.bandwidth.com	n/a(blank)	true	n/a	false	true	CR-LF	NONE
att.com	Specified by AT&T	n/a(blank)	true	n/a	false	true	CR-LF	NONE
bt.com	sip.ser-001.nat.bt.com	81.144.230.5	false	default	true	true	CR-LF	replay last sent packet
cbeyond.net	sipconnect-fca.atl0.cbeyond.net	sip-proxy-fca.atl0.cbeyond.net	true	default	true	true	CR-LF	NONE
voxitas.com	wdc01a.netlogic.net	wdc01a.netlogic.net	false	default	true	true	CR-LF	NONE
sipcall.ch	voipgateway.org	n/a(blank)	true	default	true	true	CR-LF	replay last sent packet
callwithus.com	sip.callwithus.com	n/a(blank)	true	default	true	true	CR-LF	empty packet
voipuser.org	sip.voipuser.org	n/a(blank)	false	default	true	true	CR-LF	empty packet
les.net	did.voip.les.net	n/a(blank)	false	default	true	true	CR-LF	empty packet
eutelia.it	voip.eutelia.it	n/a(blank)	true	default	true	true	CR-LF	empty packet
vitelity.net	vitelity.net	outbound.vitelity.net	true	inbound8.vitelity.net (supplied by ITSP)	true	true	CR-LF	empty packet
vitaltalk.com	vitaltalk.com	chicago-1a.vtnoc.net	true	default	true	true	CR-LF	replay last sent packet
voip.ms	voip.ms	n/a(blank)	true	default	true	true	CR-LF	NONE
callcentric.com	callcentric.com	204.11.192.31 (pick same registrar and proxy address)	false	204.11.192.31	true	true	CR-LF	NONE
simplesignal.com	sip.myvtel.com	n/a(blank)	true	default	true	uncheck ( leave PAI blank )	CR-LF	NONE
bluesip.net	bluesip.net	leave blank	true	default	true	true	CR-LF	NONE
unlimitel.ca	unlimitel.ca	sip.unlimitel.ca	true	default	true	uncheck (leave PAI blank)	CR-LF	replay last sent packet
flowroute.com	sip.flowroute.com	n/a (leave blank)	true	default	true	true	CR-LF	replay last sent packet

In addition to the settings in the table above, you will also need to configure your Caller-ID setting for the account as described below.

The SIP trunking capabilities of sipXecs (or sipXbridge) should extend far beyond the list of ITSP included in the table above. There are simply too many ITSPs so that we cannot test with them all. You can help extend the list. We are in the process of defining test procedures for ITSP interoperability testing and certification. [See [1]]

Required Parameters for dialing another sipXecs system

This is not the recommended way to do this - see HowTo interconnect two sipX PBXs.

Remote Ext. Dom	ITSP Server Address	Port	Global addr	Registrar	Reg On Init	Default Asserted Identity	SIP keepalive	RTP keepalive
ext.sipx.domain	host.ext.sipx.domain	5080	true	default	false	true	CR-LF	NONE

The ext.sipx.domain and host.ext.sipx.domain should resolve on the system placing the call to the outside address represented by the sipXecs system.

User comments

Functional Description

The sipXbridge service is designed to be as flexible as possible when it comes to accommodating differences between ITSPs. It turns out that ITSPs still have significant variability in how things work and also adherence to the SIP standard varies. The capabilities offered by sipXbridge are designed to maximize flexibility. The following lists some of the currently available features:

ITSP Registrations: Registers with ITSPs and keeps Registrations fresh.
Message size reduction and topology hiding: sipxBridge reduces message size by stripping any state that is not relevant to the ITSP (but may be relevant to sipXecs). These include route headers and other headers that are specific to sipXecs.
Near end NAT traversal requirements: Can operate behind a NAT. However, sipXbridge requires that there is no NAT between itself and the sipXecs proxy. Supports both dynamic and static NATs. sipXbridge re-writes SIP/SDP headers in the call setup signaling as needed by the ITSP. Keeps NAT bindings alive using periodic outbound signaling if needed (for example use empty packets for RTP keepalive and CR-LF sequences for SIP keepalive). Does not, in general, assume that the ITSP provides hosted NAT compensation.
Is configurable with sipXconfig: All aspects of SIP trunking are plug & play configurable
Has good media performance: sipXbridge anchors media and is implemented as an efficient media relay service. A single sipXrelay instance can comfortably handle 250 concurrent calls within acceptable limits of jitter and delay without becoming a bottleneck.
Is media (codec) agnostic.
Supports concurrent multi-ITSP configurations: A single sipXbridge instance can support multiple ITSP accounts with multiple DIDs per ITSP and can concurrently process the call setup signaling and media needed by these accounts.
Handles NAT/ITSP reboots: If the NAT reboots and comes back to life, sipXbridge will re-REGISTER with the ITSP. It relies upon session inactivity timers to clean up media resources that are allocated for the call in case of session inactivity and it uses periodic STUN global address re-discovery if configured to do so.
Works with commonly used phones and ITSPs: Exports all the necessary configuration options to allow such deployments and assumes no NAT traversal capabilities in the phone.
Supports call transfers locally: Call transfers are supported without sending the REFER to the ITSP. Therefore, it can handle both blind and consultative transfers and it is possible to transfer in or outbound calls via an ITSP back out to the ITSP (hair-pinned transfers).
Can be configured to play music on hold during the transfer.
Provides logging support: sipXbridge provides logging of messages and signaling in the syslog format expected by the sipXecs trace viewing (sipXviewer) tool.
Interoperates with the other sipXecs services (for example the conferencing service).
Integrated with sipx alarms: Provides administrator notification using the alarm facility of sipx.

How to configure sipXbridge

IMPORTANT : Please upgrade your system to version 4.0.4

Note that there is an issue with the Polycomm phone firmware 3.2.1.0054 leading to issue XX-6779. This is currently being fixed by Polycom. You should refrain from upgrading to that level of firmware until this issue is resolved.

Configuring SIP Trunking service using sipXbridge is fully supported by the sipXecs Web user interface. It involves the following steps:

Specify a SIP Trunking role for a server in the cluster
Configure a SipXbridge instance
Configure and the NAT traversal Settings (sipxrelay)
Specify a dial plan
Specify a trunking Gateway for the dial plan with a route pointing to the SipXbridge instance configured in a previous step.
Configure the ITSP account settings
Configure the caller ID settings.
Configure any required prefixes in the Dial Plan
Send profiles
Restart any services as necessary

1. Specify a SIP Trunking role for a server in the cluster

Follow the System > Servers link.

Select a server in the cluster where you want to run SipXbridge by picking the Sip Trunking role for that server. This will allow you to define a sipxbridge instance that runs on that server.

2. Configure SipXbridge

Navigate to Devices>SBC. To get to this screen :

Select the SipxBridge instance defined in the previous step and configure it. Note the inbound call destination setting ( defaults to operator ) in the screen below. This is a convenience field. You can set this to a hunt group extension, conference extension or other extension that is not an alias for a real user. Leave this field blank and use your DID as a user alias to direct your call to a specific user alias. SIPX has powerful user alias based call routing capabilities and this is the preferred way to route calls to endpoints that have user accounts associated with them. You would want to do that, for example, if you have multiple DIDs from the same provider and you want each DID to be assigned to a different user.

The public port in this page is the port that is exposed to the public network through your firewall setting. If your firewall restricts inbound traffic, you must open this port on your firewall to allow inbound signaling from the ITSP. The external port in the screen above is the port that is a port on the machine that sipxbridge runs on. It "faces" the firewall. It is associated with the public port on the firewall. Hence the firewall must be configured to send packets from the the public port to the external port. If you leave the public port blank, the external port is assumed to be the same as the public port (i.e. the mapping is assumed to be symmetric). If your firewall filtering rules allow inbound traffic from those destinations to which outbound traffic has previously been sent and if your ITSP provides "hosted NAT compensation", you do not need to reconfigure any firewall rules.

SipXbridge runs on port 5080 (not 5060). You can change port on which it receives signaling. However, if you change the sipXbridge port, be careful of causing port conflicts with other sipx components that are co-located on the same platform that bind to the same IP address. The port where sipxbridge expects to recieve signaling has nothing to do with where the ITSP expects to receive its signaling. The ITSP can continue to receive its signaling at port 5060. If your ITSP does IP address provisioning (i.e. ITSP registers your public address and signals that public address), they will probably default to signal sipXbridge on port 5060. If you do a straight through mapping on your firewall (i.e. external port maps to identical internal port) and open up port 5060, the signaling from the ITSP would bypass SipXbridge and go directly to the SIPX Proxy server and hence SipXbridge would not work. Please contact your ITSP and provision their system to signal port 5080 on your public address and open up port 5080 on your firewall (recommended) or use appropriate firewall rules to map external port 5060 to port 5080. If you chose to do the latter (not recommended - especially if you are also configuring remote workers), you would need to specify what port on the firewall you have mapped in the screen above. This note does not apply to ITSPs that function by Registration.

Typically ITSPs do not handle certain types of SIP requests such as REFER which is used in Call Transfer operations. To implement call transfer, SipXbridge does signaling translation, converting a REFER request to an INVITE request to the call transfer target. Consequently, a ringing tone will not be heard at the calling phone during call transfers when the call is routed through SipXbridge. Enable Music On Hold (MOH)on this page if you would like to hear music for blind transfers. If you do not do this, you will hear silence during the time a call is being transferred blind. You are recommended to turn MOH off for your phone when MOH is turned ON on sipXbridge as certain signaling race conditions may occur, resulting in garbled MOH.

3. Configure NAT Traversal

Navigate to System > Servers > Services > NAT. This will take you to a page where you can configure your NAT traversal service settings. You can select to use STUN or enter your public address here. A relay service (known as SipXrelay) manages a range of ports which defaults to the range 30000 to 31000. This setting must be a contiguous range of free ports.

If your server is running behind a NAT you must also explicitly declare that. Go over to System > Internet Calling and select the NAT Traversal Link. Check the Server Behind NAT box. If you plan to configure remote workers you should also enable NAT traversal on this page.

4. Configure a Dial Plan

Navigate to System > Dial Plans.

Using the pull down menu from the screen above, define a new Dial plan.

In the Gateways section drop down list, select the action to add a new SIP Trunk Gateway. Configure it as described in item 5. After you are done adding the Gateway, you must select the "Enabled" check box in the screen above. Click on Accept and OK to back out of this screen.

5. Specify a Trunking Gateway with a Route pointing to SipXbridge

Specify the address of the ITSP in the following screen. You should see the previously defined SBC (i.e. sipxbridge) appear in the drop down list for the Route.

Note the caller Id, ITSP account and Dial plan links in the screen above. You have to fill in the requisite information by clicking on these links.

6 Configure an ITSP account that is managed by SipXbridge

If your ITSP needs advanced settings, you can click on the "Advanced" link to include the necessary information. Here is what the form will look like (with the advanced section shown):

Note that the proxy domain of the ITSP account must match, or be a suffix of the Address that you enter in the Gateway page. Otherwise sipxbridge will not find the ITSP account and will return NOT found.

Most ITSPs only need for you to specify a proxy domain, user name and password. User Name is mandatory for accounts that require Registration with the ITSP.

Many ITSPs allow web access to set up your account. The password on this screen is your SIP password and not your web account password.

Some ITSPs may require advanced settings. To enter these settings, you can navigate to the ITSP Account settings from the gateway screen. For example, the Asserted-Identity field may be specialized. Click on the Advanced link to change these settings.

Whether the ITSP requires Registration or not, The P-Asserted-Identity header is a required header for most ITSPs that allow anonymous calling. It is used to compute the identity of the caller for account identification so that the From: header can be used for the caller-ID. The asserted identity field is also typically used for call forwarding to the ITSP. If the ITSP does not recognize this field and uses the From header for account identification, these features may not work as expected. if you select to "use default asserted identity", you must specify a user name so that the default Asserted Identity may be computed. If you elect to override the default Asserted Identity you must specify a valid entry (i.e. username@domain ) in the Asserted identity field. If you elect to specify an Asserted Identity, and if the asserted identity field is left blank or if you select the default and the user name is left blank, then none will be inserted into the call setup request bound for the ITSP.

If your ITSP does not support the P-Asserted-Identity (P-A-I) header and relies, instead, upon the From: header for SIP account identification, de-select the "use default asserted identity" check box in the screen above and leave the asserted identity field blank. With these settings, signaling directed towards the ITSP will not contain the P-Asserted-Identity header and the From header will contain what the P-A-I header would normally contain. If you configure things this way, the caller-Id presented to the called party when the call is forwarded will not be that of the calling party but rather, it will be the identity of the registered user from the PBX -- which is, of course, incorrect. Hence, this is not a preferred configuration. You should try to find an ITSP that supports P-Asserted-Identity to have things work as you would expect.

For ITSPs with Hosted NAT Traversal (HNT) capabilities, you usually need to set up to use private addressing and turn on RTP keep alive in order for call forwarding to the ITSP to work. However, if your ITSP allows it, turn off hosted NAT traversal at the ITSP. SipXrelay already relays media for bridged calls. If you do not turn off HNT, you will get needless double relaying of media and hence poor voice quality.

7. Configure the Caller ID settings

From the Gateway page click on the Caller ID link. Select the advanced checkbox. Enter the caller-Id for the account. The caller Id is what appears in the From: header of the outbound request for non-anonymous calls. Usually, accounts that are provisioned by public address have the caller Id set to user-name@public-address. Accounts that are provisioned by SIP Registration, usually have user-name@itsp-domain. Variations are possible. Please check with your ITSP. On this screen, the domain does not necessarily have to be a DNS Domain name. Some ITSPs may require that you have to use an IP address here. Note that the settings on this screen affect all calls that are routed via the given trunking gateway to the ITSP.

If you want to specify a per-user caller ID ( for example the DID that is assigned to the user to appear as that user's caller-ID ) here is how to proceed :

Do not specify a caller-id in the trunking gateway configuration screen below(leave all fields blank).
Specify a per-user caller ID when configuring the user.

8. Configure any required Dial Prefixes in your Dial plan

From the Gateway configuration page navigate to the Dial Plan page. Set up any dial prefixes (for example +1. This is usually country dependent. )

9. Send profiles for your server

This step writes out the configuration files to the file system on which sipxbridge runs.

10. check to see all your services are in good health

Click on the server link on the page above and restart any services necessary. Correct any errors. Check your alarm mail to see that there are no configuration alarms.

Known limitations

For outbound calling, you cannot have more than one ITSP account per ITSP domain. However, you can have multiple accounts for a given ITSP for inbound calling, assuming that your ITSP allows multiple accounts to be registered from the same IP address and port.
No end to end encryption. Since sipxbridge is relaying media it breaks end to end encryption.
To simplify the design, media is always relayed through sipxrelay when a call passes through sipxbridge. The bridge avoids hairpinning the media path however, so there is only one relay for a given end to end call and the same relay is used throughout the call.

HA Configuration

For HA Configuration each node of the HA system must have media relay ports that do not overlap with the other server. Otherwise media relaying will not work correctly If you have enabled SIP trunking on more than one server, ITSP account configurations should not interfere with each other.

Troubleshooting

Firewall Port Randomization Prevents Outbound Call from Succeeding

Some firewalls (in my case pfsense and m0n0wall) randomize outbound ports that can cause problems for some ITSPs. That is, if the source port for the REGISTER does not match the source port for the INVITE you may get an error 403.

The solution in pfsense is here: [2]

Basically you configure manual outbound NAT and specify the static port option. (tip courtesy of Jonathan Petersen).

Outbound call does not complete

Phone rings but no media or calls drop after a few seconds. Make sure your trunking gateway configuration has sipxbridge specified as the SBC. Otherwise, sipx will directly send the request to the ITSP. SipXbridge will not have a chance to re-write the request and hence your call will not complete even if your ITSP is doing hosted NAT compensation. (It might work on random occasions.)

Inbound call does not complete

Make sure your ITSP did not directly send the call setup request to port 5060. That would bypass sipXbridge altogether. Make sure you have mapped firewall port 5080 to LAN port 5080 so sipxbridge has a chance to rewrite the inbound request from the ITSP. Get a sniffer trace on your sipXbridge box and make sure the request is being routed through sipxbridge.

Cannot hear auto attendant prompt when call is answered by Auto Attendant

Check if your NAT is set up for symmetric port forwarding.

No MOH heard for SNOM phone

This is caused by a bug in SNOM firmware that does not properly set the port when transferring the call to the park server. Set the "reject stray packets flag" to false in the NAT traversal settings.

Dropped call on hold

Your ITSP may not be supporting re-INVITE or your ITSP account may be mis-configured.

Call dropped after 1/2 hour

ITSP may not be supporting session timer. Find another ITSP if possible.

SipXBridge stops registering after a while

The IP address that sipXbridge used to REGISTER is different than that returned in the Contact header of the response. If your public address changed, you need to be using STUN. Otherwise this is a protocol error. Inform your ITSP.

Call forwarding call setup not working

Check to see if your ITSP wants to see the same From header as the initial call setup. Read the material above on P Asserted Identity setup. If your ITSP does not support P-Asserted-Identity, uncheck default asserted identity in your advanced ITSP section and leave the Asserted Identity field blank. See step 8 in the setup section above for details.

Call forwarding media path not working

Your NAT may be doing NAT compensation and creating a media deadlock. Turn on RTP keepalive in the advanced section of the ITSP setup screen. Experiment with different settings. Replay last sent packet is a good bet.

Signaling OK but media not OK

If you are behind a NAT make sure that "Server Behind NAT" is checked in the Internet Calling > NAT Traversal page.

Problem reporting

Discuss problem on user list. Make sure there really is a problem and not just a misconfiguration. Detailed analysis will require a sipx-snapshot (wireshark traces do not suffice). Do NOT post excerpts of traces on the mailing list. They are not much use.

To take the snapshot :

Set logging levels of sipxbridge to DEBUG. Logging levels of sipx Proxy server to INFO, Loging level of sipx Registrar to INFO
clean out the log directory.
shut down the system.
For deep signaling issues, edit etc/sipxpbx/log4j.properties. Add the line log4j.category.org.sipfoundry.sipxbridge=trace. This turns on detailed stack logging.
restart the system.
run the problematic call flow.
See [3] for a GUI interface that allows you to take a snapshot. Alternatively you can use sipx-snapshot from the command line. Note that sipxsnapshot does not transmit any private data. It is absolutely required that this information be available to debug problems.
If the problem includes media issues such as one way speech, you would need to include a wireshark trace with your porblem report. You can filter the wireshark trace for RTP only. You can capture the trace using tcpdump -n -nn -s 0 -i any -w sipx-tcpdump.cap . You would also need to include a detailed trace for the media relay. For this edit etc/sipxpbx/log4j.properties. Add the line log4j.logger.org.sipfoundry.sipxrelay=trace (note: for version 4.0.4: log4j.category.org.sipfoundry.sipxbridge.sipxrelay=trace.) Save this and restart the media relay before running your test. It will generate a lot of logging information.
Open an issue and attach the snapshot, log files and pcap trace there or mail the list and ask for help on where to mail the snapshot.

For a detailed exposition of the problem resolution protocol in the sipx project, please read this [4]

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 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 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 have equipment that does not follow symmetric RTP, you can turn off stray packet rejection in the NAT traversal rules. This is not a recommended practice.

Linux Firewall/NAT configuration tips

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 sipx 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 are my linux firewall rules for this:

iptables --flush
iptables -F FORWARD
iptables -F nat
# EXTIF is my WAN-facing interface of the NAT ( eth3 ).
# INTIF0 is my LAN-facing interface of the NAT ( eth0 ).
export EXTIF=eth3
export INTIF0=eth0
# my sipx proxy server and sipxbridge run here.
export SIPXADDR=192.168.5.75
export PORTRANGE=30000:31000
iptables -A FORWARD -i $EXTIF -o $INTIF0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $INTIF0 -o $EXTIF  -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A PREROUTING -p udp --dport 5080 -j DNAT --to-destination $SIPXADDR
iptables -A FORWARD -i $EXTIF -o $INTIF0 -d $SIPXADDR -p udp --dport 5080 -j ACCEPT
iptables -t nat -A PREROUTING -p udp -i $EXTIF  --dport $PORTRANGE -j DNAT --to-destination $SIPXADDR
iptables -A FORWARD -i $EXTIF -o $INTIF0 -d $SIPXADDR -p udp --dport $PORTRANGE -j ACCEPT
iptables -t nat -A PREROUTING -i eth3 -p udp --dport 5060 -j DNAT --to-destination $SIPXADDR:5060
iptables -A FORWARD -i $EXTIF -o eth0 -d $SIPXADDR -p udp --dport 5060 -j ACCEPT
iptables --table nat --append POSTROUTING --out-interface $EXTIF -j MASQUERADE

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

Adtran firewall settings

ip rtp firewall-traversal

ip rtp firewall-traversal reuse-nat-ports

(courtesy of Josh Patten)

WinRoute firewall settings

Rules are

 From ITSP_SIP_server   To Kerio_fw_public_ip         ports (5080,30000-31000)   MapTo sipX_local_ip
 From sipX_local_ip     To ITSP_SIP_server            ports all NAT from  Kerio_fw_public_ip

User Experiences

Design Overview

The figure below shows a simple call setup via sipxbridge. The sipx proxy and other details have been omitted for clarity. For more details on how sipxbridge works, check out the source code from svn and look at the design document in the sipXbridge/doc/design.tar.gz file.