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