SIP Trunking with sipXecs: Overview and Configuration
From SIPfoundry sipx, The Open Source SIP PBX for Linux - Calivia
Contents |
Introduction
| Important note: sipXbridge is a new component of sipXecs that enables SIP trunking with Internet Service Providers (ITSPs) including NAT traversal. It will become available in the next release (4.0) and it is currently available in the 3.11 development release. If you want to make sure it works with your favorite ITSP, test it and share the results. |
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)
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 it done considerably.
- 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.
- bandtel.com
- les.net
- bandwidth.com
- eutelia.com
- bt.com
- Vitelity.com
Additional ones that are in process include AT&T and Voxitas.
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 | Outbound Proxy | re-INVITE | Global addr | Rport | Registrar | Inbound Proxy | Reg On Init | Reg Caller ID | SIP keepalive | RTP keepalive |
|---|---|---|---|---|---|---|---|---|---|---|---|
| sipcall.ch | voipgateway.org | ||||||||||
| callwithus.com | callwithus.com | ||||||||||
| cbeyond.net | sipconnect-fca.atl0.cbeyond.net | ||||||||||
| voipuser.org | sip.voipuser.org | ||||||||||
| bandtel.com | bandtel.com | ||||||||||
| les.net | did.voip.les.net | ||||||||||
| bandwidth.com | ot.bandwidth.com | ||||||||||
| eutelia.it | voip.eutelia.it | ||||||||||
| bt.com | sip.ser-001.nat.bt.com | ||||||||||
| vitelity.net | vitelity.net | ||||||||||
| voxitas.com | wdc01a.netlogic.net |
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]]
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 sipXbridge instance can comfortably handle 25 concurrent media streams within acceptable limits of jitter and delay without becoming a bottleneck.
- Supports concurrent multi-ITSP configurations: A single sipXbridge instance can support multiple ITSP accounts 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.
- Can support one and two armed operation: Can be configured to ITSP facing side of the B2BUA on a publicly route-able address that is different from the side that faces the private network.
- 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).
How to configure sipXbridge
Configuring SIP Trunking service using sipXbridge is fully supported by the sipXecs Web user interface. It involves two specific steps:
- Configure and start the NAT traversal relay (sipxrelay)
- Create and configure an instance of the sipXbridge service as a Session Border Controller (SBC)
- Configure a SIP Trunk as a gateway to a specific ITSP using sipXbridge as the SBC
After configuring a new SIP trunk the dialplan needs to be updated to now use this new route.
1. Configure and start the NAT Traversal Relay (sipxrelay)
sipXbridge uses a relaying service for NAT traversal. This relaying service is also used by the "Far End NAT traversal" (A.K.A. remote worker ) feature of SipXecs.
sipXbridge is configured as an SBC Gateway. Here are the steps to follow:
2. Create and configure the sipXbridge service
Navigate to Devices / SBC and create a new sipXbridge based SBC. Here is the screen you will see when you configure sipXbridge.
In particular note the addresses in the configuration screen. SipxBridge allows you to configure the following addresses:
- Public IP address is the address reachable on the Internet
- External address is the external arm of sipXbridge. Normally this is an IP address on the internal LAN.
- Internal address is the IP address sipXbridge uses to communicate with sipXproxy (internal arm)
You can set up sipxbridge to run in your DMZ, in which case your public address will be the same as your external address. If you are running SipXbridge on a machine that has a single IP address, then the External and the Internal Address will be the same. If you have two interfaces and your external interface is in the DMZ and publicly routable, then your external address and public address will be the same. You can set up for your public address to be discovered using STUN discovery or enter it manually. There are also a few advanced settings that users may need to adjust for their particular setup. You can get to these settings by navigating to the "Advanced Settings" page.
3. Setting up a SIP trunk to use SipXbridge as the SBC
The following screen shots show what you can expect to see. The specific settings are determined on a per-ITSP basis.
You will see a screen that looks like this when you configure a trunking gateway that uses sipxbridge as the SBC:
Note the ITSP account link in the page above. When you click on that link you will be taken to a screen where you can specify the details for an ITSP account.
Configuring an ITSP account that is managed by SipXbridge
Most ITSPs only need for you to specify a proxy domain, user name and password. To enter these settings, you can navigate to the ITSP Account settings from the gateway screen. Here is what it will look like.
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. If your ITSP needs advanced settings, you can click on the "Advanced" link to include the necessary information. For ITSPs with hosted NAT Traversal capabilities, you usually will not need to navigate to this page.
Finally, you need to write the configuration out as an xml file that an be read by the sipxbridge process.
Sending the configuration
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.
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 -t nat -A PREROUTING -p udp --dport 25000:25500 -j DNAT --to-destination 192.168.5.240
iptables -A FORWARD -i $EXTIF -o $INTIF0 -d 192.168.5.240 -p udp --dport 15000:15500 -j ACCEPT
Some ITSPs (notably bandwidth.com ) do not accept REGISTER. You will have to provide them with a static IP address and configure your firewall to forward packets to sipxbridge as above. Such service providers will send signaling to port 5060. For such providers, the following set of rules may come in handy.
iptables -t nat -A PREROUTING -i $EXTIF -p udp --dport 5060 -j DNAT --to-destination 192.168.5.240:5080
iptables -A FORWARD -i $EXTIF -o $INTIF0 -d 192.168.5.240 -p udp --dport 5080 -j ACCEPT
iptables -t nat -A POSTROUING -s 192.168.5.240 -o $EXTIF -j MASQUERADE
iptables -A FORWARD -p udp --sport 5060 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth3 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -o eth3 -m state --state ESTABLISHED,RELATED -j ACCEPT
Here, my sipxbridge runs on 192.168.5.240 and accepts inbound signaling on port 5080 whereas, the ITSP can send to my public address at port 5060.
It sends media in the port range 25000 to 25500 which is forwarded symmetrically to my sipxbridge installation running at IP address 192.168.5.240.
EXTIF is my WAN-facing interface of the NAT ( eth3 ). INTIF0 is my LAN-facing interface of the NAT ( eth0 ).
The figure below shows a simple call setup via sipxbridge. The sipx proxy and other details have been omitted for clarity.
