the news

I hear alot of talk about how Asterisk is broken, or not, but rarely get to experience it myself to make my own decision. Coming from an Asterisk background, I really liked Asterisk and that they pioneered a lot of the open source telephony stuff.

But yesterday I ran into an Asterisk installation where the end-user had managed to get his Asterisk box to register with a contact header of “s@127.0.0.1″

Now I was completely dumbfounded by this. The user actually had this setup working with a few providers and expected it to work everywhere. Why? This is in violation of all the RFCs I’ve ever read.

From the RFC:

 The Contact header field provides a SIP or SIPS URI that can be used
 to contact that specific instance of the UA for subsequent requests.
 The Contact header field MUST be present and contain exactly one SIP
 or SIPS URI in any request that can result in the establishment of a
 dialog.  For the methods defined in this specification, that includes
 only the INVITE request.  For these requests, the scope of the
 Contact is global.  That is, the Contact header field value contains
 the URI at which the UA would like to receive requests, and this URI
 MUST be valid even if used in subsequent requests outside of any
 dialogs.

More frustrating is that because other providers have learned to work around a broken box like Asterisk, I now had to, also, or the customer would think my system was broken and not theirs.

This is really lame. If a config is setup in an invalid way it should not be allowed by the underlying library - not just ignored! There is absolutely no practical point in having a Contact: header of localhost!

!@#!!#

I am pleased to announce the submission of mod_nibblebill for review and hopefully acceptance into the trunk of the FreeSWITCH project.

OK, it’s rev. 1 and needs a bunch of work. Got it. But it’s very functional and it does infact function!

Take a peak at the extension documentation I wrote up on their WIKI for details. The module basically handles real-time billing for lots of simultaneous calls in a way where you can give people credit that they use up and their calls get terminated when they have no more money.

Soooo many uses for this!

Let me know if you have questions, as usual! Drop me an email

Grids, grids, grids - everyone wants to make a cool grid rendering engine. Both YUI and Dojo seem to include out-of-the-box functionality to make a cool datagrid that’s similar to, dare I say it, .NET’s built-in grid rendering engine. But cooler, of course, and in JavaScript.

I love the grids they’ve come up with - specifically Dojo’s, where they’ve actually managed to render only the portions of the grid you are viewing until you scroll elsewhere. This makes it reasonable to support grids with rather large sets of data and save on rendering time until you need to render an area. Cool stuff.

What I’m not impressed with is how inflexible the inbound datasets are to these grids. Not a one seems to believe in complex XML anymore - all the cool kids now seem to be using JSON. Which is great if you’re writing your application from scratch and have that much control. But if you don’t, you’re sort of screwed. The XML parsing engines as they relate to datastores which can be used in grids are basically non-existant in both YUI and XML unless you have a very flat XML structure. Neither framework will go deeper then a single element without overriding the default data stores or writing your own parsing tool (for which you won’t find any directions on how to do).

It boggles my mind that XML, in particular, has such poor support when the browser itself provides such great support for XML as a data type. Aside from the obvious parsing functions required natively to parse HTML, you have XPath, XQuery and the DOMNode/DOMDocument structure itself built-in to every single browser out there. Why not adapt this data structure to work with these DataGrids using some of these available tools? It seems completely reasonable to me to allow for an XPath query to find certain nodes in a dataset and make them into your datagrid - and because we’re just talking about DOMNodes being returned you can still retain the cool functionality of editing and what not. And of course, you can pass all this good stuff back to any XHR command you wish in it’s native form.

So I guess I’m making the case for more formats (especially XML) to work with datasets inside DataGrid’s. I can only hope we’re not all force-fed JSON, because it’s not quite there yet when it comes to a reliable, expected output option from every app we may want to interact with. Sometimes we are writing a UI for a back-end that’s already been written and just needs an overhaul. Not all of us get to write something brand new and sparkling in Ruby with JSON support.

Here’s to hoping…

If you read my previous blog, well. I told you this was a roller coaster! I’m starting to feel manic.

Ruby, on the other hand, is pretty solid, well documented, and cool.

After fighting with stupid gems all day, I decided to just let people include their own with a simple wrapper. So I started playing with modules.

Modules really rock. They are so freakin simple it’s unbelievable. Modules are sort of like namespaces but you can build upon already loaded ones. Basically, what this means to me is that I can have a base/core module that loads all the files in some module directory, and then figures out dynamically what’s been loaded.

Here’s a practical example (from the previous blog).

Let’s say we want to be able to let a system administrator installing our software decide where users authenticate from. The avilable options *we* thought of were Active Directory, Local Database and Linux PAM. But the reality is not everyone will need all of these options, but someone might need two of them (like local DB and active directory - such that when A.D. is down you can still get into your machine). How do we do this?

First, the individual modules would look something like this:

module MyAuthFramework
  module AuthViaLDAP
    def Login
    # Do login validation here, possibly through a gem
    end
  end
end

You’d save that to a folder somewhere, along with maybe another module, like this:

module MyAuthFramework
  module AuthViaPAM
    def Login
    # Do login validation here, possibly through a gem
    end
  end
end

Note that the two modules share the same method name and base module, but the module namespace in the middle is different. Loading both the above files from the same Ruby script effectively mixes them together, creating this:

module MyAuthFramework
  module AuthViaPAM
    def Login
    # Do login validation here, possibly through a gem
    end
  end

  module AuthViaLDAP
    def Login
    # Do login validation here, possibly through a gem
    end
  end
end

Now, in a base file somewhere, we can use a nifty constants method built into modules to accurately see what’s loaded and cycle through each class, calling it’s login function with some credentials we received. Whoever returns a success could be declared the winner!

