lreproxy: add new lreproxy module
<!-- Kamailio Pull Request Template -->
<!-- IMPORTANT: - for detailed contributing guidelines, read: https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md - pull requests must be done to master branch, unless they are backports of fixes from master branch to a stable branch - backports to stable branches must be done with 'git cherry-pick -x ...' - code is contributed under BSD for core and main components (tm, sl, auth, tls) - code is contributed GPLv2 or a compatible license for the other components - GPL code is contributed with OpenSSL licensing exception -->
#### Pre-Submission Checklist <!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply --> <!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above--> <!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list --> - [ ] Commit message has the format required by CONTRIBUTING guide - [ ] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] Each component has a single commit (if not, squash them into one commit) - [ ] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist: <!-- Go over all points below, and after creating the PR, tick the checkboxes that apply --> - [ ] PR should be backported to stable branches - [ ] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description <!-- Describe your changes in detail -->
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/2208
-- Commit Summary --
* lreproxy module
-- File Changes --
A src/modules/lreproxy/README.md (1) A src/modules/lreproxy/lreproxy.c (1976) A src/modules/lreproxy/lreproxy.h (120) A src/modules/lreproxy/lreproxy_funcs.c (460) A src/modules/lreproxy/lreproxy_funcs.h (41) A src/modules/lreproxy/lreproxy_hash.c (521) A src/modules/lreproxy/lreproxy_hash.h (70)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/2208.patch https://github.com/kamailio/kamailio/pull/2208.diff
The lreproxy is a Light-RTP-Engine module for Kamailio project. The lreproxy engine have developed based LKM for linux. It uses off-loading technique for relaying huge number of RTP. It could be used in ingress nodes in your voip network. This module use a customised rtp packet classification that could lead to process faster and less consumption resource than other rtp engines. Basically all packet classifications will done based five-tuple fields in Linux kernel while in lreproxy it could be done with customised 2 or 3 tuple of packet fields.
there's no doc at all. Please take a look over other modules and provide the documentation.
Sure, It is under developing.
sergey-safarov commented on this pull request.
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + * + */ + +#include <sys/types.h> +#include <sys/socket.h> +#include <sys/time.h> +#include <netinet/in.h> +#include <netinet/in_systm.h> +#ifndef __USE_BSD +#define __USE_BSD
Is required force define `__USE_BSD` on all systems? Say on Linux.
Where I can get source (description) of `lre proxy server`? Is ` lre proxy server` fork of [`RTP proxy`](https://www.rtpproxy.org/)?
I don't publish the lreproxy engine because of quite bit of updating. No, Actually is a linux kernel module that would be insert to linux module for working with this module.
The kernel module does not have to be published here, but is it open source? If yes, is it available somewhere (another github repository or a public portal)?
sobomax commented on this pull request.
@@ -0,0 +1,120 @@
+/* + * Copyright (C) 2019-2020 Mojtaba Esfandiari.S, Nasim-Telecom
From brief look to it, this is pretty much carboon-copy of the rtpproxy module, as such original (c) line of the code should be reproduced. Thanks!
sobomax commented on this pull request.
@@ -0,0 +1,1976 @@
+/* + * Copyright (C) 2019-2020 Mojtaba Esfandiari.S, Nasim-Telecom
From brief look to it, this is pretty much carboon-copy of the rtpproxy module, as such original (c) line of the code should be reproduced. Thanks!
mojtabaesfandiari commented on this pull request.
@@ -0,0 +1,1976 @@
+/* + * Copyright (C) 2019-2020 Mojtaba Esfandiari.S, Nasim-Telecom
For cause of compatibilities with other codes in Kamailio, I decided to use rtpproxy module,such as naming of functions, parsing URL, SDP, get media descriptions and etc. But the process of relaying media is completely different. The LREProxy uses PREROUTING in netfilter hooks in Linux networking stack. The LREProxy engine is running pass the last steps of developing, Because it needs to use netlink library for interacting between user-pace and kernel-space, it took more time.
@mojtabaesfandiari are you looked [`DPDK`](https://www.dpdk.org/) initiative. This initiative driven by many hardware and software [vendors](https://www.dpdk.org/ecosystem/#members).
`DPDK` move packet processing from kernel to network interface card. `DPDK` allow get network packet processing at 40Gb/s and more speed.
@sobomax - thanks for looking into it.
@mojtabaesfandiari - if there are continuous parts of code copied over from an existing module such as rtpproxy, you have to keep original copyright line and add yours for the additions. You can split the file in two, one with copied code and one with your code, if you want to have them clearly separate.
I haven't compared any files to have an opinion on it, but if there is a copyright dispute, it should be settled before merging.
@mojtabaesfandiari - as I looked a bit over, I noticed large parts of commented code. Remove them if they are not useful anymore, makes the files big and hard to follow.
@sergey-safarov Just a quite little, I should look it more and compare its results with my results. Thanks for sharing it
@miconda Sure, I just pasted these lines "copy rights "at top of my code because i wanted to obey the roles of adding new module in Kamailio. I obey these roles in other files, like lreproxy_funcs.h. Is it right?
Short note to say that probably branching of 5.4 will happen soon, if you want this merged for 5.4.x release series, then it has to be made ready during the next days.
For the code you wrote, then you put your copyright. For the code you took from other places, you need to copy over the copyright.
Anyone else to review this PR?
@miconda I had a conversation with the author of the pull request, he wants to rework the code substancially. I don't think this should be merged in this form.
Yes, As @henningw is mentioned, some rework substancially is doing right now, I don't think it's over for this branching.
Considering the existing modules related to RTP ``` rtp_media_server.html rtpengine.html rtpproxy.html ``` I would recommend adding RTP at the beginning of the name, to make sure anyone can immediately assume this is about RTP forwarding/relaying/proxying
rtp_lr or rtp_light or `rtp_lw_relay` lightweight based on your previous name and presentation
Few questions out of curiosity ...
Did you benchmark RTPengine with the kernel module or without ?
I have the impression that this solution is using libnetfilter, queue, etc ?
Doe it mean that everything is self contain or the code to manage libnetfiler is somewhere else ?
@jchavanton Thanks for asking some important question, Q1: Yes, Because RTPengine use local hooking in network stack while this module works in prerouting hooking in network stack. Q2: We have completely different designed hash search index based of SDP parameter in session. It no have relation to libnetfilter, Connection tracking or etc. Q3: It composed of two different layer as i mentioned before. LREProxy engine is developed with Python Service, Kernel part and Unix sokect section. Also we are planing to implement the python section with C again, but later:)
About Q1, I am not sure how to interpret your answer, RTP engine is using IPtables with the kernel module, but you need to build it properly and load it, did you do it explicitly ?
The step to load it : ``` # RUN echo ">>>> building IP iptables-extension" \ # && cd /git/rtpengine/iptables-extension \ # && cp libxt_RTPENGINE.so $(pkg-config xtables --variable=xtlibdir)
# RUN echo ">>>> building Kernel module" \ # && cd /git/rtpengine/kernel-module \ # && make && cp xt_RTPENGINE.ko /lib/modules/$(uname -r)/updates \ # && depmod -a
```
About Q3, can you add a link to the source code how can anyone use it ?
Sure, We have to develop a kernel module for lreproxy for forwarding RTP packets based on SDP properties. The LREProxy engine will share in git site
Hi Motjaba, I found your answers very confusing, here is what I understand/deduct.
1- We can not conclude that lreproxy is faster than rtpengine since rtpengine was not tested with its kernel module.
2- No one can use the lreproxy module since there python/C code required is not developed yet.
In would recommend to close the PR and consider opening later when this module will become usable by kamailio users.
If you want to conclude that this media proxy is faster than RTPengine, I would also recommend that you run the tests again making sure that RTPengine is using its Kernel module.
The lreproxy engine with Python had done before and everyone could use the lreproxy after i push the service in github. In regard of comparison with rtpengine, i suggest check it in practical scenario. While the lreproxy could also works with multiple rtpengine services in cloud sulotions. Just let me share it after preparing README file.
Also i could have online demo in realtime scenario to show it's performance. Actually we used offloading technique in lreproxy. Our resaults are published in our paper. :))
The Lreproxy service is published in my git, The insulation help is in Readme file. It might be confusing,
@mojtabaesfandiari pushed 1 commit.
c5efad09dd821e1a3f3c2c037a6461c7060775bc lreproxy
the lreproxy module is updated.
@mojtabaesfandiari pushed 1 commit.
beda3fef42dfbbe96d76cf62e6b1a9f56bc957af lreproxy
https://ieeexplore.ieee.org/document/9303608
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.
@miconda Thanks for your suggestion about its name. I agree with you. The name could be change LRKProxy or something else. I dont want to say this module has more performant than rtpengine or compare with other media engine. But just as you mentioned, the rtpengine does already kernel/iptables-based forwarding. It means it works in LOCAL INPUT in Netfilter Linux networking stack to perform packet handling while this module works in PREROUTING in Netfilter before the routing decision. "All the packets, with no exceptions, hit this hook, which is reached before the routing decision and after all the IP header sanity checks are fulfilled.
@mojtabaesfandiari did you end-up sharing your code, opensource it ?
@jchavanton Sure, feel free for using it right now. It could be used right now, But because this module is new, it might be updated,
For example, some upcoming updates are: Multiple NIC relaying. Video supporting. Some quite bit changes for relaying RTP to unix socket. :)
@mojtabaesfandiari is this the source code of the kernel module you mentioned (which I think was part of Q3 in this thread)? https://github.com/mojtabaesfandiari/py-lreproxy/tree/main/lib/c
yes.
@mojtabaesfandiari
Just made a few tests, documentation is good, well done.
However I got a crash quickly, probably due to miss config, but crash in the kernel module makes it much more problematic.
``` Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195416] RIP: 0010:main_hook_post+0x70/0xb0 [lreproxy_module] Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195422] Code: c1 e5 02 41 83 e5 3c 4d 01 e5 74 e0 41 0f b7 45 02 49 89 f6 69 c0 47 86 c8 61 c1 e8 16 48 8b 1c c5 c0 b3 0c c1 48 85 db 74 c2 <8b> 43 1c 4c 89 e2 4c 89 ee 4c 89 f7 41 89 44 24 0c 0f b7 43 24 66 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195426] RSP: 0018:ffffc39844dd7ad8 EFLAGS: 00010286 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195431] RAX: 000000000000fd02 RBX: c9ec991dd1f95aa5 RCX: 0000000000000000 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195434] RDX: 00000000d43c0000 RSI: 0000000000000000 RDI: ffff9fa6df1948d8 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195437] RBP: ffffc39844dd7af8 R08: ffff9fa6df1948d8 R09: 0000000000000006 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195440] R10: 0000000000001550 R11: 0000000000000010 R12: ffff9fa6df194810 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195443] R13: ffff9fa6df194824 R14: ffff9fa5dd67f100 R15: 00000000000000b4 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195448] FS: 00007f3dda056700(0000) GS:ffff9fa6fc440000(0000) knlGS:0000000000000000 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195452] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195456] CR2: 000000000293af68 CR3: 000000050d1c0006 CR4: 00000000003606e0 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195462] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195465] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195467] Call Trace: Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195478] nf_hook_slow+0x48/0xc0 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195485] ip_output+0xcf/0xe0 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195492] ? __ip_finish_output+0x1d0/0x1d0 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195498] ip_local_out+0x3b/0x50 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195503] ip_send_skb+0x19/0x40 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195509] udp_send_skb.isra.48+0x156/0x370 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195515] udp_sendmsg+0x6c3/0xd10 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195521] ? ip_do_fragment+0x530/0x530 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195530] ? __switch_to_asm+0x34/0x70 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195535] ? __switch_to_asm+0x40/0x70 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195540] ? __switch_to_asm+0x34/0x70 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195546] ? _cond_resched+0x19/0x40 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195555] ? aa_sk_perm+0x43/0x190 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195559] ? __switch_to_asm+0x34/0x70 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195565] inet_sendmsg+0x5d/0x70 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195569] ? inet_sendmsg+0x5d/0x70 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195577] sock_sendmsg+0x5c/0x70 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195582] __sys_sendto+0x13f/0x180 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195590] ? hrtimer_nanosleep+0xc0/0x150 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195596] ? hrtimer_init_sleeper+0x90/0x90 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195601] __x64_sys_sendto+0x28/0x30 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195608] do_syscall_64+0x57/0x190 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195614] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195618] RIP: 0033:0x7f3de55b9a82 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195623] Code: 48 83 ec 18 44 89 4c 24 08 e8 aa f5 ff ff 44 8b 4c 24 08 89 c5 4d 89 f8 45 89 f2 4c 89 ea 4c 89 e6 89 df b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 3a 89 ef 48 89 44 24 08 e8 da f5 ff ff 48 8b Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195628] RSP: 002b:00007f3dda055b10 EFLAGS: 00000293 ORIG_RAX: 000000000000002c Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195636] RAX: ffffffffffffffda RBX: 000000000000000a RCX: 00007f3de55b9a82 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195639] RDX: 00000000000000ac RSI: 00007f3dd0018bc8 RDI: 000000000000000a Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195641] RBP: 0000000000000000 R08: 00007f3dd0017c2c R09: 0000000000000010 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195644] R10: 0000000000000000 R11: 0000000000000293 R12: 00007f3dd0018bc8 Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195647] R13: 00000000000000ac R14: 0000000000000000 R15: 00007f3dd0017c2c Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195652] Modules linked in: lreproxy_module(OE) xt_nat xt_tcpudp veth xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo xt_addrtype iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bpfilter br_netfilter bridge stp llc nfnetlink_queue nfnetlink_log nfnetlink rfcomm ccm cmac aufs overlay bnep nls_iso8859_1 mei_hdcp intel_rapl_msr snd_sof_pci snd_sof_intel_hda_common snd_soc_hdac_hda snd_hda_codec_hdmi snd_sof_intel_hda snd_sof_intel_byt snd_sof_intel_ipc snd_sof snd_sof_xtensa_dsp snd_hda_ext_core snd_soc_acpi_intel_match x86_pkg_temp_thermal snd_soc_acpi intel_powerclamp snd_soc_core snd_hda_codec_realtek snd_hda_codec_generic snd_compress coretemp ac97_bus snd_pcm_dmaengine kvm_intel uvcvideo kvm iwlmvm snd_hda_intel input_leds snd_intel_dspcfg videobuf2_vmalloc joydev snd_hda_codec videobuf2_memops rapl videobuf2_v4l2 intel_cstate mac80211 serio_raw snd_hda_core videobuf2_common wmi_bmof libarc4 intel_wmi_thunderbolt snd_hwdep Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195710] thinkpad_acpi btusb videodev btrtl nvram btbcm btintel ledtrig_audio snd_seq_midi snd_pcm mc iwlwifi bluetooth snd_seq_midi_event ecdh_generic ecc snd_rawmidi cfg80211 mei_me intel_lpss_pci mei intel_lpss snd_seq idma64 virt_dma snd_seq_device snd_timer ucsi_acpi processor_thermal_device typec_ucsi intel_rapl_common intel_soc_dts_iosf typec intel_pch_thermal snd soundcore int3403_thermal int340x_thermal_zone int3400_thermal acpi_thermal_rel mac_hid acpi_pad sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 algif_skcipher af_alg dm_crypt hid_generic usbhid hid nouveau crct10dif_pclmul crc32_pclmul mxm_wmi ghash_clmulni_intel i915 nvme ttm i2c_algo_bit aesni_intel drm_kms_helper crypto_simd syscopyarea cryptd sysfillrect glue_helper psmouse e1000e sysimgblt fb_sys_fops nvme_core drm sdhci_pci thunderbolt cqhci sdhci wmi pinctrl_cannonlake video pinctrl_intel [last unloaded: lreproxy_module] Feb 11 14:09:04 anton-ThinkPad-P43s kernel: [225916.195783] ---[ end trace ff79f804c7960a14 ]--- ```
I was running with the default config ``` sudo python3 pylreproxy.py ``` lreproxy was using a fake IP not present in the system, maybe this was part of the problem generating the crash ...
I got one working test.
``` /etc/py_lre_proxy/py_lre_proxy.ini [DEFAULT] start_port : 20000 end_port : 30000 current_port : 20000 internal_ip : 192.168.0.111 external_ip : 192.168.0.111 ```
I left it running for several hours, no more crash, there seems to be something odd with kamailio responsiveness degrading over time. Could be related to my config, did you ever do long lasting end2end tests ?
One obvious missing feature is hosted NAT traversal/port latching, this will greatly reduce the use cases where it can be use.
Nice work !
@jchavanton - is the module ready to merge in your opinion (docs, code, or what you had time to look over)?
@mojtabaesfandiari - is it ok to rename the module to LRKProxy as you made a remark on a comment above?
@miconda Sure, although, lreproxy can be searched and tracked on internet, but i think LRKProxy is better. What do you think? If yes, i have to change the name of lreproxy in project. let me do it during next days, Also some updates will publish as soon. Thanks @jchavanton I am trying to check what you mentioned, Just let me a few days, I will update you during next days.
As before, I strongly suggest that you remove all references to "RTPengine" as it is another product, not a generic name for an RTP proxy. LRKproxy is better.
Few comments on the module being ready to merge : - I noticed the module interface was outdated it should be tested one more time, `child_init` and `mod_init` may not be working. - The documentation is good however it is made in the README instead of the XML files - Based on my quick tests there was an unexpected performance degradation seen this may not be a real concern if the module is mainly still an alpha POC
@jchavanton,there was a quite bit issue when the lreproxy kernel engine received duplicate ports. You could check it after update. Thanks
@jchavanton, Would you please let me know more details related to first comment that you mentioned? The second comment is accepted and i will do it. Let me know how do you test it?What unexpected performance degradation did you see?
Actually, I am planning for having a workshop of using lreproxy( LRKProxy ) as soon.
@jchavanton, Would you please let me know more details related to first comment that you mentioned? The second comment is accepted and i will do it. Let me know how do you test it? What unexpected performance degradation did you see?
@mojtabaesfandiari Considering that my test report is very limited, we can ignore the comment of signaling degradation, it may have been caused by a miss-config, like the one causing the crash. I was simply curious to know if you did some small sustained load tests. But now that I think about it, it seems obvious you did such tests since you have shared a presentation comparing load tests performance, I am guessing these tests where using the module as well. In this case this seems like a significant load testing effort.
My previous comment : "I left it running for several hours, no more crash, there seems to be something odd with Kamailio responsiveness degrading over time. Could be related to my config, did you ever do long lasting end2end tests ?"
I am also glad that you that may have found an issue related to duplicate ports, not sure I will find more time to test again shortly. I have a very good impression on the work done !
About my other comment on the module interface, it is is still a problem, it should trigger a compilation warning, if you do `make clean && make` in the module folder.
@mojtabaesfandiari pushed 1 commit.
0a8717667a0ccdb5ae1ae9f32077d0d9e053d634 lreproxy
Please adjust your commit messages to follow the project's guidelines for commit messages. Just committing with the module name is not explaining anything.
@mojtabaesfandiari pushed 0 commits.
lreproxy is updated right now.
Please adjust your commit messages to follow the project's guidelines for commit messages. Just committing with the module name is not explaining anything.
I fixed my commit message in last update. Thanks
I am planning to change lreproxy to lrkproxy. any idea in this regard? @miconda, let me know do i have to create new PR after renaming module or some things else?
I think it would be good to create a PR with the new name, so it will be a clean merge of the module. Thanks!
lreprxoy name is changed to lrkproxy
OK, thanks - closing this one then, discussions can continue on the new PR #2657.
Closed #2208.