Alanta Web Conferencing Released to Beta

I’m pleased to announce that the product the small team at Alanta has been working on for the last 18 months is finally in beta. Now, this is a true beta, rather than a Google-style “forever-beta”, so use at your own risk. But we’ve been dog-fooding it ourselves for the better part of six months, and we decided it was time to let other folks start banging on it. As Matt Mullenwegg said, “If you’re not embarrassed when you ship your first version you waited too long.” And if that’s true, well, we haven’t exactly waited too long.

If you have only a small amount of courage, you can start using it here:  http://alanta.com/

Some Details

Alanta is the first completely in-browser web conferencing and collaboration solution with acoustic echo cancellation. There are other in-browser solutions, like DimDim and TokBox, but because they use Flash, and because Flash has no echo cancellation, they’re basically unusable unless everyone in the conference is wearing headphones. We managed to add echo cancellation by using Silverlight as our platform, which gave us raw access to the audio and video streams, though precious little else. As a result, we ended up having to rebuild the entire web conferencing stack, more-or-less from scratch: but the result is a solution that can offer features nobody else has.  

Some Important Caveats

1. We’re still working through some stability issues with our media server. As a result, sometimes sound will cut out on one or more parties. Our best recommendation is to (a) refresh your browser when this happens, and (b) don’t use this yet for mission-critical stuff. Like I said, this is a real beta.
   
2. At the moment, this is all just running on one aging server for which we’re paying $70 / month. We’re not expecting a ton of usage right out the gate, but if we’re wrong, we might hit some near-term scalability issues.
   
3. We theoretically support Macs, but our testing shows that this support is still pretty iffy. It turns out there are important differences in how various sound card/web cam drivers behave under Silverlight, and these differences seem to be worse on Macs. We’re working to improve this.  Still beta, remember?
   
4. There’s no hard-coded limit to the number of concurrent sessions in each call, but we’ve noticed that our media server starts acting weird after four or five. We’re working on that. Have I mentioned that this is beta?

Some Additional Details

1. This all free at the moment – we haven’t even built the piece to charge folks. We anticipate that we’ll eventually offer a free and several paid levels.
   
2. This is all written in Silverlight. Some folks have wondered about our choice of platform, mostly because of the limited reach of Silverlight compared to Flash. We don’t think this is going to be an issue in the long term: Silverlight had ~25% reach when we started, is now up to ~70%, and is continuing to grow at ~2% a month (see riastats for details).  HTML5 isn’t going to be an option for at least five years, as the W3C/IETF committee tasked with working on realtime web conferencing technologies only spun up last month, and is likely years away from a working spec, let alone widespread browser adoption.
   
3. We built the media pieces basically from scratch. We used CSpeex for our audio codec and ported the Speex preprocessor from C to C# for the heart of our audio DSP, but we rolled our own video codec, media server, and protocol. It would have been nice to use RTP and a concomitant RTP server, but Silverlight doesn’t support UDP, and we have some long-term plans to fix the problems inherent in real-time two-way communication over TCP/IP that required us to control the underlying protocol. Our acoustic echo cancellation is the piece that needs the most long-term work: we’re measuring about 90% echo removal in our tests, which is OK for 2-3 people in a room, and lots better than Flash, but the 10% that remains is still too annoying when it’s multiplied by lots of simultaneous participants.

Because all this is happening is completely in-browser, the next step in our strategy is to offer a simple API that websites can use to add real-time communications to their own sites.  Imagine car dealerships talking with customers in real-time as they’re browsing their site, or Nordstrom’s “personal shoppers” talking with their clients, or, really, any website with a high-touch sales model. Or use it to turn casual games into social games: Scrabulous meets Chatroulette (presumably without the penises).  Or lots of stuff we haven’t thought of yet.  Our bet is that companies will be looking to distinguish themselves over the next few years by adding real-time communications to their websites; and that customers will grow to expect it.

I’d like to offer a special thanks to Andre Kirchner and Roman Buchyn, the two other Alanta developers, and to Alex Ermolaev, our CEO.  You’ve been a great team to work with, and I look forward to conquering the world with you.

URL Rewriting Module Interferes with WCF REST Service Processing

I spent most of yesterday and a good chunk of this morning troubleshooting a problem with a WCF REST service I’ve been trying to create.  Specifically, I had a brain-dead simple WCF service that looked like this:

    [ServiceContract(Namespace = "AjaxRoomService")]
    public interface IAjaxRoomService
    {
        [OperationContract]
        [WebGet(ResponseFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Wrapped)]
        string SayHello();
    }

The implementation looked like this:

    public class AjaxRoomService : IAjaxRoomService
    {
        public string SayHello()
        {
            return "Hello";
        }
    }

And the actual .svc file looked like this:

<%@ ServiceHost Language="C#" Debug="true" Service="Alanta.Web.Services.AjaxRoomService" Factory="System.ServiceModel.Activation.WebServiceHostFactory" CodeBehind="AjaxRoomService.svc.cs" %>

Note that I was using the WebServiceHostFactory, so I didn’t need to have anything in my web.config file.  Simple, right? Everything should have worked, right?  But when I tried to call the service (i.e., by navigating to http://localhost:51150/Services/AjaxRoomService.svc/SayHello), I consistently received a 404 error.

I did my standard Google searches, but all the issues people described had to do with running the service in IIS, and I wasn’t even getting that far: I was just trying to get this running under Cassini, in Visual Studio. 

But after much troubleshooting and more than a little swearing, I finally put my finger on it.  We’re using a simple URL rewriting module that shouldn’t have been interfering with this, but it was.  The trouble was in this particular line of code in the URL rewriting module:

HttpContext.Current.RewritePath(rewrittenPath);

A debugger showed that it was rewriting the path from “/Services/AjaxRoomService.svc/SayHello” to “/Services/AjaxRoomService.svc/SayHello” – in other words, it wasn’t making any changes.  But as soon as I changed it to only rewrite the path if the path had actually changed, my problem went away:

// Only rewrite the path if the path has changed, as otherwise it interferes with .svc request processing.
if (string.Compare(HttpContext.Current.Request.Path, rewrittenPath, true) != 0)
{
    Debug.WriteLine(string.Format("Rewriting {0} to {1}", HttpContext.Current.Request.Path, rewrittenPath));
    HttpContext.Current.RewritePath(rewrittenPath);
}

Not exactly a dramatic discovery, but I figured it might benefit someone else at some point, so I’ll toss it out there for the Google indexer to discover, in the hopes that it helps someone else someday.