Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
After working for a company that deals in VOIP almost exclusively, bandwidth is not the real problem for VOIP, it is the latency. If 'on average' you packets are 'quick' getting there, makes for good bandwidth. But getting there in order, reliably is the issue. Some of the VOIP compression algorithm's really help reduce the bandwidth to pretty much a non-issue, but long latency kills you. Since most IP providers are not focused on low latency connections, just 'fast' connections, one of the few ways many VOIP providers have found to make it work is to 'significantly over subscribe bandwidth'. If you need a T1 of bandwidth, you may have to get at least a T3 to make the T1 of voice fully usable. Unless you can get a IP provider that focuses on low latency connectivity or you manage your own network end to end, it is almost impossible to guarantee any kind of high quality VOIP service. It doesn't have to be that way. But from experience, most IP providers do not give priority to VOIP flagged packets, so even flagging them is a waste of time. And if even one of the routers 'accidentally drops' the flag, all bets are off. If industry starts recognizing the priority flags for VOIP or other truly time sensitive packets, there are people/companies that will turn it on for all their packets, making it a moot point again. Yes, I am cynical, but experience earned my my gray hair.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |