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

This topic contains 6 replies, has 0 voices, and was last updated by  olivier1010 9 years, 1 month ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #40954

    olivier1010
    Member

    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 :

    http://www.opalsoft.net/qos/VoIP.htm

    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 :

    http://www.opalsoft.net/qos/VoIP.htm

    #46273

    imported_fulvio
    Participant

    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.

    #46274

    olivier1010
    Member

    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.

    #46275

    vealtenio
    Member

    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.

    #46276

    Bob_Cat
    Member
    #46277

    Anonymous
    Member

    DELETED

    #46278

    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.

    #46279

    Acecare
    Member

    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.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.