module MyAuthFramework
  def Login
    MyAuthFramework.constants.each do |modulename|   # Cycle through all modules
      mod = Object.const_get(modulename)                    # Instantiate the module
      mod.Login()    # Call the method in each module
  end
end

This routine will effectively call the Login() methods in both the included modules, LDAP and PAM.

cool, huh?

Check out the docs for more goodness.

So I am now in week 4 of trying to switch to Ruby on Rails from CakePHP. It is truly a roller coaster ride.

On the upside, I have been very, very impressed with the true object-oriented nature of Ruby. Really, I can’t say enough here. The fact that you can override and extend pretty much anything in the language to your liking is just awesome. Everything is an object - just like Java or Javascript - but without the annoyances of an overwhelming required number of definitions or memory concerns. You can even overload symbols and other operators. The built-in introspection and modularity is just slick.

On the downside, I am continuing to have trouble taking advantage of this “goodness” so many speak of with Rails. I don’t think it’s because of lack of trying. I think it’s due to lack of good documentation.

As a practical example, let’s say I want to do something as simple as create a login generator that can integrate with LDAP as well as a local database. This is a practical scenario I’ve run into in the PHP world - I want to have Windows users use the same login/password on an intranet site as they do for their Windows credentials. But I also want a fallback mechanism so I can login when LDAP is broken, or when I need to create a special account for, say, a contractor who only needs temporary access and should not be allowed onto the Active Directory network. In PHP, you simply go to www.php.net/ldap for the LDAP pieces, or maybe do a search for a PECL library that handles LDAP for you. Then you cobble together a quick model, view and controller using CakePHP’s scaffolding and get the login and logout stuff done. Or you extend the CakePHP authentication modules that are well documented right within the CakePHP manual. Probably about two hours of work.

Now let’s apply this to Rails. Not knowing where to start, and not having a search box on the RubyonRails API page (there isn’t one - how silly), I try some Google-fu to find the equivalent in rails. The first relevant hit is a page that seemed like a match - http://wiki.rubyonrails.org/rails/pages/Authentication . An authentication wiki page on Rails own site. Seems legit.

But then I load the page and the first thing I am greeted with is:

“This article is part of the confusing world of Authentication in Rails. Feel free to help: AuthenticationNeedsHelp.”

ehh

Then I start examining the list of available plug-ins, gems and solutions to authentication that people have listed. Almost all of them are labeled either deprecated, incomplete or “good for beginning Ruby on Rails user.” Fine, I think, maybe one will work and I just have to find which one. So I start clicking into each page.

LoginGenerator seems relevant.

But scrolling through that page, the text and comments suggest that it no longer works for versions past 2.0.2. But don’t worry - it links to ANOTHER site that swears to be the real solution I am looking for! That’s here - http://wiki.rubyonrails.com/rails/pages/Acts_as_authenticated .

Woohoo! This page starts by proclaiming “Yay! (read why)” and then explains that THIS is the right place for an authentication system generator. As if the page already knew that all those OTHER pages one might stumble upon prior were total crap. But before I get too excited, I click on the link which states that “…you really want to see the official Acts As Authenticated Github.” So I bite - I click the link, and am whisked away to the project page, which states right at the top:

“Please note that acts_as_authenticated, is no longer developed/maintained”

WTF?!?!

So we go back to the drawing board - all the way back to the Wiki page we started with - and look for more. Restful_authentication seems to be the top item, so maybe I should have started there. Again, I click it, and the first comment mentions that some material links to the wrong source. ugh. It then lists four locations to get information. I start with the first one - the official plug-in homepage. It says it’s for rails 1.2. But I’m on Rails 2.2.2. [Sigh] Do I try it? Or go back to the drawing board?

Maybe I am missing something, but one strong part of PHP was the manual and the comments - the manual matched the methods and classes that were actually available almost 98% of the time, and were never incomplete in terms of broken. Does such a resource exist for Rails where I can go to a webpage to find plug-ins and they reliably work and are available? This has to be my #1 frustration with Rails at this point.

If you have comments, please add them. I’d love to hear solutions to how to better manage rails plug-ins, gems and other “goodies” that seem to just be scattered everywhere.

I join in celebrating FreeSWITCH’s 1.0.2 release! The project is really gaining momentum and looks very promising, and I’m happy to be along for the ride.

I am also honored to have the TCAPI project mentioned in their announcement as a “future look ahead.”

What happened to TCAPI, you may ask?

TCAPI is very much alive and well but admittedly we are working very hard on getting some core pieces in place first before inviting the masses to join. I really am only looking for dedicated contributors at this point who want to spend time and energy contributing to the project. The project has morphed slightly along with another project (well known to many of you). While all the details are not yet public, I’m happy to share info on a 1:1 basis. Feel free to drop me a note if you are still interested in contributing to this project - email me.

In the meantime, if you haven’t played with FreeSWITCH yet, hop to it!

I thought it would be good to share my experience with installing Ruby on Rails w/ CentOS 5.2.

It didn’t get off to a very good start, namely because the person before me had already tried to install rails unsuccessfully. The issue appears to stem from the configure mechanism in Ruby which links against zlib libraries that may or may not be correct. Undoing this was non-trivial.

Specifically I was receiving this error when doing anything with gem:

/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`gem_original_require': no such file to load -- zlib (LoadError)


Installing zlib and zlib-devel libraries on CentOS did not fix the problem because the linking had already occurred back in the ruby build (I think, anyway). I decided the easiest thing was to do a “rip and replace” fix by ripping out all of ruby and the associate gem software and re-installing. I did this as follows:

1. Remove all packages that were installed via yum

rpm -qa | grep ruby
yum remove [insert results from output above here]