Thanks much everyone for the great help. I did go through the last suggestions about the callfile (no CRLF issue, permissions are 644 and file owned by root, starting asterisk through strace, etc.), but none helped.
However, by chance, I happened on a pattern: The callfile is handled only if I... 1. Stop Asterisk through its init.d script 2. Mv the callfile 3. Start Asterisk through its init.d script Here are the commands I run, the little script I use to move the callfile, and what it contains: =========== /var/tmp> /etc/init.d/asterisk start /var/tmp> ./mvSIP.bash /var/tmp> /etc/init.d/asterisk stop /var/tmp> /etc/init.d/asterisk start =========== /var/tmp> cat mvSIP.bash #!/bin/sh cp callfileSIP.call.backup callfileSIP.call mv callfileSIP.call /var/spool/asterisk/outgoing =========== Channel: SIP/xlite Context: callback-dialtone-auth Extension: s Priority: 1 MaxRetries: 2 RetryTime: 60 WaitTime: 30 Archive: yes =========== Once the callfile has been handled, it is moved from /var/spool/asterisk/outgoing to ./outgoing_done and has a couple of lines appended: =========== ... StartRetry: 2306 1 (1297171283) Status: Completed =========== I don't know if it means anything, but here's the output of "mount" on this appliance (the root filesystem uses yaffs for persistence): =========== /var/tmp> mount rootfs on / type rootfs (rw) /dev/root on / type yaffs (rw) proc on /proc type proc (rw) ramfs on /var/tmp type ramfs (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw) usbfs on /proc/bus/usb type usbfs (rw) securityfs on /sys/kernel/security type securityfs (rw) =========== Thank you. -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
