[asterisk-users] rtcachefriends & qualify

[Mindaugas Kezys]

The problems we have with Asterisk Realtime:

 

   1. After reload all registrations are void.

   2. Without reload prune does not take effect.

 

Test it in your scenario also.

 

Regards,

Mindaugas Kezys

 

Kolmisoft UAB 

VoIP Billing Solutions

e-mail: info at kolmisoft.com

URL: http://www.kolmisoft.com

 

From: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of jonas kellens
Sent: Tuesday, March 02, 2010 11:44 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] rtcachefriends & qualify

 

Thank you for your answer, Nic.

It seems that by putting rtcachefriend=yes, the qualify works as expected and even changes made to my realtime MySQL-DB take affect immediately without the need of a reload (I changed the username and name).

However the old username and name are still valuable and using this old SIP-user, one can still make outgoing calls. Receiving calls is no longer possible :

WARNING[32439]: app_dial.c:1272 dial_exec_full: Unable to create channel of type 'SIP' (cause 20 - Unknown)

Adding 'rtautoclear=yes' to sip.conf makes no difference. Changes to SIP-account are taken immediately, but the old SIP-credentials are still valid. (even after an unregister and re-register)

Only after a "sip reload" I get the notice :

[Mar  2 10:41:03] NOTICE[32498]: chan_sip.c:15889 handle_request_register: Registration from '"Gerrie"<sip:gerrie001a at 192.168.1.150;transport=UDP>' failed for '192.168.1.105' - No matching peer found

So a "sip reload" is always necessary to clear the cache ??


Jonas.

On Mon, 2010-03-01 at 14:31 +0000, Nic Colledge wrote: 

Hi,

 

I think so, maybe someone can help clarify this for me also. I have:

rtcachefriends=yes

rtautoclear=yes

in sip.conf and was under the impression that this caches the settings from the database until a user unregisters. When they unregister the data is removed from the cache (rtautoclear). For me this was a nice compromise.

 

This is from memory but I’m pretty sure I got this from the documentation online, if someone can confirm what I’m saying that would be sweet.

 

Thanks.

Nic. 

 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20100302/d78d19f2/attachment.htm