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
I prefer second way. Without any duplication. For old configs branches 4.4, 5.0, 5.1 is always available.
Sergey
ср, 19 дек. 2018 г. в 10:50, Daniel-Constantin Mierla miconda@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:
- add a function with similar name in corex module and same behaviour
like the one from core
- 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
-- 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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@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:
- add a function with similar name in corex module and same behaviour
like the one from core
- 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
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@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@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:
- add a function with similar name in corex module and same behaviour
like the one from core
- 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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Hello,
i agree with Mr. Johansson . Merging main modules and cores help to find right function in documentation.
Thanks
/O “The campaign to remove Kamailio extensions to Kamailio”
________________________________ From: sr-users sr-users-bounces@lists.kamailio.org on behalf of Olle E. Johansson oej@edvina.net Sent: Wednesday, December 19, 2018 11:25 AM To: Kamailio (SER) - Development Mailing List Cc: sr-users@lists.kamailio.org Subject: Re: [SR-Users] [sr-dev] RFC: updates to some core functions
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@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@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:
- add a function with similar name in corex module and same behaviour
like the one from core
- 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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hello,
for those that are not aware of, the functions exported by modules are indexed by name at:
* https://www.kamailio.org/wiki/alphaindexes/devel/modfunctions
That should make it easy to find the functions and their module.
Cheers, Daniel
On 19.12.18 09:33, YAS0 CANER wrote:
Hello,
i agree with Mr. Johansson . Merging main modules and cores help to find right function in documentation.
Thanks
/O “The campaign to remove Kamailio extensions to Kamailio”
*From:* sr-users sr-users-bounces@lists.kamailio.org on behalf of Olle E. Johansson oej@edvina.net *Sent:* Wednesday, December 19, 2018 11:25 AM *To:* Kamailio (SER) - Development Mailing List *Cc:* sr-users@lists.kamailio.org *Subject:* Re: [SR-Users] [sr-dev] RFC: updates to some core functions 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@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
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:
- add a function with similar name in corex module and same behaviour
like the one from core
- 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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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.
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@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@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:
- add a function with similar name in corex module and same behaviour
like the one from core
- 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@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
On 19 Dec 2018, at 09:41, Daniel-Constantin Mierla miconda@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.
/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@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@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:
- add a function with similar name in corex module and same behaviour
like the one from core
- 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@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
-- 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
On 19.12.18 09:47, Olle E. Johansson wrote:
On 19 Dec 2018, at 09:41, Daniel-Constantin Mierla miconda@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.
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@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@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:
- add a function with similar name in corex module and same behaviour
like the one from core
- 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@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
-- 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
On 19 Dec 2018, at 12:26, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 19.12.18 09:47, Olle E. Johansson wrote:
On 19 Dec 2018, at 09:41, Daniel-Constantin Mierla miconda@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@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@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@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
-- 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
On Wed, 19 Dec 2018 at 08:49, Daniel-Constantin Mierla miconda@gmail.com wrote:
- remove the function export from the core and export one with the same
name from the corex module
I vote for the second, I like a clean house :-)
On 12/19/18 3:18 AM, Victor Seva wrote:
On Wed, 19 Dec 2018 at 08:49, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
2) remove the function export from the core and export one with the same name from the corex module
This would be my preference as well.
--fred
-
Daniel-Constantin Mierla -
Fred Posner -
Henning Westerholt -
Olle E. Johansson -
Sergey Safarov -
Victor Seva -
YAS0 CANER