I found a cool C# library for use with Asterisk (AGI) and .NET: MONO-TONE. It looks promising as an easy way to deal with AGI from C#. I think that I'll be extending it to support FastAGI as well, and contributing the changes back. Nice work Gabriel!

I'm doing my own realtime support for Asterisk, in an attempt to make it scale. Asterisk is nice software, but straight out-of-CVS, the performance for high volume (say, over 20,000 clients) sucks. There are also other inconviences with using a file-based store to determine how to route calls. Mainly, it's inflexible and hard to achieve high-perf when everything is based on a large .conf file. Not to mention that Asterisk uses linked lists for everything so looking up any user is an O(N) op (and parsing the users file is O(N*N) by default!). So, I'm going to put my own logic as a replacement for some of the critical parts.

One of my concerns was performance. Since I'll have multiple Asterisk clusters banging on my .NET code (via SOAP), I wanted to ensure the whole end-to-end process was fast enough.

I used gSOAP to create the C code on Linux. gSOAP is seriously nice. At least an order of magnitude easier to use than I expected any SOAP library that works on Linux would be.

I created a simple test. I made a database with phone numbers and codecs. The idea is that when an incoming call comes in, Asterisk will use my code to SOAP over to my Windows machines, get the data, and then go on its merry way.

My Asterisk machine is a P4 2.4GHz, 512MB RAM (but, I have a Gnome session running on it). My Windows XP machine (I tested against my desktop) is a P4 3GHz HT, 1.5GB RAM. I'm running ASP.NET 2 Beta 1 and SQL Server 2000.

The test program consists of a loop (count 5000) that generates a random number, then uses gSOAP to ask for the codec for that number. Simple, tight.

The results on Linux are particularly impressive. Each instance of the test app only used a max of 4% processor, and under 1MB of RAM. The bottleneck was definately inside ASP.NET. To simulate more load from other machines in a cluster, I ran 1, 2, and 4 instances of the test program. Also note that background tasks on the XP machine used up about 10% of the CPU.

Results:
 Single process (5000 total requests): 
  Total time:                   18 seconds (0.0036s/request)
  Requests per second:   277
  ASP.NET/IIS CPU:          30%
  SQL Server CPU:            4%

 Dual process (10,000 total requests):
  Total time:                   23 seconds (0.0048s/request)
  Requests per second:   384
  ASP.NET/IIS CPU:          60%
  SQL Server CPU:            7%

 Quad process (20,000 total requests):
  Total time:                   42 seconds (0.0052s/request)
  Requests per second:   476
  ASP.NET/IIS CPU:          80%
  SQL Server CPU:           10%

These results are encouraging enough that I'm not worried of the performance impact of using SOAP with Asterisk. My target was to have a response in less than 0.1 seconds. Although, anything under 0.5s would be quite unnoticable to a client. Even in tests with more threads, my single request response time was always way under 0.1 seconds.

Also, as far as I know, Whidbey Beta 2 (the version I'll go live with) makes some performance improvements. And also, IIS6 on Windows 2003 is much faster than IIS5.1 on XP. At any rate, a single proc desktop machine serving 476 RPS? That's pretty damn good perf if you ask me!

Out of all my experiences (heh) with Linux, Mono has to be the best one. It just works. I'm writing a set of web services to manage Asterisk. Things like adding users to the dialplan, configuring incoming numbers, voicemail, etc. I wrote a library to deal with the config files in VS2005, and tested on VS2005. Drag and drop, and bingo: it works just fine on Linux.

I just got a nice queued reload finished for Asterisk via my webservices. A little bit of threading code, and 40 lines later, it's done. Build, drag and drop (Samba), and presto. Works, smoothly. I just can't stress how cool it is to be able to work with MS tools, use shared code libraries with Windows, and then just drag and drop over the network and have it running right alongside with Asterisk.

We're doing a pretty ambitious project, the entire front-end on Windows, and Linux for everything to do with the voice. So far, everything's been a breeze, thanks to .NET. Not having to write in C, or ... PHP <shudder> ... is so nice. At any rate, we're hoping to launch by the end of the month. So if we do, I'll go into more detail on what things .NET let us just speed right through.

And already, I've made a new convert. We hired a guy who has worked with Java and PHP, never with .NET. You should of seen his face and heard his comments when I took him on a whirlwind tour of ASP.NET 2 and web services, adding in xcopy deployment to Linux in to boot. Wow :).

I ran into an issue with Asterisk, mainly that you can't dynamically control which codec gets accepted. You have to make your choice “up front”, when you define a user/peer. This means, for example, if you want to say “for this call, use the GSM codec”, you can't. You've got to let Asterisk's code work things out, and even it works out on your side, the callee might decide to use a different codec anyways. This means that I end up declaring various peers: peerX-g729, peerX-ulaw, etc., and then have to swap them out when I call Dial.

Even worse, there's no easy way of completely avoiding transcoding when you want to. For instance, I have several phones connected to my server. Some use GSM, some use ULAW, some use G.729. They all use the same dialplan, and ulaw is usually negotiated for the termination. That means my little server gets nailed doing all this transcoding. This is even sillier when you realise that my termination provider has big hardware and will handle transcoding for me. So, without making a seriously complex dialplan, I'm stuck.

Well, IMO, that sucks.

So, I actually dove into the code, and patched it: http://bugs.digium.com/bug_view_page.php?bug_id=0003346 I've yet to see if this will get into the actual codebase. I sure hope so, since I *hate* forking. Indeed, that's one major criticism I have of the “you can just modify it to suit your needs“ claims of OSS. But, the ones in power seem quite rational, so there's some hope... maybe :).

Asterisk is a large project, but thanks to Visual C++ 2005, I could navigate it (New Project From Existing Code is very useful!). Unfortunately, I think there's a bug, as VS takes up 1.4GB of memory when editing this project. However, it's still quite responsive -- except for the Virtual Memory Warning from Windows, and the initial slowness, I'd never notice it was eating all that memory.