On Jun 28, 2004 at 16:51, Jev <jev(a)ecad.org> wrote:
I have made a diagram using Dia, of a ser footprint that I would like to
put together.
http://www.ecad.org/~jev/ser/SerFootprint.png
The idea is that all user accounts, and locations (Down to ser/rtpproxy
fronted) will be stored in the main Billing/User accounts back end. I
want to have a farm of front end ser machines which will just proxy
invites/registers/byes to the back end for authentication,
authorization, and billing, and also proxy RTP by means of either Maxims
rtpproxy or AG's mediaproxy.
The front end SERs will be able to come and go, and our cisco router
will manage the balancing (using things like 'sticky IP').
So all the packets comming from the same ip will be sent to the same
fron end SER? (hashing after src ip)?
Anyway there are some problems related to the nat traversal:
1. nat ping - nat ping needs to access usrloc, so that it would know
which users to ping. However on your setup the front-end servers have no
ideea about this, so they wouldn't be able to nat ping. The "main"
server (User accounts) knows who to ping but its ping won't traverse a
symmetric nat (the nat will have an open binding only with the outbound
proxy, which would be one of the load balanced front-ends).
2. consider user A calling user B, where at least B is behind a nat.
The invite would reach the "main" server which will look up B and will
try to send the message to B's address. Unfortunately B's nat will drop
the packet, because it has an open binding only between B and the load
balanced ip. (this will work only if B has a full cone nat which is very
very unlikely)
3. assuming the above stuff will work somehow, you still have to be very
carefull to open only one rtp proxy session (since each front end has
its own rtp proxy you should make sure you use force_rtp_proxy on only
one of them, for the same call)
Andrei