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