[Serusers] fix_nated_contact onreply

[Nils Ohlmeier]

Hi Samuel,

Am 02.03.2009 9:51 Uhr, schrieb samuel:
> 2009/2/27 Nils Ohlmeier <lists at ohlmeier.org <mailto:lists at 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