[asterisk-dev] Realtime caching or something else?

[Dmytro Mishchenko]

May be users/peers handling and caching should be done independently from 
chan_sip implementation and can be utilized by other channels too. E.g. 
chan_iax2 has its own code for caching realtime users.

Dmitry.

On Tuesday 17 October 2006 15:27, Olle E Johansson wrote:
> 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