QOS and VoIP

Home Page Forums Network Management ZeroShell QOS and VoIP

This topic contains 18 replies, has 0 voices, and was last updated by  olivier1010 8 years, 4 months ago.

Viewing 15 posts - 1 through 15 (of 20 total)
  • Author
    Posts
  • #40950

    olivier1010
    Member

    It can be a problem for very small business where the DSL link is shared between Data and VoIP.

    In our country there are lots of very small business companies.

    It is not possible here to have multi play offers (multiple ATM VCI channels). Tier 1 providers keep this technology too expensive, they are using it but only for their residential offers (triple play : data, TV and Voice).

    ATM could be a good solution to manage a good QOS on slow links but it is too expensive. Most small providers here are not ready to offer this to resellers, certainly because the setup is complex and or they do not have enough engineers to support it.

    More, i think that the futur is IP, not ATM. IP is simpler and lower cost.

    As the global DSL infrastructure in the country is managed by only two tier1 providers (France Telecom and SFR), there is no possibility to solve the problem.

    So we are using at small clients sites a normal ADSL link.

    As we can’t have neither ADSL annex M in France, because it is forbidden by the telcom regulation authority (ARCEP), the maximum upload speed we can have is about 800 to 900 kbps in best cases with ADSL2+.

    When we have this speed, there is no real problem, QOS is working good enough for VoIP.

    But in the field, we can have upload speeds from 256 to 600 kbps or sometimes less when reach extended ADSL is used for very long lines.

    In this case, a 1500 bytes packet cause a delay that can be bigger than some VoIP providers buffers using old hardware designed for fiber links where small buffers are enough.

    Reducing the MTU to about 500 bytes is not a solution, because some web sites and applications do not tolerate this, for example if you do this, the Maxtrox.com web site will stop to work.

    One of the main benefit of using QOS is costs reductions.

    To allow QOS to work on slow links for realtime traffic like VoIP, there is no other solution than reducing the data MTU, or better, fragmenting the data traffic between edge routers.

    This could be done through a specific router interface. An example of such a special router interface is the one we can have on Mikrotik routers, where we can use a “packer” interface, to compress IP headers between two routers.

    This concept could be extended to an autofragmenting interface, managed by the linux kernel, or eventualy inside a user land process if M Torwald do not want this inside the kernel. Using such an interface between two routers would allow to reduce the Data MTU size transparently, only when needed.

    #46249

    julyinin
    Member

    Fragmenting a non VoIP paquets to allow insertion of VoIP paquets with a correct jitter value, but how??

    ________________

    #46250

    olivier1010
    Member

    I think that it this should be implemented in the linux kernel, not in user mode for performance reasons.

    Cisco did it with AutoQOS. AutoQOS is a group of methods to manage VoIP traffic effectively and simply.

    Fragmenting is something that Linux can do easily, for UDP and TCP. This should be extended to QOS, adding auto detection and fragmentation of non VoIP frames.

    #46251

    Anonymous
    Member

    DELETED

    #46252

    olivier1010
    Member

    Yes it should but this has never been done.

    I think that the reason is :

    Most telcom providers do no want to see this inside IP protocols, because they want to keep their ATM hardware and links as long as possible.

    The furur is IP, not ATM. We need a strong QOS inside IP now. We need a reliable fragmentation mecanism between WAN routers.

    Without this, even HFSC is not strong enough to give the same level of jitter than ATM on slow links.

    #46253

    atheling
    Member

    Is this really that big a problem nowadays?

    1. Good VoIP practice is to keep VoIP traffic on separate networks. So there should be very little queuing delays caused by bulk traffic.

    2. If you are running VoIP and general traffic on the same link (probable in a home and maybe small business environment) you could have a problem. But…

    2a. Many (most?) SOHO links are asymmetrical with the low speed being the uplink. That is the link you can control by setting the MTU. For example, I have an uplink speed of about 3 M bit/sec. A 1500 byte packet arriving just before a VoIP RTP packet would delay the VoIP packet by 4ms. Not good, but not too bad either. And that is the link I can control queuing on so I could set the MTU on it if I wanted. On the downlink side I have about 30 M bit/sec. If the ISP queues a 1500 byte packet in front of a VoIP packet the delay would be 0.4 ms. Not enough to worry about.

    2b. Unless you are running a server and dishing up HTML pages or sending email, your uplink packets are likely to be pretty small (HTML queries, DNS queries, etc.) so setting a small MTU on your uplink will not really affect your Internet experience.

    #46254

    olivier1010
    Member

    It can be a problem for very small business where the DSL link is shared between Data and VoIP.

    In our country there are lots of very small business companies.

    It is not possible here to have multi play offers (multiple ATM VCI channels). Tier 1 providers keep this technology too expensive, they are using it but only for their residential offers (triple play : data, TV and Voice).

    As the global DSL infrastructure in the country is managed by only two tier1 providers (France Telecom and SFR), there is no possibility to solve the problem.

    So we are using at small clients sites a normal ADSL link.

    As we can’t have neither ADSL annex M in France, because it is forbidden by the telcom regulation authority (ARCEP), the maximum upload speed we can have is about 800 to 900 kbps in best cases with ADSL2+.

    When we have this speed, there is no real problem, QOS is working good enough for VoIP.

    But in the field, we can have upload speeds from 256 to 600 kbps or sometimes less when reach extended ADSL is used for very long lines.

    In this case, a 1500 bytes packet cause a delay that can be bigger than some VoIP providers buffers using old hardware designed for fiber links where small buffers are enough.

    Reducing the MTU to about 500 bytes is not a solution, because some web sites and applications do not tolerate this, for example if you do this, the Maxtrox.com web site will stop to work.

    One of the main benefit of using QOS is costs reductions.

    To allow QOS to work on slow links for realtime traffic like VoIP, there is no other solution than reducing the data MTU, or better, fragmenting the data traffic between edge routers.

    This could be done through a specific router interface. An example of such a special router interface is the one we can have on Mikrotik routers, where we can use a “packer” interface, to compress IP headers between two routers.

    This concept could be extended to an autofragmenting interface, managed by the linux kernel, or eventualy inside a user land process if M Torwald do not want this inside the kernel. Using such an interface between two routers would allow to reduce the Data MTU size transparently, only when needed.

    #46255

    Anonymous
    Member

    DELETED

    #46256

    Anonymous
    Member

    DELETED

    #46257

    DrmCa
    Participant

    Hoping someone can point me in the right direction about configuring QOS for the Linksys PAP2T adapter I am using.

    I’ve added a VOIP class, classified it for SIP protocol, attached VOIP class to PPPOE interface and saved/activated everything. However there are no VOIP class packets in the Statistics window even as I am talking over the phone attached to the PAP2T.

    My class definition is as follows:

    1 * * MARK all opt — in * out * 0.0.0.0/0 -> 0.0.0.0/0 LAYER7 l7proto sip MARK set 0xd

    PPPOE interface reads this status:

    QoS Status:Enabled Max:5Mbit/s Guaranteed:5Mbit/s (Assigned:2%)

    Tried to move VOIP class to ETH1 to which PPP is attached, to no avail.

    What am I doing wrong?

    #46258

    VeFeh
    Member

    I have tried L7 sip pattern and it didn’t work for me..

    Try by specifying ports.. Sip is UDP 5060

    #46259

    DrmCa
    Participant

    @vefeh wrote:

    I have tried L7 sip pattern and it didn’t work for me..

    Try by specifying ports.. Sip is UDP 5060

    That works in a sense that port-based classification identifies VoIP traffic in statistics. Don’t know yet if it helps to improve voice quality though.

    After looking at L7 manager, I have a question: are there actual protocol pattern definitions in Zeroshell? There seems to be only bunch of comments.

    # SIP - Session Initiation Protocol - Internet telephony - RFC 3261, 3265, etc.
    # Pattern attributes: good fast fast
    # Protocol groups: voip ietf_proposed_standard
    # Wiki: http://www.protocolinfo.org/wiki/SIP
    # Copyright (C) 2008 Matthew Strait, Ethan Sommer; See ../LICENSE
    #
    # This pattern has been tested with the Ubiquity SIP user agent and has been
    # confirmed by at least one other user.
    #
    # Thanks to Ankit Desai for this pattern. Updated by tehseen sagar.
    #
    # SIP typically uses port 5060.
    #
    # This pattern is based on SIP request format as per RFC 3261. I'm not
    # sure about the version part. The RFC doesn't say anything about it, so
    # I have allowed version ranging from 0.x to 2.x.
    #Request-Line = Method SP Request-URI SP SIP-Version CRLF

    Not to hijack the thread, but once we are on QOS topic, is there any way to prioritize VPN traffic? I work from home using company laptop, which has Aventail VPN software installed. It uses a hard token for authentication. How can I set up a rule to prioritize its traffic 2nd to VoIP and give the rest lower priority?

    #46260

    KLGIT
    Member

    I do exactly what you are talking about using ZeroShell routers.
    We have a 5Mbps symmetrical Internet connection that is shared with our LAN/WAN, VPN and VoIP systems.

    I have setup a ZeroShell router between our ISP’s access device and our firewall. I have setup QoS rules on the ZS router to prioritize VoIP traffic AND to reserve a minimum amount of bandwidth for VoIP use.
    I also setup rules to catch VPN traffic which in our case mostly carries remote terminal sessions between remote terminal clients and our application server. I gave these a responsive profile and priority second only to the VoIP traffic.

    I have several other rules to handle things like web and e-mail traffic, bulk traffic etc. as well as a rule to give IM/CHAT traffic a very low maximum bandwidth rate.

    This whole setup works quite well with up to 6 VoIP/SIP channels active (VoIP is guaranteed 512K of bandwidth) and there are no issues in our VoIP calls related to the router not doing it’s job. For example, I can be pulling down updates at a pretty high transfer rate, and if there’s no calls, the D/L rate will near max out our bandwidth. If I then make a call, I can watch the transfer drop speed as the VoIP call gets priority. The call will proceed clean and clear with no stuttering or dropping while the transfer continues at a reduced rate.

    Setting up your QoS rules is where the problem lies. Just picking the built in L7 SIP rule won’t cut it. You have to go through your setup and make custom rules for your configuration. This involves understanding the SIP protocol and how it works, what ports it uses etc. You’ll need to prioritize not just the voice packets but also the handshake and call setup traffic. Plus you may still need rules using the IP or address of your SIP provider and your internal SIP box. However, once you do this, it works like a charm. We’ve been running this way for over a year with no problems.

    That said, when we initially set this up, we were using DSL. While the setup did work, it was not as good as with our current setup. The reason is that the DSL system in use by our ISP introduces latency of it’s own.
    Add that to the fact that no QoS is done by ISP’s and the fact that you are sharing the capacity of the DSL backplane with other DSL users and you end up with periods of poor VoIP performance.

    The unfortunate fact is that MOST consumer grade DSL products sold by most ISP’s are not a good candidate for VoIP traffic. Sure, it works great some times, but it is not consistent.
    If your ISP has a business class DSL service and IF they prioritize that traffic over the consumer/residential DSL traffic, then DSL can work well for several channels of VoIP, especially if you can use a good CODEC like G.729.

    Anyway, it can be done, ZeroShell and DSL can do it, but many of the factors in a successful implementation are out of your control.

    Good luck

    #46261

    mgibbons
    Member

    Can you share your Zeoshell rules and configuration with us please? As an example.

    Many Thanks

    KR’s

    Mark

    #46262

    DrmCa
    Participant

    It looks like there is no way to set up working QoS for VOIP phone, at least not using Linksys PAP2T adapter.
    Correct me if I am wrong, but SIP travels over UDP ports specified per line, i.e. 5060 and 5061 in my case. I can QoS those.
    But actual voice traffic travels over RTP protocol using port range specified per device, which would make it impossible to QoS that port range, as we don’t know which SIP port the RTP ports correspond to.
    Basically with the way PAP2T handles VOIP, there is no way to direct one VOIP line’s traffic over one DSL connection, and other VOIP line’s to another.

    Hoping I am making sense.

Viewing 15 posts - 1 through 15 (of 20 total)

You must be logged in to reply to this topic.