i have a system FreePBX version 2.210.62.6 Dahdi version 2.10.0.1, Asterisk version 1.8.20.1. They experience choppy audio on outside calls when they start to get heavy call volume. Upwards of 14 concurrent calls and then the call quality goes down hill. I have done a TCPdump and all I see is some"Wrong Timestamp" errors in the streams. I do not see the CPU or the Memory getting saturated. I know that I need to upgrade. Can I upgrade this system from Asterisk 1.8 to 11 or even 13 using asterisk-version-switch? I have done it within the same main version, just not sure about taking it from one major version to another. I will get the Freepbx updated. I need to resolve this soon.
Seems like that would be a dahdi hardware or driver issue. It would be interesting if the problem followed an upgrade. Also, searching for audio issue specific to your hardware driver, firmware version, etc, may yield additional clues.
As far as moving from one version to another, on the FreePBX end, you can go to 2.11 without any issues. on FPBX12, the layout starts changing, and the user/device/extension paradigm changes abit, but it’s still doable with a little mindset change. going to FPBX 13 is a major change. I still haven’t wrapped my mind around some changes (or at least experienced some changes first-hand).
For asterisk , the switch-asterisk-version works well, but I don’t remember it being in the 2.10 version, but maybe i’m mistaken, it’s been a while.
You are already in Centos 6.2 (or better), so what part is just some YUM commands to update.
I would use the upgrade scripts on the FPBX web site to bring the OS/Asterisk/FPBX upgrades together. Having done only web updates (FPBX) before, it gets a little tricky after a while.
Any possibility of dumping the PRI infavor of SIP/Internet? Get a dedicated connection (which may cost less than a PRI (at least here), and you can put more than 14 calls easily before saturation. (10meg up/down can handle 80+ calls)
Thanks for the insight. I was contacted by Digium support last night and they had me run a script to get ifo off the system. After sending it to them I left the system as is. I didn’t want to skew the data I sent them with changing things after. The customer does have a 30/30 fiber connection, but they are leary of using just that. We set them up with 15 SIP paths with NexVortex to use only for outgoing only. On Monday they bursted up to 35 concurrent calls several times before 9am. They maxed out the PRI each time. I don’t see the CPU on the system peaking. It is an Atom processor, could that be a problem?
Well, a maxed out PRI means what? 1.4 Mbps of bandwidth assuming one channel for timing? Unless you are transcoding all those calls, as long as you have the RAM, I am pretty sure an atom processor should be able to handle 23 concurrent calls. However, when we start talking about packets per second, it could be up there around 1150 for all 23 channels. That can be a lot of PPS for an atom processor/network card with either bad drivers or whatever. I wouldn’t blame the CPU necessarily though. In other words, your hardware could be to blame, but blaming the correct piece of hardware is only fair.
Digium Tech support had me upgrade the system to version 11. Thinking that the new version would correct the issues. Not so much. I got called in first thing this am and ALL the phones rejected incoming calls, the system had all channels of the PRI in use. The Pri could have been that busy with calls stacking up. All calls go to Call Flow Controls and then to a IVR, then to a Que when the user selects talking to a person. So I reverted back to Asterisk 1.8 and got them back to normal. So I am back at square 1.
Can someone confirm that Device and User mode is unusable in Freepbx with Asterisk version 1.10 and above. I have noticed that PJsip is supposed to be an alternative, but from what I read it isn’t near the same.
PJsip, in the opinion of many, is not yet comparable in features and stability to sip, especially for sip trunks. I would avoid it unless, again, you are willing to work with it knowing not everything will work the way you might expect.
I don’t know, I have been looking at FreeSwitch lately. I also just stumbled onto RestApps and using the EPM to do the hot desking. I have Yealink T26 phones so I need to figure out how they will play into this. If I stay with Fpbx I am considering building a new box and using the new version of Fpbx with Asterisk 13. Might be a shorter learning curve anyway.
Please understand that DAHDi is an analog/TDM/radio/tdmoe/othershit channel driver outside of Asterisk and definitely outside of FreePBX, in your case it’s the TDM bit.
If you have your timing/framing/line-coding/build-out correct and there are no alarms/errors on the span then it will work without problem. dahdi_tool will allow you to “drill down” on your spans and see any obvious errors.
dahdi_monitor can record any particular channel to a file to check, I would start there and record a few conversations and confirm the in/out side ( you can record TX/RX as stereo)
If that test passes or identifies the direction of the choppiness , then your problem is unlikely DAHDI, but the other leg of the bridge (asterisk via SIP with all the network debugging needed there . . . .)
I’m pretty sure that FreeTDM that FreeSwith uses is just DAHDI code under another name, I will happily be corrected here, so maybe the network problems will follow you into FreeSwitch.
This is a wierd problem for me. This all worked just fine until 3 weeks ago. All the settings are correct AFAIK The system has been installed for over a year. The dahdi_monitor I have never used that. I will work on learning that.
As far as Freeswitch is concerned I am just intrigued by it.
Did you find anything that would apply to the situation on my call center? We are switching to SIP next Monday because the PRI (SIP to PRI) provider as a company has fallen apart and we have lost confidence in them. It would be nice to know I am doing the right thing based on knowledge and not emotion.
I spent months working with @jfinstrom at his previous job, trying to troubleshoot a choppy audio problem on the 24-port DAHDI card. There were three issues that eventually led me away from using that particular card:
The machine has to be super-top-end. I went through 15 different motherboard/CPU/memory combos before I found one that would work reasonably well. We were seeing a million interrupts a second and anything the system did other than that would cause choppy audio. Since we were recording all outgoing calls, that meant that we have choppy recordings all the time.
Anything that causes latency in the system will mess with you. This includes network traffic, disk traffic, keyboard input, etc.
We upgraded the board to a new version of the firmware and made the problem even worse.
The company went out of business shortly after that, so moving to new cards wasn’t a really hard choice. We also switched out our T1 connection (to the CO) and went to a VOIP connection over a faster network.
Once the choppiness started, my experience was that it would only get worse.
@sippy - make sure you don’t skimp on the network connection to your VOIP provider. Changing from a PRI to SIP changes the potential problems you can see. For example, you may change from choppiness to echo. In my experience, assuming you have a good Internet connection and reasonably fast network components, switching from PRI to SIP can be an upgrade.
This site is also recording all calls for compliance. Our RTT is <50 mSec and we have 100x20 Mbit/sec bandwidth with low jitter (<5 mSec most times w/ 20mSec buffer for G.711u). I am deploying a separate VoIP router with its own IP address right off of Comcast’s modem, then feeding back to the LAN so users can use FOP2.
Note: The router chosen for this site (testing, one, two) is a TP-Link WR841ND 9.0 w/ DD-WRT hardware specific Standard firmware. $20 on amazon. It has GbE prots on WAN/LAN and can do source based NATing!
We have yet been able to narrow this down to either our hardware or software. The T1 provider replaced their Adtran unit last Thursday. My client burst to 30 calls yesterday morning and still had issues. We have them on a SIP trunk backup for outgoing calls. We know that at least 7 calls went out over the SIP trunk. No idea yet which calls had the issue.
If the choppiness is getting worse as the call volume goes up, it’s probably hardware at your end. Check your logs for failed RAID component drives and rogue USB devices. One of the steps we undertook that helped a little bit was disabling all of the on-board devices that we weren’t using (printer, com ports, etc.). We also did some troubleshooting with “lspci” and “modprobe”, making sure we were mapping a dedicated IRQ to the DAHDI card.