[asterisk-dev] Realtime and call states in SIP
Olle E Johansson
oej at edvina.net
Wed May 30 00:20:59 MST 2007
Realtime buddies in SIP was designed in a way to reduce amount of
memory used and also to add some sense of "realtime", being able to
add peers in the database at any given time and have them activated
immediately.
The way it was designed was that we load the device data in memory
only when needed, then release it almost immediately.
Later on, someone added caching, the ability to keep it in memory for
a while longer so that we don't need to check the database for each
authentication attempt in a registration or a call setup.
This has been used in a way to move realtime buddies to "static
buddies from database". And now I'm getting bug reports in the bug
tracker that subscriptions (state notifications) does not work with
realtime. It was never designed to work with realtime. In fact, if
you have realtime in combination with subscriptions, your database
will start to get a huge amount of queries every time the state changes.
This badly needs a redesign. I've been asking before, but got almost
no answers. I don't want to support this hybrid function any more,
patching to a point where the code gets too confusing for anyone to
understand.
Seems like what people want is "load device from database into static
memory when it registers. Release when it expires. Reload from
database at re-registration."
I would call this "SIP dynamic static peers" to confuse even more.
For Kevin: SIP-DSP :-)
If we implement this, we can implement *real* caching for the
realtime buddies, where the system is in control and release when it
needs to re-use the memory. With that, we can say "keep up to a
maximum of 500 peers in the cache. Manage it yourself, thank you." I
have something similar implemented for ASTUM users already. Everytime
an object in the cache is used, it's moved to the top. When the cache
it full, the one's at the bottom is released from memory. With a time
limit, expiration time, of course.
What do you think?
/O
More information about the asterisk-dev
mailing list