[Asterisk-Users] sip seeding vs registration

[Greg - Cirelle Enterprises]

At 07:00 PM 12/22/04, you wrote:
>What registration failure is that?

from the asterisk messages log:
Registration from '<sip:40852 at 192.168.70.2>' 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,
>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