Hi all. I was hoping someone could double-check my thinking, and make sure I get off on the right foot with a new SER setup. I don't think any of the examples in the admin manual cover my scenario, so I'm not entirely sure on how to approach it. Here comes the crude ASCII: +--------+ +-------------------+ +-------+ +----------------------+ | Phones |___| Router/SER Server |___| I'net |___| SER Server/PSTN Gate | | 10.x | | 10.0.0.1 - Public | | * | | 17.40.2.42 | +--------+ +-------------------+ +-------+ +----------------------+ [Figure explanation: The phones (Cisco 7960s) are on a private, NAT'd network. The IP router for this network also happens to be the local SIP server, running SER. Another SER server, reachable via the Internet, has access to a PSTN Gateway.] All of the documentation I've seen assumes that either the phones are behind NAT, and the SIP server is outside, or that both devices are public. I'm hoping that having the SER server multihomed will ease some of the issues associated with SIP-through-NAT. Testing without the local server showed problems with call transferring and the like, though I still suspect this was entirely my fault. What would be the proper way to go about configuring SER for this type of network layout? If I use record_route() and proxy all of the RTP traffic, does this avoid needing to mangling up the poor packets with the nathelper module? It seems like if I add "mhomed=1" to the local server, to get the "Via" header set to the external interface's address, and add "reply_to_via=yes" on the public SIP server, the local SER should be able to function like a traditional proxy for the phones. Is this the next-best thing to end-to-end connectivity? How about user configuration? Add accounts for each of phone numbers to both SER servers, grant them to a new group on the public server (17.40.2.42), and then, to forward inbound calls, is it as simple as: is_user_in("To", "my-local-group") { route(x) } If it's any easier, I *can* move the SER server to a separate machine behind the NAT on the 10.x network. Thanks for listening, and extra thanks for any insight you can provide. Jeremy -- Jeremy M. Dolan <mailto:jmd@pobox.com> <http://jmd.us/> PGP: 1024D/3C68A1BA 9470 210C A476 FFBB 6D11 0223 0D1C ABFC 3C68 A1BA