I read that, but I am not using that sample config file.

Greger V. Teigre wrote:

Have a look at the http://ONsip.org/ Getting Started document. Note the news-posting on the frontpage regarding an error in the rtpproxy example config. g-)

Rod Bacon wrote:

...

Well.. it probably is.

I have had mixed success with SER 0.8.14 and RTPPROXY. I have RADIUS auth, accounting, MYSQL, blah, blah, blah, all working....

My question, however, surrounds NAThelper configuration. If I leave all clients behind NATs to attempt registration with private IPs, fix the IPs with NAThelper and proxy the streams, then everything works OK. If I inroduce a client that is on a LIVE IP address, I only get one-way audio to a natted client (the natted client can't hear the live client). I assume that what is happening is that the live client is attempting to send it's audio direct to the natted client, instead of via the proxy. I figure that I've missed something silly somewhere in the config, but I'm darned if I know where.

I won't bother posting my entire config (unless specifically requested), rather I'd like a general pointer as to where I should be looking. Thanks in advance.

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

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