[asterisk-dev] Realtime caching or something else? (SIPretransmit#2)

[Bill Kunyiha]

I think there should be a new variable (cluster=yes/no)where by if
cluster=yes is enabled, and the peer is not in cache, asterisk should look
for the peer in the database(Postgres, Mysql etc). This way users will still
have MWI and phones could register in any machine.  

-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Watkins, Bradley
Sent: Tuesday, October 31, 2006 6:16 AM
To: Asterisk Developers Mailing List
Subject: RE: [asterisk-dev] Realtime caching or something else?
(SIPretransmit#1)

I certainly am most interested in static realtime, although it would be
nice to be able to mark a user/peer/whatever to always be in memory (in
the case where you don't have registrations for that entry).  Also, I
think manager and CLI commands are requisite for getting new entries.

Regards,
- Brad 

> -----Original Message-----
> From: asterisk-dev-bounces at lists.digium.com 
> [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of 
> Olle E Johansson
> Sent: Tuesday, October 31, 2006 7:59 AM
> To: Asterisk Mailing List Developers
> Subject: [asterisk-dev] Realtime caching or something else? 
> (SIP retransmit#1)
> 
> Friends,
> 
> The realtime caching in chan_sip is beginning to annoy me. I 
> think there's a great confusion here and we need to create a roadmap.
> 
> For me, "caching" is controlled by the software. In order to 
> avoid extra access to storage, we keep stuff in memory so 
> they can be retrieved faster when needed. The software is in 
> control and can release memory allocated by objects at any time.
> 
> In chan_SIP, developers are trying to extend "caching" to "static".  
> Let me explain.
> 
> We have static and realtime devices.
> 
> * Static are loaded in memory at startup and stays in memory, 
> regardless of registration status.
> 
> * Realtime are loaded in memory when needed and then released 
> as quick as possible.
> 
> Realtime objects are not meant to stay in memory and provide 
> services. Asterisk should be able to delete them at any time, 
> without loosing functionality.
> 
> The caching was implemented for performance. As a side 
> effect, we could provide some extra functionality like NAT 
> traversal support (qualify) and MWI notification until the 
> object is deleted from memory.  This is where the problem 
> starts. From reading the bug reports, users need something else.
> 
> What users seem to want is a way to load static objects, that 
> stay in memory, from realtime storage. Delete them when we 
> have no registration (expiry or
> unregister) and load them when they
> register again.
> 
> This is *not* caching. This is a new mechanism that we do not 
> support today, but users seem to think that we support - thus 
> filing a lot of bug reports.
> 
> I don't want to continue fixing a broken implementation. My 
> suggestion:
> 
> * Implement real caching: A configuration option that says 
> how many devices we should keep in memory (a max level) and a 
> way to determine which ones to expire when we hit this level. 
> Do *not* provide NAT keepalives or MWI for these.
> Maybe we need manager/CLI commands for deleting cached 
> objects that have changed in the database.
> 
> * Implement static realtime: When a device registers, load it 
> in memory from realtime storage and keep it in memory. 
> Provide services like NAT keepalives and MWI during registration.
> Only delete these from memory when they unregister or 
> registration expires.
> 
> * We could additionally implement manager commands (and CLI) 
> for forcing a load
>    into memory from static storage. So if you configure for 
> static and add a device during
>    runtime, there's no need for full reload, just tell 
> asterisk that there's a new device
>    that needs to be loaded into memory.
> 
> I think we need to discuss this and decide on what we want to do.  
> Today, what we
> actually deliver and what users believe we deliver does not 
> match, which results in extra bug reports.
> 
> When we approach IM outside of a call, it's very important 
> that we have a cleaner implementation than we have today.
> 
> /O
> 
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
> 
> 
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it. 
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev