Introduction

The Intertex IX67 "SurfinBird" SIP Firewall is one of the few firewall/NAT's that is able to handle the SIP protocol.

Key Features include:

• Highly functional firewall that is easy to configure
• DHCP server that allows the definition of options (e.g. option 66 for TFTP server)
• Caching DNS server
• Full SIP Firewall / NAT traversal that eliminates the need for things like STUN, TURN, ICE, etc.
• Excellent performance
• IX67 User Forum

Additional SIP Switch Software:
The IX67 offers an additional option enabling the SIP Switch software. Unfortunately this comes at a price of $500. However, it enables interesting additional functionality that makes perfect sense in conjunction with sipX:

• B2BUA allows using a SIP service provider to originate / terminate SIP calls. The IX67 registers with e.g. Vonage and other SIP providers. It can be used as a gateway in the sipX dialing plan for outgoing and incoming calls.
• Additional capabilities, such as the possibility to create users and register phones is not as useful as sipX is the better proxy to do this with.

What do we want to accomplish?

Once the sipXecs IP PBX solution is installed either in a company or at home, you will most likely want to use your new phone system to talk to other people. Using a PSTN gateway is the most obvious and in many cases the most simple way to provide external connectivity to your sipX system. However, terminating calls into the PSTN is not free and a good PSTN gateway still is fairly expensive. So why not use the Internet to directly call another party or hand-off calls over your broadband connection to a carrier that offers SIP trunking and PSTN origination / termination services.

Here is what we would like to accomplish:
Allow internal phones to call SIP URIs on the Internet (remote phones reachable on the Internet) -*STATUS: Works
Allow remote (external) phones to be configured so that they can register with the sipX server on the local LAN -*STATUS: Works
Allow external callers to reach internal phones using a SIP URI derived from your domain name (e.g. user1@mycompany.com) -*STATUS: Works
Allow calls to be handed off to a SIP service provider over a SIP trunk for termination into the PSTN -*STATUS: Requires B2BUA or the Intertex SIP Switch option
Allow calls that originate in the PSTN to reach you using a SIP service provider that connects to the sipX server over a SIP trunk -*STATUS: Requires B2BUA or the Intertex SIP Switch option

All this requires proper NAT and firewall traversal, both at the near end and at the far end.

Initial Basic Configuration of the IX67

The following description of basic configuration of the Intertex IX67 starts from default configuration. Use the Get Default Values button in the IX67 Web interface to return to default values if in doubt.

Network Configuration

WAN settings: In this example we use the IX67 as the NAT / Firewall between the Internet and our internal LAN. The Cable / DSL modem provided by the ISP assigns network configuration using DHCP. We therefore configure WAN used as outside and Get by DHCP.

LAN settings: Make sure you only have one DHCP server on your local LAN. If you want the IX67 to be your DHCP server, check DHCP server. Note that the IX67's DHCP server allows the definition of DHCP options and therefore is able to tell your phones where to find the TFTP server to retreive configuration information.

Define inside and assign an IP address and Netmask.

DNS Server: While the IX67 provices an internal DNS server that can provide name resolution for your local LAN, its function is limited. I therefore prefer to configure a real DNS server on my internal LAN. Either Microsoft Server 2000/2003 or a Linux server can be used for this purpose (it could also be the sipX server). That same server then also provides DHCP services for my local LAN. Enabling the DNS server of the IX67 allows the IX67 to act as a DNS forwarder for your internal DNS server. Configure your internal DHCP server to distribute a DNS server address to its clients that corresponds to your internal DNS server only. The internal DNS server then uses the IX67 as a DNS forwarder, which allows requests for external name resolutions to be forwarded to the DNS server assigned to the IX67 by the ISP. No change to your clients or the internal DNS server is required should the ISP change its DNS server addresses.

Security Settings

By default you should use the High profile. I switched to the Low profile so that my Vonage terminal adaptor could connect to the Vonage server.

Firmware Update

Firmware release 3.17 (November, 2005) is used.

Additional Packages or Licenses from Intertex

