Hello!
Is it possible to find out the name of the onreply_route that was set
before?
Something like this:
t_on_reply("MANAGE_REPLY");
...
if ( t_is_set("onreply_route") ) {
get_onreply_route_name();
...
}
--
BR,
Denys Pozniak
I have kamailio behind a TLS termination proxy so the sockets are correctly
deduced to be TCP. However the clients only talk TLS to the proxy and are
confused when the top Via header added by Kamailio is TCP. Is there a way
for Kamailio to forcibly pretend its protocol is TLS? Like
advertised_address but "advertised_protocol" instead.
(With pjsip testing: it has a flag use_tls which ignores TCP from Kamailio
and continues to use the persistent TLS transport to proxy. Linphone fails
because it tries to honor TCP in Via and is unable to establish TCP
transport).
BTW I am using t_relay_to_tcp so Kamailio will return traffic to the proxy
as TCP even though the contact addresses specify transport=TLS.
Hi everybody,
I'm just testing Kamailio 5.4.1 with dialog replication over DMQ. This
seems to work very good. Dialogs are replicated without problems.
When I'm restarting one node I would have expected, that all dialogs are
synced again, just like in dmq_usrloc.
But this does not happen. After a restart the nodes dialog-list is empty.
Did I miss somethin? Is there a special parameter that I have to set?
BR, Björn
--
Björn Klasen, Specialist
TNG Stadtnetz GmbH, Network Management (VoIP)
Projensdorfer Straße 324
24106 Kiel
Germany
T +49 431/ 530530
F +49 431/ 7097-555
mailto: bklasen(a)tng.de
http://www.tng.de
Register: Amtsgericht Kiel HRB 6002 KI
Executive board (Geschäftsführung): Dr.-Ing. Volkmar Hausberg,
Sven Schade, Carsten Tolkmit, Dr. Sven Willert
Tax-Id (Steuernr.): 2029047020, VAT-Id (USt-Id): DE225201428
Hi,
I have still the problem that my htables are not written into a sqlite
db when I shutdown kamailio.
Manual writing via:
kamcmd htable.store ...
is working.
As I can see in the logs with highest loglevel, the function destroy()
is never called.
ht_db_url.len is > 0
ht_db_init_con() should work, else nothing would work with the db.
But I can not see the debug messages from ht_db_open_con()
Any ideas?
Best regards,
Bernd
Hi,
I was able to test the PLMN 00101 for VoLTE, but unable to test it with other PLMNs. I am specifically looking to have a successful test with PLMN31501. VoLTE is not enabling once I configure it.
I followed this https://open5gs.org/open5gs/docs/tutorial/02-VoLTE-setup/
Any one has experience for PLMN 315?
Hi,
I have a scenario where I have an edge proxy (named RS), which locally stores registrations from Endpoints in its USRLOC, but which then also forward's REGISTER requests on to another proxy (named CN), which stores registrations in its USRLOC. (which then does DMQ with another CN like it).
Both RS and CN are storing Path information, for example:
kamctl ul show displays on both RS and CN:
"Path": "sip:vs-rs01.blah.foo.bar;lr;received=sip:3.4.5.6:33577",
So I know the path info is in there.
I want CN , when presented with an INVITE, to reply with a 302 Redirect.
Right now I have this:
if (!lookup("location",sip:$tU@nodomain)) {
}
reg_fetch_contacts("location", "$tu", "called");
xlog("location info $ulc(called=>path)");
sl_send_reply("302","Redirect");
and the xlog does display the path. Good, so I have it being sent all the way through RS and CN and into CN’s USRLOC.
but this isn’t complete.
I am now faced with two issues.
One, I need to mangle the Path into a Contact header for the Redirect.
Two, I need to delete the Contact header that sl_send_reply is putting on there, which is the Contact as RS sees it from the endpoint. This needs to be removed and replaced with a Contact of only the RS server.
It feels like there ought to be a simpler way to do this than parsing the Path string and reassembling a Contact from it, but if there is it's not readily apparent. Both Google and chatgpt have failed me :)
Thanks in advance,
Jawaid
Hi Gang
I just updated our dev plattform from 5.6 to 5.7
5.5 was working fine with TLS under Ubuntu Focal.
5.6 under Jammy started to dump cores.
5.7 still shows the same behaviour, usually shortly after a restart.
Oct 20 09:45:01 dev-cpereg01 kamailio[11925]: CRITICAL: <core> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f1bb0dd4bd8), called from tls: tls_init.c: ser_free(405), first free tls: tls_init.c: ser_free(405) - ignoring
Oct 20 09:45:11 dev-cpereg01 kamailio[11905]: ALERT: <core> [main.c:776]: handle_sigs(): child process 11924 exited by a signal 11
Oct 20 09:45:11 dev-cpereg01 kamailio[11905]: ALERT: <core> [main.c:779]: handle_sigs(): core was generated
Could anyone point me the correct direction on how to fix this issue?
Am I the only one seeing this issue?
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
Hi All,
I started a discussion on the matrix channel about some 404 RPM repos
and wanted to bring it here to further discuss.
We typically configure our various RPM-based package managers to allow
patch updates from the repos.
As an example, if trying to install 5.7.x, can be done as follows:
|yum -y install yum-utils yum-config-manager --add-repo
https://rpm.kamailio.org/centos/kamailio.repo yum-config-manager
--disable \* yum-config-manager --enable kamailio-5.7 yum install kamailio |
This will fail though because
https://rpm.kamailio.org/centos/7/5.7/5.7/x86_64/ does not exist.
Throughout the repos for centos/rhel/fedora I found the existence of
packages is inconsistent.
We can tell the intention was to allow the above behavior as the
kamailio.repo comes with the above configuration.
The above example will update /etc/yum.repos.d/kamailio.repo as follows:
|[kamailio-5.7] name=Kamailio - 5.7 - Packages for the latest Kamailio
5.7 release
baseurl=https://rpm.kamailio.org/centos/$releasever/5.7/5.7/$basearch/
enabled=1 metadata_expire=30d repo_gpgcheck=0
gpgkey=https://rpm.kamailio.org/rpm-pub.key type=rpm
skip_if_unavailable=True |
That is for centos though, and I found that some of the other distros
have incomplete kamailio.repo files as well.
In example, the rhel kamailio.repo is missing separate entries for 5.7,
but it does exist in the centos version.
Looks like some small cleanup is in order to make the end user
experience more consistent.
I believe sergey was maintaining those repos last, please chime in here
if you can.
If needed I can pick up some of those responsibilities as well.
--
Regards,
*Tyler Moore* <https://devopsec.net/>
Full Stack Software Engineer
<http://www.google.com/search?q=full+stack+software+engineer+job+description>
Flyball Labs <http://goflyball.com/>
Office: 888-907-2085, ext: 34 <tel:8889072085;ext=34>
Cell: 248-909-2769 <tel:2489092769>
Email: tmoore(a)goflyball.com
FLYBALL TECHNICAL SOLUTIONS, LLC <http://flyballlabs.com/>
--
Tyler Moore
Regards,
*Tyler Moore* <https://devopsec.net/>
Full Stack Software Engineer
<http://www.google.com/search?q=full+stack+software+engineer+job+description>
Flyball Labs <http://goflyball.com/>
Office: 888-907-2085, ext: 34 <tel:8889072085;ext=34>
Cell: 248-909-2769 <tel:2489092769>
Email: tmoore(a)goflyball.com
FLYBALL TECHNICAL SOLUTIONS, LLC <http://flyballlabs.com/>
Hi All,
I started a discussion on the matrix channel about some 404 RPM repos
and wanted to bring it here to further discuss.
We typically configure our various RPM-based package managers to allow
patch updates from the repos.
As an example, if trying to install 5.7.x, can be done as follows:
yum -y install yum-utils
yum-config-manager --add-repo https://rpm.kamailio.org/centos/kamailio.repo
yum-config-manager --disable \*
yum-config-manager --enable kamailio-5.7
yum install kamailio
This will fail though because
https://rpm.kamailio.org/centos/7/5.7/5.7/x86_64/ does not exist.
Throughout the repos for centos/rhel/fedora I found the existence of
packages is inconsistent.
We can tell the intention was to allow the above behavior as the
kamailio.repo comes with the above configuration.
The above example will update /etc/yum.repos.d/kamailio.repo as follows:
[kamailio-5.7]
name=Kamailio - 5.7 - Packages for the latest Kamailio 5.7 release
baseurl=https://rpm.kamailio.org/centos/$releasever/5.7/5.7/$basearch/
enabled=1
metadata_expire=30d
repo_gpgcheck=0
gpgkey=https://rpm.kamailio.org/rpm-pub.key
type=rpm
skip_if_unavailable=True
That is for centos though, and I found that some of the other distros
have incomplete kamailio.repo files as well.
In example, the rhel kamailio.repo is missing separate entries for 5.7,
but it does exist in the centos version.
Looks like some small cleanup is in order to make the end user
experience more consistent.
I believe sergey was maintaining those repos last, please chime in here
if you can.
If needed I can pick up some of those responsibilities as well.
Regards,
Tyler Moore
Full Stack Software Engineer
Flyball Labs
Office: 888-907-2085, ext: 34
Cell: 248-909-2769
Email: tmoore(a)goflyball.com
Hi All,
We have recently encountered a challenging issue in our environment that I
wanted to bring to your attention. A few months ago, we performed updates
to our Docker and OpenSSL installations, upgrading OpenSSL to version
1.1.1u. Since then, we have been experiencing intermittent traffic blocking
(TLS and UDP both for around 10 minutes and getting recovered) on some of
our instances.
Prior to the OpenSSL upgrade, we had not observed any such issues. However,
the situation has become more complex due to a substantial increase in
traffic, with each instance now handling 4K-5K concurrent calls and a daily
total of approximately 200,000 calls per instance.
Our initial suspicion was related to a Docker iptable issue. To investigate
further, we conducted a GDB trace using "kamctl pstrap" and discovered
specific log entries indicating potential issues within the
"pthread_rwlock_wrlock" function. This has prompted us to explore whether
the problems are linked to the OpenSSL upgrade.
We are considering upgrading Kamailio to the latest version, although this
process typically requires a significant amount of time for proper planning
and testing. Given the high volume of calls we are currently handling, we
are also exploring the possibility of a temporary solution involving a
rollback of the OpenSSL version to see if it resolves the issue.
Curiously, during a recent load test using SIPP, which simulated 10,000
concurrent calls with a rate of 100 calls per second, we did not encounter
the same problem.
any hints or insights you may have that could help us pinpoint the root
cause of the problem .
We do have a complete GDB trace available, but its size necessitates
sharing a truncated version for now.
version: kamailio 5.4.3 (x86_64/linux) 0178a5
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE,
USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, 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_BLACKLIST,
HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_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: 0178a5
compiled on 12:36:56 Oct 22 2023 with gcc 4.8.5
Operating System Host :
LSB Version: :core-4.1-amd64:core-4.1-noarch
Distributor ID: Rocky
Description: Rocky Linux release 8.8 (Green Obsidian)
Release: 8.8
Codename: GreenObsidian
container os (Centos7)
Kamctl pstraip output (truncated to last few lines)
---start 154 -----------------------------------------------------
kamailio: No such file or directory.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007fbf6f38a0c3 in __epoll_wait_nocancel () from /lib64/libc.so.6
$1 = 82
$2 = {pid = 154, unix_sock = 182, idx = 27, status = 1, rank = 48, desc =
"tcp receiver (tcp:xxx.xxx.xxx.xx:5060 <http://223.62.234.57:5060/>)
child=27", '\000' <repeats 81 times>}
#0 0x00007fbf6f38a0c3 in __epoll_wait_nocancel () from /lib64/libc.so.6
No symbol table info available.
#1 0x0000000000684858 in io_wait_loop_epoll (h=0xb41720 <io_w>, t=2,
repeat=0) at core/io_wait.h:1039
n = 84
r = 0
fm = 0x2
revents = 8201656
__FUNCTION__ = "io_wait_loop_epoll"
#2 0x0000000000699e7a in tcp_receive_loop (unix_sock=186) at
core/tcp_read.c:1997
__FUNCTION__ = "tcp_receive_loop"
#3 0x00000000005279e7 in tcp_init_children () at core/tcp_main.c:5134
r = 27
i = -1
reader_fd_1 = 186
pid = 0
si_desc = "tcp receiver (tcp:xxx.xx.xxx.xxx:5060
<http://223.62.234.57:5060/>
)\000\000\000\355\217c\000\000\000\000\000\240\213{\001\001\000\000\000\017\000\000\000\000\000\000\000\250\a2o\276\177\000\000\200\b\231o\000\000\000\000\260\006\346\261\376\177\000\000\230\210w\000\000\000\000\000=\000\000\000>\000\000\000\270\016z\350\274\177\000\000\060;8o\002\000\000\000P\224\346\352\001\000\000"
si = 0x0
__FUNCTION__ = "tcp_init_children"
#4 0x000000000042ae66 in main_loop () at main.c:1771
i = 16
pid = 94
si = 0x0
si_desc = "udp receiver child=15
sock=xxxx.xxx.xxx.xx:5060\000\000\000\v\235\200", '\000' <repeats 13
times>,
"P\r\346\261\376\177\000\000\270%}\000\000\000\000\000T\000\000\000\000\000\000\000\060;8o\277\177\000\000\343\207\201\000\000\000\000\000\277;8o\277\177\000\000
\271A\000\000\000\000\000@\374Ko\276\177\000"
nrprocs = 16
woneinit = 1
__FUNCTION__ = "main_loop"
#5 0x0000000000433ad6 in main (argc=9, argv=0x7ffeb1e60e38) at main.c:2856
cfg_stream = 0x16c9010
c = -1
r = 0
tmp = 0x7ffeb1e61f0c ""
tmp_len = 2496
port = 2496
proto = 1472
ahost = 0x0
aport = 0
options = 0x7d5238
":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:"
ret = -1
seed = 2208520674
rfd = 4
debug_save = 0
debug_flag = 0
dont_fork_cnt = 0
n_lst = 0x7fbf6f40f3a0 <intel_02_known>
p = 0xf0b5ff <Address 0xf0b5ff out of bounds>
st = {st_dev = 76, st_ino = 120506675, st_nlink = 2, st_mode =
16877, st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 0, st_size = 40,
st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1698340416, tv_nsec =
618631009}, st_mtim = {tv_sec = 1698340416, tv_nsec = 618631009}, st_ctim =
{tv_sec = 1698340416, tv_nsec = 618631009}, __unused = {0, 0, 0}}
tbuf = '\000' <repeats 376 times>...
option_index = 0
long_options = {{name = 0x7d742f "help", has_arg = 0, flag = 0x0,
val = 104}, {name = 0x7d2a34 "version", has_arg = 0, flag = 0x0, val =
118}, {name = 0x7d7434 "alias", has_arg = 1, flag = 0x0, val = 1024}, {name
= 0x7d743a "subst", has_arg = 1, flag = 0x0, val = 1025}, {name = 0x7d7440
"substdef", has_arg = 1, flag = 0x0, val = 1026}, {name = 0x7d7449
"substdefs", has_arg = 1, flag = 0x0, val = 1027}, {name = 0x7d7453
"server-id", has_arg = 1, flag = 0x0, val = 1028}, {name = 0x7d745d
"loadmodule", has_arg = 1, flag = 0x0, val = 1029}, {name = 0x7d7468
"modparam", has_arg = 1, flag = 0x0, val = 1030}, {name = 0x7d7471
"log-engine", has_arg = 1, flag = 0x0, val = 1031}, {name = 0x7d747c
"debug", has_arg = 1, flag = 0x0, val = 1032}, {name = 0x0, has_arg = 0,
flag = 0x0, val = 0}}
__FUNCTION__ = "main"
[Inferior 1 (process 154) detached]
---end 154 -------------------------------------------------------
---start 155 -----------------------------------------------------
kamailio: No such file or directory.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007fbe6e5bd39e in pthread_rwlock_wrlock () from /lib64/libpthread.so.0
$1 = 83
$2 = {pid = 155, unix_sock = -1, idx = -1, status = 1, rank = -4, desc =
"tcp main process", '\000' <repeats 111 times>}
#0 0x00007fbe6e5bd39e in pthread_rwlock_wrlock () from
/lib64/libpthread.so.0
No symbol table info available.
#1 0x00007fbe68b745c9 in CRYPTO_THREAD_write_lock () from
/lib64/libcrypto.so.1.1
No symbol table info available.
#2 0x00007fbe68afe07e in CRYPTO_free_ex_data () from
/lib64/libcrypto.so.1.1
No symbol table info available.
#3 0x00007fbe68ea52c2 in SSL_free () from /lib64/libssl.so.1.1
No symbol table info available.
#4 0x00007fbe69149480 in tls_h_tcpconn_clean_f (c=0x7fbceeae00d0) at
tls_server.c:655
extra = 0x7fbceec3b898
__FUNCTION__ = "tls_h_tcpconn_clean_f"
#5 0x00000000004fbf2d in _tcpconn_free (c=0x7fbceeae00d0) at
core/tcp_main.c:1529
__FUNCTION__ = "_tcpconn_free"
#6 0x0000000000510912 in tcpconn_put_destroy (tcpconn=0x7fbceeae00d0) at
core/tcp_main.c:3284
__FUNCTION__ = "tcpconn_put_destroy"
#7 0x00000000005156a5 in handle_tcp_child (tcp_c=0x7fbe6f813440, fd_i=-1)
at core/tcp_main.c:3723
tcpconn = 0x7fbceeae00d0
response = {140449434960080, -2}
cmd = -2
bytes = 16
n = 1865551792
t = 887186228
crt_timeout = 410
con_lifetime = 57680
__FUNCTION__ = "handle_tcp_child"
#8 0x00000000005208ed in handle_io (fm=0x7fbe6f9d7c78, ev=1, idx=-1) at
core/tcp_main.c:4542
ret = 1
__FUNCTION__ = "handle_io"
#9 0x00000000004e93ed in io_wait_loop_epoll (h=0xad5740 <io_h>, t=5,
repeat=0) at core/io_wait.h:1070
n = 1
r = 0
fm = 0x7fbe6f9d7c78
revents = 1
__FUNCTION__ = "io_wait_loop_epoll"
#10 0x0000000000523c99 in tcp_main_loop () at core/tcp_main.c:4827
si = 0x0
r = 28
__FUNCTION__ = "tcp_main_loop"
#11 0x000000000042b1be in main_loop () at main.c:1779
i = 16
pid = 0
si = 0x0
si_desc = "udp receiver child=15 sock=xxx.xx.xxx.xxx:5060
<http://223.62.234.76:5060/>\000\000\000\v\235\200", '\000' <repeats 13
times>,
"P\r\346\261\376\177\000\000\270%}\000\000\000\000\000T\000\000\000\000\000\000\000\060;8o\277\177\000\000\343\207\201\000\000\000\000\000\277;8o\277\177\000\000
\271A\000\000\000\000\000@\374Ko\276\177\000"
nrprocs = 16
woneinit = 1
__FUNCTION__ = "main_loop"
#12 0x0000000000433ad6 in main (argc=9, argv=0x7ffeb1e60e38) at main.c:2856
cfg_stream = 0x16c9010
c = -1
r = 0
tmp = 0x7ffeb1e61f0c ""
tmp_len = 2496
port = 2496
proto = 1472
ahost = 0x0
aport = 0
options = 0x7d5238
":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:"
ret = -1
seed = 2208520674
rfd = 4
debug_save = 0
debug_flag = 0
dont_fork_cnt = 0
n_lst = 0x7fbf6f40f3a0 <intel_02_known>
p = 0xf0b5ff <Address 0xf0b5ff out of bounds>
st = {st_dev = 76, st_ino = 120506675, st_nlink = 2, st_mode =
16877, st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 0, st_size = 40,
st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1698340416, tv_nsec =
618631009}, st_mtim = {tv_sec = 1698340416, tv_nsec = 618631009}, st_ctim =
{tv_sec = 1698340416, tv_nsec = 618631009}, __unused = {0, 0, 0}}
tbuf = '\000' <repeats 376 times>...
option_index = 0
long_options = {{name = 0x7d742f "help", has_arg = 0, flag = 0x0,
val = 104}, {name = 0x7d2a34 "version", has_arg = 0, flag = 0x0, val =
118}, {name = 0x7d7434 "alias", has_arg = 1, flag = 0x0, val = 1024}, {name
= 0x7d743a "subst", has_arg = 1, flag = 0x0, val = 1025}, {name = 0x7d7440
"substdef", has_arg = 1, flag = 0x0, val = 1026}, {name = 0x7d7449
"substdefs", has_arg = 1, flag = 0x0, val = 1027}, {name = 0x7d7453
"server-id", has_arg = 1, flag = 0x0, val = 1028}, {name = 0x7d745d
"loadmodule", has_arg = 1, flag = 0x0, val = 1029}, {name = 0x7d7468
"modparam", has_arg = 1, flag = 0x0, val = 1030}, {name = 0x7d7471
"log-engine", has_arg = 1, flag = 0x0, val = 1031}, {name = 0x7d747c
"debug", has_arg = 1, flag = 0x0, val = 1032}, {name = 0x0, has_arg = 0,
flag = 0x0, val = 0}}
__FUNCTION__ = "main"
[Inferior 1 (process 155) detached]
---end 155 -------------------------------------------------------
Thanks & Regards
Pintu Lohar