[sr-dev] [kamailio/kamailio] lreproxy module (#2208)

Daniel-Constantin Mierla notifications at github.com
Sun Jan 3 20:44:57 CET 2021


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 or view it on GitHub:
https://github.com/kamailio/kamailio/pull/2208#issuecomment-753666893
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20210103/00eeff52/attachment.htm>


More information about the sr-dev mailing list