[asterisk-users] rtcachefriends & qualify & sip reload

[Ishfaq Malik]

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