[OpenSIPS-Devel] [opensips] [RFC] An initial attempt of porting rtpproxy-ng module from your twin project to OpenSIPS. (#152)

ag at ag-projects.com ag at ag-projects.com
Fri Feb 21 19:14:56 CET 2014


This is in 2008 and 2009 http://mediaproxy-ng.org

http://web.archive.org/web/20080712171630/http://mediaproxy-ng.org/
 
MediaProxy 2.0 is the second generation media relay application which is based on a completely new design that allows for major improvements in areas such as scalability (an order of magnitude more scalable than previous version) and security (communication between relay and dispatcher is encrypted).

So while your product has new and cool features OpenSIPS users might enjoy, the choice for its naming is not that great. If I were you I would rename it to something that uniquely identifies your product and causes no confusions with the past, present and future.

Thanks,
Adrian

On 21 Feb 2014, at 13:59, Richard Fuchs <notifications at github.com> wrote:

> As the author of mediaproxy-ng, let me try to clear up the confusion about the naming.
> 
> Many moons ago, the team at Sipwise was using a privately developed, closed source RTP proxy. It was designed to be used with the Openser "mediaproxy" module, and as such we called our project mediaproxy, even though it was completely unrelated to the AG Projects Mediaproxy.
> 
> Later on, we decided to redesign our mediaproxy from scratch and eventually make it open source. Thus, mediaproxy-ng was born. At around the same time, we decided to shift our focus away from the Openser "mediaproxy" module and support the control module "rtpproxy" instead (even though compatibility with the other module was retained).
> 
> Yet again later on, consensus among developers was that the future way to go for media/RTP proxying was to employ a JSON-like control protocol that allows complete rewriting of the entire SDP body. We went ahead and implemented this into mediaproxy-ng. As a new control module was required, we took the old "rtpproxy" module and modified it. As the new module was (and still is) intended as a drop-in replacement for the "rtpproxy" module (and not the unrelated "mediaproxy" module), we called it "rtpproxy-ng" to make transitioning easier.
> 
> Other people have suggested to call the new module "mediaproxy-ng" instead of "rtpproxy-ng", which would be more logical because it was meant to be used with the mediaproxy-ng daemon, but then that would imply that this module somehow is a fork or modification of the old "mediaproxy" module, which it isn't. All the functions within "rtpproxy-ng" are taken more or less directly from "rtpproxy" without even renaming them, so it makes sense to retain "rtpproxy" in the name of the module.
> 
> Also, there's no reason why "rtpproxy-ng" cannot be used with other RTP/media proxies if they choose to implement this new protocol. By no means is it exclusive to mediaproxy-ng.
> 
> So the reasons for the naming are entirely historical. Other than the reasons given for easy transitioning from "rtpproxy" to "rtpproxy-ng", there's no reason why the module can't be renamed to anything else.
> 
>> Reply to this email directly or view it on GitHub.
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20140221/5c452bba/attachment.htm>


More information about the Devel mailing list