Analytics Tracking Code

Showing posts with label FreeSWITCH. Show all posts
Showing posts with label FreeSWITCH. Show all posts

Sunday, June 2, 2013

FreeSWITCH on OpenBSD - Project Status 2013-06-02

I've finally gotten around to making new headway with the FreeSWITCH on OpenBSD project. Although I can honestly see at least year (or more, really) of labour in front of me to produce a high quality port which I would be content to run my voice services on.

At the moment, I have a semi functional build which compiles a binary capable of executing just past the banner. I haven't checked the last call trace yet, however it looks like we are breaking just after the process forks and spins up a bunch of threads.

Recent Work

I merged a commit today that replaces the hash table wrapper that used to point at internal sqlite APIs to a the public hash table implemented by APR.  This is in reaction to an instant crash bug that I was encountering when the old system tried to access the internal sqlite malloc code.

I'll note that the original implementation of the hash table stuff used APR in the good old days (2008) and was replaced by Anthony for reasons that I am currently unclear about.

The results tested well in an impromptu set of test cases I whipped up to see if things should work, and the configurations loaded successfully, however the test of the new implementation really will only happen down the road when we start flinging calls around. 

Observations

I find the code style of the FreeSWITCH developers difficult to read for a couple reasons:

  • Long symbol that_describe_what_should_be_happening_like_this
  • Long prototypes that disappear off the edge of my monitor, I've seen lines with more than 180 characters which is a bit much.
I'm not going to whinge about the code style too much since it is what it is, however I've voiced my official note saying I don't like it.

Another issue I have is with the munging of dependencies. What I mean here is that the developers have taken a number of liberties in changing the internals of some dependencies. I suppose that they had their reasons, however it does make me twitch.

The more I fiddle with the internals of FreeSWITCH, the more I approve of the projects that have come from the OpenBSD guys. Especially when it comes from the perspective of portability, where the dependency trees are vanishingly small.  The FreeSWITCH perspective is somewhat along the lines of "ok, this pile of kitchen sinks seems balanced, don't fuck with it".



Current tasks

There are couple items to do right away. The first is spin up the module loading code, port some modules, and verify that the core modules are loading in what appears to be a correct manner.

Also I noticed that I am statically linking my internal libfreeswitch library and that needs to stop.

Down the road

I really dislike the manner in which freeswitch loads its configuration. On the horizon is a new launching and configuration loading change that makes me less twitchy. I'll make sure that everything I do here could be conceivably imported upstream.

Also, there are couple areas that I think may need special attention, memory handling and threading

Summary

There is lots left to do!

Thursday, March 28, 2013

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.