2009/3/2 Nils Ohlmeier <lists@ohlmeier.org>

Hi Samuel,

Am 02.03.2009 9:51 Uhr, schrieb samuel:

2009/2/27 Nils Ohlmeier <lists@ohlmeier.org <mailto:lists@ohlmeier.org>>

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.

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

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.

> 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?revision=1.46&view=markup
<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?

Yes, currently it checks only for private IPs in the Contact header, that is right.

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