The homepage of Josh Fuller.
Categories
Mon, 18 Feb 2008
My home network infrastructure
People often ask me what sort of network I have set up at home. Here is a basic diagram...
+--------+ +------------+
| docsis | | iPod touch |
+--------+ +------------+
| /
| /
+---------+ / WiFi +--------+ +----+
| dd-wrt |--->})~~~~~~({<---| laptop |--| TV |
+-v-v-v-v-+ +--------+ +----+
| | | | Wired
| | | +-------------------------------+
| | | |
| | +--------------------+ |
| | | |
| +---------+ | |
| | | |
+------+ +----------+ +----------+ +---------+
| iMac | | spa-3000 | | asterisk | | switch |
+------+ +----------+ +----------+ +---------+
| | | | | | | |
[drives] [pstn] [phone] [guest clients]
The Asterisk box and the SPA-3000 are not always hooked up but there's space available for the systems on the network at all times.
email: Josh Fuller | tag: /technology/computing/networks | permanent link | Share on Facebook
Jave - a java GUI-based ASCII editor
I ran across a wonderful java based ASCII editor yesterday called Java Ascii Versatile Editor.
The program vastly simplifies 7-bit ASCII drawings by allowing you to edit them in a graphical environment.
It's sort of like Gimp for text. It makes it very easy to draw completely portable network diagrams that can be viewed with zero proprietary software installed.
I'm a firm believer that if you're not able to write your documentation from a console using only vi, emacs, nano (or dos edit) then you probably shouldn't be writing documentation in the first place.
Some people like fancy photos. Jave allows me to serve them a "big cup of STFU."
DISCLAIMER: I use nano for the most part because I am lazy when it comes to learning shortcuts. I am, however, becoming a VI convert more and more every day .
email: Josh Fuller | tag: /technology/computing/software | permanent link | Share on Facebook
A VoIP troubleshooting tool manifesto for the Next Generation
We in the telecommunications world are at a strange crossroads--- a "singularity," for lack of a better term--- where legacy circuit switched voice and current generation packet switched voice exist within one constantly evolving and relatively unstable network platform.
In the legacy world call processing happens in a fairly linear fashion: telephony switches send messages back and forth over common signalling points using well defined protocols. Voice circuits always remain in an idle state waiting for control messages that "turn on" the voice path.
In the "Now Generation," complex network elements are commissioned within our ever-growing data complexes at an exponential rate. This current technology does not use signalling formats or media paths that allow existing legacy telephony monitoring tools to be used for performance analysis, triage of call outages and day-to-day operational readiness and maintenance. True "Next Generation" call processing and signalling is far less linear than traditional telephony. Existing network services such as bind are retooled to become services such as enum. In a purely IP world media and signalling paths are no longer static. Voice and signalling paths are created only when needed and those resources are released back to a pool of loosely interconnected devices once no longer required.
Servers chop media into small packets with an address on each one telling the network devices where to send them. Inside of each packet is a payload. The payload is a piece of the media transmitted inside the packet. The sending server sends the packet to a nearby router and forgets about it.
The nearby router send the packet to another router that is closer to the recipient server. When the receiving server finally gets the packets (which may have all taken completely different paths to get there), it uses instructions contained within the packets to reassemble the data into its original state.
Vendor monitoring technologies partially fill the surveillance gaps in networks but do not support open and extensible signalling and media protocols due to architecture "racism." Oddly, the basic media formats are almost always thrown away due to cost savings in server storage.
Bit flushing is also a quick and dirty way to increase monitoring probe performance without actually using scalable hardware. Not capturing the media packets is a dangerous and confusing choice which is the network equivalent of throwing the baby out with the bathwater. Existing call processing tools have a very poor capacity to measure in-band signalling methods such as RFC-2833 DTMF. The all-important DNS queries--- the glue that makes enum NAPTR possible--- are often completely invisible. At a bare minimum media must always be watched for the possible existence of tertiary signalling.
Sadly, the true issue isn't something as simple as vendor lock-in, budget constraints or protocol exclusion. The real issue is that there is no such thing as a switch anymore, a voice path or a circuit.
The network itself is the point that must be monitored.
Read that again. Drill it into your brain. The network itself is the point that must be monitored.
Why?
VoIP is a moving target with numerous protocols loosely gathered together in a server farm pretending to be a traditional telephony network.
A single call progressing through this server farm may use many different protocols and transport mechanisms for completion.
For example: cdp; skinny; sccp; sgcp; rvp/ip; h.245; h.225; megaco; h.248; dns; enum; sip; sip-t; rfc-2833 dtmf; inband signalling; rtp; rtcp; rtsp; t.38; t.30; ulaw; alaw; gsm; gcp; ss7; mf; unistim; mgcp; SDP envelopes; sigtran; q.931; radius; h.323.
Now for the real mind blowing experience: By the time you finish reading the list it has already become obsolete.
Our seemingly impossible challenge is to develop and deploy tools that both graphically and logically depict a call from end to end on a network that has numerous traditional and non-traditional signalling and media ingress and egress points.
Since IP networks effectively forget about the packets they have already handled it becomes impossible to troubleshoot VoIP calls without being able to disassemble, rethread and reassemble transmitted packets into a cohesive call end-to-end.
Integration with legacy networks such as traditional TDM causes even more confusion as the intersecting technology boundaries create logically and functionally different calls in the network.
In the past, I have suggested that the solution for this is an open-standards based unix tool with the capacity to:
capture a feed from all network probes in parallel
intelligent packet capture and merge with no duplication of packets
capable of capturing ALL protocols associated with VoIP and TDM
In a perfect world this would be a real time active capture device that creates both a visual depiction and a packet-capture dump of a call. These storage files should be in an open and extensible format such as tcpdump. At a minimum this tool should include every single leg of the call from the ingress to egress point of a voice network.
If I were to create such a system I would leverage open-source products (such as sipP, Wireshark, Asterisk and Sip Scenario) to create a distributed packet capture tool while avoiding vendor hardware and software lock-in. I would attract and retain in-house resources solely tasked to create a customized open-source platform capable of understanding both "next generation" and legacy technologies.
Any system I would source from a vendor would have to support open standards and would have to be based on an easily upgraded and extensible technology geared towards an eventual migration to IMS. I also would urge organizations responsible for deployment of VoIP infrastructure to restructure their teams that work on "Next Generation" services into cohesive organizations to remove interdepartmental roadblocks, compartmentalization of knowledge and entrenched corporate beauracracy.
Finally, I would forbid any potential vendor from treating Internet Explorer as a personal extension of their command and control environment.
email: Josh Fuller | tag: /technology/telecommunications/voip | permanent link | Share on Facebook
I've recently started to use JDarkroom for all my markdown editing tasks. It's really nice to have a cross-platform text editor that feels like editing in a console with no distractions.
email: Josh Fuller | tag: /technology/computing/software | permanent link | Share on Facebook
Sat, 16 Feb 2008
Thanks, Saara and Markus! I never knew you won the lottery!
email: Josh Fuller | tag: /personal | permanent link | Share on Facebook
Thu, 14 Feb 2008
email: Josh Fuller | tag: /links/political | permanent link | Share on Facebook
Sun, 10 Feb 2008
Remove Go iDisk from the Finder.app menu
One of the nicest things about xnu is how much control you have over Aqua and how it functions.
The menus for Finder (and many other applications) are for all intensive purposes "open source" and you can modify them once you understand how they are built.
NOTE: You must have the XCode Developer Tools installed for this to work.
Open Terminal.app
cd /System/Library/CoreServices/Finder.app/Contents/Resources/English.lproj
(substitute your native language as appropriate)
sudo tar cvf Menus.nib.tgz Menus.nib
sudo open Menus.nib
Use Interface builder to remove definitions for iDisk.
Save file to desktop.
Delete the old directory (rm -rf Menus.nib) and copy the edited file back into the Finder resources tree.
If you make Finder FUBAR boot from the DVD and replace the file in Terminal.
email: Josh Fuller | tag: /technology/xnu | permanent link | Share on Facebook
Mon, 04 Feb 2008
Handy ways to cut an IP address out of command responses
Every now and then I need to write scripts that read the local IP address and use them on the command line. There are two ways that I've found that will do this in a flash.
They aren't very eloquent but they work.
cut and cut again
ip addr list eth0 | grep "inet " | cut -d' ' -f6 |cut -d/ -f1
cut and awk
ifconfig eth0 | grep "inet addr" | cut -d: -f2 | awk '{ print $1}
email: Josh Fuller | tag: /technology/unix | permanent link | Share on Facebook
Sat, 02 Feb 2008
Using sipP as a Call Generator to load test Asterisk on Ubuntu Server
Using sipP as a Call Generator to load test Asterisk on Ubuntu Server
Note: this requires you to have access to more than one Asterisk server within a network! You also need access to the superuser account.
Preparation and Existing Configuration Backup
- Log in to your Asterisk server and become superuser with
sudo -s - Change to the superuser's home with
cd ~ - Backup the current Asterisk configs with
tar czvf asterisk-configs.tgz /etc/asterisk - Ensure sipP is installed with
apt-get install sip-tester
Test Configuration
Map out the scenario you plan to test.
+--------+ call => +--------+ |Asterisk|---------|Asterisk| |Server |---------|Server | +--------+ <= call +--------+
Set up your Asterisk extensions to answer and hangup in each server
extensions.conf example
[default] exten => service,1,Answer() exten => service,n,Dial(SIP/1234@remote-peer) exten => t,1,Hangup() [sipp] exten => 1234,1,Answer() exten => 1234,n,Milliwatt() ; this provides the media for rtp loopback
sip.conf example
[sippuac] type=friend username=sippuac host=dynamic context=sipp insecure=port,invite nat=yes promiscredir=no
Connect to each server and set up some background sipP sessions.
- From each Asterisk server (with Asterisk running)
sipp `ifconfig eth0|grep "inet addr"|cut -d: -f2|awk '{ print $1}'` -i `ifconfig eth1|grep "inet addr"|cut -d: -f2|awk '{ print $1}'` -d 1s -l 100 -aa -mi `ifconfig eth1|grep "inet addr"|cut -d: -f2|awk '{ print $1}'` -rtp_echo -nd -r 12 -bg
This generates about 12cps with a call duration of one second. You can use the -bg flag to keep the calls running in the background.
- Start tshark on a system that can see the entire network
tshark -i capture eth -r "sip" -w name of file.cap
Wait while test completes
killall sippon any server where you had it running and [ctrl]-[c] the tshark sessionsave data
email: Josh Fuller | tag: /technology/telecommunications/voip | permanent link | Share on Facebook