Asterisk 1.4.18 "stalls" within dialplan

Hi there,

I’m a bit new to Asterisk, yet still learning.

I build
libpri 1.4.3
zaptel 1.4.9.2
asterisk 1.4.18
asterisk add-ons 1.4.6

Been testing (or rather learning) from the following extension:-
[incoming]
exten => s,1,Answer()
exten => s,2,Wait(1)
exten => s,3,Playback(main-menu)
exten => s,4,Background(enter-ext-of-person)
exten => s,5,Waitexten(5)
exten => s,n,Goto(internal,${EXTEN},1)
exten => s,n,Hangup()

exten => i,1,Background(pbx-invalid)
exten => i,n,Goto(incoming,s,5)

exten => t,1,Goto(internal,SwitchBoard,1)

Calling the above from:-

[internal]
exten => test,1,Verbose(1|Test [incoming] extension)
exten => test,n,Goto(incoming,s,2)
exten => test,n,Hangup()

Which worked great this afternoon. :laughing: (IMHO)

Then… I ran “yum -y update” which, except for some other packages, also updated my kernel to 2.6.24.3-12.fc8

Now, when I try this extension test again, Asterisk simply “freezes” or “pauses” during execution of above extension test:- (As reflected below)

-- Executing [test@phones:1] Verbose("SIP/Wicus-007ee120", "1|Test [incoming] extension") in new stack

Test [incoming] extension
– Executing [test@phones:2] Goto(“SIP/Wicus-007ee120”, “incoming|s|2”) in new stack
– Goto (incoming,s,2)
– Executing [s@incoming:2] Wait(“SIP/Wicus-007ee120”, “1”) in new stack
– Executing [s@incoming:3] Playback(“SIP/Wicus-007ee120”, “main-menu”) in new stack
– <SIP/Wicus-007ee120> Playing ‘main-menu’ (language ‘en’)

Asterisk doesn’t play the sound NOR does it pass the Playback priority. It just “sits” there…

I have rebuild
libpri
zaptel
asterisk and
asterisk-addons
after the new kernel was installed. (and the machine rebooted of course)

Even rebooted twice after all the rebuilds. Yet, no luck to date. :frowning:

I’ve been googling around, yet can’t find any similar problem.
I think that I might be missing the correct key words… or so I currently believe. :unamused:

Calling another extension directly works fine.

Can any Guru assist a humble beginner? :confused:

Thanks in advance.

You could try make distclean before you re-compile.

Download the book Asterisk: The Future of Telephony, 2nd Edition FREE from Digium.

digium.com/elqNow/elqRedir.h … 510480.pdf

On page 49 the options are explained; make distclean

Hi bwilks,

I am using “The Future of Telephony, 2nd Edition” as downloaded from Digium, as I am going along.

Currently I have cleaned-out everything that is asterisk, (rm -rf /var/lib/asterisk etc) and will be attempting a rebuild of all the modules. (With the exception of my config files :smile: )

zaptel was removed with “chkconfig --del zaptel”

The ATCOM FXO X100P card caused a lot of “FXO PCI Master abort” messages in the system log. This has been resolved by removing the card… :smiling_imp: (Which is destined for the garbage bin - and to be replaced by ztdummy )

One strange message during Boot-Up which I am not familiar with is:-

Starting udevd: udevd[533]: lookup_user: specified user ‘asterisk’ unknown
udevd[533]: lookup_group: specified group ‘asterisk’ unknown

As I have seen this since I started with Asterisk, and to date still do not know where it fits in, I’m neglecting it as I hope it will not cause any issues :blush:

:arrow_right: Ok, this fix was as simple as “rm /etc/udev/rules.d/zaptel.rules” :exclamation:

libpri / zaptel & Asterisk has been rebuild with the following commands in this specific order:-

make distclean

make clean

./configure

make menuselect

make

make install

      # make samples <- not used, to prevent overwriting of current configs

make config

I downloaded all the required sounds files (EN), and placed them into /usr/src/asterisk/asterisk-1.4.18/sounds

:question: Yet, when executing “make install”, they are all re-downloaded… :question:

Does one need to edit the “Makefile” to prevent the re-download of all these files ?

Could the “copying” of the sound files be the reason for the issues experienced? When I compiled 1.4.18, I just copied the sound files from ver 1.4.17’s sounds directory to 1.4.18’s sound directory. (1.4.17 got it’s sound files from 1.4.16 if I recollect correctly)

Will post/edit back in a moment on the progress…

Thanks a million bwilks.

Between the “make distclean” and re-download of all the sound files when “make install” was invoked, ALL is once again A-OK.

The idea of doing a system update (kernel update) that causes a total rebuild of Asterisk is a bit dounting for comercial installations. Especially with time it takes to download the sound files…

Thanks again though. Now I can continue again. 8)

Are you using a Digium card to hang a phone or a line off of?

If yes, then you need to remember that zaptel is a kernel module, and when you change the kernel, you need to rebuild zaptel for the new kernel.

You can try running:

/etc/init.d/zaptel restart

If zaptel does not start, you need to rebuild zaptel for your new kernel.

After rebuilding zaptel, run:

/etc/init.d/zaptel restart

If zaptel starts, then do

/etc/init.d/asterisk restart

and you should be good to go.

–Matthew

I experienced this issue with a tdm400 zaptel card installed. It just froze on any audio, be it playback or background command, even voicemail, whatever. Without the tdm400/wctdm/zaptel card and modules installed (pure IP calls) the system would work fine. Under the failing conditions. the board did not acquire interrupts. and zttest would not produce much. Try running zttest on the zaptel device and cat /proc/interruupts to see if wctdm (or whatever zaptel module) is getting any - should be lots - of interrupts. Notice also if your zaptel module (like wctdm) is sharing interrupts with another device. You want that board to have its own interrupt for best performance.

The fix for me was to get the kernel out of apic (Advanced Programmable Interrupt Controller) mode, so the kernel command line would include “noapic”. Depending on your bootloader, you would want to append noapic to the kernel arguments, or supply it manually at the boot prompt.

In grub, for example, /boot/grub/grub.conf:

title Default (2.6.9-55.0.9.EL)
root (hd0,0)
kernel /vmlinuz-2.6.9-55.0.9.EL ro root=/dev/md1 selinux=0 vga=normal noapic
initrd /initrd-2.6.9-55.0.9.EL.img

In this example I am also disabling selinux and have removed rhgb (RedHat Graphical Boot) and set vga=normal to avoid loading a video framebuffer. You can also consider acpi=off to turn off the Advanced Configuration and Power Interface. This may not be necessary, but I try to steer clear of bells and whistles in kernel options that aren’t as important as the service we’re providing.

Not all systems I’ve worked on behaved this way, and I have some that the APIC interface works fine on. It is probably related to the motherboard chipset.

Good luck,

Andy