[Serusers] Replication problem

[Klaus Darilion]

Andreas Granig wrote:
> 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.

This means, you also have to store the contacts of the registered 
clients in these proxies.

> 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
> 
>