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
