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 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
