[asterisk-dev] Realtime and call states in SIP

[Loic Didelot]

Hello,
I know that you mentioned 500 just as a number but I think 500 is far
too low. Not sure if I understand everything right but my guess is that
one realtime buddy will take 0.4 kb maximum. So if I would like to only
use 256 MB of memory for the caching I could cache more than 500.000
buddies. I think if the aim is to reduce the load from the database it
should be able to cope with a big list. If you redesign the whole
realtime implementation, then you should think big.

Many sip devices have a short expiration time (+- 1 minute) to cope with
nat issues. I think it would not be a good idea to free them after
expiration and reload them form DB immediately again. Maybe we should be
able to set a configuration variable to define how long a buddy will
stay in cache after expiration: keepincacheafterexpiration=600 


Excuse me if I should be completely off topic.

Best regards,
Loic Didelot.

On Wed, 2007-05-30 at 09:20 +0200, Olle E Johansson wrote:
> 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
> _______________________________________________
> --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
-- 
Loic DIDELOT (CTO)
voipGATE S.A.
Tel: +352 20 200 223
Fax: +352 20 200 923
E-mail: ldidelot at voipgate.com
Web: http://www.voipgate.com