- This topic is empty.
March 24, 2008 at 11:34 am #40954olivier1010Member
Hi, i’ve decided to copy this in the zeroshell forum, because i think that the QOS WAN problem on Linux need to be adressed.
VoIP is not working correctly on Linux because of a poor QOS design.
Qos is working correctly for data, but realtime traffic like VoIP is not cleanly supported by Linux over low speed (< 2Mbps) WAN links.
This is the reason why, as of today, there is no other serious solution than using a Cisco router to manage VoIP over a shared Data/Voice SDSL link.
This text has been written by Leonardo Balliache, July 2.003
For those interested in the full original text, they can read it here :
Here is this very interesting text :
Some particulary VoIP packet characteristics that have to be considered are:
* VoIP travels on RTP protocol over UDP.
* VoIP packets are very small. Payload is 20 to 150 bytes with a RTP/UDP/IP header of 40 bytes (IP=20 bytes; UDP=12 bytes; RTP=8 bytes). Then due to the high relation between header size and payload size the transmission of VoIP packets is not an efficient process.
* Being VoIP a protocol to service a playback application (voice playback) its maximum end to end delay should be less that 150-200ms; 150ms is better. This, to guarantee the good quality of the sound to be transmitted.
What kind of problems VoIP packets experience when traveling throughout lines, switches and routers?
* The efficient of transmission is low. For transmitting 20-150 bytes you need a header of 40 bytes. A relation of 200%-26.67%.
* Packets are small. When they travel throughtout lines transmitting bulk traffic, with big packets (1000-1500 bytes, and even bigger), they have to make queues that looks like this:
********** * * ********** ********** * ********** * * **********
Here ********** is a big 1200 byte packet; * is a small VoIP packet. This kind of queue is formed on routers. Then VoIP packet have to wait its turn on the routers to be forwarded behind, perhaps several, big packets. This problem conspire against the restriction of having a low forwarding delay.
* They are UDP packets. Some routers are designed to control unresponsive flows, like UDP is. See below. Then, perhaps, they have a higher probability to be dropped on these kind of routers.
Studying how Cisco deals with these problems is interesting to understand why Linux routers give us lower response when VoIP packets are tried to be forwarded. I’m going to copy here some text (in cursive) taken from my work Network QoS using Cisco HOWTO.
………. (removed by admin because copied from Cisco’s documents)
Now is easy to understand why Linux doesn’t lend as good VoIP service as Cisco does. They have what in my country is known as a “poison engine”.
I don’t know if Linux folks have implemented something like this. I was searching in Internet and I can’t find anything. If someone of you know something, please let it know to the rest of us.
Well, but, how to deal with this problem using our current Linux?
I suggest (opinions are welcome) to begin with the ingress side. Having the guarantee that our VoIP packets will be forwarded to the outgoing queue as soon as they reach our router is a good first step. Then something like this seems to be good enough:
The end can be found here :March 24, 2008 at 9:14 pm #46273imported_fulvioParticipant
Olivier, what you say it is very interesting and I know you are right.
I will try to search if a kernel patch already exists to fragment all packets in presence of RTP packets in the IP queues.
Any suggest is appreciated.March 25, 2008 at 12:23 am #46274olivier1010Member
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.
Olivier.August 28, 2008 at 6:47 am #46275vealtenioMember
Hello friends, I am using internet telephony. When I talk over the internet and I play an audio file on my pc the other person on the line can’t hear it. I tried to solve this problem thru changing some options in the sound card but I couldn’t. How can a person hear something played on the pc when talking over VoIP? Any helpful suggestion would be greatly appreciated. Thanks a lot.September 30, 2008 at 11:13 am #46276Bob_CatMember
There are some guidance notes on voip-info.org about traffic shaping on linux:
http://www.voip-info.org/wiki/view/QoS+with+Linux+using+PRIO+and+HTBAugust 3, 2009 at 11:00 pm #46277AnonymousMember
DELETEDAugust 4, 2009 at 1:35 pm #46278vpn_rollercoasterMember
Zeroshell should not be used solely for QoS implementation of VoIP on a network regardless of available bandwidth and latency of data circuits. The best practice and most common means to resolve issues like this with mixed data, video and voice traffic is to use Intelligent L2 Switching. This will include vlans (using 802.1q), Class of Service (802.1p) and trunking (802.3ad) on the switch. At layer 2 the switches are best left to handle control of latency and preferential services while leaving the zeroshell/router to handle the routing.July 8, 2010 at 7:37 am #46279AcecareMember
I also encountered this problem a long time ago. I had no choice but to call a technical support. They told me that we have free service to fix that problem so I didn’t need to worry. After working, fortunately, I tried to call and the other line clearly heard my voice.
- You must be logged in to reply to this topic.