Greger, Klaus,
Another problem: nathelper uses the in memory location table to ping natted clients. Thus, also nathelper would have to query the database and we need a process to watch the expires and delete outdated entries.
Interesting thoughts. I still don't have the overall overview of the cache and where exactly it is used, but I already thought this won't be that easy.
However, I'll start writing my diploma thesis the next weeks, and it will target SIP clusters using SER, because there's rather few work done which is available for the public.
The basic idea is to use one SER pair (let's say sip1.foo.bar) as some kind of session border controller secured with some failover protocol (carp/vrrp/...) which does the NAT ping and SIP balancing stuff. When this border proxy reaches it's max. capacity, you can just add another pair (sip2.foo.bar) and propagate it to new customers.
Behind that border proxy you can dynamically add/remove the proxies which do the routing. They all have a database cluster behind them which they use for location lookup and other stuff. After experimenting a lot with SIP replication I think it's best to delegate this to the DB system where a lot of work is done in this area for years now.
I'm fully aware that all this sounds much easier than it is, but IMHO this is the way to go, because it's the only solution I can think of which scales and is also able to handle NAT.
Well, we'll see where this all leads us (or me) to ;o)
Andy