Richard schrieb:
You have to use nathelper+rtpproxy as soon as one of the clients is behind NAT. E.g. if the public client calls the natted client, you also have to use rtpproxy. Thus, you have to setup a reply route.
nat_uac_test detects only if the caller is natted. To detect if the callee is NATed, use the nat_flag parameter: http://lists.iptel.org/pipermail/serusers/2003-December/004412.html
Anyone knows how to find out if a callee in a mid-dialog call is behind NAT?
If the callee is in your usrloc there's no problem at all: save() stores the nat flags you set upon checking the callees initial REGISTER. So there's never a problem when the callee is known to you, i.e. has REGISTERed itself at your proxy. So there's no problem for foreign inbound calls to your clients, because you can check on the first INVITE if the foreign client is behind a NAT and you know already if your client is behind a NAT, so you can loop in your RTP relay when needed.
The trouble is calls originating from one of your subscribers without NAT to a foreign destination: you don't know anything about their NAT state when SER processes the intiial INVITE. I don't know a way to determine the NAT-state of any foreign destinations while processing the first INVITE. But I think: every domain has to be NAT-able by itself. So if you take care that your NAT'ed clients can be reached and the foreign domain takes care that their NAT'ed clients can be reached about the same way, there should be no problem.
Just my two cents.
Alex Mack