<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
I appreciate the insight, but let me clarify.<br>
<br>
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.<br>
<br>
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).<br>
<br>
I hope I've better explained the situation.<br>
<br>
Thanks again for your comments,<br>
<br>
- Darren<br>
<br>
<br>
<br>
Brett N wrote:
<blockquote
cite="mid53889.207.90.232.34.1142269388.squirrel@mail.nemeroff.com"
type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:serusers@lists.iptel.org">serusers@lists.iptel.org</a>
<a class="moz-txt-link-freetext" href="http://lists.iptel.org/mailman/listinfo/serusers">http://lists.iptel.org/mailman/listinfo/serusers</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>