<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Maxim Sobolev a écrit :
<blockquote cite="mid:4A736AD5.5090907@sippysoft.com" type="cite">
<pre wrap="">Emmanuel,
Thank you for your message. Please see my comments in-line below.
Emmanuel BUU wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello everybody,
I would like to submit two enhancement proposal for the RTPproxy software:
1/ automatic bridging handling
(...)
Ultimately, the configuration of RTP proxy could be automated by
scanbing the IP routing tables of the host.
</pre>
</blockquote>
<pre wrap=""><!---->
This feature is already supported in our private development tree (IPv4
only for now) and it will be released soon. It would require matching
changes on the part of SER/Kamalio/OpenSIPS/B2BUA as well as IPv6
support, which what holds it at the moment.
</pre>
</blockquote>
Hum great, maybe I can help with the NATHELPER module of OpenSIPS if
you describe me what change have been made to the RTP proxy control
protocol and provide me access to the source code.<br>
<br>
<blockquote cite="mid:4A736AD5.5090907@sippysoft.com" type="cite">
<blockquote type="cite">
<pre wrap="">2/ External NAT handling
I would also to handle the case where RTP proxy is behind a NAT (one to
one NAT). If the communication is on the internal network then the
previous processing is applied. If the communication is to be done with
the external network, rtp proxy would bind to the same interface but
advertise the NATed adress in the answer.
</pre>
</blockquote>
</blockquote>
What about this case? Is there a way to handle external NAT by pairing
some interface witn an external advertised address ?<br>
<blockquote cite="mid:4A736AD5.5090907@sippysoft.com" type="cite">
<blockquote type="cite">
<pre wrap="">
We propose to implement these two enhancements but would like to agree
with the rtp maintainer in order to have a chance to push this into the
open source. This lead me to another question. RTPProxy has currently
no configuration file. Would the crowd here consider such an addition to
describe the networks (and maybe the port range)?
What config library would you favor?
</pre>
</blockquote>
<pre wrap=""><!---->
Yes, RTPproxy really needs a configuration file, this is something on my
list of features for 2.0 as well. I don't have any strong preference for
config library, however it should meet the few basic criteria:
1. BSD-like license. Apache, Mozilla, MIT are fine. No GPL/LGPL.
2. Clean interface and internal representation. Ability to have
different contexts.
3. Ability to handle on-the-fly config file reload gracefully.
So, feel free if you want to suggest and discuss something or even want
to make a code submission.
</pre>
</blockquote>
Few !! These are proper requirements. Why is GPL not accepted? I
thought that rtpproxy was GPL also?<br>
Or maybe there is an intellectual propery issue?<br>
<br>
Ok I did not find any of these compling the 3 requirements. Req #3 is
tough ...<br>
<blockquote cite="mid:4A736AD5.5090907@sippysoft.com" type="cite">
<pre wrap="">
I look foward to hearing from you.
Sincerely,
</pre>
</blockquote>
<br>
</body>
</html>