Depth of Knowledge

Thoughts from a tech consultant.

Aastra MBU 400 and FreeSWITCH

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.

Aastra 420d Portable handset which connects to MBU 400 base station, supports multiple handsets
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.
  • Buttons are a little small, and the ergonomics kind of suck.
Modern implementations like the Cisco SPA232D and correlated SPA302 portable handset does everything the MBU 400 does and much better.

FreeSWITCH on OpenBSD

Been a while since I posted. If you’re reading this post you, you probably came in from your favourite search engine while searching for OpenBSD and FreeSWITCH.

FreeSWITCH is a software voice switch which handles any manner of voice related activities.

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.

Copyright Modernization Act - My View

For some pre-reading for this article:

I am not satisfied by what I read about the upcoming Copyright Modernization Act. As a technology industry expert I am quite familiar with the methodologies and rationale involved with the implementation of Digital Rights Management. 

Most importantly is the implications around digital content locks and their viability.

Foremost in my concern is that otherwise legitimate usage of digital content is permanently restricted simply by the presence of a digital lock of any kind. The implications of this is that legally purchased content can only be accessed through pre-approved processes and devices. Otherwise fair access to the locked content becomes illegal under the provisions of the new bill.

For instance, my mother has been a subscriber to Audible.com where she purchases recorded audio books which are stored in the DRM encumbered audible format. However, one of her intentions for purchasing the content is to be able to consume it while in her vehicle.  Unfortunately her vehicle does not include authorized audible decryption software, so it becomes necessary to convert the encrypted files to a format which the vehicle does comprehend (in this case MP3). In no way is this an illegal activity, nor should it be under any appropriate copyright law, however with the new digital lock provisions, doing this becomes illegal.

There are a number of other consequences to the act that I am uncertain are covered by exemptions such as recovering installation keys to installed software products on Microsoft Windows and viewing encrypted content over an unsecured monitor.

Effectively the law has the digital locking aspects backwards, where fair dealing with content should trump any locking provisions, not the other way around.

SMART Payout Software Demonstration in .net WPF

I wrote a WPF demonstration software for use with the Innovative Technology SMART Payout recently. I am available to provide software consulting services around this device and its cousin the SMART Hopper.



Features:

My software is a good demonstration of how to interact with the device. Naturally it needs to not look crummy :)  Was written in C# .NET 4 WPF inside of Expression Blend 4.


Comments

Kacper Wikieł
Can you publish your code or send it to me?
Ted Bullock
Sure, I can track this down. Might take a day or two though.
Ted Bullock
Sure, I can track this down. Might take a day or two though.
Palacios Tebal
hi,

I am programming in wpf and nv200, and I have many problems with device or library. Can you provide codes of your software ?, I could send you my code and software.

Many thanks,
Miguel.
Ted Bullock
Yes, I have the code.
Ted Bullock
Old comment, sorry.

Ok, I'm not sure how stable the device is in deployment. My observations while developing against it weren't great though.

Had some firmware issues though (couldn't get it to run on current firmware) end result of which was to revert to previous version.

Support from the manufacturer was alright, I got an engineer to walk me through a variety of features on the phone with very little in the way of preliminaries. Although it was a call to the UK which wasn't cheap.
Ted Bullock
Oh sorry, haven't been watching for comments.

Uh yeah, I might still have the code around somewhere. I'll look. Do you still need it?
Nemanja
Is this device stable? I'm developing app for NV200 Smart Payout and Smart Hopper in C# 4.0.
I noticed some problems with device or provided library.
Дмитрий Сергеев
Can you provide codes of your software&

How to Secure a Computer in an Hour

I’m not a security expert.

Well, let me say that I am the most technically skilled security expert that I know, however, I do not consider myself to be a security expert. My general approach to security is, turn off as much as possible, block everything except those few things I need and while I am at it, update everything to fix as many vulnerabilities as possible.

So I am now administrating a server rack full of equipment running a slew of operating systems from linux to OpenBSD, to Windows Server 2003, 2008 and 2008 R2.  Now there is nowhere nearly enough time in my day to audit these systems for vulnerabilities, and beyond running windows update, patching the linux/bsd machines, turning features off and putting a pf firewall in front of the entire rack, I am not certain what else I should be doing?

I’d love some input here? If I were to spend a single hour tomorrow above and beyond my regular work securing the services, where would the best place to start be?