[sr-dev] [SR-Users] RFC: updates to some core functions

Wed Dec 19 13:31:30 CET 2018

Hi,

given the fact, that we do a lot of "non-sip" related stuff with Kamailio
(we are using Kamailio as a Diameter HSS, Diameter Charging-Server (OCS),
Diameter Routing-Agent (DRA)), I would also vote for number (2):

>     2) remove the function export from the core and export one with the
same
>     name from the corex module

Thanks,
Carsten
--

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/


Am Mi., 19. Dez. 2018 um 12:55 Uhr schrieb YAS0 CANER <
caner_yaso at hotmail.com>:

> TmEXIT , kEXIT and corEXIT is failed 😊
> ------------------------------
> *From:* sr-users <sr-users-bounces at lists.kamailio.org> on behalf of Olle
> E. Johansson <oej at edvina.net>
> *Sent:* Wednesday, December 19, 2018 2:38 PM
> *To:* Daniel-Constantin Mierla
> *Cc:* Kamailio (SER) - Development Mailing List; Kamailio (SER) - Users
> Mailing List
> *Subject:* Re: [SR-Users] [sr-dev] RFC: updates to some core functions
>
>
>
> > On 19 Dec 2018, at 12:26, Daniel-Constantin Mierla <miconda at gmail.com>
> wrote:
> >
> >
> > On 19.12.18 09:47, Olle E. Johansson wrote:
> >>
> >>> On 19 Dec 2018, at 09:41, Daniel-Constantin Mierla <miconda at gmail.com>
> wrote:
> >>>
> >>> corex module was added to hold the functions that otherwise would be
> >>> more or less "in the core", like those that were updated to support
> >>> variables in the parameters, so this is the one to take the place of
> >>> core in regard to exporting functions.
> >>>
> >>> tmx was added because tm module became very big, but also to try to
> >>> separate a bit between transaction management code and some functions
> in
> >>> top of it, in the way that tmx can work only with exported api by tm,
> so
> >>> if one adds a function there doesn't get access to all internals of
> >>> transaction and it is safer not to mess up things there. It is more or
> >>> less like usrloc and registrar, usrloc does internal management of
> >>> location records, registrar is the interface to configuration file (but
> >>> there are other modules on top of usrloc, like pua_usrloc, dmq_usrloc,
> ...).
> >>>
> >>> kex is the one that collected some functions that use to be in kamailio
> >>> (or better said openser at that time) but not in ser during 2005-2008
> >>> and can be a module that be analyzed to see if can be merged into other
> >>> modules. A big chunk of it used to be related to MI commands, but as we
> >>> got rid of MI, might be easier now to split parts of it and relocate.
> >>>
> >> Ok, so removing kex is a good first step for the coming release.
> >>
> >> It’s really hard explaining TMX and TM for new Kamailians.
> >
> > We can add a note at the top of docs for each of these modules to refer
> > to the other.
> >
> > On the other hand, I do not like to have a huge module. It is not
> > suitable for small embedded systems. Also, there are other modules using
> > the tm api, so it is a common approach. The tmx is exporting mostly
> > functions at higher level of transaction interaction, one can build a
> > transaction stateful sip routing without it, only using tm.
> >
> Damn it. My campaign for exit of the x modules just died. Sad story.
>
> Thanks for all the responses!
>
> /O
> > Cheers,
> > Daniel
> >
> >>
> >> /O :-)
> >>
> >>> Cheers,
> >>> Daniel
> >>>
> >>> On 19.12.18 09:25, Olle E. Johansson wrote:
> >>>> Going back one step, are there any reasons to keep tmx, kex and corex
> modules at all?
> >>>>
> >>>> At this point in the project I think many of the functions should be
> merged into
> >>>> the main modules and core.
> >>>>
> >>>> If I remember correctly, they exist because of a multi-brand history
> that is not
> >>>> really the case any more.
> >>>>
> >>>> /O
> >>>> “The campaign to remove Kamailio extensions to Kamailio”
> >>>>
> >>>>
> >>>>> On 19 Dec 2018, at 09:11, Henning Westerholt <hw at kamailio.org>
> wrote:
> >>>>>
> >>>>> Am Mittwoch, 19. Dezember 2018, 09:03:26 CET schrieb Sergey Safarov:
> >>>>>> I prefer second way. Without any duplication.
> >>>>>> For old configs branches 4.4, 5.0, 5.1 is always available.
> >>>>> Hello,
> >>>>>
> >>>>> I would prefer also the second way, for the same reason: less
> duplicated
> >>>>> functions.
> >>>>>
> >>>>> Best regards,
> >>>>>
> >>>>> Henning
> >>>>>
> >>>>>
> >>>>>> ср, 19 дек. 2018 г. в 10:50, Daniel-Constantin Mierla <
> miconda at gmail.com>:
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> it was brought into discussions several times in the past about
> core
> >>>>>>> functions not accepting variables in the parameters. I think it is
> time
> >>>>>>> to update them during the 5.3 release development. For few of
> them, I
> >>>>>>> added in the past some alternative function in the corex module
> (e.g.,
> >>>>>>> force_send_socket() in core and set_send_socket() in corex module).
> >>>>>>>
> >>>>>>> So, I see two options:
> >>>>>>>
> >>>>>>> 1) add a function with similar name in corex module and same
> behaviour
> >>>>>>> like the one from core
> >>>>>>>
> >>>>>>> 2) remove the function export from the core and export one with
> the same
> >>>>>>> name from the corex module
> >>>>>>>
> >>>>>>> First one will ensure that configs using the functions right now
> keep
> >>>>>>> working without any update.
> >>>>>>>
> >>>>>>> The second one will be better in long term from the point of
> >>>>>>> documentation (no duplicated docs), but there might be few cases
> that
> >>>>>>> would require updates in the config -- iirc, there are some
> functions
> >>>>>>> that can get special tokens in the parameters (like
> forward(uri:host,
> >>>>>>> uri:port)), they will get an equivalent with variables, but old
> config
> >>>>>>> will not be compatible.
> >>>>>>>
> >>>>>>> Obviously the reason for this email is to ask the developers and
> users
> >>>>>>> what would be the preferred way from own point of view.
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>> Daniel
> >>>>> --
> >>>>> Henning Westerholt - https://skalatan.de/blog/
> >>>>> Kamailio services - https://skalatan.de/services
> >>>>> Kamailio security assessment - https://skalatan.de/de/assessment
> >>>>>
> >>>>> _______________________________________________
> >>>>> Kamailio (SER) - Development Mailing List
> >>>>> sr-dev at lists.kamailio.org
> >>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
> >>>> _______________________________________________
> >>>> Kamailio (SER) - Development Mailing List
> >>>> sr-dev at lists.kamailio.org
> >>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
> >>> --
> >>> Daniel-Constantin Mierla -- www.asipto.com
> >>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> >>> Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
> >>> Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019,
> in Washington, DC, USA -- www.asipto.com
> >>>
> > --
> > Daniel-Constantin Mierla -- www.asipto.com
> > www.twitter.com/miconda -- www.linkedin.com/in/miconda
> > Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
> > Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019,
> in Washington, DC, USA -- www.asipto.com
> >
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20181219/a61b12eb/attachment-0001.html>