Hi,
A question to the NAT experts:
I wonder if there are known side effects if I use fix_nated_contact() in
combination with nat_flag in the registrar module instead of
fix_nated_register() to save NATed contacts?
What I want to do is checking for NAT on a stateless SER acting as load
balancer, then forwarding it to a proxy in the LAN, like:
# remove P-Nated-HF here if present...
if(method == REGISTER &&
!search("^Contact:[ ]*\*") &&
client_nat_test("7"))
{
fix_nated_contact();
append_hf("P-Nated: 1\r\n");
force_rport();
}
# forwarding to proxy using dispatcher module
And in the proxy:
modparam("registrar", "nat_flag", 1)
# ...
if(method == REGISTER)
{
if(is_present_hf("P-Nated")) setflag(1);
save("location");
}
# ...
if(method == INVITE)
{
# a request for a local user...
lookup("location");
setdsturi("sip:<address of loadbalancer>");
t_relay();
}
Of course a mechanism has to be provided to let the loadbalancer or an
external application NAT-ping the address provided in the rewritten contact.
As far as I have seen, the difference is that this approach would save
the NAT-adress of the contact in usrloc with an empty received-param,
while fix_nated_register() saves the private adress of the contact with
the NAT-adress in the received-param.
I would assume (not verified yet), that in the case of using
fix_nated_contact(), the NAT-address is set as r-uri after a lookup,
with an empty dst-uri, which will have to be set to the load balancer's
address to traverse the client-side NAT.
In case of using fix_nated_register(), I assume the r-uri is set to the
client's private address, and the received-address as dst-uri.
Traversing the client's NAT wouldn't be that easy in this case because
you would have to save the received-address somewhere in the message and
forward the request to the load-balancer, which in turn has to forward
it to the client's NAT address.
So would this approach using fix_nated_contact() for REGISTERs make
sense for using a SER-based load balancer? Or are there any limitations
I haven't considered?
Thanks,
Andy