10 Jan
2006
10 Jan
'06
9:59 p.m.
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
11 Jan
11 Jan
1:15 p.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
2:29 p.m.
Hi Klaus!
Klaus Darilion wrote:
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
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.
12 Jan
12 Jan
7:27 p.m.
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
7:54 p.m.
On 01/12/06 19:27, Andreas Granig wrote:
Andreas Granig 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.
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
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
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
8:20 p.m.
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
13 Jan
13 Jan
12:43 p.m.
On 01/12/06 20:20, Andreas Granig wrote:
Daniel-Constantin Mierla wrote:
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.
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?
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
1:06 p.m.
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
23 Jan
23 Jan
8:12 p.m.
Daniel-Constantin Mierla wrote:
I've submitted the patch at the sourceforge-page.
Cheers,
Andy
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.
24 Jan
24 Jan
10:59 a.m.
Hello,
On 01/23/06 20:12, Andreas Granig wrote:
Daniel-Constantin Mierla wrote:
I've submitted the patch at the sourceforge-page.
great, thanks. It will be
merged with the new development of
registrar/usrloc.
Cheers,
Daniel
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.
6878
days inactive
6892
days old
9 comments
3 participants
participants (3)
-
Andreas Granig -
Daniel-Constantin Mierla -
Klaus Darilion