1 Aug
2005
1 Aug
'05
12:41 p.m.
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