[Serusers] fix_nated_contact onreply

[samuel]

Hi Nils,

responses inline...

2009/2/27 Nils Ohlmeier <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


>
> > 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
> 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.


>
> Greetings
>   Nils
>
> Thanks for everythin and I hope I've been clearer in this mail,
Samuel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20090302/cc782a9b/attachment.htm>