Taking a SIP from the VoIP fountain....

Bad metaphorical post title aside (ouch),  I am currently investigating "cutting the Vonage cord" (another bad metaphorical allusion).

I haven't had a proper land line in 10 or so years. Vonage has served me well.  But, I find that with everyone in my family owning a smartphone, we rarely use our home phone line.  As anyone who has called us will know, sometimes we can't find our "wireless" phone(s) -- is it buried in the couch cushions again?  We are also horrible about retrieving voice mail (even though we have Vonage forward transcripts to our smartphones).

Really, outside of having a number "for our house", we don't use it much.  But our monthly bill for this convenience is over $30 per month!  I know, I know... why don't we just find a lower cost VoIP provider?  But that still requires us having to swim in someone else's pool (sorry about that, there I go again).

But, hey... wait a minute!  I am a software engineer who specializes in communication.  There must be something I can do here.  All I need is some way of getting my home phone number to forward to a PBX under my own control.  Think of the things I could do!

I could...

• Have the call ring to any smartphone that is registered on my Wi-Fi (i.e. mine and my wife's phones when we are home)
• Forward the call to voice mail immediately if we aren't home.
• Register another "business" phone number that does something similar... basically track me down (e.g. smartphone or home number or voicemail)

..and so much more!

So, I start looking at FreeSWITCH and Asterisk.  Wow!  I need a book, or two, and a lot of time.

(Another variation of swimming in someone else's pool).

Okay, so do I really need a full blown PBX to do this?  Nope. I can do most of this with a cheap DID (Direct Inward Dialing) provider that could forward to a SIP proxy (of my own configuration or design).  (I won't go into details about SIP here... just know that it is the standard Internet way of locating and setting up calls. It is pretty complex too, but it is fundamentally a protocol specification.)

So, I start looking at OpenSIPS and over SIP server solutions.  It looks like all the pieces are there to do what I need. I just need to write a script....

Okay. My engineer senses start pulsing again (sort of like Spiderman's senses but rather than danger it warns me that I am about to use a complex system to do what seems so simple in my head).  I don't want to solve my problem with a simple OpenSIPS configuration... I want to intimately understand what is going on inside of SIP and implement just enough to do what I want.  How better to learn a system than to dive right in and try to build one yourself?

By learning OpenSIPS, I'll become an OpenSIPS expert but I won't really know how SIP works.   Sure, they take care of the plumbing, but I am interested in the plumbing.

So, I start with the SIP RFC .  Well that's over 200 pages!  Okay, Todd.. slow down. What do I minimally need to let two VoIP user agents (i.e. phones or smartphone apps) talk to each other?

I start from there.... and here I am today.  I've got some primordial code handling SIP registrations over UDP.  I have a long way to go, but I am going to have fun with it and I am going to learn a lot. 

Maybe I'll finish enough of it to put it out there as open source. Not an OpenSIP competitor, but a super simple, super hacky way of creating your own lightweight home VoIP system.

Note: Currently using LuaJIT and Copas socket server to play around with SIP and I as I mentioned above, I've got Registration working.  Ooooh... so much fun!

Hackable (Software) Things

I like hackable things. I'll keep that vague, because I am in a vague mood.
See if you can spot the common theme:

1. Emacs
2. TeX / LaTeX
3. Forth (interactive on an MCU)
4. Snabb Switch
5. Smalltalk  (Squeak)
6. Unix command line (awk, sed, kornshell, bourne shell, maybe bash, etc)

Okay... why?

They are worlds at my fingertips.

They don't use XML.

They are extensible.

I can make them do useful things.

With the exception of #3 (Forth), none really manipulate the "physical world".

Speaking of Forth... having shipped a few professional devices built with Forth, I still haven't found anything nearly as useful or fun for MCU work.

Something I would love to have for embedded MCU work:

A nice REPL / Editor environment (host side, please) for manipulating/deploying eLua on MCUs. 

eLua has poor interactivity support, but I wonder if remotely instrumenting it is a better approach... maybe via ZeroBrane or Emacs?

Mutter... Adventures in VOIP/messaging systems

Over the past couple of years I've been playing around with a "toy" Mumble server I developed.
Mumble, if you don't know, is a popular gamer VOIP and messaging system.  It is open sourced and has clients running on Windows, Linux, iOS (iPhone) and Android (I prefer Plumble).   It has a published spec for communication so it is relatively easy to build a minimal server.  I've built one in the past in Erlang and have recently started one in Lua(JIT).

Why would I want to implement my own Mumble server (I'm calling it Mutter) when a perfectly good one exists as part of the Mumble project?  Well, I am curious how many interesting things I can do with a compliant server without touching the client software.

Some of my experiments involve creating additional levels of authentication (e.g. a query response from a server bot, additional detection of client OS/hardware stuff, etc) as well as the potential to bridge to other VOIP or messaging systems.

Other things I am curious about playing with is "adhoc" conference calls that could spawn quickly and privately in the cloud. 

Right now it is mostly for fun. I've got basic messaging and TCP voice channels working. I am not interested in building a full blown Mumble server (that already exists!) but curious as to what can be done minimally....