I have an IVR platform that is pure SIP. Sometimes the playback of audio prompts will get choppy and almost robotic sounding. It seems to be a sporadic issue. The machine it’s on is a 3.2ghz 1gb ram machine. Kernel is 2.6 and Im running the latest versions of asterisk/zaptel (1.4.0-beta3)
I currently do not have any digium hardware on it due to it being straight SIP.
I have been doing researching and checking into possible timing issues. I have ztdummy loaded, but not sure how this will hold up in a production evironment. Can anyone shed some light on why this may be happening?
If you’re sure it’s a timing issue, you might want to make sure that the timing from your USB is good. Could be a touchy oscillator getting too warm or something.
Also, Kernel 2.6 is supposed to have a built in timer that works like ztdummy, but I don’t know how well it works with Asterisk, so I just use ztdummy myself.
What kind of system is your server? is it a desktop that you converted or a system built to be a server? I’d recommend using a good quality network card and other such peripherals, since it could just be an issue of the bus getting overloaded doing things that built-in cards aren’t designed for.
well, I am not entirely sure it’s a timing issue. From what research I have done, it all points to being a timing issue and/or major packet loss.
The machine is a server grade 1u rack mount. It has onboard nic.
I am curious if anyone has a pure SIP installation of Asterisk running and if so , how does it perform?
I went ahead and just ordered a digium t1 card to see if it helps eliminate some of this issue, as I have read that ztdummy isnt quite up to production quality.
I am running a pure ip server without any digium hardware. SIP phones and and IAX trunk to the provider.
I am experiencing similiar choppiness and poor quality of recorded messages. If I unload ztdummy the problem goes away but the meetme conference bridge breaks. It will not recognize any PIN numbers as valid.
I am running * 1.2.13 on a 1U server with CentOS 4.4. I have not upgraded the kernel on the production server because it didn’t seem to help on a test server.
I am very interested in hearing from other people running a pure IP setup and how they are dealing with this problem.
I started another thread a few days ago on this and digium recommended I install a card or upgrade the kernel.
I got the same response from Digium. I upgraded the kernel to 18.104.22.168 and have tried with and without a digium card.
We currently do call recording/transfers on a seperate box without these issues, it seems to be only when trying to do an IVR type scenario where it has to playback multiple prompts. (if I run the IVR script on the other box, the same issue arises)
I have also tested on a Dual 2.6 xeon box 2 mg ram machine that has a Digium t1 card. When dialing in on the T1 line there of course is no issue, but trying a straight SIP DID, these issues manifest themselves again.
I am begining to wonder if Asterisk can be implemented in a straight SIP production environment. So far, I am not entirely sure it can. I am willing to pay money for consulting work on this project as well. We are currently in a time sensitive situation. We are moving buildings within 2 weeks and want to roll out the new IVR engine.
Yeah , I am assuming the same as you… not very many doing a straight SIP environment. I am going to continue trying to test this and pin Digium down on some sort of solution. If i come across something I will be sure to pass it on.
That’s where I am right now as well. switched to 22.214.171.124 set the timing to 1000hz and then recompiled. As of last night we had out SIP provider change our originating server (they were sending us calls from east coast, while we are on west) … Installed a digium card for timing… got a west coast hop and it works much better last night and today.
I have found that the NTP setup on a system has a slight effect on the quality of my pure SIP conversations and such. If you edit /etc/ntp.conf and point the server to “clock.redhat.com”, it makes a noticeable improvement.
I may be way off base with this, but for whatever reason, it works.