[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