Can't say too much constructive about that without info, I'm not a fan of it.
We need a debug trace of the registration process (SIP trace and * messages) to debug why it failed,
not just a one-line message, and anything after that is useless, as you point out.
However, I don't think it has anything do to with loading (or not) all your modules, unless you're running out of memory.
Greg - Cirelle Enterprises wrote:
With this I didn't mean you need to set them to be the same, it just should be the sameAt 07:00 PM 12/22/04, you wrote:
What registration failure is that?
from the asterisk messages log: Registration from '<sip:[EMAIL PROTECTED]>' failed for '192.168.70.25'
The only way to tell is a complete SIP trace of what's going on.
That may be, but the point is when the registration failure like above occurs, the phone is useless, the calls directed to that phone go to voice mail
The registration timeout on the phone and in Asterisk should be the same,
because asterisk would dictate it's own value if the client's value is out of bounds of configuration,
otherwise Asterisk will accept the client's, and so the two will always have the same value automatically.
unless the server goes down and reboots. The server usually has no way to tell a phone to
re-register (no real need to do so) On the next phone registration they will be in sync again.
We tried that but still had the registration failures.
What has stopped the registration failures is stripping out a bunch of unused
(in our case) modules to try to isolate the issue.
so far No Registration Failures have been detected.
the following is what our current modules.conf file looks like:
modules.conf [modules] autoload=yes
noload => pbx_gtkconsole.so noload => pbx_gtkconsole.so noload => pbx_kdeconsole.so
noload => app_intercom.so
noload => chan_modem.so noload => chan_modem_aopen.so noload => chan_modem_bestdata.so noload => chan_modem_i4l.so
noload => chan_mgcp.so noload => chan_skinny.so
; require for voicemail load => res_adsi.so
load => res_musiconhold.so
noload => app_festival.so noload => app_url.so noload => app_image.so noload => app_disa.so noload => app_qcall.so noload => app_adsiprog.so
noload => app_ices.so
noload => codec_lpc10.so noload => codec_g729.so noload => codec_g726.so noload => codec_alaw.so noload => format_vox.so
noload => format_h263.so noload => format_jpeg.so
noload => cdr_csv.so noload => cdr_manager.so
noload => app_zapras.so noload => app_flash.so noload => app_zapbarge.so noload => app_zapscan.so noload => app_talkdetect.so noload => app_alarmreceiver.so
noload => chan_alsa.so noload => chan_oss.so
noload => res_config_odbc.so noload => res_odbc.so noload => cdr_odbc.so noload => cdr_pgsql.so noload => app_realtime.so
[global] chan_modem.so=no
Eventually, we will retry the app_realtime again, but so far that has been a failure.
The more pressing issue is the registration failure issue
Greg
_______________________________________________ Asterisk-Users mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________ Asterisk-Users mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
