Moved
This blog has moved to blog.jacolyte.com
This blog has moved to blog.jacolyte.com
There are some very striking similarities between computer programs and biochemistry. Within DNA you’ll find sequences with various “flow control” signals. E.g. the sequences AUG, TAA, TAG, and TGA have special meaning to the ribosomes that actually take DNA and translate it into proteins. One signal (AUG) tells the ribosome where to start translating the mRNA to protein, and the other three are stop signals, telling the ribosome it has finished the current protein being produced. You can even observe boolean logic within cells. The production of lactose-metabolizing enzymes within E. Coli can be modeled with boolean logic or pseudo code.
if glucose_levels_low and lactose_present:
produce_lactose_digesting_enzymes()The production of proteins and enzymes can also be modular. Genetic information is stored in such a way that the constituents of a protein act like software plugins. There are plugins (called domains) that allow proteins to bind to DNA, or to bind to RNA, or to bind to hormones, or modify RNA, and the list goes on. These “plugins” basically have some kind of functionality that can be present on many different enzymes. There may be hundreds of proteins out there that work with DNA, and each of them might have a module that allows them to attach to DNA. Rather than each enzyme independently mutating and evolving a DNA binding site, they might just swap it around, which is strikingly similar to code sharing and modularity among software.
The similarities are fascinating and seem endless among computer systems and biochemical systems. Perhaps since we’re composed of biochemical “software” and “machinery”, it’s only natural that our computer systems behave in the same manner.
I made a simple little inheritance simulating program. Remember those Punnett square graphs you did in biology during 9th grade?
When running the program, you give it two pairs of genotypes and a number of generations, the program will then perform a cross between the two.
I’m studying biology currently, and I thought it would be neat to try and translate it to software. Maybe in the future I’ll add a random weight to an allele, which makes it more or less advantageous than the alternative.
I recently learned about the tac command, which is a cleverly named
command that means cat backward. When you tac a file it is output
from bottom to top, which is useful if you need to grep a gigantic
log file for the most recent instance of foobar or what-have-you.
At work I’ve been going over code that does file handling. Previously we would read our files into memory completely then work on it. This was fine up until we had to deal with a large file. Now our processes are dying with out-of-memory errors.
The simple way to handle large files is to operate on them line by line. I’ve seen people do that by writing lines like the following.
while line = some_open_file.gets do_stuff_to_line(line) end
I don’t like it. I do like using blocks that automatically close the open file, which is much more in line with the Ruby Way™.
Here’s how I’m doing it.
File.open(file_path, "r") do |file|
file.each do |line|
process_line(line)
end
endMuch better. Please resist the urge to File.read("some_huge_file.dat").
Just when I was getting comfortable within the division I was moved to, I was called upon to transplant once more. I can’t say I’m displeased with the move, I’m quite happy actually. So far I’ve been moved three times. From division A, to B, to C, and back to A.
I learned the ropes of being a professional software developer in division A, where running your program and watching it crash and fail was perfectly fine. If your data became corrupt, it was no big deal, just restore it from backup.
In division B I was asked to be the developer support for a Drupal
project. The project was pretty much covered by our creative
department. They had full control and the vision for the project, and
I was the guy who made sure they were doing the server side stuff
correctly. I occasionally ran an svn up command or two, and a couple
of mysqldumps, and maybe a few scps. Nothing major.
Division C was a massive paradigm shift for me. I went from working on a project that dealt with the web, had an agile mindset, and threw caution to the wind, to a project where every aspect of business was touched. I began working on a CRM for the company, and caution was critical. My division A mindset kicked in while on division C and I threw caution to the wind and deleted a few database records to try to complete a task I was given. Not knowing the delete would cascade, a whole day’s worth of sales efforts were gone as a result. Later my co-worker on division C told me: “Yeah… as a general rule of thumb, don’t delete anything from the database.” No kidding. Despite the terror that was instilled in me from deleting anything, I enjoyed working on division C. I learned that RDBMSs can be pretty awesome, and that caution and thinking-before-executing are pretty good things. They help you understand better rather than relying on errors and backtraces to tell you what to do. This has made me exponentially a better programmer.
At first I was very reluctant to work on division C. It felt restrictive. I felt like I was sealed into a tiny wooden box. The permissions were stringent, and doing things by hand were preferred if it meant safety was guaranteed. The security settings on the servers were tightly controlled, and I had none of my beloved root access that I enjoyed on division A. I eventually learned that things were this way for a reason, and that these were mission critical systems I was dealing with. Long story short, I’m much more receptive to others' ideas and workflows, even if they seem very awkward to me at first.
Now that I’m back on division A, I feel like I have a very fresh perspective. I’m employing the caution and putting extra thought into my code. Not surprisingly, I’m much more productive as a programmer now. Programming is feels more awesome for me than it’s ever been.
Holy. Shit. Getting a basic Asterisk system set up is a pain in the ass. Not because Asterisk is a shoddy product—it really is awesome—but because there is a certain lack of tutorials and introductory material, and getting help from IRC can be excruciating when the people who hold all of the sacred knowledge talk to you condescendingly.
I’m a Ruby developer and have never wet my feet with telephony. Never. That said, all I wanted to do was get a basic setup and make a few phone calls and feel a little encouraged by having a working system. This task took me about two or three days. Someone on IRC that I spoke with said it took them three months. I hope to ease this enormous barrier to entry for you telephony newbies with a tutorial.
Before the tutorial, I have some general advice when learning Asterisk.
Unfortunately, the information about Asterisk is scattered. In addition to being scattered, there are a lot of deep and potentially foreign concepts you must learn in order to be proficient with Asterisk. My advice to you is to compile a list of terms and concepts that you find yourself unfamiliar with, then research those terms and concepts and define them in your own words. When you can define the concepts you can confirm that you understand them.
The documentation on the Asterisk website is sparse, so there are sites like voip-info.org which serve to supplement the official documentation. There’s also a book called “Asterisk: The Future of Telephony”. Unfortunately it’s outdated and uses a version older than Asterisk 1.6, but it is still immensely useful. I’d recommend reading through the whole thing and then going back to chapter one when you want to actually experiment with Asterisk. The reason I recommend this is because the Asterisk book is strangely organized, and you will hit roadblocks when attempting to take Asterisk for a test drive because the book clarifies critical information in later chapters.
Google everything. You will need to do a lot of research alongside your Asterisk endeavors. This is mandatory. Otherwise, you will fail. Asterisk is a foreign beast to non-telephony folks, so polish up your Google-fu.
Beware of IRC. As usual, asking questions on IRC might yield condescending responses if you don’t fully understand everything (which seems to defeat the purpose, am I right?). People involved in telephony seem to be grumpy, so take their advice with a grain of salt. They are helpful, but very cranky. You’ve been warned.
On to the tutorial.
To get the most out of the tutorial, it’s best read from start to finish. Experimenting half-way might yield frustration. If you’re like me, you get impatient and want to experiment incrementally with every new bit of information you acquire. Unfortunately, the tutorial is not organized like this. It’s designed so that the Eureka moment is at the very end. Silly how that works.
For this tutorial I’m going to use the following technologies.
I’m going to install Asterisk on a remote server, and two soft phones (SIP phones) on my desktop. You may have two different soft phones on different computers if you want.
Install Asterisk with sudo apt-get install asterisk. Typically Asterisk is
run on a remote server, but if you only have one box, installing it locally
is fine too.
Install soft phones. You can install either Ekiga, LinPhone, X-Lite,
Twinkle, or whatever soft phone you want that supports SIP. For this
tutorial I’m using Twinkle, and I strongly recommend it. I chose Twinkle (sudo apt-get install twinkle) because I can run two instances on one machine, and Twinkle also lets you
change the SIP port.
Put the following in your /etc/asterisk/sip.conf file.
[general] context=default allowoverlap=no bindport=5060 bindaddr=0.0.0.0 srvlookup=yes [blaine] type=friend context=phones host=dynamic [billy] type=friend context=phones host=dynamic
The entries [billy] and [blaine] define SIP devices. The book’s
example names them [1000] and [1001], which look like extensions! Don’t
be fooled by the book! You’re not defining extensions, even though the
book makes them look like extensions. I have renamed the book’s example
entries to [blaine] and [billy] for clarity. Take some time to burn the
following into your skull: “sip.conf is where I define SIP devices,
extensions.conf is where I define arbitrary extensions”. I made the
mistake of getting confused and thinking that I have defined extensions by
making entries in my sip.conf file. This is not the case, don’t make my
silly mistake.
Great. Thus far Asterisk now knows that you have two SIP phones. What it
doesn’t know is what to do with them or how to reach them. That’s where your
extensions.conf file comes in. Put the following in your
/etc/asterisk/extensions.conf file.
[globals] [general] autofallthrough=yes [default] exten => s,1,Verbose(1|Unrouted call handler) exten => s,n,Answer() exten => s,n,Wait(1) exten => s,n,Playback(tt-weasels) exten => s,n,Hangup() [incoming_calls] [internal] exten => s,1,Verbose(1|Echo test application) exten => s,n,Echo() exten => s,n,Hangup() exten => 1000,1,Verbose(1|Extension 1000) exten => 1000,n,Dial(SIP/billy,30) exten => 1000,n,Hangup() exten => 1002,1,Verbose(1|Extension 1002) exten => 1002,n,Dial(SIP/blaine,30) exten => 1002,n,Hangup() [phones] include => internal include => default
This configuration gives the SIP phone called billy an extension of 1000
and blaine an extension of 1002. I don’t know what the other stuff means
because I basically ripped out the example configuration from the book and
made minor changes.
Now make Asterisk aware of these changes. Use the Asterisk CLI by doing
asterisk -r as root and then enter reload. Now Asterisk not only knows
about your SIP phone devices, but it has extensions attached to them. Which
means they are now actually reachable.
Once you’re this far, you should be able to configure a couple of soft phones and have them call each other. However; one thing you must watch out for, if you’re trying to configure two soft phones on the same box, they will both try to use the same port and fail will ensue. If you have both soft phones and the Asterisk server running on the same box, all three will be fighting for port 5060. If you’re doing it all on one box, leave the Asterisk server using 5060, and configure the soft phones to use something like 5058 and 5059.
If you’re using Twinkle, fire it up for initial configuration. When I was
prompted how I want to configure Twinkle, I chose Profile editor. For the
profile name I put “Blaine” and hit OK. The next screen will ask you for
your SIP information. Your name can be anything, I put Blaine. The User
name is the matching SIP account blaine defined in sip.conf. The
Domain is the IP address or host name of the box you have Asterisk sitting
on. If Asterisk is running on your local box, put either localhost or
127.0.0.1. Leave the other options blank and hit OK. For this tutorial, at
this point after configuring one instance of Twinkle, I launched another,
and when asked if I want to start anyway despite Twinkle already running, I
selected yes. In my second instance of Twinkle, I was asked to select
a profile. I clicked on Editor under the Create profile section. I called my
second profile Billy. I put Billy for the Your name field, billy for the
User name, and then my Asterisk host name/IP for Domain. I left the rest
blank and clicked OK. At the profile selection screen, I clicked System
Settings and changed the port to something different than my first running
instance of Twinkle and clicked OK. I then checked Billy for my profile
and clicked Run.
If you’ve followed me this far, you should have two Twinkle soft phones running on your local box, both on separate ports. Now you need to register these soft phones with Asterisk. Simply select the Registration menu and click Register. This will make Twinkle talk to Asterisk and say: “Hey, I’m here, I’m awake, and I’m ready to take phone calls, but I’m running on a non-standard port, so make note of that please.”
Once both soft phones are registered, you can now put in an extension on the
Call line in Twinkle, and click Dial. And once you do, witness the glory
of your other soft phone ringing with a status of “Incoming Call”.
I’ve recently been designated to be the company Asterisk expert. In light of this news, I’ve been studying Asterisk and basic telephony concepts. I’ve been reading the book “Asterisk: The Future of Telephony”, and I highly recommend it. It’s awesome and it covers a lot of the basics, or at least gives you an idea of what to Google. As I study, I try to define concepts in my own words. When I know that I can do this, I know that I understand. So, here are my notes so far.
Previously known as Zaptel. It’s a device driver/layer that abstracts the PSTN hardware. This driver layer sits on an Asterisk box and allows analog phone hardware to connect to the Asterisk box, and also allows the Asterisk box to connect to the PSTN. The analog hardware can then reach the PSTN via Asterisk, and vice versa. Anything interacting with Asterisk can then potentially interact with the PSTN, IP phones, analog phones, etc. DAHDI can be used to interface with FXO/FXS hardware.
Telephony protocols. A telephone exchange (telephone service provider, PBX, or wall jack) are considered FXSs. The phones plugged into these are considered FXOs. With these standards, FXOs and FXSs can communicate with each other with defined standards. FXSs can talk to FXOs to determine whether they are “off-hook” or “on-hook”, or when they are able to send/receive voice signals. The only difference between these two are which end of the wire they’re on. FXSs generate voltage and dial tone (e.g. phone company), and the FXO accepts voltage and dial tone (e.g. standard home phone).
An FXO device (e.g. analog desk phone) needs to connect to an FXS, therefore the FXO uses FXS signaling. This is how it works when you’re setting up channels in Asterisk. For every FXO device, you need an FXS channel for FXS signaling, and for every FXS, you need an FXO channel for FXO signaling. The Asterisk book says: “Ports are defined in the configuration by the signaling they use, as opposed to the physical type of port they are. For instance, a physical FXO port will be defined in the configuration with FXS signaling, and an FXS port will be defined with FXO signaling. This can be confusing until you understand the reasons for it. FX_ cards are named not according to what they are, but rather according to what is connected to them. An FXS card, therefore, is a card that connects to a station. Since that is so, you can see that in order to do its job, an FXS card must behave like a central office and use FXO signaling. Similarly, an FXO card connects to a central office (CO), which means it will need to behave like a station and use FXS signaling. The modem in your computer is a classic example of an FXO device.”
One can purchase PCI cards with FXO and FXS ports. These cards interface the PSTN with analog phones. With a card like the Openvox A400P, one could have a 2 line + 2 phone + Asterisk PBX system. The PCI card would sit on the Asterisk box, and Asterisk could then allow these 2 phones to communicate with these 2 lines and vice versa.
One of the protocols that Asterisk supports. SIP is defined as a protocol that can transfer voice, video, data, etc. It transfers data using the Internet Protocol. SIP phones can be physical phones that look like regular phones connected via Ethernet, or they can be software based phones on a computer, or installed on an Internet capable PDA. Asterisk can sit in the middle of SIP phones, analog phones, and phones that support other protocols, and let each interact with each other.
The worldwide network of circuit-switched phone systems. It’s the network that connects all of the telephone companies together and allows calls to be made across networks.
An adapter used to connect analog telephones to digital/VoIP systems.
Used sometimes because firewalls might block SIP/RTP packets. It’s also used in the case that SIP phones communicate across public/private networks. SIP on its own apparently fails at this, and requires STUN. If two SIP phones connecting are routable from each other and no firewall exists between them, then they can communicate just fine.
Computer record generated by telephone exchange containing details of a call. In Asterisk, these are stored in a CSV file in /var/log/asterisk/cdr-csv. These records contain various fields, and have super-awesome meta data about the phone call. E.g. end time, start time, duration, caller ID, source, destination, etc.
Protocol that allows VoIP connections between servers as well as communication between client-server. It’s an alternative to protocols like SIP and H.323.
One of the protocols used to make phone calls or send data. One of SIP, FXO, FXS, IAX2, H.323, etc. Channels must be defined within Asterisk configuration in order for any communication to take place. FXO and FXS channels can be defined in dahdi_chan.conf, and other channels in their respective .conf files.
Methods that FXS signaling uses to request a dial tone. Loop start creates a short in the circuit, ground start will ground one of the leads, and Kewlstart is the same as loop-start, but much smarter. Kewlstart is the preferred method in Asterisk when configuring analog circuits. These methods can be defined in the DAHDI channel configuration file chan_dahdi.conf
I’ve been using zsh for the past few days, and I really like it. I like it so much I want it to be my default. The chsh command allows you to change your default shell. If you’re going to do this on a remote machine, make sure the shell you change it to is valid. chsh doesn’t appear to complain if the shell you choose is not found.
I foolishly did chsh -s zsh on a remote server, not knowing that you must pass the full path to your preferred shell. This was on the root account, thus requiring the box to be brought down to fix. If you do chsh -s $(which zsh) then you’ll be in good shape.
