jonas kellens wrote: > I'd like to add to my thread that realtime SIP peers do not seem to be > surviving a "sip reload". > > step 1 : 2 realtime SIP peers are registered to Asterisk, they can > make a phone call to each other. > step 2 : I do a 'sip reload' > step 3 : the 2 realtime SIP peers are no longer able to phone to each > other > > [Mar 2 11:32:41] WARNING[32668]: app_dial.c:1272 dial_exec_full: > Unable to create channel of type 'SIP' (cause 20 - Unknown) > [Mar 2 11:32:41] == Everyone is busy/congested at this time (1:0/0/1) > [Mar 2 11:32:41] == Auto fallthrough, channel > 'SIP/gerrie001-09ed70d0' status is 'CHANUNAVAIL' > > I look at the mysql-table 'sip_buddies' and the values for 'ipaddr' > and 'port' are still filled in and correct. > > When executing 'sip show peers', the realtime peers also have disappeared. > At first there was : > Name/username Host Dyn Nat ACL Port > Status Realtime > gerrie002/gerrie002 192.168.1.104 D N 5060 OK > (10 ms) Cached RT > gerrie001/gerrie001 192.168.1.105 D N 5060 OK > (30 ms) Cached RT > > Now there is : > Name/username Host Dyn Nat ACL Port > Status Realtime > gerrie002/gerrie002 192.168.1.104 D N 5060 > UNREACHABLE Cached RT > > Using Zoiper softphone, the SIP-accounts still show status 'registered'. > > Re-registering is the only thing that helps : > Name/username Host Dyn Nat ACL Port > Status Realtime > gerrie001/gerrie001 192.168.1.105 D N 5060 OK > (9 ms) Cached RT > gerrie002 (Unspecified) D N 0 > UNREACHABLE Cached RT > > And for account 2 : > Name/username Host Dyn Nat ACL Port > Status Realtime > gerrie002/gerrie002 192.168.1.104 D N 5060 OK > (6 ms) Cached RT > gerrie001/gerrie001 192.168.1.105 D N 5060 OK > (9 ms) Cached RT > > In the mysql-DB, the field 'regseconds' turns from zero to some large > integer... > > I can reproduce the above very easy by just initiating 'sip reload'... > > Is this behaviour normal ?? > > Jonas. Hi
In my experience, yes, that is normal behaviour. Generally any SIP phone will try to reconnect with the server within 2 mins anyway. If you are changing RealTime config in your DB you need to do a sip prune realtime either directly from asterisk cli or using AMI. You really do not need to do a SIP reload when changing the config of one sip extension. Ish -- Ishfaq Malik Software Developer PackNet Ltd Office: 0161 660 3062 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
