1 - Call The Phone Number to Turn on the Light

2 - The VOIP Provider attempts to route the call via Asterisk running on Amazon EC2

3 - Asterisk rejects the call because no clients are registered

5 - Now a Ruby Rails App waits to send the caller’s Phone number when asked via REST web technologies

6 - The rejected call (step 3) is now diverted by the VOIP Provider to the pre-registered phone number.

7 - The pre-registered phone number is assigned to a cell phone which communicates via BlueTooth to a Cell Phone/Wired Phone Converter

8 - The ringing cell phone which has now been converted to an analog phone signal (Identical to one that would be wired in your house - RJ11 ) Makes it’s way to a FXO box.

9 - The FXO box has now converted the analog signal to digital and routes the signal using SIP technology to a second copy of Asterisk running in VMWare Player on an old clunker Compaq Deskpro PC

10 - The VMWare Image is actually TrixBox 2.0 configured to route the call from the FXO device to a VoiceXML Server.

12 - The "Drive" where "flag.txt" resides is shared out to 3 clients

1. The Host Compaq WinXP
2. Debian running virtually on Xen
3. WinXP running on a 4 year old toshiba that hosts the VoiceXML Server

13 - A C# program (ConsoleApplication1) running via mono on debian "sees" the existence of the "flag.txt" file and proceeds to open it.

14 - Normally the file contains "bluetooth" which then triggers ConsoleApplication1 to execute a bash shell script called "getCallerID"

15 - getCallerID executes a "wget" to retrieve via Ruby/Rest running on Amazon Ec2 the caller ID info.  The file returned ("index.html") is parsed by ConsoleApplication1

16a -   If the "On" telephone number was called then a "on.txt" file is written to the shared drive

16b -   If the "Off" telephone number was called then a "off.txt" file is written to the shared drive

17 - Now a second C# App called ConsoleApplication2 running on my old toshiba laptop looks for the “On” or “Off” text files that are shared out from Asterisk running on the compaq

18 - It makes a “One Shot” such that a JMS and VoiceXML event only happen when the state has changed from “On” to “Off” or Vice Versa.

19 - A third C# App called (I bet you can’t guess the name...) ConsoleApplication3 catches the “One Shot” from the toshiba and sends the appropriate “On” or “Off” message to ApacheMQ via JMS.

20 - While step 19 is happening the VOIP call is routed to it’s final Destination on the toshiba laptop.  There the caller hears an audible confirmation of which function he requested (On or Off).  The audio originates from Voxeo’s Prophecy VoiceXML Server.

21 - As the caller hears the response from step 20 a C# program running on an old PowerPC Mac running Ubuntu see’s a new message in it’s queue on the ApacheMQ server and retrieves it.

22a - If the message is “ON” then the mac executes a bash shell script called “LON” which ejects the CD Drive which in-turn presses a switch momentarily which is wired into a latching relay which turns on the Light.

22a - if the message is “OFF” then the mac executes a bash shell script called “LOFF” which sends an “ATH1” via minicom to it’s built in modem which is wired to a circuit I built that resets everything, thus turning off the light..

23 - And there you have it. Twenty Some steps to turn on a light via a phone call....

Let me know what you think via my Blog...