Mono or CLR in FreeSWITCH

Mon, 13 Oct 2008 22:43:10 GMT

mod_managed is now in the FreeSWITCH tree. This replaces mod_mono, and allows selection of either the Microsoft CLR or Mono 2.0+ as the runtime engine to use. All the interfaces, and most of the code, are identical for both versions. Modules written on Mono will work on the CLR version and vice versa.

Check it out.

Update on mod_mono in FreeSWITCH

Thu, 18 Sep 2008 02:24:38 GMT

FreeSWITCH's mod_mono plugin should now work fine on Linux. Additionally, it's in the Visual Studio Solution file, all you need to do is compile mod_mono (it won't build by default). There's also now support for running mod_mono inside FreeSWITCH inside another managed application, just in case you're embedding FreeSWITCH.

For more info: http://wiki.freeswitch.org/wiki/Mod_mono

Mono in FreeSWITCH - Experience in embedding Mono

Tue, 02 Sep 2008 02:04:38 GMT

Managed code? In MY softswitch? It's more common than you think.

A while back, I tried creating a mono plugin for Asterisk. The goal being that'd you'd be able to write in-process apps in decent languages, rather than resorting to C. Well, there were no standards of how functions operated (i.e., who's responsible for memory), and my requests to standardize these were met with hostility. (Actually, when I asked why they didn't refactor some stuff, like the multi-thousand-line switch statements, I was told "refactoring doesn't exist for C"... sigh.) But the real showstopper was that we couldn't figure out how to get Asterisk to play nice with mono as far as threads go. I had a very active Asterisk developer work on it with me, and he pretty much told me it wasn't going to work. Oh well.

When I stopped really being involved with Asterisk, I had seen a couple big Asterisk developers leave to start FreeSWITCH. It was mainly an idea at that point, to do things right and build a scalable, clean system. Well, fast forward a few years and FreeSWITCH has really come far. You can go read their site for more details, but it's a more flexible, scalable, and vastly cleaner VoIP platform. That's why, at v1.0.1, it already supports UDP, TCP, TLS, SRTP, IPv6, wideband codecs, and more. Oh, and it runs cross-platform, including Windows.

But the really great thing about FS is that it was designed to be modular from the beginning. And, it was designed to allow people build apps into it. It has some nice out-of-process extensibility, think Asterisk Manager and AGI, without the suck. [I wonder how many * flames I'm gonna get?] But also of interest, they designed an app API from the start. It's written in C++, and SWIG friendly so you can quickly add other languages (Javascript and Lua seem to be the most popular).

Well, the thought of running interpreted stuff in-process disgusted me, so I immediately set out to try to add Mono support. Much to my surprise, the FS team was extremely supportive. They helped me figure out all the bits of FS and the API I needed. In fact, one of the project leads told me, "Hell, if you're gonna write mod_mono, we'll give you checkin support right now.". A short bit later, we had mod_mono working!

Not satisfied with doing just apps, I turned to doing a full integration. A bit of SWIGwork later, and I had the entire FreeSWITCH header files SWIG'd and C# accessible. I found a few APIs that didn't import (varargs stuff, I think), but the FS team helped add some different methods to work around that.

The Mono side was pretty straightforward. We write a C/C++ module for FS that gets Mono up and running. Then it kicks off mod_mono_managed, which actually loads modules, runs initialization code, etc.
The biggest problem I ran into was a problem between SWIG and Mono. Mono would attempt to free strings with g_free, crashing on Windows. I wrote a SWIG-C# post-processor to tweak the SWIG code to avoid it; I'm not sure it's accurate, but we haven't noticed issues so far. A few things we ran into were quickly cleared up by the awesome people #mono. This week we'll be testing and make sure it's fixed in Mono 2.0.

So, the bottom line is that you can write any sort of module for FreeSWITCH, from simple apps and API functions, down to a full codec or endpoint, all in managed code (though, the interop might not be pretty sometimes). I've tried some simple stuff out in C#, F#, and Javascript (JScript .NET), and it all works fine. The code is in the FS SVN, under /freeswitch/src/mod/languages/mod_mono and mod_mono_managed. It's not part of the official build yet, so there may be a bit of work involved in getting it going. But I have heard from other people that they've gotten it working. Some info is here: http://wiki.freeswitch.org/wiki/Mod_mono -- Right now, we've only tested on Mono 1.9.1, but we're going to only support 2.0 as of very soon. (F# only supports 2.0, so earlier versions are irrelevant to my interests :).)

This is exciting for us, as it allows us to build *safe* applications that run in-process with the switch. But, unlike the embedded scripting languages, we get top-notch performance and access to complete libraries. We're combining this in-process approach with out-of-process (Event Socket, outbound) to get a robust and very scalable system. For our particular application, we have several GB of decision data that we keep in RAM on separate servers (which is in turn sync'd to SQL Server 2008, via a proprietary change replication system). For obvious reasons, we didn't want that memory being stuck in the FS process. Having Mono on both sides allows us to share code between the different systems, while still getting optimizations for both environments.

You can email me: mgg AT a t r e v i d o _ net or use the chat widget on the on my site if you have questions or problems getting it going.

I'll post a follow up once it's in the official build.

[Giagnocavo]Michael::Write() - FreeSWITCH

Mono or CLR in FreeSWITCH

Update on mod_mono in FreeSWITCH

Mono in FreeSWITCH - Experience in embedding Mono