[Asterisk-Users] sip seeding vs registration

[Karl Brose]

Oh, I see.  This is the realtime connected problem.
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:

> 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,
>
With this I didn't mean you need to set them to be the same, it just 
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
> Asterisk-Users at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>