TCP port, VPN and resolving the cutting voice problem

Home » Asterisk Users » TCP port, VPN and resolving the cutting voice problem
Asterisk Users 19 Comments

Hi All;

Can I run the IAX on TCP port instead of UDP port?

If I ran IAX in TCP port, and in case my network was having a lot of users doing browse on the internet and downloading, so in that case and if the IAX used TCP port, so the voice will be better than using UDP (because in TCP the lost packets will be resend while in TCP it will not which will cause the voice to be cutting)?

Same thing if we used the VPN, and in case of other users are using the Internet to do browsing and downloading then the voice quality will be better than without VPN as the VPN is using TCP?

The internet bandwidth is not that small .. but the users are doing a big amount of work and we would like to overcome the packets losses in case of using the UDP as the packets are not resend.

Any advise for this?

What could be a solution that I can apply it to resolve the voice cutting if the Asterisk was using the internet that is shared with the users in the office that are doing download and browsing?

One more thing, what about using the Buffering or any other technique that can help to overcome packet losses due to the internet download and browsing?

Appreciate any help or advise?

Regards
Bilal

19 thoughts on - TCP port, VPN and resolving the cutting voice problem

  • The re-sending would introduce massive latency and jitter. That’s why UDP is used. In real-time voice, by the time the packet is ‘missed’ it’s too late to retransmit it.

    S

  • Dear;

    I know understand the latency due to the resending .. But if the link was have a good speed internet, then resending will make a big latency?

    Maybe this latency better than having a cutting voice?

    What if we reduce the packet size and make it TCP, so resending might cause acceptable delay?

    But again, what about running IAX in TCP port, this is possible?

    Any other solution to resolve the cutting in the voice while others doing download and browsing?

    Regards
    Bilal

  • Just the contrary – Most QoS schemes will drop TCP first, specifically
    because it is known that with TCP, the packet will be resent, so no
    application will be hurt. UDP is not dropped first because it is known that
    there will likely be more impact.

    I am not aware of any way to run IAX over TCP, and I agree it would be a bad
    idea. The proper thing to do is to implement PROPER QoS on BOTH SIDES of
    the link, which I hope is point to point. If it goes over the Internet,
    your QoS is lost as soon as it hits a router you dont control (or pay for
    QoS services on)

    I think in IAX, the jitter buffer size can be adjusted, but I dont know the
    detail on this.. A jitter buffer can be looked upon as like a funnel – as
    packets arrive, they are dumped in the funnel, which is then pouring your
    audio out the bottom in a smooth stream, no matter how much delay there is
    in the filling of the funnel. When the funnel runs out of packets (ie:
    delay has caused you to run out of data) then you get a break in your audio
    stream. Increasing the jitter buffer (bigger funnel) can fix this, but at a
    certain point, the audio will be SO DELAYED (because the packets are waiting
    in the buffer) that the users will notice and get confused.

    -Steve

  • Fundamentally, TCP’s congestion-avoidance and loss-recovery logic simply
    won’t work well with voice, unless you’re willing to accept a really
    horrendous latency (hundreds of milliseconds) and then perhaps not
    even then. TCP is designed to ensure reliable data delivery and
    reasonable network efficiency (i.e. avoiding congestion and avoiding an
    excessive number of retransmissions) and is simply not well suited for
    isochronous (or close-to-isochronous) data streams such as VoIP.

    Sure, it is *possible*. I don’t think anyone has implemented it, because
    everyone who might is probably pretty well aware that it would not work
    well.

    I’d recommend the following general approach (not my own ideas, just
    ones I’ve adopted from other peoples’ recommendations):

    – Deliberately “throttle” both inbound and outbound TCP connections,
    so that they do not consume all of your link bandwidth. Set aside
    some amount of the link bandwidth for VoIP traffic (SIP or IAX2)
    traveling over UDP.

    For outbound traffic, what you need is a rate-limiting traffic
    shaper which supports multiple queues. Linux can do this with its
    advanced traffic shaping modules.

    For inbound traffic, what you need to do is prevent the sending
    TCP stack (at the far end) from being able to queue up and transmit
    an excessively large amount of traffic. Since you have no *direct*
    control over the remote systems, you have to do it indirectly…
    and the way you do it is by “input policing”. This simply means
    that when incoming TCP packets start consuming more than a
    specific percentage of your inbound bandwidth, you start
    dropping them… artificially creating a “lost packet” error,
    which then causes the sending system to reduce its transmit window
    and enter a congestion-avoidance process.

    This also can be done using the Linux traffic-shaping modules.

    – Prioritize the packets you send, with VoIP packets being transmitted
    before TCP packets.

    This can be done using a combination of traffic-shaping modules (to
    set up and prioritize the queues and set their transmit rates) and
    iptables (which can be used to mark VoIP packets as needing
    expedited delivery).

    Take a look at http://lartc.org/howto/ – it’s a complex subject but
    a well-designed traffic shaping configuration can have really
    excellent benefits.

  • Just want to point out that a jitterbuffer will do NO GOOD if packet loss
    is occurring. Proper QoS on both ends is ideal of course, but I have seen
    some pretty clever ideas employed on the CPE side of link to effectively
    provide QoS in both directions, when you have no control over your ISPs
    routers. For example – you can effectively control the inbound flow of a
    TCP based application by delaying the ACKs sent back to the content
    provider. Doesn’t help you with UDP streams though, unfortunately.

    j

  • I’m certainly not a network expert (beyond normal network knowledge for an
    IT person), and I agree with you TCP SHOULD be dropped first because of what
    you said, but I often heard so-called network expert (or at least some
    holding jobs as such) say that it`s normal my UDP packets get dropped
    because they are UDP.

    UDP is, or was until recently, considering to be carrying those “who cares?”
    packets, like SNMP, etc. Sort of like ICMP. The reverse logic held true,
    where if it was a mechanism using UDP, it was because nobody really cared
    about reliability in the first place.

    VoIP may have changed some people`s mind, of course.

    Mike

    href=”mailto:asterisk-users-bounces@lists.digium.com”>asterisk-users-bounces@lists.digium.com
    [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Steve Jones
    Sent: Tuesday, November 30, 2010 1:33 PM
    href=”mailto:asterisk-users@lists.digium.com”>asterisk-users@lists.digium.com
    problem

    Just the contrary – Most QoS schemes will drop TCP first, specifically
    because it is known that with TCP, the packet will be resent, so no
    application will be hurt. UDP is not dropped first because it is known that
    there will likely be more impact.

    I am not aware of any way to run IAX over TCP, and I agree it would be a bad
    idea. The proper thing to do is to implement PROPER QoS on BOTH SIDES of
    the link, which I hope is point to point. If it goes over the Internet,
    your QoS is lost as soon as it hits a router you dont control (or pay for
    QoS services on)

    I think in IAX, the jitter buffer size can be adjusted, but I dont know the
    detail on this.. A jitter buffer can be looked upon as like a funnel – as
    packets arrive, they are dumped in the funnel, which is then pouring your
    audio out the bottom in a smooth stream, no matter how much delay there is
    in the filling of the funnel. When the funnel runs out of packets (ie:
    delay has caused you to run out of data) then you get a break in your audio
    stream. Increasing the jitter buffer (bigger funnel) can fix this, but at a
    certain point, the audio will be SO DELAYED (because the packets are waiting
    in the buffer) that the users will notice and get confused.

    -Steve

  • On Tue, Nov 30, 2010 at 1:00 PM, Steve Totaro
    wrote:

    I would suggest #3 because it is bullet proof unless your calls are
    maxing the bandwidth. You can always sell it to the decision makers
    as a business continuity contingency plan. The suits like those
    buzzwords and if the pipe is big enough, then you could allow mission
    critical business data to use that circuit.

    It is an easy sale to the bossmen, especially with the way you can
    talk down ISPs nowdays.

    Haggle with them, they are dying for the business. I got almost every
    circuit for half off the original quote. Just wait till the end of
    the month and say, “I can have this singed and faxed over today if you
    can provide (name your terms, MRC, NRC, contract duration)

    It is a different world now. Americans are generally not very good
    hagglers. My travels have taught me many tricks and you can haggle
    virtually anything, within reason of course.

    Get quotes from all the carriers, haggle with them all, and then use
    them against each other, it can be time consuming, but I have paid for
    my salary in savings a few times over.

    Thanks,
    Steve T

  • Not necessarily. See below. Basically the problem is that you have a
    congested link, and TCP is not the fix for congestion.

    Are you sure you are getting packet loss, and not just delayed
    packets, that might be arriving AFTER the jitter-buffer’s max delay?
    Either would create the same symptom. But the solution to them is
    slightly different.

    TCP VPNs are bad for several reasons – namely that TCP inside TCP will
    generate excessive and unnecessary retransmissions. That’s why most
    VPNs use UDP or IPSEC. TCP in TCP will increase delay and/or
    congestion on your links.

    Yes. If you are using DSL/cable/other-commodity-circuit, I’d suggest
    a second DSL circuit to be used only for VoIP. Nobody likes to pay
    for that, I know, but that’s really the solution.

    If you are using an (expensive) enterprise-class circuit (metro
    ethernet, DS3, OC3, etc) for internet, work with your provider. At
    the very least, have the provider does some form of fair queuing and
    you do the same, you’ll probably eliminate 95% of your problem. If
    they are willing to do QoS to your specs, even better (but I wouldn’t
    count on this).

    But clearly the way the circuit is configured today, you are having
    packet loss (the cutting out of voice) or excessive queing of packets.
    This is because queues in routers are getting too full, and something
    has to be dropped or something is arriving too late for the jitter
    buffers on the VoIP equipment to compensate. In otherwords, you are
    bandwidth constrained. So you need to either increase your bandwidth
    (expensive!) or implement QoS of some type.

    There are some ways to implement QoS on your end if your ISP won’t
    cooperate, but it’s not a 100% perfect solution.

    QoS.

    Certainly.

    If your problem is lost packets, you need QoS or bandwidth, but that
    aside, increased buffers in routers might help or hurt, depending on
    how things are behaving. You can try both (your ISP will need to do
    the same, if you are getting cut-outs on inbound packets; if you can
    get your ISP to adjust this, you can probably get him to just
    implement QoS and be done with this; If he can’t implement QoS, at
    least get him to do some sort of fair queuing!).

    If your problem is excessively delayed (due to queuing) packets, you
    also need QoS or bandwidth. But you can increase the jitter buffer on
    both ends of the VoIP call. If you use a VoIP provider, they will
    need to increase the buffer size on their end. Of course this will
    increase the amount of talk-over and result in less user satisfaction.
    Delay is a bad thing on phone calls.

  • 1. Drop IAX and use SIP
    2. Use some QoS or traffic management. There are plenty of
    opensource products, I go with Vyatta every time.
    3. Get a dedicated VoIP pipe that will not be in contention with
    YouTube or whatever.

    Thanks,
    Steve T

  • Thanks all for ur participation and kindly advise.

    As I noticed that jitterbuffer could help if the ping does not have request time out but the voice is also cutting .. but in that case, I have to set the jitterbuffer at the IP Phones and Asterisk boxes.

    I have a polycom phone for example, and to set the jitterbuffer there are the following paramters:

    Payload Size
    Jitter Buffer Minimum
    Jitter Buffer Shrink
    Jitter Buffer Maximum

    When it use the minimum, and when it use the Shrink and when it use the maximum?

    If to look at the asterisk (in the SIP or IAX files) then there are a paramters for the jitterbuffer also, but really I am not able to know when to use this and when to use this:

    jenable, jbforce, jbmaxsize, jbresyncthreashold, jbimpl, jblog

    How to use the jbresyncthreashold? In which case?

    Regarding to the QoS, which will be need in case having a packet loose, correct?

    I just need to ask about something:
    What I will be able to do if my ISP did not setup the QoS at his side? What kind of settings I can do in my DSL router (in case of Cisco, or in case of Linksys that running linux firmware)?

    From the other side, if I used linux server to set the QoS, so do I have to let all the network elements to pass this linux server (so it will be the default gateway for other elements)?

    Appreciate the kindly help.
    Regards
    Bilal

  • If getting a second circuit is out of the question.

    1. Switch to SIP
    2. Install and Learn Vyatta for QoS (Squid may help you quite a bit
    as well) as your router (or whatever you prefer) I use the paid
    versions of Vyatta but the free edition should be sufficient.

    I did the same setup over OpenVPN VSAT links in Iraq, 700ms ping
    times. I used GSM and some tricks on the Vyatta box.

    Originally, before I deployed the above, it was a wild west situation
    like what you have now. Going from G729 to GSM made a big improvement
    in conjunction with QoS.

    My theory on that is that G729 is already a very lossy codec, so any
    more loss, garbled audio. GSM is less lossy.

    Switch from IAX to SIP was another huge improvement, and then finally
    putting Vyatta and QoS as my router made calls almost crystal clear.

    There was the obvious lag time but users get used to that and wait a
    second or two before speaking so they don’t talk over each other and
    the quality was five by five, except for solar flares, sandstorms,
    rain. Things beyond my control.

    Thanks,
    Steve T

  • Any idea what is it about SIP over IAX2 that made such an improvement?

    -M

    On Thu, Dec 2, 2010 at 6:01 AM, Steve Totaro
    wrote:

  • No but if google my posts about IAX2, you will see that I have seen
    IAX2 cause so many problems with audio, I have made a good amount of
    money just switching customers to SIP. Even a large ITSP.

    I have found it to be responsible for poor audio in over a dozen cases
    and after switching to SIP, the audio was five by.

    Several people that work for Digium that will remain anonymous, have
    said to only use IAX when absolutely needed.

    You will also see people agreeing with me and others that have no issues.

    I just use SIP.

    Thanks,
    Steve T

  • Dear;

    I understood that Vyatta is the solution for the QoS, but I am not able to know if I can use a Vyatta hardware router to be DSL router and I set my QoS in it to resolve the voice problem. Is it possible?

    Thanks for the help.
    Regards
    Bilal

  • I wouldn’t bother with their hardware. You can run it on most servers
    providing the drivers for the hardware are supported.

    Just install it on a box with two NICs and put it between the router and
    your LAN, both static IPs, simple

    If I were you, I would find out what kind of DSL modem you have, but if it
    is doing NAT, DHCP, and all of that, you may be able to turn off everything
    except for the modem and use Vyatta for everything from NAT, DHCP, QoS,
    Squid, Firewall.

    In this case, one NIC would have your public IP, I suspect you would get it
    via DHCP or worst case, from your ISP, the second NIC is for the LAN, you
    can add more NICs for various purposes as well.

    I run Asterisk on Vyatta systems and it works great. No NAT issues with
    remote phones, QoS, and whatever else your imagination can come up with.

    I also install Webmin and NTOP.

    Just be aware that as soon as you activate the firewall, everything is
    blocked, so if you are going to use it as a firewall, get as many rules in
    place as you can think of.

    Thanks,
    Steve T

  • Dear Steve;

    I am fully thanks for your advise and kindly help.

    I am asking about the ability to use vyatte hardware DSL router because of the following reasons:

    1) I am afraid to make Asterisk the gateway for the whole network and this might effect on the performance and might cause a big load, u do not think so?

    2) If any problem happened regarding to the QoS rules or regarding to the firewall or any other thing and they decided to do hardware restart for the server (or the PC machine), then the Asterisk will be restarted and that will effect on the telephony service at the site?

    3) I am afraid if we applied the QoS and bandwidth divsion at Vyatte, and then we route the traffic to the DSL router (which will do the NAT to ISP), then all the QoS rules will be ignored (or become not effected)? What do u think?

    Again, special thanks for the guide and special help.

    Regards
    Bilal

  • What you probably have is a DSL MODEM that can act as a ROUTER but most
    likely doesn’t have to.

    Your device probably has the same capabilities as most modems, the added
    features of NAT, DHCP, and whatever else. Normally you can disable that
    additional functionality. Now you just have a DSL modem.

    If you can turn off the “ROUTER” functions on the MODEM then you can use a
    Vyatta server to be a “ROUTER” that just so happens to be connected to DSL,
    but could just as easily be connected to a gigabit connection.

    Have you tried dumping IAX and using SIP?

    Have you verified that your bandwidth is saturated? Have you run NTOP or a
    similar tool to see what is eating all the bandwidth?

    I would start with the above because you have no idea what the problem is at
    this point.

    You need to come to a consensus of how many simultaneous calls are going to
    be allowed. You can QoS your VoIP all day long, but if one too many people
    get on the phone, everyone suffers.

    Once you get that number, you have to do the math as far as bandwidth to
    reserve and limit the calls on the Asterisk side. If this leaves you with
    less than enough bandwidth for business activities, you have to get more
    bandwidth, it is that simple.

    1. No, I don’t think so. Why do you? You want voice to be #1 correct? I
    presume your LAN connection is faster than your DSL. Any modern server can
    handle these chores. You are talking DSL, so I cannot imagine you have much
    call volume, setups and tear downs. Any G729 or codec conversion should be
    very light. If you are using G729 then set the phones to use it as well.
    You could probably run World Community Grid and consume all of your cycles
    without a hitch (not recommended, I use it for burn in on new machines)

    2. Yes, you could setup a failover but I have servers with years of uptime
    and over a year of Asterisk not being restarted 1.0 and 1.2. Besides
    internal communication, would you not lose phone service now if your DSL
    “ROUTER” had to be rebooted? You don’t need to activate the firewall if you
    feel NAT is adequate protection. QoS is your goal, the rest is just icing
    on the cake.

    3. You are not tagging the packets for the ISP, you are controlling the
    rate at which protocols can consume on outbound traffic. You assign a port
    a piece of the pie, you have to let Vyatta know how big the pie is and how
    much of a slice each protocol gets.

    Inbound is a little trickier, what kind of DSL do you have, inbound may not
    be the problem. If it is, last I knew Vyatta used “Rate-limiting” which
    would essentially drop packets from the sender causing them to slow down,
    the protocols that you do not limit will not drop packets.
    http://en.wikipedia.org/wiki/Rate_limiting

    It has been a while since I looked at the latest and greatest or talked to
    the dev guys at Vyatta but they were discussing another method on the
    inbound side. Nevertheless, rate-limiting works for VoIP when correctly
    applied.

    Use google for God’s sake. There are very well done videos and diagrams
    that are specific to Asterisk, Vyatta, and all of your questions.

    http://www.google.com/search?q=vyatta+asterisk+qos

    Thanks,
    Steve T

  • Dear Steve;
     
    Really until now, I am not able to know if Vyatta has a DSL router (hardware) that can be used to do the QoS and bandwidth management without need to download the software of Vyatte and install at the server?
     
    I am trying actually not to let all the traffic passing Asterisk server (where Vyatte is installed), because making asterisk to be the bottle neck, then it is not a reliable solution for the network. Does not think so?
     
    The DSL bandwidth is 1 Mbps, so it is not enough.
    The used codecs are G729
    I am doing  a ping, and no request time out .. but voice is cutting when other is browsing and downloading .. even no request time out … but if others are not using internet for data browsing and downloading, voice is fine.
     
    And yes, I tried to use SIP instead of IAX, but also there is a problem in the voice when other are using the internet.
     
    What do u think?
    Regards
    Bilal

  • If I were you I would visit their site! I seriously doubt that they have a
    DSL router. They came out with appliances, maybe they do. Go empower
    yourself and look at their offerings.

    The first thing they put out as an appliance was a Dell R200. That was cool
    because we used Dell R200s in our fly-away kits, two for redundancy, so
    instead of buying their marked up R200s we just loaded up our own.

    Not to be rude, but it is still business hours there, give them a call.

    I cannot spoon feed you anymore.

    I don’t see how it could be a bottleneck, it is impossible, your DSL is the
    bottleneck.

    Unless you are using really old junk, and even then, 10BaseT would probably
    be sufficient.

    I also told you that you didn’t have to put Asterisk on the Vyatta box, it
    is just something I do. I have not had a problem with 100meg links or
    really latent and slow VSAT links. It just works.

    I have no more answers for you since you are unwilling to try to answer them
    yourself first.

    Thanks,
    Steve T

    href=”mailto:asterisk-users@lists.digium.com”>asterisk-users@lists.digium.com,
    href=”mailto:eng_mohd_taher@hotmail.com”>eng_mohd_taher@hotmail.com