Analytics Tracking Code

Saturday, March 30, 2013

Today I'm hanging out at my parents gas station/gallery/cafe/grocery store/internet publishing company. I took some time today to configure an Aastra MBU 400 for use with FreeSWITCH. The MBU 400 is a discontinued Aastra product apparently targeted towards residential or small office deployments where users would want portable handsets, akin to standard wireless portables that people already have in their homes.

The MBU 400 base station in my possession has a traditional POTS RJ11 port on the back for connecting to standard phone systems as well as a 10/100 network port to get the device onto the network and communicate with a SIP server.

It is possible to provision the network configuration for the base station through one of the handsets, selecting between static IP or DHCP. Also it seems possible to provision some aspects of the SIP configuration though the handset as well, although the experience would probably be tedious and is likely missing many fine grained settings. Like most SIP phones, the configuration can be pushed out with some proprietary gear from Aastra, which I don't own, and wouldn't buy anyway.

The MBU 400 has a web interface, for which the default credentials are:

Username: admin

Password: 22222

The SIP account configuration seems to require both the Registrar and Outbound Proxy fields to be filled (even if they have the same information). I pointed these towards my FreeSWITCH instance, to which I had already setup a new user extension.

Seeing as how my FreeSWITCH server is remote (I don't leave it sitting around my parents place), it needs to communicate over an IPv4 NAT. The out of the box configuration didn't seem to work, but with a lot of diddling around with settings I managed to get it to connect.

To get inbound and outbound calling working, I needed to turn on stun, rport and turn the keepalive time down.

The MBU 400 is definitely an aged device which doesn't support a lot SIP features, notably there is no support for any type of encryption at any point in the communication process. Nor does the device support TCP SIP connections, which I prefer over UDP for a variety of reasons (which I might get into some other time). Codec support is pretty sparse and I ended up with vanilla PCMU audio.

Some conclusions:

The device is out of production. Don't buy a new one. Support has expired from Aastra too.

Nice for setups like my parents, it answers legacy POTS calls by default, but automatically dials out on my SIP circuit.

Works with FreeSWITCH for inbound and outbound dialing, but I haven't tested other features like message waiting or holding calls.

These days voice is pretty important, and the backend infrastructure which implements it is in a decades long process of migrating from the traditional POTS (Plain Old Telephone System) to an all IP phone system. FreeSWITCH is definitely going to be on the platforms that ushers in the next generation of telecom. While I have some reservations about how the project is developed and maintained, it has a lot of things going for it like stability and a remarkable feature set.

Using FreesSWITCH on OpenBSD might seem like a good idea seeing as how OpenBSD has the spectacular pf firewall, excellent security history and doesn't move very far in weird and zany directions.

FreeSWITCH on the other hand can't seem to stop moving in weird and zany directions. They (even after moving to stable release tarballs) suggest that checking the source out from git is the best way to the most current and stable versions and don't blink twice at dragging the entire source tree of their dependencies into their git repository. The FreeSWITCH developers attitude towards using system versions of their dependencies ranges from aggressive no's to rampant apathy. I understand their reasoning (which is not exactly wrong), though for me this is pretty odd considering that pretty much every other major project doesn't have this problem.

So OpenBSD and FreeSWITCH... Where to start.

At the time of writing there is no port of FreeSWITCH for OpenBSD, or any substantial package built for any major open source operating system. Nor is there likely to be without some serious effort. The only way to use the software is to jump though the git checkout hoops and run their gigantic build process through from start to finish (yawn). Debugging their build process on other operating systems than linux is a pain as well, given the dependency on stuff like gnu make, the position of the planets in the night sky and the inclusion of dependencies in their source tree.

There have been thousands of hours of effort put into making those dependencies 'work' properly on OpenBSD (nevermind all the other platforms out there). And replicating all that work into FreeSWITCH source tree just seems dumb and a waste of time (which it is).

My proposed solution (and admittedly a work in progress without a finish line in sight) is the creation something along the lines of a shallow fork of upstream FreeSWITCH that could actually be used as an OpenBSD port.

First order of business is the build system, and again since we're talking about OpenBSD, I am not talking about using autoconf, gnu make, cmake, imake, scons, or any number of build suites. Really, I'm just talking about vanilla OpenBSD make (here is an interesting thread on BSD Make). Of course, use system libraries or existing tested ports wherever possible. The source tree should contain just those files actually needed for creating a bare installation

There are a long list of modules that also need porting, including some core requirements like mod_sofia.

After that there needs to be some work done on things like moving configuration to /etc, logs to /var/log and various other activities consistent with making FreeSWITCH a valid citizen on OpenBSD.

As I said, this is a work in progress, you can see the progress here on github.