[asterisk-dev] Realtime and call states in SIP

[Olle E Johansson]

30 maj 2007 kl. 09.42 skrev 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.
>
Absolutely, I was just adding a number.  You also have to consider  
that you
can't have 500.000 simultaneous calls and you don't want to have peers
in memory for too long, then you loose the synch with the database  
and you
can switch to static anyway and issue a reload whenever you want to  
refresh
in-memory copies.

For chan_sip3 I'm trying to design a way to have all the devices in  
memory
and use manager commands to force resynch of individual devices or
groups of them. We won't keep all data in memory, but enough so we know
if we have a peer and how to communicate and authenticate with it. After
auth, we can load the rest and keep it in memory for the transaction  
processing,
then release that part.

> 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

Well, I think that's a broken model. Why not use NAT keepalives from  
the device
or from Asterisk, something that doesn't mean that you have to  
authenticate? With a 1 minute
expiration you will get a lot of auth messages and put un-needed  
burden on
your CPU.

> Excuse me if I should be completely off topic.
Not at all, not at all. This is the kind of feedback I was looking  
for. I need all kinds
of input, regardless of what I think ;-) in order to create a useful  
solution.

/O