Nils,<br><br>Thank for your time.<br><br>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 ;)!!!!<br><br>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.<br>
<br>Thank you again!!!<br><br>Samuel.<br><br><div class="gmail_quote">2009/3/2 Nils Ohlmeier <span dir="ltr"><<a href="mailto:lists@ohlmeier.org">lists@ohlmeier.org</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Samuel,<br>
<br>
Am 02.03.2009 9:51 Uhr, schrieb samuel:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2009/2/27 Nils Ohlmeier <<a href="mailto:lists@ohlmeier.org" target="_blank">lists@ohlmeier.org</a> <mailto:<a href="mailto:lists@ohlmeier.org" target="_blank">lists@ohlmeier.org</a>>><div class="Ih2E3d"><br>
<br>
Hi Samuel,<br>
<br>
> I have seen lots of default config files where in the reply route<br>
only<br>
> after checking the message (client_nat_test(1)) fix_nated is called.<br>
> Why is not called when the NAT flag is set upong lookup_XX?<br>
<br>
because the Registrar module takes already care of setting everything up<br>
correctly when lookup() is being called.<br>
<br>
<br>
But, as far as I know, only in the called direction. If the called party<br>
is registered and behind NAT the lookup will indeed set the destination<br>
to the "public" side of the NAT. I was more interested in "rewriting"<br>
the Contact for the 200 OK because otherwise we find the classical lost<br>
of ACK and call drop after 2x-3x seconds<br>
</div></blockquote>
<br>
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?<br>
In the direction of the request where the registrar is involved we do already quite some NAT tests.<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> In ser-oob I think the reply_route should include the case of a user<br>
> called behind a NAT and the reply is not fixed due to some router in<br>
> the middle. Will it hurt including fix_nated_contact in the case of<br>
> checking the flag?<br>
<br>
I'm not entriely sure that I get what mean/complain about.<br>
When I take a look at the latest ser-oo.cfg from CVS Head<br>
<a href="http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/etc/ser-oob.cfg?revision=1.46&view=markup" target="_blank">http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/etc/ser-oob.cfg?revision=1.46&view=markup</a><br>
<<a href="http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/etc/ser-oob.cfg?revision=1.46&view=markup" target="_blank">http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/etc/ser-oob.cfg?revision=1.46&view=markup</a>><br>
I see in the REPLY_ROUTE a nat_uac_test("12) call and a<br>
fix_nated_contact() call afterwards. So the Contact of the B (called)<br>
party should be fixed if he is located behind NAT.<br>
<br>
<br>
But nat_uac_test will only check for private addresses on Contact, isn't<br>
it?<br>
</blockquote>
<br></div>
Yes, currently it checks only for private IPs in the Contact header, that is right.<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Let me try to explain with a message exchange<br>
<br>
---INVITE--> a.b.c.d:61000<br>
<--200OK-- source=a.b.c.d:61000 but Contact: a.b.c.d<br>
<br>
so ACK will be sent to a.b.c.d:5060 (deafult SIP port) instead of the<br>
"nated" port 61000.<br>
<br>
I know it's some ALG in the router but I was just wondering whether<br>
checking the natflag in the onreply route and calling fix_nated_contact<br>
would help in this case or it would cause other issues.<br>
</blockquote>
<br></div>
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.<br>
<br>
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.<br>
I'll add it and document the risk of both checks.<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Thanks for everythin and I hope I've been clearer in this mail,<br>
</blockquote>
<br></div>
I think I understood it better this time :-)<br>
<br>
Cheers<br><font color="#888888">
Nils<br>
</font></blockquote></div><br>