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 <[email protected]> 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 <[email protected]>: > > 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: > > 1. Implement the functionality in ims_register_pcscf. > > 2. 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 > > [email protected] > > 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:[email protected] > > 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 > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev >
_______________________________________________ Kamailio (SER) - Development Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
