[sr-dev] Re: [kamailio/kamailio] Implementation of the timer_enable() function in Kemi (Issue #4008)
Hello
I tested:
KSR.timer.timer_enable("tmr4", 0) and KSR.timer.timer_enable("tmr4", 1)
It works.
Thanks
Juan
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4008#issuecomment-2445103412
You are receiving this because you are subscribed to this thread.
Message ID: ___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] Re: [kamailio/kamailio] p-charging-vector bug in siputils with force flag (Issue #3929)
Closed #3929 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3929#event-14979146630 You are receiving this because you are subscribed to this thread. Message ID: ___ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] git:master:ad919796: timer: export timer_enable(...) to kemi
Module: kamailio
Branch: master
Commit: ad919796b24d0c38af136cbad2563e6f98df4b74
URL:
https://github.com/kamailio/kamailio/commit/ad919796b24d0c38af136cbad2563e6f98df4b74
Author: Daniel-Constantin Mierla
Committer: Daniel-Constantin Mierla
Date: 2024-10-29T06:52:22+01:00
timer: export timer_enable(...) to kemi
- GH #4008
---
Modified: src/modules/timer/timer.c
---
Diff:
https://github.com/kamailio/kamailio/commit/ad919796b24d0c38af136cbad2563e6f98df4b74.diff
Patch:
https://github.com/kamailio/kamailio/commit/ad919796b24d0c38af136cbad2563e6f98df4b74.patch
---
diff --git a/src/modules/timer/timer.c b/src/modules/timer/timer.c
index 5cb92a8847c..e31ede94903 100644
--- a/src/modules/timer/timer.c
+++ b/src/modules/timer/timer.c
@@ -306,6 +306,19 @@ static int timer_enable_func(sip_msg_t *m, char
*timer_act, char *enable)
return timer_enable_helper(m, a, en);
}
+static int ki_timer_enable(sip_msg_t *m, str *timerid, int enable)
+{
+ timer_action_t *a;
+
+ a = find_action_by_name(timer_actions, timerid->s, -1);
+ if(!a) {
+ LM_ERR("timer '%s' not declared\n", timerid->s);
+ return -1;
+ }
+
+ return timer_enable_helper(m, a, enable);
+}
+
static int get_next_part(char **s, str *part, char delim)
{
char *c, *c2;
@@ -522,3 +535,27 @@ struct module_exports exports = {
destroy_mod /* destroy function */
};
/* clang-format on */
+
+
+/**
+ *
+ */
+/* clang-format off */
+static sr_kemi_t sr_kemi_timer_exports[] = {
+ { str_init("timer"), str_init("timer_enable"),
+ SR_KEMIP_INT, ki_timer_enable,
+ { SR_KEMIP_STR, SR_KEMIP_INT, SR_KEMIP_NONE,
+ SR_KEMIP_NONE, SR_KEMIP_NONE, SR_KEMIP_NONE }
+ },
+ { {0, 0}, {0, 0}, 0, NULL, { 0, 0, 0, 0, 0, 0 } }
+};
+/* clang-format on */
+
+/**
+ *
+ */
+int mod_register(char *path, int *dlflags, void *p1, void *p2)
+{
+ sr_kemi_modules_add(sr_kemi_timer_exports);
+ return 0;
+}
___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] git:master:79d7fae0: core: parser sdp - check body end for extract_ice_option()
Module: kamailio
Branch: master
Commit: 79d7fae0f26f577356f017cfff5e00c348cf259c
URL:
https://github.com/kamailio/kamailio/commit/79d7fae0f26f577356f017cfff5e00c348cf259c
Author: Daniel-Constantin Mierla
Committer: Daniel-Constantin Mierla
Date: 2024-10-29T08:20:44+01:00
core: parser sdp - check body end for extract_ice_option()
---
Modified: src/core/parser/sdp/sdp_helpr_funcs.c
---
Diff:
https://github.com/kamailio/kamailio/commit/79d7fae0f26f577356f017cfff5e00c348cf259c.diff
Patch:
https://github.com/kamailio/kamailio/commit/79d7fae0f26f577356f017cfff5e00c348cf259c.patch
---
diff --git a/src/core/parser/sdp/sdp_helpr_funcs.c
b/src/core/parser/sdp/sdp_helpr_funcs.c
index 0e61fe5ca5d..5c7076823c4 100644
--- a/src/core/parser/sdp/sdp_helpr_funcs.c
+++ b/src/core/parser/sdp/sdp_helpr_funcs.c
@@ -379,22 +379,24 @@ int extract_ice_option(str *body, sdp_stream_cell_t
*stream)
sdp_ice_opt_t *ice_opt;
char *ptr_src;
+ char *end;
int max_options =
10; /* protection - max options can be
listed in one line */
int length = 0; /* each option length */
/* a=ice-options: */
- if((body->len < 14) || (strncasecmp(body->s, ICE_OPTIONS, 14) != 0))
+ if((body->len <= 14) || (strncasecmp(body->s, ICE_OPTIONS, 14) != 0))
return -1;
+ end = body->s + body->len;
ptr_src = body->s + 14;
if(*ptr_src == 32)
ptr_src++; /* if starts with a space, skip it */
/* identify all existing ICE options, if they are listed in one row */
- while(*ptr_src && *ptr_src != '\r' && *ptr_src != '\n'
+ while(ptr_src < end && *ptr_src && *ptr_src != '\r' && *ptr_src != '\n'
&& max_options-- > 0) {
- while(*ptr_src != 32 && *ptr_src && *ptr_src != '\r'
+ while(ptr_src < end && *ptr_src && *ptr_src != 32 && *ptr_src
!= '\r'
&& *ptr_src != '\n') {
length++;
ptr_src++;
___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] Re: [kamailio/kamailio] Implementation of the timer_enable() function in Kemi (Issue #4008)
Pushed a commit to export the function to the kemi. Testing and reporting the result would be appreciated. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4008#issuecomment-2443663014 You are receiving this because you are subscribed to this thread. Message ID: ___ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] Re: [kamailio/kamailio] Implementation of the timer_enable() function in Kemi (Issue #4008)
Closed #4008 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4008#event-14980478793 You are receiving this because you are subscribed to this thread. Message ID: ___ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] Re: topos module with storage "shm"
Hi Stefan,
Thanks for the follow up on this topic. On the first thought, I am not 100%
sure if integrating the htable module into another module is the best way to go
forward.
Don’t you think a direct integration of a shared memory cache (e.g. like usrloc
module, dialog module etc..) would be more efficient and easier to use? You
will also loose direct feedback about errors or delay for DMQ synchronisation
if you channel it over another module. I think it would be also good to have an
own “message topic” for the DMQ synchronisation that the traffic can be clearly
attributed to the topos module and not have it integrated into the htable DMQ
traffic.
I understand the motivation of not writing everything from the scratch. Not
sure how feasible this is, but perhaps it’s possible to create a generic memory
cache layer that can be used from modules and not using the htable module which
exports functionality for the configuration script.
Maybe other people that worked recently with these specific modules can share
their opinion as well.
Cheers,
Henning
From: Stefan Mititelu via sr-dev
Sent: Montag, 28. Oktober 2024 18:53
To: Kamailio (SER) - Development Mailing List
Cc: Stefan Mititelu
Subject: [sr-dev] Re: topos module with storage "shm"
I am going to look into the following dev idea:
1. from htable module try export a bind() API functions (e.g. similar to
usrloc) and check that basic htable module ops can be done from another module
2. next, create a topos_htable module that will work with those htable module
API functions
3. last, add new storage("htable") to topos module
This way, topos can use all features of htable module (e.g. standalone SHM
storage and DMQ sync if/when needed)
Thanks,
Stefan
On Tue, Oct 22, 2024 at 10:07 AM Henning Westerholt
mailto:h...@gilawa.com>> wrote:
Hi Stefan,
thanks for the reply. DMQ is usually fast, but it can have data loss or data
synchronization issues if you are using in concurrent access scenarios.
Regarding using the shared memory as a cache, this is of course frequently used
in usrloc module or others. It would certainly help for short unavailability of
the database. It also should improve the performance if combined with a
timer-based write-back mode, like in usrloc.
Cheers,
Henning
From: Stefan Mititelu
mailto:stefan.mitit...@net2phone.com>>
Sent: Monday, October 21, 2024 5:05 PM
To: Henning Westerholt mailto:h...@gilawa.com>>
Cc: Kamailio (SER) - Development Mailing List
mailto:sr-dev@lists.kamailio.org>>
Subject: Re: [sr-dev] topos module with storage "shm"
So far I've been thinking of this topos SHM htable stuff as a replacement for
existing storages (redis/mysql).
Now, I am thinking of this topos SHM htable as a cache between kama procs and
existing storages. So this should happen:
1. on store, always keep in shm htable and write in storage db
2. on load, check shm htable first, and if not found, load from storage db in
shm htable
Should be an improvement to existing active-active setups, when redis db
becomes unavailable.
Of course, DMQ sync of this topos SHM htable can be done, in best effort way.
Can happen that db storage is unavailable and DMQ sync is too slow at the same
time => topos will still fail.
Thanks,
Stefan
On Mon, Oct 21, 2024 at 4:28 PM Stefan Mititelu
mailto:stefan.mitit...@net2phone.com>> wrote:
Hi,
Thanks for the feedback for this.
My motivation is related to an active-active scenario and supposing that redis
db becomes unavailable => topology info will then become unavailable. Now that
I am double thinking about DMQ sync, I think you are right. If DMQ does not
sync fast enough, there will be no topology info available too...
Looking in existing code, and doing some tests with redis, I see topos does 2
types of redis store:
1. for dialog "d:..."
2. for each transaction "b:..."
I. Suppose a BYE comes to a kamailio => topos needs to have the nr 1. already
synced or will send back "404 Not here" and not forward the BYE
II. Suppose a 200OK for that BYE comes to a diiferent kamailio => topos needs
to have the nr 2. already synced or will have bad Via header and log error
Thank you,
Stefan
On Mon, Oct 21, 2024 at 10:02 AM Henning Westerholt
mailto:h...@gilawa.com>> wrote:
Hi Stefan,
certainly, a new storage mode “shared memory” could be added, to avoid any
additional dependencies for topos. This sounds useful.
I personally don’t see a large case for adding also DMQ synchronisation
capabilities for it. The DMQ synchronisation is not 100% reliable in all corner
cases, there are no locks or other synchronization mechanism implemented. As a
loss of topology related information would cause immediate issues for message
processing, it might be not the best choice especially as there is already
redis as a distributed in memory storage available.
But maybe I just misunderstood the motivation for the DMQ synchronization for
topos information. If its e.g. more about an active/passive fail-over
[sr-dev] Re: [kamailio/kamailio] core: local TCP socket is bound on listening address (PR #3925)
This PR is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3925#issuecomment-2445730566 You are receiving this because you are subscribed to this thread. Message ID: ___ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
