In my opinion,
consider the considerations of strong module dependencies in the design. For example, you
have used the capabilities of another module in your code and called it recently, while it
might be better to design and implement this capability in the new module itself. Another
important point is that this heavy dependency can even reduce the performance of the
Rrtpengine module in normal mode. Suppose you have several rtpengine nodes separately from
the Kamailio server. In this case, you will not receive the media packets on the Kamailio
server itself. How does the new module want to access the packets on the other server? I
think each nodes separately performs the recording operation and saves it to its own file
system. However, this development can be a good contributions for Kamailio.
Its a bit difficult to comment on the performance differences of different architectural
approaches without seeing it implemented and running somewhere. Regarding the rtpengine
call recording, this is indeed executed on the individual nodes where the rtpengine is
executed.
If the mentioned new module needs to communicate with the rtpengine, its is in my opinion
a good design choice to use the existing module and not duplicating the same code again on
its own. I don't think this will cause any issue for the performance of the rtpengine
module (for its own usage), if the communication path from the Kamailio server to the
rtpengine daemons is working fine.
What i mean the strong dependency between the siprec module and the rtpengine daemon
service. Using pure code in the siprec module can add these capabilities when you use
other rtp engines (like as lrkproxy or rtpproxy) in the solution. However, we have to wait
for the work to be done.
--
Reply to this email directly or view it on GitHub:
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3948/c2296048103(a)github.com>