[sr-dev] Contributing platform specific code to Kamailio

Tsvetomir Dimitrov tsv.dimitrov at gmail.com
Thu Oct 19 09:49:22 CEST 2017


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 at 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 at 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:
> > 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
> > sr-dev at 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 at 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 at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20171019/43f4d4b9/attachment.html>


More information about the sr-dev mailing list