[asterisk-dev] realtime, rtcachefriends/rtupdate, qualify and hints interaction

[Olle E. Johansson]

10 mar 2010 kl. 15.37 skrev Leif Madsen:

> Ron Arts wrote:
>> I am planning on writing a patch to refresh the realtime cache
>> after a sip reload, but maybe I'm doing the wrong thing here.
>> 
>> Now. What I'd like to do is:
>> 
>> 1. ensure that a SUBSCRIBE message from a phone fills the realtime
>>    cache, so the subscribe succeeds
>> 2. somehow ensure that after a sip reload the entire cache is refreshed
>>    so that qualifying keeps happening.
>> 
>> Is this stupid for some reason? Did I miss something?
> 
> I'm sure there is a reason this is they way it is, and that a developer will 
> enlighten us as to why this is the case, but I agree that it'd be nice to not 
> require the phones to re-register to get put back in the cache with realtime 
> after a sip reload.
> 
> I'm not sure I'd go the route of refreshing the cache after a sip reload (i.e. 
> clearing the cache, then trying to load all the information back into memory 
> from the database) -- I have a vague recollection of a reason why this was not 
> possible.
> 
> However, maybe it would be easier to implement a system that simply doesn't 
> remove the entries from memory upon a reload? Without knowing anything about the 
> core code, and only about the implementation of realtime, I'm not sure if this 
> is an appropriate route either.
> 
> Hopefully an experienced developer in chan_sip and database integration can 
> enlighten us as to why things are implemented the way they are. It may be 
> possible that no developer has scratched the itch, as it were.
> 
The cache stuff is a mess because it's been patched over and order until it became useless.
It's not what you want Ron.

What you want to code, if you start coding, is a static realtime mode. You want to load all the peers when needed from realtime and KEEP it in memory until all registrations and subscriptions has expired. This is not dynamic realtime.
Dynamic realtime means that we should remove it from memory when there's no current action, no open transaction. 
This is not what most users want, but what it was designed for. After that initial design, caching was added and things got out of control.

Do it right. Make it simple. Load the peer, make it static (don't forget to add astdb for restarts of Asterisk so they stay in memory) and don't remove it as long as we have a reg or sub binding.

And please add manager actions to refresh individual peers or groups from database into memory.

If you want to discuss this further, I'm available now and then on IRC and XMPP. I've written many mails to the list about the need for a redesign of SIP realtime, maybe you can use Google to find a few of them.

/O