Have you looked at the Path implementation in the experimental CVS module?
It should be possible to use for that purpose. As stated earlier on this
list, it's on my to-do list to set up a test implementation with at least
two registrars using that module, but...
I'm not sure I understand the idea of using a SER pair as a session
border controller. Also, using carp/vrrp, do you plan an active-passive
setup?
g-)
Andreas Granig wrote:
Klaus Darilion wrote:
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.
Right, and this is also a reason why I want to go for a single
location table inside a DB cluster instead of using the cache. But
I'll have to lookup the discussion with Jan about the new cache
pointed out by Greger first.
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?
I currently favour the Path header over rewriting the Contact, because
that's what the Path header is designed for, isn't it? (haven't fully
read the RFC yet).
Andy