September 1999

Another Piece Of The Puzzle

I just read Graham Davies’ interesting article “Making Voice Fit Into The Data Network Puzzle” (Internet Telephony, July, 1999), and have a couple notes.

When we estimate VoIP bandwidth efficiency we have to take into account not only codec compression and silence suppression rates, but also data protocol overheads. Otherwise, our bandwidth estimate will be overly optimistic. If we use G.729 codec (8 Kbps) with 50 percent silence suppression and ignore protocol overheads, we need only 4 Kbps bandwidth in this case.

Suppose, however, that we send voice over IP over ATM (AAL2). For every 20 byte payload (2 voice frames) we have 40 bytes RTP/UDP/IP overhead + ATM overhead (5 byte ATM header + 1 byte AAL2 header per every 53 byte ATM cell + 3 bytes AAL2 header per every payload packet). Overall, we need about 14.2 Kbps bandwidth, which is 3.5 higher than 4 Kbps.

Even if we can compress IP header on access and use RTP multiplexing on backbone, our bandwidth requirement will be well above 4 Kbps. The real benefit of VoIP is not so much bandwidth savings, but [1] savings of access charges and international settlement rates, and [2] value added services.

— Lev Sofman

Calling All Linux Gurus

Reality Check columnist Robert Vahid Hashemian received the following queries in response to his July column, “Hacker Attack. Are You Next?” Below he responds to one letter, but opens the floor to Linux users to get feedback on the issues discussed. Robert can be reached at rhashemian@tmcnet.com.

What was the hole that allowed root access? What is the fix?
— Paul Campbell

Robert Vahid Hashemian responds:
It’s hard to tell with certainty how the hacker got in. Buffer overflows on samba or nfs daemons are likely suspects. You can get patches for these holes from your vendor. If you are not using samba or nfs, you could disable them.

I read your article. Good job on discovering the hack! <applause> I’m wondering if you have any suggestion for me, as to where I could attend the best four years of anti-hacker training available at a non-institutional level. I am a disabled war veteran, eligible for up to four years of training at government expense. I’m not at all interested in going through the standard “four years of college,” rather I am looking for a company willing to offer me the best anti-hacking training I can get. If you have any ideas, please let me know where to start looking.

— Ben Gannon, USMC, Ret.

In response to Robert’s June column, “The Droop In The Local Loop:”

Our office uses radio for our last mile Internet connection. It’s been working great at about 512K bandwidth. The next step to eliminate Ameritech phone lines coming to our office would be implementing IP telephony on our net connection to our ISP. Do you feel this is practical yet for an office that uses four voice lines and a fax machine? If so, what do you recommend for hardware needed at our location as well as our ISP? Enjoyed reading your article in Internet Telephony.

— Bret Schrader, Owner, Force Systems, Inc.

Robert Vahid Hashemian responds:
Absolutely. With compression rates running at 16 or 8 Kbps, you should be able to easily accommodate your voice needs. Unfortunately, my job prevents me from recommending vendors. We basically cover them all in this publication and on our Web site, TMCnet.com™, at www.tmcnet.com. Just make sure you kick the tires really hard. Check that delays and jitters (if any) are within your acceptable limits and the product is deployed on a solid platform.

Great article. The experience you relate in your article has been replicated with our ILEC on occasions too numerous to count. It takes BellSouth a *minimum* of 4 hours to do *anything*. T1 down, PRI not working, break in the phone lines, switching problem, doesn’t matter.

As an ISP, our policy is that we don’t do business with the ILEC unless there’s NO other economical means available. However, in our particular neck of the woods (rural Mississippi), generally there are no other choices. As a matter of fact, it was this collosal ineptitude that caused us to seek CLEC certification. We are now in the process of bringing up a separate company, a CLEC, which will not only serve our ISP, but offer other services as well.

As a CLEC, I’ve already had massive problems with the ILEC. A 6-month trunking negotiation was negated by, evidently, one individual *after* we were supposed to be up and running. So, just as was true as an ISP, I can’t believe anything that the ILEC agrees to until the service is actually up and running (and that includes the price quoted!). I really don’t expect to find the service at the backbone network level to be any better than at the end-user level.

What is so frustrating is that those in charge of implementing the 1996 Telco Act are completely oblivious to the problems that everyday users experience with ILECs, and the attitude of the ILEC when those problems occur. Evidently the ILECs have “bought” (use your own connotation here) a lot of good will with the powers-that-be, and blind eyes continue to be turned. I *really* cringe when I hear Congressman Tauzin arguing that the ILECs should be allowed more latitude in deploying broadband services, when the ILEC roadblocks are the reason broadband services are not any further deployed than they are now!

However, as an incurable optimist, I have to believe that one of two things will happen:

1. those in decision-making positions will grow a brain and figure out that the ILECs are still monopolies that are in full-crisis mode, and are not to be trusted; or (and more likely)
2. The wheels of governmental affairs will continue to grind slow enough that those of us actually trying to deploy networks will be able to finish.

Meanwhile, I’ve got ports to install, T1s to provision, and customers to take care of. Something ILECs have long forgotten.

– Karl Bullock, President/Sr. SysAdmin, Dixie-Net