nat_uac_test("19") will add an extra test where srcip:port is compared to contactip:port. If they differ, you can add force proxing as stun failed. (BTW, STUN clients SHOULD not try to replace contact and sdp when symmetric nat is detected, but many uacs do.) Also, investigate active media, force_nated_sdp("3"). Many gateways support active media and some user agents. g-) ----- Original Message ----- From: Darren Sessions To: brettlist@nemeroff.com Cc: serusers@lists.iptel.org Sent: Tuesday, March 14, 2006 3:58 PM Subject: Re: [Serusers] Nat Helper + Media Proxy

I appreciate the insight, but let me clarify.

Today, we use stun + nathelper with over 6000 customers - and it works well. We have a relatively small percentage of customers that have, thus far, unsolvable issues (mostly symmetric nats). Having implemented the ser media proxy software about 2 years ago, I am familiar with the general principle behind the module (although the media proxy of today is far more advanced). Mediaproxy seems to work wonders for our customers that have problems and/or just don't work with our primary stun + nathelper methods.

What I meant to explain is that I wanted to utilize each of the modules specific functionality in a staged approach on one server. One of our primary concerns is local bandwidth consumption (we're a small outfit). To keep that to a minimum, we don't want to just use media proxy instead of nathelper to solve our problems. We'd prefer to use nathelper where it fits with the 90%+ of the customer base, and use mediaproxy with the rest , based on an analysis done on the call (e.g. all calls routing through one server and based on results from the previously mentioned nat testing functions (or something similar), would process a particular call with the appropriate module (nathelper or mediaproxy) and functions).

I hope I've better explained the situation.

Thanks again for your comments,

- Darren

Brett N wrote: Look, think of it this way..

When a NATTED phone makes a sip call, it places it's NATTED address in the header information of the call.. Making the far end phone send audio to this UNREACHABLE ip address.. Nathelper will assist you in REWRITING the SIP message such that you REMOVE the private addresses your NATTED phone has put in the SIP message and instead places the actual IP/port your phone uses to talk to SER with into the message. This in itself for most people will allow a natted phone to make phone calls..

Now if you are going from nat to nat or having trouble with one way calls or the like, or if you just want more control over the audio path, you can try mediaproxy. Chances are that you'll either need something like nathelper to fix the SIP messaging OR your proxy will need to be able to ping and be ping the proxy. OR your media proxy module will need to be able to do this rewriting for you.

Hope that helps. -Brett

On Mon, March 13, 2006 10:44 am, Darren Sessions wrote: I've been reading the docs on nathelper and mediaproxy and am curious about the possibility of implementing both modules/functionalities on the same proxy (with the dispatcher and media proxy scripts running on separate boxes).

The scenario would be to use either nathelper functionality or mediaproxy functionality based on results from something like client_nat_test, nat_uac_test, or another function like these. This would prevent unnecessary local bandwidth consumption by providing the correct nat transversal mechanism.

After extensive googling, I still haven't been able to find a working/ semi-working example on this type of combination.

Does anyone have any good pointers, example configs / basic configs, or ideas?

Thanks in advance,

- Darren

CALL | |-> Analysis | |-> NATHELPER or |-> MEDIAPROXY

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

------------------------------------------------------------------------------

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