[asterisk-users] Realtime SIP, multiple AX servers question

[Tilghman Lesher]

On Wednesday 05 January 2011 09:39:00 Bryan Field-Elliot wrote:
> On Jan 4, 2011, at 12:26 PM, Tilghman Lesher wrote:
> 
> > It wasn't designed to do this.  While you can have the same sippeers
> > table for multiple servers, you really should have a separate sipregs
> > table for each backend server.  The reason why is that some mappings
> > depend implicitly on the host to which it was registered.  For example,
> > if a phone is behind a NAT, then the external port is dependent upon
> > the same host responding.  If a different host tries to communicate to
> > that external port, some NAT devices will not route the packet
> > properly.  This is especially true for SIP over TCP, but it's also true
> > for UDP packets.  (Routing packets back through a NAT without verifying
> > the sending IP is a security risk.)
> >
> > Probably more appropriate for your case is to use DUNDi to coordinate
> > your machines as to which server presents holds the registration for
> > any specific phone.
>
> We have one table which is serving both purposes (peers and reg). When
> we want to route a call to an ATA, we first look up that ATA's
> regserver in that table, and then construct a SIP URI based upon that
> regserver address. In that way, we route the call through the server to
> which the ATA is currently registered. So I guess we're covered already
> in the scenario you describe. It seems like not a great design to have
> to have a private sipregs table for every server in our pool,
> especially given that the pool will grow (or maybe shrink) over time.
> Is that really the recommended design? I haven't seen any articles
> describing that setup for RealTime in a multi-server environment.

Sorry, but a private table for sipregs for each server was exactly what it
designed for, in order to separate out values which change per-server from
general configuration (same for every server).  While I understand that
you're presently using a separate lookup into that table, DUNDi is the
(scalable!) protocol meant to perform this task for you.  Clearly, using a
shared sipregs table has its own set of problems; rather than sticking to
your flawed configuration, I would think that you would jump at the chance
to fix it.

-- 
Tilghman