[Serusers] fix_nated_contact onreply

[samuel]

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 at ohlmeier.org>

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20090302/fe4d0b8e/attachment.htm>