Hi Tsvetomir,
any updates regarding this? I believe otherwise, I would assign ressources from our side for this in February/March next year. However, I would want to avoid double work.
You can share it privately with me, if you don't want to publish it yet.
Thanks, Carsten
2017-10-19 9:49 GMT+02:00 Tsvetomir Dimitrov tsv.dimitrov@gmail.com:
Hi Carsten,
Thanks for your responce and please excuse my late reply too. I'm still working on the changes and will make a pull request as soon as I am ready. It will be a separate module which handles the IPSec tunnel creation/tear down, so that ims_register_pcscf won't be polluted with platform specific functionality. You are right, that new module can be ifdef-ed and replaced with something *BSD specific or whatever OS someone wants to use.
Best regards, Tsvetomir
On Fri, Oct 13, 2017 at 6:21 AM, Carsten Bock carsten@ng-voice.com wrote:
Hi Tsvetomir,
sorry for the late reply. I assume this mail got lost a bit in the days of Astricon. I even asked Daniel about this mail during Astricon, but he hadn't seen it yet. Right now, I'm officially on holiday....
Can you please provide a Pull-Request for the changes?
From my perspective, it is likely fine to have a Linux-Only module, it might not be the first one. If you can encapsulate your extensions with some IFDEF's, so the functionality can be disabled on non-Linux, then that would be fine with me.
It would be great, if Daniel or anyone else from the Management-Group could answer or comment this one as well??
Thanks, Carsten
2017-10-04 10:14 GMT-04:00 Tsvetomir Dimitrov tsv.dimitrov@gmail.com:
Hello,
I am working on a functionality which handles ipsec tunel creation for VoLTE registration and I'd like to contribute it to the project. However the code is heavily Linux specific - uses xfrm framework, so it won't compile on distribution with older kernels and definitely won't compile on *BSD.
How problematic is this? How to handle this implementation so that it gets merged?
Right now I can see two options:
- Implement the functionality in ims_register_pcscf.
- Implement separate ipsec module and handle the tunel creation/tear
down from the configuration.
The first solution is definitely the easiest one for implementation, but after my patch the module won't be as portable as it is now and I'm afraid my patch will be rejected.
The second one separates the platform specific code in separate module and won't affect ims_register_pcscf. However I need data from ims_usrloc_pcscf, which is not accessible from the configuration. Also, writing separate module for a limited IPSEC handling seems like a overkill for me.
What's your opinion?
Best regards, Tsvetomir
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
-- Carsten Bock CEO (Geschäftsführer)
ng-voice GmbH Millerntorplatz 1 20359 Hamburg / Germany
http://www.ng-voice.com mailto:carsten@ng-voice.com
Office +49 40 5247593-40 Fax +49 40 5247593-99
Sitz der Gesellschaft: Hamburg Registergericht: Amtsgericht Hamburg, HRB 120189 Geschäftsführer: Carsten Bock Ust-ID: DE279344284
Hier finden Sie unsere handelsrechtlichen Pflichtangaben: http://www.ng-voice.com/imprint/
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev