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