[Asterisk-Users] sip seeding vs registration

[Greg - Cirelle Enterprises]

At 03:43 PM 12/23/04, you wrote:
>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.

The module elimination was to try and rule out memory issues as the machine
is limited to 512MB RAM.

When utilizing the app_realtime:

The CLI interface is consistently issuing these messages.

it has been a slow day with no real phone activity.

     -- SIP Seeding '40853' at 40853 at 192.168.70.24:5060 for 3600
     -- Saved useragent "Sipura/SPA2000-2.0.10(e)" for peer 40853
     -- SIP Seeding '40853' at 40853 at 192.168.70.24:5060 for 3600
     -- SIP Seeding '40854' at 40854 at 192.168.70.24:5061 for 3600
     -- SIP Seeding '40854' at 40854 at 192.168.70.24:5061 for 3600
     -- Saved useragent "Sipura/SPA2000-2.0.10(e)" for peer 40854
     -- SIP Seeding '40854' at 40854 at 192.168.70.24:5061 for 3600
     -- SIP Seeding '52221' at 52221 at 192.168.70.26:5060 for 3600
     -- SIP Seeding '52221' at 52221 at 192.168.70.26:5060 for 3600
Dec 23 16:22:44 NOTICE[12551]: chan_sip.c:7742 handle_request: Registration 
from '<sip:52221 at 192.168.70.2>' failed for '192.168.70.26'
     -- SIP Seeding '52221' at 52221 at 192.168.70.26:5060 for 3600
     -- Saved useragent "Grandstream BT100 1.0.5.20" for peer 52221
     -- SIP Seeding '52221' at 52221 at 192.168.70.26:5060 for 3600
     -- SIP Seeding '1002' at 1002 at 192.168.70.251:5060 for 1800
     -- SIP Seeding '1002' at 1002 at 192.168.70.251:5060 for 1800
     -- Saved useragent "X-Lite release 1103m" for peer 1002
     -- SIP Seeding '1002' at 1002 at 192.168.70.251:5060 for 1800
     -- SIP Seeding '40852' at 40852 at 192.168.70.25:5060 for 3600
     -- SIP Seeding '40852' at 40852 at 192.168.70.25:5060 for 3600
Dec 23 16:48:47 NOTICE[12551]: chan_sip.c:7742 handle_request: Registration 
from '<sip:40852 at 192.168.70.2>' failed for '192.168.70.25'
     -- SIP Seeding '40852' at 40852 at 192.168.70.25:5060 for 3600
     -- Saved useragent "Grandstream BT100 1.0.5.20" for peer 40852
     -- SIP Seeding '40852' at 40852 at 192.168.70.25:5060 for 3600
     -- SIP Seeding '1002' at 1002 at 192.168.70.251:5060 for 1800
     -- SIP Seeding '1002' at 1002 at 192.168.70.251:5060 for 1800
     -- Saved useragent "X-Lite release 1103m" for peer 1002


The /var/log/asterisk/messages file gives

Dec 23 12:24:00 NOTICE[12551]: Registration from '<sip:52221 at 192.168.70.2>' 
failed for '192.168.70.26'
Dec 23 12:50:05 NOTICE[12551]: Registration from '<sip:40852 at 192.168.70.2>' 
failed for '192.168.70.25'
Dec 23 13:23:41 NOTICE[12551]: Registration from '<sip:52221 at 192.168.70.2>' 
failed for '192.168.70.26'
Dec 23 14:23:22 NOTICE[12551]: Registration from '<sip:52221 at 192.168.70.2>' 
failed for '192.168.70.26'
Dec 23 14:49:26 NOTICE[12551]: Registration from '<sip:40852 at 192.168.70.2>' 
failed for '192.168.70.25'
Dec 23 15:23:03 NOTICE[12551]: Registration from '<sip:52221 at 192.168.70.2>' 
failed for '192.168.70.26'
Dec 23 16:22:44 NOTICE[12551]: Registration from '<sip:52221 at 192.168.70.2>' 
failed for '192.168.70.26'
Dec 23 16:48:47 NOTICE[12551]: Registration from '<sip:40852 at 192.168.70.2>' 
failed for '192.168.70.25'
Dec 23 17:22:25 NOTICE[12551]: Registration from '<sip:52221 at 192.168.70.2>' 
failed for '192.168.70.26'
D


Restoring the system to using *.conf files eliminates all of this output 
and calls
going directly to voicemail

Unfortunately, I don't have the exact channel cannot be created or ? 
messages as there were
non today and are usually seen in the CLI.

Unless I'm mistaken, these general messages indicate a registration 
failure, do they not?

When a call comes in and goes directly to voicemail  while the extension is 
sitting idle
waiting for a call, not busy or off the hook, I think is an issue.

g