Intermittent Break ups - echoing - QOS?

[pmartin]

Ive been having an issue for awhile now...It seems my call center, which is approximately 18 extensions - Inbound and outbound calls, is reporting that while on the phone the calls will get crackly and break up. Also, all inbound callers report that they hear echoing while talking to us. I have a 10mb connection both up and down which is barely being utilized so i think i can rule out bandwidth. I also have put a sniffer on the network and cant seem to find anything out of the ordinary. My question is, would implementing QOS be of any help? Please any suggestions or recommendations would be greatly appreciated since im getting hammered on this by my boss. Here is some of my pertinent info:

Inbound provider - vitelity
Outbound Provider - voip.ms

FreePBX 2.5.2.2
* Running Asterisk Version : Asterisk 1.4.21.2
* Asterisk Source Version : 1.4.21.2
* Zaptel Source Version : 1.4.12.1
* Libpri Source Version : 1.4.10
* Addons Source Version : 1.4.7

 

[Linetux]

What's your timing source for this install?

 

[pmartin]

Sorry...Timing source?

 

[lowno]

Are you using data on the same line? If you, you need QoS regardless of what you might think. Also what codec are you using? What is your upload speed?

 

[pmartin]

Data is being used on this connection...Upload speed (10mb), where do i find my codecs settings? I forget where they are located?

 

[lowno]

QoS most likely will solve your issues. I usually use an RV042 or RV016. What I do is restrict the bandwidth on all IP addresses, except the pbx. In your case I would give 8 down and 8 up for those ip addresses. The pbx will have no restrictions, thus the 2 meg up and down will be reserved for the phone system. Works fine for me.

 

[Linetux]

It seems that's not very common knowledge of how poor of a timing source ztdummy really is.

When they released Asterisk 1.6, they made a HUGE improvement in the timing source by using the pthreads kernel timer.

For those folks who have a TDM card installed in the system, this becomes the preferred timing source.

If you don't have one, you need to get one in any kind of environment where you have much more than just a couple of calls going on. It's what keeps line quality up, and you can't even do conferencing properly without it.

If you don't have a need for a PSTN interface, go get a Sangoma UT-50 or UT-51.

Unless you've got a lot of people using that 10M connection, I'm not as sold on the whole QoS thing. But then again, each provider is different in the way they provision, and some will choke up a lot faster than others - in which case QoS will help internally.

 

[dswartz]

" When they released Asterisk 1.6, they made a HUGE improvement in the timing source by using the pthreads kernel timer."

Thanks for the info. Is there anything specific to do to get this?

 

[pmartin]

So if i were to get the Sangoma UT-50 or UT-51...How do i go about installing it and configuring it to work with PIAF?

 

[lowno]

Not trying to be naive here, but I have client systems with over 100 concurrent calls using the same providers that he listed, and have no hardware timing source.

I think you would be surprised as to what those 18 call center reps are using the internet for.

Not saying that 100% QoS is the issue, but it is an easy first start to tackle the problem.

 

[pmartin]

Also to clarify....Im running SIP inbound and IAX2 outbound.

 

[dswartz]

There is pretty much zero you can do about inbound with QoS on your end.

 

[lowno]

There is pretty much zero you can do about inbound with QoS on your end.

The way I suggested to implement QoS, I don't believe this to be correct. When limited by ip address, essentially every ip except the phone system. Only the allocated mount of bandwidth is available, in my example 8 megs. Leaving the 2 for voice, essentially he will never NOT have bandwidth for voice.

Now this is just how I implement reliable QoS. Their are other ways to implement QoS, this is just how I do it.

Granted this is only to ensure that the data consumption is not causing the call quality issues.

Also there can be other issues at play. Do you have port 5060 forwarding to the pbx? Do you have fail2ban running? Their have been relentless attacks on port 5060 over the past few months. They flood your system with with requests and consume all of our bandwidth.

 

[pmartin]

i think im going to go with the Sangoma UT-50...Can someone tell me how i configure it or what i will need to do?

 

[Linetux]

The config is pretty simple:

http://wiki.sangoma.com/sangoma-wanpipe-voicetime

It's a little trickier if you have the most recent zaptel or dadhi installs, but Sangoma is really good about supporting their products if you get stuck.

Once you're done, there's nothing else to really do - Asterisk will happily use that device before zt-dummy.

 

[Linetux]

I'm glad you like playing with fire!

After talking with a number of Asterisk developers, I never trust software-based timing sources.

I'd rather spend $70 and have it done right vs. not and 'maybe' be ok.

IAX is also a problem child with this stuff... but like I said the insurance/assurance is cheap.

 

[Linetux]

Thanks for the info. Is there anything specific to do to get this?

You have to have the OS support for pthreads, then you can turn it on from make menuselect.

I just did some further reading up on it - looks like Digium changed their tune from the original release back in 1.6. Now they say they'd rather have you use dadhi's timer above pthreads (although I don't have any experience with testing it, so I can't say if it's better or not) - but now they're pimping timerfd as the new "best" timing source outside of real hardware. But that's only available in 2.6.26 kernels, which is a far cry from the current 2.6.18 source that's currently in Cent/RedHat. So you'd have to break away from PIAF if you wanted to go that route.

See https://wiki.asterisk.org/wiki/display/AST/Timing+Interfaces for more info.

 

[blanchae]

The Sangoma instructions indicate that you have to download and re-install Zaptel or Dahdi. I'm pretty sure you don't have to do that. Just install the USB Voicetime, perform an amportal stop, service dahdi restart, amportal start and check using the "debugging section" of the previous link that it is up.

 

[Linetux]

Yes, you're quite correct... I didn't catch that part. Since you already have the source with PIAF, there's no need to d/l it from Digium again.

 

[pmartin]

Well i just pulled the trigger and purchased the Sangoma UT50 ....I noticed that on the instructions it states that for best operation use a 2.6.25 or newer Linux kernel..Well im at 2.6.18-92.1.22.el5...How big of an issue is this?