In Kamailio we accept modules that offer the same/similar functionality that is provided by other modules. So from this point of view, it is not a problem that we already have rtpproxy, rtpengine or mediaproxy as alternatives for relaying RTP packets.

Personally, as I understood after a brief check, I can't see this module being more performant than rtpengine in any way, because rtpengine does already kernel/iptables-based forwarding. But performance is also not a criterion to accept a contribution.

First criterion is to be sure is no conflict in terms of copyright. Second is not to be confusing in relation with the other existing modules. And, the third, very important as well, is that the author of the module is willing to maintain and support the module for at least a few years.

From my point of view, the second is quite debatable, because, as I understand, the LREProxy name expands to Light-RTP-Engine-Proxy. In my opinion, that suggests it is a proxy for the existing RTPEngine, which obviously is not the case. From what we have now, it is also a little bit confusing considering we have both RTP+Proxy and RTP+Engine, this one is somehow combining the both.

Also, from a personal point of view, Proxy is a generic term (used in things like RTPProxy or MediaProxy) referring mainly to get-in/send-out, while Engine suggests more, like processing, transformation, ... which clearly the existing RTPEngine does with encryption/decryption or transcoding.

If LREProxy aims to focus on performance, I would propose to change the E in the name suggest what this module does, like LRKProxy (Light-RTP-Kernel-Proxy) or LRIProxy (Light-RTP-IPTable-Proxy), or meaning of E in something that relates, like Express (Light-RTP-Express-Proxy). This will greatly avoid any confusion with existing modules, making this one distinct in name and purpose.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.