[asterisk-users] rtcachefriends & qualify & sip reload

[jonas kellens]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20100302/a7958ca5/attachment.htm