monowall Screencast Tutorials

Rarely do I profess as much devotion to a piece of software as I have for m0n0wall. I’m told that it’s one of the single most successful open source projects and it’s easy to see why. It’s been my primary router for over four years. It’s never let me down, and the user community is very supportive.

I am happy to see that Phillip Cooper has recently created a series of “screencasts” documenting it’s basic setup and configuration. This should help new users a lot. I wish they’d been around when I got started. I further wish that I’d thought to do the screencasts myself. It’s a good idea.

He has one describing some basics of traffic shaping but I find it a little simplistic. It merely assigns some bandwidth to a pipe set aside for UDP traffic at port 5060 to/from a specific IP, which is a SIP phone. I say it’s simplistic as it really only handles one SIP phone, and not well if that phone is capable of multiple active calls. Consider the following:

• Port 5060 is for SIP signaling

If a phone supports multiple registrations to the same server then it may use 5061, 5062, etc for SIP signaling to the other accounts.

• You need to accommodate SIP media

Port 5060 does not pass the calls voice streams. These are on other ports, often in the 10,000-20,000 range. One port for call media in each direction. This is actually where the assured bandwidth is required or you get choppy calls.

• Call media is not always UDP anymore

Historically SIP call media is sent using UDP. However the most recent releases of Asterisk and many commercial IP-PBX systems can also send call media over TCP if desired. Thus it may be better to be protocol agnostic in sending traffic to/from a SIP device.

• 20 kbps is not much bandwidth

In the example he assigns 20 kbps to the pipe dedicated to VOIP traffic. That certainly won’t pass a G.711 call, or even a G.729a, call which require about 80 kbps and 35 kbps respectively. It might pass a very compressed ILBC call. It’s just an example so he may not have intended to use real-world figures.

• There’s no relationship to the maximum actual bandwidth available in each direction

My experience has been that you need to know the actual available bandwidth in creating pipes. This is because you need to be 100% certain that you never saturate your connection in either direction. The instant you saturate the connection packets get queued and call continuity cannot be assured. You effectively lose control of the traffic.

It’s kind of a top down process. You start by knowing how much bandwidth you really have, the divide it up by application. This is described in my previous post on traffic shaping for successful voip over DSL.

Despite these things I think the screencasts are great and Phillip is to be commended. I’ve done similar for things for other projects. While I’ve used m0n0wall for a long time I’ve had precious few ways to contribute to the project. I may be able to contribute more detailed screencast as it would document an Asterisk or hosted PBX situation with multiple phones.

BTW – did you know that one way you can contribute to the m0n0wall project is to purchase m0n0wall merchandise at www.cafepress.com. A portion of the proceeds go to the project sustainers.