found 433779 asterisk/1:1.6.2.7-1 user [email protected] usertag 433779 + missing-dependency thanks
hi, it appears that asterisk is incorrectly treating DNS resolution failure during SIP registration as a "404 not found" SIP response. when my system boots, asterisk is started after my recursive DNS server, and i see this in /var/log/asterisk/messages: [May 31 17:36:41] WARNING[1689] acl.c: Unable to lookup 'inbound23.vitelity.net' [May 31 17:36:41] WARNING[1689] acl.c: Unable to lookup 'outbound.vitelity.net' [May 31 17:36:41] WARNING[1704] acl.c: Unable to lookup 'inbound23.vitelity.net' [May 31 17:36:41] NOTICE[1704] chan_sip.c: Registration from '<sip:[email protected]>' failed for '127.0.0.1' - No matching peer found [May 31 17:36:41] WARNING[1704] chan_sip.c: Got 404 Not found on SIP register to service [email protected], giving up it seems to be impossible for asterisk to have received a "404 not found" response from the SIP peer if DNS is not available, and indeed i verified with a packet sniffer that no SIP packets were sent or received. it looks like there are two bugs here: 1) asterisk should treat DNS resolution failures as transient network failures, not SIP failures, and be subject to retrying the registration. asterisk made no attempt to retry the registration after the initial DNS failure. 2) /etc/init.d/asterisk contains the following LSB header: ### BEGIN INIT INFO # Provides: asterisk # Required-Start: $remote_fs # Required-Stop: $remote_fs # Should-Start: dahdi mysql postgresql # Should-Stop: mysql postgresql # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Asterisk PBX # Description: Controls the Asterisk PBX ### END INIT INFO if i'm not mistaken, on systems with parallel booting enabled this means it would be possible for asterisk to start before the network is up or name resolution is available. i believe that $named and $network should be added to Should-Start. -- Robert Edmonds [email protected]
signature.asc
Description: Digital signature
