1 Aug
2005
1 Aug
'05
1:24 p.m.
Andreas Granig wrote:
Greger, Klaus,
This means, you also have to store the contacts of the registered
clients in these proxies.
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.
As you have routing proxies and outbound proxies, have you thought about
how to route the SIP messages from the routing proxies via the
corresponding outbound proxy? Using the Path: header, or rewriting the
contact in the REGISTER messages in the outboundproxy before forwarding
it to the routing proxy, or any other method?
regards,
klaus
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