<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br>On Jan 4, 2011, at 12:26 PM, Tilghman Lesher wrote:<br><br><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;">It wasn't designed to do this. While you can have the same sippeers table<br>for multiple servers, you really should have a separate sipregs table for<br>each backend server. The reason why is that some mappings depend<br>implicitly on the host to which it was registered. For example, if a phone<br>is behind a NAT, then the external port is dependent upon the same host<br>responding. If a different host tries to communicate to that external port,<br>some NAT devices will not route the packet properly. This is especially<br>true for SIP over TCP, but it's also true for UDP packets. (Routing<br>packets back through a NAT without verifying the sending IP is a security<br>risk.)<br>Probably more appropriate for your case is to use DUNDi to coordinate your<br>machines as to which server presents holds the registration for any<br>specific phone.</blockquote><br>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.<br><br>Thank you,<br><br>Bryan<br><br><br><br></body></html>