27 Feb
2009
27 Feb
'09
4:02 p.m.
I have seen lots of default config files where in the reply route only
after checking the message (client_nat_test(1)) fix_nated is called.
Why is not called when the NAT flag is set upong lookup_XX?
In ser-oob I think the reply_route should include the case of a user
called behind a NAT and the reply is not fixed due to some router in
the middle. Will it hurt including fix_nated_contact in the case of
checking the flag?
Friday thoughts...
Samuel
27 Feb
27 Feb
4:16 p.m.
Hi Samuel,
I have seen lots of default config files where in the
reply route only
after checking the message (client_nat_test(1)) fix_nated is called.
Why is not called when the NAT flag is set upong lookup_XX?
because the Registrar module takes already care of setting everything up
correctly when lookup() is being called.
In ser-oob I think the reply_route should include the
case of a user
called behind a NAT and the reply is not fixed due to some router in
the middle. Will it hurt including fix_nated_contact in the case of
checking the flag?
I'm not entriely sure that I get what mean/complain about.
When I take a look at the latest ser-oo.cfg from CVS Head
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/etc/ser-oob.cfg?re…
I see in the REPLY_ROUTE a nat_uac_test("12) call and a
fix_nated_contact() call afterwards. So the Contact of the B (called)
party should be fixed if he is located behind NAT.
Greetings
Nils
2 Mar
2 Mar
11:51 a.m.
Hi Nils,
responses inline...
2009/2/27 Nils Ohlmeier <lists(a)ohlmeier.org>
But nat_uac_test will only check for private addresses on Contact, isn't it?
Let me try to explain with a message exchange
---INVITE--> a.b.c.d:61000
<--200OK-- source=a.b.c.d:61000 but Contact: a.b.c.d
so ACK will be sent to a.b.c.d:5060 (deafult SIP port) instead of the
"nated" port 61000.
I know it's some ALG in the router but I was just wondering whether checking
the natflag in the onreply route and calling fix_nated_contact would help in
this case or it would cause other issues.
Hi Samuel,
But, as far as I know, only in the called direction. If the called party is
registered and behind NAT the lookup will indeed set the destination to the
"public" side of the NAT. I was more interested in "rewriting" the
Contact
for the 200 OK because otherwise we find the classical lost of ACK and call
drop after 2x-3x seconds
I have seen lots of default config files where in
the reply route only
after checking the message (client_nat_test(1)) fix_nated is called.
Why is not called when the NAT flag is set upong lookup_XX?
because the Registrar module takes already care of setting everything up
correctly when lookup() is being called. In ser-oob I think the reply_route should include
the case of a user
called behind a NAT and the reply is not fixed due to some router in
the middle. Will it hurt including fix_nated_contact in the case of
checking the flag?
I'm not entriely sure that I get what mean/complain about.
When I take a look at the latest ser-oo.cfg from CVS Head
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/etc/ser-oob.cfg?re…
I see in the REPLY_ROUTE a nat_uac_test("12) call and a
fix_nated_contact() call afterwards. So the Contact of the B (called)
party should be fixed if he is located behind NAT.
Greetings
Nils
Thanks for everythin and I hope I've been clearer in this mail,
Samuel.
1:17 p.m.
Hi Samuel,
Am 02.03.2009 9:51 Uhr, schrieb samuel:
Yes, currently it checks only for private IPs in the Contact header,
that is right.
2009/2/27 Nils Ohlmeier <lists(a)ohlmeier.org
<mailto:lists@ohlmeier.org>>
Hi Samuel,
Ok. But then you are referring only to the reply route, which has
nothing to do with the registrar or any lookup_xxx() call, right?
In the direction of the request where the registrar is involved we do
already quite some NAT tests.
I have seen lots of default config files where in
the reply route
only
after checking the message (client_nat_test(1))
fix_nated is called.
Why is not called when the NAT flag is set upong lookup_XX?
because the Registrar module takes already care of setting everything up
correctly when lookup() is being called.
But, as far as I know, only in the called direction. If the called party
is registered and behind NAT the lookup will indeed set the destination
to the "public" side of the NAT. I was more interested in
"rewriting"
the Contact for the 200 OK because otherwise we find the classical lost
of ACK and call drop after 2x-3x seconds In ser-oob I
think the reply_route should include the case of a user
called behind a NAT and the reply is not fixed due to some router in
the middle. Will it hurt including fix_nated_contact in the case of
checking the flag?
I'm not entriely sure that I get what mean/complain about.
When I take a look at the latest ser-oo.cfg from CVS Head
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/etc/ser-oob.cfg?re…
<http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/etc/ser-oob.cfg?revision=1.46&view=markup>
I see in the REPLY_ROUTE a nat_uac_test("12) call and a
fix_nated_contact() call afterwards. So the Contact of the B (called)
party should be fixed if he is located behind NAT.
But nat_uac_test will only check for private addresses on Contact, isn't
it? Let me try to explain with a message exchange
---INVITE--> a.b.c.d:61000
<--200OK-- source=a.b.c.d:61000 but Contact: a.b.c.d
so ACK will be sent to a.b.c.d:5060 (deafult SIP port) instead of the
"nated" port 61000.
I know it's some ALG in the router but I was just wondering whether
checking the natflag in the onreply route and calling fix_nated_contact
would help in this case or it would cause other issues.
Yes in this scenario there is either a strange ALG in between, or it is
quite stupid UA which learned its public IP but not its public port.
We could extend the nat_uac_test in the onreply route to compare the
port in the Contact header with the port from the transport. This check
is a little dangerous, because if you have UAs running on public IP
which do not want to use symmetric signaling, it breaks if we "fix"
their contacts. But as we do the same thing already for the request I
guess the risk is not any higher.
I'll add it and document the risk of both checks.
Thanks for everythin and I hope I've been clearer
in this mail,
I think I understood it better this time :-)
Cheers
Nils
6:34 p.m.
Nils,
Thank for your time.
This time I think I explained it better and your answers are what I was
looking for. BTW, the customer made some changes and everything is running
now...I love ALGs ;)!!!!
Since I don't think there are many UAs with public IP and asymetric
signalling I would add it in the example (oob) config file, maybe commented
with the warning you said.
Thank you again!!!
Samuel.
2009/3/2 Nils Ohlmeier <lists(a)ohlmeier.org>
Hi Samuel,
Am 02.03.2009 9:51 Uhr, schrieb samuel:
I think I understood it better this time :-)
Cheers
Nils
2009/2/27 Nils Ohlmeier <lists(a)ohlmeier.org
<mailto:lists@ohlmeier.org>
Hi Samuel,
Ok. But then you are referring only to the reply route, which has nothing
to do with the registrar or any lookup_xxx() call, right?
In the direction of the request where the registrar is involved we do
already quite some NAT tests.
I have seen lots of default config files where in
the reply route
only
after checking the message (client_nat_test(1))
fix_nated is called.
Why is not called when the NAT flag is set upong lookup_XX?
because the Registrar module takes already care of setting everything
up
correctly when lookup() is being called.
But, as far as I know, only in the called direction. If the called party
is registered and behind NAT the lookup will indeed set the destination
to the "public" side of the NAT. I was more interested in
"rewriting"
the Contact for the 200 OK because otherwise we find the classical lost
of ACK and call drop after 2x-3x seconds
In ser-oob I think the reply_route should include
the case of a user
I see in the REPLY_ROUTE a
nat_uac_test("12) call and a
fix_nated_contact() call afterwards. So the Contact of the B (called)
party should be fixed if he is located behind NAT.
But nat_uac_test will only check for private addresses on Contact, isn't
it?
Yes, currently it checks only for private IPs in the Contact header, that
is right.
Let me try to explain with a message exchange
called behind a NAT and the reply is not fixed
due to some router in
the middle. Will it hurt including fix_nated_contact in the case of
checking the flag?
I'm not entriely sure that I get what mean/complain about.
When I take a look at the latest ser-oo.cfg from CVS Head
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/etc/ser-oob.cfg?re…
<
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/etc/ser-oob.cfg?re…
---INVITE--> a.b.c.d:61000
<--200OK-- source=a.b.c.d:61000 but Contact: a.b.c.d
so ACK will be sent to a.b.c.d:5060 (deafult SIP port) instead of the
"nated" port 61000.
I know it's some ALG in the router but I was just wondering whether
checking the natflag in the onreply route and calling fix_nated_contact
would help in this case or it would cause other issues.
Yes in this scenario there is either a strange ALG in between, or it is
quite stupid UA which learned its public IP but not its public port.
We could extend the nat_uac_test in the onreply route to compare the port
in the Contact header with the port from the transport. This check is a
little dangerous, because if you have UAs running on public IP which do not
want to use symmetric signaling, it breaks if we "fix" their contacts. But
as we do the same thing already for the request I guess the risk is not any
higher.
I'll add it and document the risk of both checks.
Thanks for everythin and I hope I've been clearer in this mail,
5730
days inactive
5733
days old
4 comments
2 participants
participants (2)
-
Nils Ohlmeier -
samuel