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
Hi Andreas!
Andreas Granig wrote:
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?
I think the only limitation is, that the SIP client sees a modified URI in incoming INVITE requests and in the 200 Ok responses for the REGISTER messages. I guess most clients do not care, but AFAI remember there was a posting that a client did not accept the 200 Ok reponse with the modified contact.
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(); }
I you do not care about the "strict" clients, what about using fix_nated_contact in the load balancer and fix_nated_register in the proxy? Then, the requests should be automatically be routed to load balancer.
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.
AFAIK this is correct.
regards klaus
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
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi Klaus!
Klaus Darilion wrote:
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?
I think the only limitation is, that the SIP client sees a modified URI in incoming INVITE requests and in the 200 Ok responses for the REGISTER messages. I guess most clients do not care, but AFAI remember there was a posting that a client did not accept the 200 Ok reponse with the modified contact.
I faintly remembered this discussion, thus the question.
But I see this approach isn't RFC compliant, so maybe it's better to forget this hack and go for a clean Path-Header solution...
Andy
Andreas Granig wrote:
But I see this approach isn't RFC compliant, so maybe it's better to forget this hack and go for a clean Path-Header solution...
Just an idea regarding load balancing and NAT using the Path header:
When having a scenario like this:
[uac] -> [nat] -> [sip loadbalancer] -> [sip proxy]
Then I could construct a Path header like the following at the load balancer for REGISTERs:
Path: <sip:<own-address;lr>, <sip:<received-address>;lr>;nat=yes
Which is saved at the sip proxy when acting as registrar and will be converted into a Route header for subsequent requests towards the uac.
This would allow loose-routing on the load balancer to traverse the client's nat: In addition to removing the first uri (the own) from the Route header, loose_route() would check for the "nat=yes" flag in the next uri and would remove that uri from the Route header too after setting it as dst-uri.
Would this make sense, or are there more-elegant/simpler/better ways for achieving such a loadbalancing scenario (keeping in mind that there might be more than one load balancer and that it has to work with NAT)?
Andy
On 01/12/06 19:27, Andreas Granig wrote:
Andreas Granig wrote:
But I see this approach isn't RFC compliant, so maybe it's better to forget this hack and go for a clean Path-Header solution...
Just an idea regarding load balancing and NAT using the Path header:
When having a scenario like this:
[uac] -> [nat] -> [sip loadbalancer] -> [sip proxy]
Then I could construct a Path header like the following at the load balancer for REGISTERs:
Path: <sip:<own-address;lr>, <sip:<received-address>;lr>;nat=yes
Maybe is better to have: Path: sip:own-address;lr;received=received-address for the server in front of nat (load balancer). When loose_route() process the header it can take the received parameter and use it as dst_uri if no other Route header is present.
Otherwise I see troubles to process a Route header which does not have server's address -- think about peering with other SIP networks where you cannot control what the server will add as parameters to Record-Route.
Cheers, Daniel
Which is saved at the sip proxy when acting as registrar and will be converted into a Route header for subsequent requests towards the uac.
This would allow loose-routing on the load balancer to traverse the client's nat: In addition to removing the first uri (the own) from the Route header, loose_route() would check for the "nat=yes" flag in the next uri and would remove that uri from the Route header too after setting it as dst-uri.
Would this make sense, or are there more-elegant/simpler/better ways for achieving such a loadbalancing scenario (keeping in mind that there might be more than one load balancer and that it has to work with NAT)?
Andy
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Daniel-Constantin Mierla wrote:
Maybe is better to have: Path: sip:own-address;lr;received=received-address for the server in front of nat (load balancer). When loose_route() process the header it can take the received parameter and use it as dst_uri if no other Route header is present.
Makes sense and seems to be a cleaner solution, yes.
Otherwise I see troubles to process a Route header which does not have server's address -- think about peering with other SIP networks where you cannot control what the server will add as parameters to Record-Route.
I don't really get your point. In my understanding, this particular Route header, inserted at the proxy, never leaves the own network because it will be removed at the next hop (the load balancer in this case).
But I like the idea using the received-param much better anyhow...
So I'd like to port my Path-patch posted on the ser list in October (http://mail.iptel.org/pipermail/serdev/2005-October/005847.html) to openser. There are just one problem: as far as I've read, you're working on a cacheless solution for usrloc, so there might be quite some code conflicts if I start off now. So when do you think will your changes be in CVS?
Andy
On 01/12/06 20:20, Andreas Granig wrote:
Daniel-Constantin Mierla wrote:
Maybe is better to have: Path: sip:own-address;lr;received=received-address for the server in front of nat (load balancer). When loose_route() process the header it can take the received parameter and use it as dst_uri if no other Route header is present.
Makes sense and seems to be a cleaner solution, yes.
Otherwise I see troubles to process a Route header which does not have server's address -- think about peering with other SIP networks where you cannot control what the server will add as parameters to Record-Route.
I don't really get your point. In my understanding, this particular Route header, inserted at the proxy, never leaves the own network because it will be removed at the next hop (the load balancer in this case).
I am thinking to a scenario where you peer your network to another ones. So you have a connection like:
[Your proxy] <---> [Load balancer] <---> [Foreign proxy]
When the calls come from the foreign proxy, the RR added by Foreign proxy is not controllable, so in the case of BYE you may get in difficulties to make the decision to remove or not the Route header. You may get a solutions based on IP of the Foreign proxies, but it may get ugly at a moment.
But I like the idea using the received-param much better anyhow...
So I'd like to port my Path-patch posted on the ser list in October (http://mail.iptel.org/pipermail/serdev/2005-October/005847.html) to openser. There are just one problem: as far as I've read, you're working on a cacheless solution for usrloc, so there might be quite some code conflicts if I start off now. So when do you think will your changes be in CVS?
If you can do the patch in about one week, then it is fine. We are not planning any changes next week to registrar/usrloc, so we can work afterwards on the version which includes your patch.
Cheers, Daniel
Andy
Daniel-Constantin Mierla wrote:
When the calls come from the foreign proxy, the RR added by Foreign proxy is not controllable, so in the case of BYE you may get in difficulties to make the decision to remove or not the Route header. You may get a solutions based on IP of the Foreign proxies, but it may get ugly at a moment.
Ok, got it.
If you can do the patch in about one week, then it is fine.
Hard to say, because it'll be my first experience with the openser code, but it should be possible, yes...
Andy
Daniel-Constantin Mierla wrote:
So I'd like to port my Path-patch posted on the ser list in October (http://mail.iptel.org/pipermail/serdev/2005-October/005847.html) to openser. There are just one problem: as far as I've read, you're working on a cacheless solution for usrloc, so there might be quite some code conflicts if I start off now. So when do you think will your changes be in CVS?
If you can do the patch in about one week, then it is fine. We are not planning any changes next week to registrar/usrloc, so we can work afterwards on the version which includes your patch.
I've submitted the patch at the sourceforge-page.
Cheers, Andy
Hello,
On 01/23/06 20:12, Andreas Granig wrote:
Daniel-Constantin Mierla wrote:
So I'd like to port my Path-patch posted on the ser list in October (http://mail.iptel.org/pipermail/serdev/2005-October/005847.html) to openser. There are just one problem: as far as I've read, you're working on a cacheless solution for usrloc, so there might be quite some code conflicts if I start off now. So when do you think will your changes be in CVS?
If you can do the patch in about one week, then it is fine. We are not planning any changes next week to registrar/usrloc, so we can work afterwards on the version which includes your patch.
I've submitted the patch at the sourceforge-page.
great, thanks. It will be merged with the new development of registrar/usrloc.
Cheers, Daniel
-
Andreas Granig -
Daniel-Constantin Mierla -
Klaus Darilion