asterisk users - Nov 2010 - TCP port, VPN and resolving the cutting voice problem

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

On 30 Nov 2010, at 09:28, bilal ghayyad wrote:
> 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)?
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
> 
> On 30 Nov 2010, at 09:28, bilal ghayyad wrote:
> > 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)?
> 
> 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
>

On Tue, Nov 30, 2010 at 4:28 AM, bilal ghayyad <bilmar_gh at yahoo.com>
wrote:
> 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
>
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

On Tue, Nov 30, 2010 at 1:00 PM, Steve Totaro
<stotaro at totarotechnologies.com> wrote:
> On Tue, Nov 30, 2010 at 4:28 AM, bilal ghayyad <bilmar_gh at
yahoo.com> wrote:
>> 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
>>
>
> 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
>
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

On Tue, Nov 30, 2010 at 2:28 AM, bilal ghayyad <bilmar_gh at yahoo.com>
wrote:
> 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)?
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.
> 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?
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.
> 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?
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.
> 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?
QoS.
> 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?
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.

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



---------original message ------

From: "Mike" <list at net-wall.com>
To: "'Asterisk Users Mailing List - Non-Commercial
Discussion'" <
asterisk-users at lists.digium.com>
Date: Tue, 30 Nov 2010 12:34:08 -0500
Subject: Re: [asterisk-users] TCP port, VPN and resolving the cutting voice
problem
> 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?

I think the point is that with TCP, congestion will create a vicious circle
of more congestion, while with UDP congestion is bad in itself, but doesn't
result in more congestion created by the original congestion.

That being said, isn't UDP sometimes looked at as being lower priority than
TCP by many routers out there and dropped first when congestion does occur?
That makes it a good reason to use TCP in some cases.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20101130/ae695ee6/attachment.htm

> 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?
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.
> 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?
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.
> Any other solution to resolve the cutting in the voice while others doing
download and browsing?
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.

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)?

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

------------
> > 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

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
---------------------
 
> 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
> 
> On Thu, Dec 2, 2010 at 3:14 PM, bilal ghayyad <bilmar_gh at
yahoo.com>
> wrote:
> 
> > 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
> >
> > ------------
> > > > 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