No additional items were purchased from Intertex. In particular this configuration does not rely on any functionality provided by the SIP Switch features that can be bought extra. The sipX server provides significantly more advanced SIP features as compared to the Intertex SIP Switch functionality.
{{Box Important| Intertex IX67 uses one SIP User License for each SIP registration - even in passthrough mode. |} One can register unlimited number of IP phones to sipX via Intertex as wall as register to unlimited number of ITSPs but only first 5 (or more if You buy additional licenses) will be able to make or receive calls.
IX67 will generate '404 Not Found' error for calls from/to SIP users that do not fit in 'Registered SIP Users' menu on the router.

There is no limit to the number of concurrent incoming or outgoing calls as long as the above criteria are met. One can always have 70 incoming calls from non-registered users

Forward Incoming SIP Traffic to the sipX Server

The Intertex IX67 is transparent for SIP traffic in both directions (to and from the WAN). To configure the IX67 to forward incoming SIP traffic from the WAN to the sipX server on the local LAN a Static Domain Forwarding rule has to be defined. This allows phones connected to the Internet to do the following:

• Call an internal extension (e.g. sip:user@mydomain.com or sip:user@<external IP address>)
• Register with the sipX server and behave as if they were on the local LAN.

Note: Typically a far side (remote) NAT is placed between the remote phone and the Internet. For the phone to obtain the IP address of the WAN interface of the NAT it is connected to requires the help of a STUN server. Any STUN server that is publicly accessible on the Internet can be used for that purpose (e.g. stun.fwdnet.net). While STUN can deal with the most common situations of NAT, it does not work in every situation. The best setup is to use an IX67 also as the far side (remote) NAT. In this case the use of STUN is unecessary.

Configuration of the IX67

• Choose a fixed IP address for the sipX server on the local LAN. Alternatively if you want to use a DHCP assigned address you should reserve an IP address based on the server's MAC address so that always the same address is assigned. Make sure you have a DNS server on the local LAN that can resolve the sipX server's host name to a valid IP address.
• Using the IX67 Web interface, go to SIP Advanced and setup Static Domain Forwarding. For Domain enter your public IP address, i.e. the public address assigned to the WAN port of your IX67. The Forward to (IP) field is for the IP address of your sipX server on the local LAN. For Domain you can also enter a name that has to be resolvable to the external IP address of the IX67 by any client on the Internet (e.g. you might want to use dyndns.org in case you have a dynamic IP address assigned by your ISP).

Provided you have setup user accounts on the sipX server for every user of a remote phone, such users' phones can now register with the sipX server.

• Configure the username and SIP password (not the PIN) into the phone
• If behind a NAT configure a STUN server
• Configure the WAN port of the IX67 as the outbound proxy address for the phone

Domain Forwarding

Forwarding an IP address:
Forwarding an IP address is typically used if the address cannot be resolved to a domain name using DNS. Packets pass through the IX67 and arrive at the sipX server. The sipX server does not recognize the incoming IP address as a domain it is responsible for and therefore sends the request back out in an attempt to forward to the appropriate proxy for that domain. Unfortunately that causes a Loop Error in the IX67 (as it should).

Forwarding a domain:
Domain forwarding is always used if the SIP URI external callers use can be resolved to the external IP address of the IX67. If domain forwarding (where mydomain.com resolves to the external IP address of the IX-67 for clients on the Internet) is used, the IX67 will not handle SIP message processing, but will instead forward all SIP messages to the sipX server.

While forwarding an IP address works "out-of-the-box" by simple configuring a forwarding address, domain forwarding requires an additional parameter to be changed.

In the IX67, an outgoing call is a call to a domain the IX67 is not configured to be responsible for. By default all outgoing calls are authenticated. Therefore, when using sipX as the SIP server, change the setting Allow outgoing calls from in the SIP Switch menu in the IX67 web interface from Inside to All. By doing this all calls to users registered on the sipX server need not be authenticated by the IX67.

DNS Name Resolution Requirements

When setting up the sipX server, a fully qualified host name is chosen which defines the domain for which the sipX server operates. That means that all phones registered with the sipX server get assigned a SIP URI of the form "sip:user@domain". This also means that incoming calls have to be addressed to users on that domain for sipX to forward them correctly.

For calls from the Internet to reach user agents registered with the sipX server, the domain name for which the sipX server is configured has to be resolvable using DNS for clients on the Internet to the external interface of the NAT/Firewall that sits between the Internet and the sipX server.

In particular that means that calls addressed to "sip:user@<external IP address>" will not work (where <external IP address> is the external address of your NAT/Firewall).

Also if you use DYNDNS to point to your external NAT/Firewall address (e.g. name.dyndns.org), this will not work unless name.dyndns.org is also the fully qualified host name of your sipX server on the internal LAN.

How to Configure the Counterpath (aka Xten) eyeBeam phone

As an example here is the configuration for the Xten eyeBeam phone to register with the sipX server. The setup is according to the diagram above where the Xten eyeBeam phone is in a remote location and behind a remote NAT/Firewall (Cisco PIX 506E). The Free World Dialup (FWD) STUN server is used for the phone to discover its external IP address.

1. Configure a user in the sipX server to be used with the remote Xten eyeBeam phone. Note the user name (User ID), as well as the SIP Password (not the PIN).
2. Create a new line in the Xten eyeBeam phone as follows:

For this setup to work the domain name used on the Internet has to be the same as the domain for which sipX is configured on the internal network. In addition, sipX has to be configured to use DNS SRV and your internal DNS server has to include the necessary SRV records.

In particular, if the domain name used on the Internet is mydomain.com, then the sipX fully qualified host name has to be sipx.mydomain.com. Using Config Server go to Configuration and change Domain from sipx.mydomain.com to mydomain.com. This will enable using DNS SRV. And lastly, test your internal DNS server to make sure it provides correct name resolution, including the DNS SRV records. Refer to the installation documentation for further information on how to configure DNS.

The phone should now successfully register with sipXecs and you should be able to call internal extensions (try dial 101 to get the voicemail system).

Setting up a sipXecs Server Alias

If it is not possible to use the same domain name on your internal LAN as well as for the external interface of your IX67 firewall, then a sipX server alias might be required. This situation typically occurs if you use sipX at home and your ISP only provides a dynamic address. Using http://dyndns.org you can assign a DNS resolvable name to your external interface; however, you might not want to use this same name as your internal domain name on the LAN.