[sr-dev] Re: topos module with storage "shm"
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 setup, data-consistency issues are of course not a big issue. Cheers, Henning From: Stefan Mititelu via sr-dev Sent: Friday, October 18, 2024 10:45 AM To: sr-dev@lists.kamailio.org Cc: Stefan Mititelu Subject: [sr-dev] topos module with storage "shm" Hi, I am thinking of this idea to add shm storage for topos module. Main motivation for this is that if db backend is not available, there will be no store/load happening. Did anyone else thought of this or is doing something similar already? I see 2 milestones here: 1. Add code in topos to keep a shm hash table with all the information needed, guarded via locks. The api functions should be very similar to what tps_storage.c has, just it will do ops directly in memory not on db. 2. Find a way to synchronize this topos hash table among multiple kamailios. This should be similar to how htable module syncronize via DMQ. Sync may happen either for each new cell, for batches or for entire topos hash table. What do you think of this? Any opinions, comments, appreciated. Thank you, Stefan Mititelu ___ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] [kamailio/kamailio] [JWT Module] Failed to decode JWT value (Issue #4003)
### Description
Tried to verify a dubious JWT, but I get a token decoding error. I tried
different variations of the key, such as `.pem`, `.key` extensions, `PKCS1`,
`PKCS8` formats, reading the key from a variable or file.
### Troubleshooting
Reproduction
Have the following Kamailio config:
```
loadmodule "jwt.so"
...
modparam("jwt", "key_mode", 0)
$var(authorization_header_value) =
"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiIyIiwianRpIjoiYmQ1NzlhZTYyZjg2ODE5N2I5OTk1YTFkOWM4NGZkOGFiNWIyYWI4Nzk5YzM0OWVmYjBkNjg1NWFiNDcwYWUzOTYyMzFmYzc5NjIxZDQxODciLCJpYXQiOjE3MjkxODU3MTguNjQxMjI1LCJuYmYiOjE3MjkxODU3MTguNjQxMjI";
$var(jwt_verification) = jwt_verify("/etc/kamailio/oauth_pub.pem", "RS256",
"sub='$fU'",
"$var(authorization_header_value)"
);
...
```
oauth_pub.pem:
```
-BEGIN PUBLIC KEY-
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA5mfAgdn7JaiRS2Bsov4S
zTlGLSe2wxbdUxIreTcqs88PmWOBtuSeQg5tU3CRnPtsuuRJrlUniV5g56YAHrnt
Qe8meu877iTrcJB6Cii3n+d7SgwCfjMvaFBR+mdGsidAyGBpRhoPrH7SD6CRpBLr
Mxylcgqw4uH/0HdF+B8P5motUQz/tul/UKsq1nvC2AOOzFel1IsUah8dQuxzMx+P
RYcsngJam8TkGr6QidTXc2rD4lEoCD1s/huGUq55bc19J3yRliN2j8cO9j1bGTsp
GYEVtA3PiH/73BZTa3FHbhRYqhvjYacC8eWBFhwThC9CgPyOXrq4L7p9tJAlNwmd
dQHhIzZ9vugQuhfnuUTb0/r2tjpsSPL7etgJdxtZ4Xh9aBEpYn//RAgu5Dkauc2S
XF+uLWwBptFTM3SNppDPMdjRkYakWjVP2pgBGMmrINFb8RQAPEJzD1gVt0fYCxaY
jiazbSc9FPfSbFENHq+r8D7OivpiW0q9+tSZbYmAFzZekoUAoboQThSdRcOy9tFz
196xfg4dOyxkRGGHstz28qBv340ppjnHQd+RZOvbr8s2zEIxGiOpfX8CuLur/nKl
Ld3qtzg0caqDz6nsYK+95rExnbtU+gFcHnwtMdk3R8X6lVHzDeTjO2Nk4Zo023zo
qFH/rRyJBOp98fQPOpx5qncCAwEAAQ==
-END PUBLIC KEY-
```
Debugging Data
Log Messages
```
[jwt_mod.c:501]: ki_jwt_verify_key(): failed to decode jwt value
```
SIP Traffic
### Possible Solutions
I've wrote a C++ program using `libjwt` to make sure the issue is not neither
my key, nor `libjwt`. And they aren't. Here is the program:
```cpp
#include
#include
#include
static const char jwt_test[] =
"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiIyIiwianRpIjoiZDY2NDQ4MTdhYWRhNTQ1MDI1YmUwZmU1M2I1ZmFhYTdkZGI3NTY5NTBiMDYxMzk5MzFmNTQ1ZjhkMmE4N2ZhYjU0ODgzNjJhZGNiMWQ5ZTkiLCJpYXQiOjE3MjkyMjg5NjIuMzg5MDI3LCJuYmYiOjE3MjkyMjg5NjIuMzg5MDMzLCJleHAiOjE3MjkyNzIxNjIuMzc5MTg3LCJzdWIiOiIxNDQ0ODEiLCJzY29wZXMiOltdLCJ1c2VyIjp7ImlkIjoxNDQ0ODEsImFjY291bnRfaWQiOjEyOTMyNn0sIm1veHRyYS10b2tlbiI6Ik1WUXpNekZVTU1hdlFET2hNVlNabEdRZ1ptQUNPRmNGU1JKZEVGNGZTQTFFRWxJLVVCMTRkREZVTVZkbFkxY0xjaHhrWkhrU1pnVjVERUppQ0dKSEJWZGxYQTFMQmwwYUF4MUdHbHdkX0RmbHhORGRNMXMzOXlabjhMMEV5USIsImRldmljZSI6eyJpZCI6ImY4MzI0NDkyLWJiYjQtNGJiNC04ZWQxLWZlMTM1OWQwOTNlNSIsInR5cGUiOiJ3ZWIiLCJ2ZXJzaW9uIjoiMS43LjAifX0.E_6jsC7yxPZgHRry55J0oOBzw25tvlfnWRBqSwLVFeAtavkVrYGmH9BGaByaAhebKNijy2WUg1X8Ug0N9Z9cc3P8u2wDSlvlzTNrxnPqdxMrKtP5wiIbImXboobFqKXLRmbor_9I7r0lBlX-e0xSis-PTaBqH40hDYPj0rR5cqnrszSkEMd2jFdiLL5BoF0pqysvrXA631KKA9oHGzAivib_GOddHeUOAVs7-hMVdnDqgrzZ6lDYkQndutrHpwILZWz09ngJBbRh_mN_cE4dDxghgeSotXADT-h5DlokV8ChkgkmHh6m4gU2lvnb7aY9dbCp9R44T1Rpz1P_HhPQ27p1Sgin40Oc2abBwDePw_chl0ajJHuhJCiK7YHbcmzcv3dZ-igVMYpMqhGIlyyuAHCSrKFVFLhodA1xlyCmMqJfFPOZ6DdKzbAQDWPN2xsCMy7WkGT5KmBQR5wWJRIRbTj4OUWo6iUrQdNyjB0F1RKqkuZlz414Hj0tkS5GlS1rfxOtS4yc2m_ERGomSmpDgoq2zpA5o3oJJWXqA7TzT8X_9Up5DkVQCMGW6Z2OT9Sr8hNjIXB1qgYiiZtNf9_b4bma5JEwVvR2-qcZ92V6owFTYx78smdyOgAaMlBQ_9AM6kARz4ZnC3Mz2feJT2qKLP-z9senqIB8k_xNx2lbU2w";
static unsigned char key[16384];
static size_t key_len;
static void read_key(const char *key_file)
{
FILE *fp = fopen(key_file, "r");
int ret = 0;
fp = fopen(key_file, "r");
key_len = fread(key, 1, sizeof(key), fp);
fclose(fp);
key[key_len] = '\0';
}
int main()
{
jwt_t *jwt = NULL;
int ret = 0;
read_key("oauth_pub.pem");
ret = jwt_decode(&jwt, jwt_test, key, key_len);
printf("Decoding exit status: %d\n", ret);
printf("User ID: %s\n", jwt_get_grant(jwt, "sub"));
return 0;
}
```
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.8.2 (x86_64/linux) 3fa5f4
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE,
USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC,
F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES,
TLS_PTHREAD_MUTEX_SHARED
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE
262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 3fa5f4
compiled on 10:39:56 Jun 12 2024 with gcc 8.5.0
```
* **Operating System**:
```
Rocky Linux 8.10 (Green Obsidian)
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4003
You are receiving this because you are subscribed to this thread.
Message ID: ___
Kamailio (SER) - Development Mailing List
To unsu
[sr-dev] Re: [kamailio/kamailio] Fixed segfault when using kazoo_query in kazoo mod (PR #4002)
@linuxmaniac Thanks, fixed the commit message -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4002#issuecomment-2425976247 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] rtpengine module: Question about re-enabling nodes
Hi,
we had strange behavior with kamailio when some rtpengines were
unreachable, so we looked into the the source code and found this in
select_rtpp_node_new():
3323 /* Try to enable if it's time to try. */
3324 if(node->rn_disabled && node->rn_recheck_ticks <= get_ticks()) {
3325node->rn_disabled = rtpp_test(node, 1, 0);
3326 }
Does this mean that a ping will be done during rtpengine manage?
Is this wise? I mean there are dedicated pings in the background. Doing
this in rtpengine manage will only periodically delay the processing of
a SIP message. We fear that in high traffic situations this could occupy
all threads. Is this a bug?
As a workaround we think setting rtpengine_tout_ms to a lower value
might help as it shortens the amount of time the module delays the
processing of the SIP message.
What do you think?
Best wishes
Christian Berger
--
Christian Berger - ber...@sipgate.de
Telefon: +49 (0)211-63 55 55-0
Telefax: +49 (0)211-63 55 55-22
sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf
HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois
Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391
www.sipgate.de - www.sipgate.co.uk
___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] Re: rtpengine module: Question about re-enabling nodes
Hi,
Yes this is how currently rtpengine module re-detect rtpengines: during
SIP routing processing. (e.g. rtpengine_manage())
Yes, lowering "rtpengine_tout_ms" will make rtpp_test() C code function
take shorter time => rtpengine_manage() will take shorter time.
Also disabling "aggressive_redetection" modparam helps alot in case when
no rtpengines available at all. Thus, redetection of unavailable
rtpengine nodes is tried only when their time comes, based on
"rtpengine_disable_tout" modparam. Right now, if no rtpengines available
at all, and aggressive redetection is enabled(by default), redetection
happens for each new SIP message, independent of
"rtpengine_disable_tout" modparam. So delays SIP routing alot. (PR:
https://github.com/kamailio/kamailio/pull/3992)
This way of detecting rtpengine has, of course, both pros and cons.
I've been thinking of adding another behavior of this node re-detection
in code, guarded via new modparam: expose an rtpengine_ping() config
function and call it from rtimer. And rtpengine_manage() function will
just check if any nodes available, but not ping them anymore. => not
sure how much time have for it though.
Thanks,
Stefan
On 10/21/24 11:16, Christian Berger via sr-dev wrote:
Hi,
we had strange behavior with kamailio when some rtpengines were
unreachable, so we looked into the the source code and found this in
select_rtpp_node_new():
3323 /* Try to enable if it's time to try. */
3324 if(node->rn_disabled && node->rn_recheck_ticks <= get_ticks()) {
3325 node->rn_disabled = rtpp_test(node, 1, 0);
3326 }
Does this mean that a ping will be done during rtpengine manage?
Is this wise? I mean there are dedicated pings in the background.
Doing this in rtpengine manage will only periodically delay the
processing of a SIP message. We fear that in high traffic situations
this could occupy all threads. Is this a bug?
As a workaround we think setting rtpengine_tout_ms to a lower value
might help as it shortens the amount of time the module delays the
processing of the SIP message.
What do you think?
Best wishes
Christian Berger
___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] Re: [kamailio/kamailio] Fixed segfault when using kazoo_query in kazoo mod (PR #4002)
@remcovanvugt pushed 1 commit. 3c8126974f03c9a297e10e5db5d9b5fcbfd797aa kazoo: fixed segfault when using kazoo_query -- View it on GitHub: https://github.com/kamailio/kamailio/pull/4002/files/38c8cc862d5cd4b441d7ab8de55fd339b41cd1c1..3c8126974f03c9a297e10e5db5d9b5fcbfd797aa 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] Fixed segfault when using kazoo_query in kazoo mod (PR #4002)
@remcovanvugt commented on this pull request.
> @@ -846,17 +846,17 @@ void kz_amqp_channel_close(kz_amqp_conn_ptr rmq,
> amqp_channel_t channel)
kz_amqp_error("closing channel",
amqp_channel_close(rmq->conn, channel,
AMQP_REPLY_SUCCESS));
}
-#if AMQP_VERSION_MAJOR == 0 && AMQP_VERSION_MINOR < 13
@linuxmaniac This was not supposed to be removed, fixed that
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4002#discussion_r1808390500
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] Fixed segfault when using kazoo_query in kazoo mod (PR #4002)
@linuxmaniac commented on this pull request.
> @@ -846,17 +846,17 @@ void kz_amqp_channel_close(kz_amqp_conn_ptr rmq,
> amqp_channel_t channel)
kz_amqp_error("closing channel",
amqp_channel_close(rmq->conn, channel,
AMQP_REPLY_SUCCESS));
}
-#if AMQP_VERSION_MAJOR == 0 && AMQP_VERSION_MINOR < 13
not, really. The code is different. Please, put it back as it was.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4002#discussion_r1808393748
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] Fixed segfault when using kazoo_query in kazoo mod (PR #4002)
@remcovanvugt commented on this pull request.
> @@ -846,17 +846,17 @@ void kz_amqp_channel_close(kz_amqp_conn_ptr rmq,
> amqp_channel_t channel)
kz_amqp_error("closing channel",
amqp_channel_close(rmq->conn, channel,
AMQP_REPLY_SUCCESS));
}
-#if AMQP_VERSION_MAJOR == 0 && AMQP_VERSION_MINOR < 13
Sorry about the extra work, I overlooked the commit between 5.8.2 and master.
That's why this got accidentally removed. It should be as it was now.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4002#discussion_r1808421205
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] Fixed segfault when using kazoo_query in kazoo mod (PR #4002)
> you need to format the code with clang-format and amend Done -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4002#issuecomment-2426078366 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] Fixed segfault when using kazoo_query in kazoo mod (PR #4002)
@linuxmaniac commented on this pull request. > @@ -888,8 +888,8 @@ int kz_amqp_connection_open_ssl(kz_amqp_conn_ptr rmq) amqp_ssl_socket_set_verify( rmq->socket, kz_amqps_verify_peer | kz_amqps_verify_hostname); #else - amqp_ssl_socket_set_verify_peer(rmq->socket, kz_amqps_verify_peer); not really. Still changes here. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4002#pullrequestreview-2381466112 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] Fixed segfault when using kazoo_query in kazoo mod (PR #4002)
@linuxmaniac requested changes on this pull request.
you need to format the code with clang-format and amend
> @@ -846,17 +846,17 @@ void kz_amqp_channel_close(kz_amqp_conn_ptr rmq,
> amqp_channel_t channel)
kz_amqp_error("closing channel",
amqp_channel_close(rmq->conn, channel,
AMQP_REPLY_SUCCESS));
}
-#if AMQP_VERSION_MAJOR == 0 && AMQP_VERSION_MINOR < 13
why are you removing this part?
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4002#pullrequestreview-2381363036
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] Fixed segfault when using kazoo_query in kazoo mod (PR #4002)
@remcovanvugt pushed 1 commit. f8a1d2e86b2fe59c8d02a239dc7b893a4b92ee85 kazoo: fixed segfault when using kazoo_query -- View it on GitHub: https://github.com/kamailio/kamailio/pull/4002/files/61fcd7d73a8fd2ed68435f81f18dad9c5a941928..f8a1d2e86b2fe59c8d02a239dc7b893a4b92ee85 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] Fixed segfault when using kazoo_query in kazoo mod (PR #4002)
@remcovanvugt commented on this pull request. > @@ -888,8 +888,8 @@ int kz_amqp_connection_open_ssl(kz_amqp_conn_ptr rmq) amqp_ssl_socket_set_verify( rmq->socket, kz_amqps_verify_peer | kz_amqps_verify_hostname); #else - amqp_ssl_socket_set_verify_peer(rmq->socket, kz_amqps_verify_peer); Formatted that back to what it was -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4002#discussion_r1808436621 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] Fixed segfault when using kazoo_query in kazoo mod (PR #4002)
@remcovanvugt pushed 1 commit. 61fcd7d73a8fd2ed68435f81f18dad9c5a941928 kazoo: fixed segfault when using kazoo_query -- View it on GitHub: https://github.com/kamailio/kamailio/pull/4002/files/940293a8e53868aca618075bfa5c32baef948fa8..61fcd7d73a8fd2ed68435f81f18dad9c5a941928 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] Fixed segfault when using kazoo_query in kazoo mod (PR #4002)
@linuxmaniac approved this pull request. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4002#pullrequestreview-2381582991 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:b1aae565: rtpengine: disable aggressive redetection by default (#3992)
Module: kamailio
Branch: master
Commit: b1aae5658e84453ce5849a627832efbbb6c20117
URL:
https://github.com/kamailio/kamailio/commit/b1aae5658e84453ce5849a627832efbbb6c20117
Author: Stefan Mititelu
Committer: GitHub
Date: 2024-10-21T08:53:39-04:00
rtpengine: disable aggressive redetection by default (#3992)
---
Modified: src/modules/rtpengine/config.c
Modified: src/modules/rtpengine/doc/rtpengine_admin.xml
---
Diff:
https://github.com/kamailio/kamailio/commit/b1aae5658e84453ce5849a627832efbbb6c20117.diff
Patch:
https://github.com/kamailio/kamailio/commit/b1aae5658e84453ce5849a627832efbbb6c20117.patch
---
diff --git a/src/modules/rtpengine/config.c b/src/modules/rtpengine/config.c
index 7ea1a0d68e9..ba2bd5c5747 100644
--- a/src/modules/rtpengine/config.c
+++ b/src/modules/rtpengine/config.c
@@ -32,7 +32,7 @@
struct cfg_group_rtpengine default_rtpengine_cfg = {
60, /* default
disable timeout in seconds */
- 1, /* default
aggressive_redetection enabled */
+ 0, /* default
aggressive_redetection disabled */
1000,/* default wait
timeout in milliseconds */
MAX_RTPP_TRIED_NODES, 5, /* rtprengine retries */
};
diff --git a/src/modules/rtpengine/doc/rtpengine_admin.xml
b/src/modules/rtpengine/doc/rtpengine_admin.xml
index f898aa32979..b443fbc0290 100644
--- a/src/modules/rtpengine/doc/rtpengine_admin.xml
+++ b/src/modules/rtpengine/doc/rtpengine_admin.xml
@@ -219,20 +219,20 @@ modparam("rtpengine", "rtpengine_disable_tout", 20)
- Default value is 1 (enabled).
+ Default value is 0 (disabled).
Can be set at runtime, e.g.:
- $ &sercmd; cfg.set_now_int rtpengine
aggressive_redetection 0
+ $ &sercmd; cfg.set_now_int rtpengine
aggressive_redetection 1
Set aggressive_redetection
parameter
...
-modparam("rtpengine", "aggressive_redetection", 0)
+modparam("rtpengine", "aggressive_redetection", 1)
...
___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] Re: [kamailio/kamailio] rtpengine: disable aggressive redetection by default (PR #3992)
Merged #3992 into master. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3992#event-14764287142 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] rtpengine: disable aggressive redetection by default (PR #3992)
> I will double check that part of the code, since I don't think a lock get is > necessary. It only updates a value inside a node, inside the list of nodes, > but not changes the list links at all. (this in another PR) I think you're right. However, you would need a memory fence to safely access the values in shared memory without a lock. Also, without the lock, you might get multiple processes doing the health check at the same time, but that's not a big deal. If you want to be fancy, you could make it so that other processes skip the instance while some process is doing busy the health check, and only use it (or continue skipping it) after the health check is done. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3992#issuecomment-2426580443 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:6b7894d6: modules: readme files regenerated - rtpengine ... [skip ci]
Module: kamailio
Branch: master
Commit: 6b7894d66ca65ca99b5987ddc35a7f28c7a88949
URL:
https://github.com/kamailio/kamailio/commit/6b7894d66ca65ca99b5987ddc35a7f28c7a88949
Author: Kamailio Dev
Committer: Kamailio Dev
Date: 2024-10-21T15:01:11+02:00
modules: readme files regenerated - rtpengine ... [skip ci]
---
Modified: src/modules/rtpengine/README
---
Diff:
https://github.com/kamailio/kamailio/commit/6b7894d66ca65ca99b5987ddc35a7f28c7a88949.diff
Patch:
https://github.com/kamailio/kamailio/commit/6b7894d66ca65ca99b5987ddc35a7f28c7a88949.patch
---
diff --git a/src/modules/rtpengine/README b/src/modules/rtpengine/README
index 6b1d875d77e..4658b7a3f35 100644
--- a/src/modules/rtpengine/README
+++ b/src/modules/rtpengine/README
@@ -674,15 +674,15 @@ modparam("rtpengine", "rtpengine_disable_tout", 20)
to all rtpengines, else no rtpengine will be queried until its
rtpengine_disable_tout timeout passes.
- Default value is ???1??? (enabled).
+ Default value is ???0??? (disabled).
Can be set at runtime, e.g.:
$ kamcmd cfg.set_now_int rtpengine
aggressive_redetectio
-n 0
+n 1
Example 1.3. Set aggressive_redetection parameter
...
-modparam("rtpengine", "aggressive_redetection", 0)
+modparam("rtpengine", "aggressive_redetection", 1)
...
4.4. rtpengine_tout_ms (integer)
___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] Re: [kamailio/kamailio] Fixed segfault when using kazoo_query in kazoo mod (PR #4002)
waiting for comments from @lazedo for a bit -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4002#issuecomment-2426254753 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] Segmentation fault when sending ACK for 487 to duplicate URI using siptrace module (Issue #3970)
This issue 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/issues/3970#issuecomment-2428112757 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, 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 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 > setup, data-consistency issues are of course not a big issue. > > > > Cheers, > > > > Henning > > > > > > *From:* Stefan Mititelu via sr-dev > *Sent:* Friday, October 18, 2024 10:45 AM > *To:* sr-dev@lists.kamailio.org > *Cc:* Stefan Mititelu > *Subject:* [sr-dev] topos module with storage "shm" > > > > Hi, > > I am thinking of this idea to add shm storage for topos module. Main > motivation for this is that if db backend is not available, there will be > no store/load happening. > > Did anyone else thought of this or is doing something similar already? > > I see 2 milestones here: > > 1. Add code in topos to keep a shm hash table with all the information > needed, guarded via locks. The api functions should be very similar to what > tps_storage.c has, just it will do ops directly in memory not on db. > > 2. Find a way to synchronize this topos hash table among multiple > kamailios. This should be similar to how htable module syncronize via DMQ. > Sync may happen either for each new cell, for batches or for entire topos > hash table. > > What do you think of this? Any opinions, comments, appreciated. > > Thank you, > > Stefan Mititelu > ___ 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"
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 < 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 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 >> setup, data-consistency issues are of course not a big issue. >> >> >> >> Cheers, >> >> >> >> Henning >> >> >> >> >> >> *From:* Stefan Mititelu via sr-dev >> *Sent:* Friday, October 18, 2024 10:45 AM >> *To:* sr-dev@lists.kamailio.org >> *Cc:* Stefan Mititelu >> *Subject:* [sr-dev] topos module with storage "shm" >> >> >> >> Hi, >> >> I am thinking of this idea to add shm storage for topos module. Main >> motivation for this is that if db backend is not available, there will be >> no store/load happening. >> >> Did anyone else thought of this or is doing something similar already? >> >> I see 2 milestones here: >> >> 1. Add code in topos to keep a shm hash table with all the information >> needed, guarded via locks. The api functions should be very similar to what >> tps_storage.c has, just it will do ops directly in memory not on db. >> >> 2. Find a way to synchronize this topos hash table among multiple >> kamailios. This should be similar to how htable module syncronize via DMQ. >> Sync may happen either for each new cell, for batches or for entire topos >> hash table. >> >> What do you think of this? Any opinions, comments, appreciated. >> >> Thank you, >> >> Stefan Mititelu >> > ___ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] Re: [kamailio/kamailio] [JWT Module] Failed to decode JWT value (Issue #4003)
What you set in `$var(authorization_header_value)` does not look like a complete JWT, your C example code has a larger value in `jwt_test`. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4003#issuecomment-2428302062 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:0cbb2eb0: jwt: print decode result in error log message
Module: kamailio
Branch: master
Commit: 0cbb2eb035c7d2a29ae707cde94a2c0573e0ffd5
URL:
https://github.com/kamailio/kamailio/commit/0cbb2eb035c7d2a29ae707cde94a2c0573e0ffd5
Author: Daniel-Constantin Mierla
Committer: Daniel-Constantin Mierla
Date: 2024-10-22T07:34:29+02:00
jwt: print decode result in error log message
---
Modified: src/modules/jwt/jwt_mod.c
---
Diff:
https://github.com/kamailio/kamailio/commit/0cbb2eb035c7d2a29ae707cde94a2c0573e0ffd5.diff
Patch:
https://github.com/kamailio/kamailio/commit/0cbb2eb035c7d2a29ae707cde94a2c0573e0ffd5.patch
---
diff --git a/src/modules/jwt/jwt_mod.c b/src/modules/jwt/jwt_mod.c
index 0efb793c47f..af3d42f79c5 100644
--- a/src/modules/jwt/jwt_mod.c
+++ b/src/modules/jwt/jwt_mod.c
@@ -498,7 +498,7 @@ static int ki_jwt_verify_key(
ret = jwt_decode(
&jwt, jwtval->s, (unsigned char *)kdata.s,
(size_t)kdata.len);
if(ret != 0 || jwt == NULL) {
- LM_ERR("failed to decode jwt value\n");
+ LM_ERR("failed to decode jwt value (ret: %d jwt: %p)\n", ret,
jwt);
goto error;
}
if(jwt_validate(jwt, jwt_valid) != 0) {
___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] git:master:c823f413: core: parser sdp - check length for rtpmap extract
Module: kamailio
Branch: master
Commit: c823f41350ab9186a323707e9be32e31922bec17
URL:
https://github.com/kamailio/kamailio/commit/c823f41350ab9186a323707e9be32e31922bec17
Author: Daniel-Constantin Mierla
Committer: Daniel-Constantin Mierla
Date: 2024-10-22T07:41:08+02:00
core: parser sdp - check length for rtpmap extract
---
Modified: src/core/parser/sdp/sdp_helpr_funcs.c
---
Diff:
https://github.com/kamailio/kamailio/commit/c823f41350ab9186a323707e9be32e31922bec17.diff
Patch:
https://github.com/kamailio/kamailio/commit/c823f41350ab9186a323707e9be32e31922bec17.patch
---
diff --git a/src/core/parser/sdp/sdp_helpr_funcs.c
b/src/core/parser/sdp/sdp_helpr_funcs.c
index a74f78abb84..fe5b464e473 100644
--- a/src/core/parser/sdp/sdp_helpr_funcs.c
+++ b/src/core/parser/sdp/sdp_helpr_funcs.c
@@ -151,6 +151,9 @@ int extract_rtpmap(str *body, str *rtpmap_payload, str
*rtpmap_encoding,
char *cp, *cp1;
int len;
+ if(body->len <= 9) {
+ return -1;
+ }
if(strncasecmp(body->s, "a=rtpmap:", 9) != 0) {
/*LM_DBG("We are not pointing to an a=rtpmap: attribute
=>`%.*s'\n",
* body->len, body->s); */
___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
