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  savings of access charges and international settlement rates,
and  value added services.
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 email@example.com.
What was the hole that allowed root access? What is the fix?
Robert Vahid Hashemian responds:
Its 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> Im
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. Im 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 Roberts June column, The Droop In The Local Loop:
Our office uses radio for our last mile Internet connection. Its 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,
As an ISP, our policy is that we dont do business with the ILEC unless
theres 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, Ive 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 cant believe anything that the ILEC
agrees to until the service is actually up and running (and that includes the price
quoted!). I really dont 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
- 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
- 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, Ive 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