Reply To: An explanation: why VoIP over WAN don’t work well with Linux

Home Page Forums Network Management ZeroShell An explanation: why VoIP over WAN don’t work well with Linux Reply To: An explanation: why VoIP over WAN don’t work well with Linux


Unfortunately i’m not aware of this :=(

I think that it is something to create, nobody seems really aware of this problem.

Most of the time, professionals say : use a dedicated ADSL or SDSL link for VoIP or it will not work correctly. Well… Why do we have QOS if it is not efficient ?

In fact, it is perfectly possible to share a link with Data, as soon as the data MTU do no exceed about 200 Bytes.

A simple calculus :

For a 1 Mbps uplink Wan speed, we need about 12 ms to transmitt a full 1500 bytes IP frame.

So, as soon as there is a big data transfer on the Wan, even with the best QOS algorythm, a VoIP paquests need to wait between 0 and 12 ms in the best case before to be sent, if it can be queued just after the actual Data paquet. In the worst case, if the queue is not almost empty, or if the QOS algorythm decide to not give full priority to the VoIP paquet, then evntually the VoIP paquet will need to wait more than 12 ms to be transmitted.

0-12 ms of jitter is the best case, for a 1 Mbps link. If the upload link is slower, then jitter will be higher. A good test is to issue a ping during a heavy upload. You will see that even with the highest ICMP priority you will set on QOS settings, the ping timing value will dramatically increase during this upload. This is a symptom of the bad realtime QOS of Linux.

12 ms of jitter is something quite high, not for asterisk, but for some VoIP providers, who sometime do not have equipment to compensate for such a high jitter (this is because historically they were working on high bandwith links, and their hardware do not care slow speed links with high jitter).

I think that there is no other way than fragmenting the Data traffic, to create holes for VoIP paquets in the upstream QOS queue.

In a fisrt implementation attempt, perhaps it would be simpler to forget the automatic fragmentation, forcing fragmentation on all data traffic ?

After all, a dedicated link is a compromize. But VoIP cannot tolerate jitter. So i think that in the case of a shared link, it is better to reduce Data efficiency, fragmenting all data traffic.

In a second phase, it would be interesting to implement an auto VoIP traffic detection, to fragment data only when necessary, like in cisco routers.