When I look at the debian repositories maintained by the project, there are instructions to import the public key of the repository for apt using this command:
wget -O http://deb.kamailio.org/kamailiodebkey.gpg | sudo apt-key add -
which results in:
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
gpg: no valid OpenPGP data found.
Is there an alternate method that can be posted in the repository that will get better results?
Thank you,
TL
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
Hello,
I encountered a problem stopping Kamailio with FIPS OpenSSL:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007ff7292380ac in OPENSSL_sk_pop () from /lib64/libcrypto.so.3
Missing separate debuginfos, use: dnf debuginfo-install
kamailio-5.7.3-4816.x86_64
(gdb) bt
#0 0x00007ff7292380ac in OPENSSL_sk_pop () from /lib64/libcrypto.so.3
#1 0x00007ff72914bf5b in conf_modules_finish_int () from /lib64/libcrypto.so.3
#2 0x00007ff72914c694 in CONF_modules_unload () from /lib64/libcrypto.so.3
#3 0x00007ff7291efff9 in OPENSSL_cleanup () from /lib64/libcrypto.so.3
#4 0x00007ff72954702b in ?? ()
#5 0x0000000100061c08 in ?? ()
#6 0x00007ff7190566c8 in ?? ()
#7 0x00007ffccf196a20 in ?? ()
#8 0x000000000071da8a in futex_release (lock=0x7ff729f08b50 <syslog>)
at core/mem/../mem/../futexlock.h:134
#9 0x00000000006e9448 in destroy_tls () at core/tls_hooks.c:75
#10 0x000000000041f278 in cleanup (show_status=1) at main.c:594
#11 0x0000000000420af1 in shutdown_children (sig=15, show_status=1) at
main.c:721
#12 0x0000000000421717 in handle_sigs () at main.c:752
#13 0x0000000000430c88 in main_loop () at main.c:1988
#14 0x0000000000439d13 in main (argc=14, argv=0x7ffccf1973f8) at main.c:3212
(gdb)
Environment:
Oracle Linux Server 9.3
Kamailio 5.7.3
yum list --installed | grep ssl
openssl.x86_64 10:3.0.7-24.0.3.el9_fips
@tools
openssl-libs.x86_64 10:3.0.7-24.0.3.el9_fips
@tools
openssl-pkcs11.x86_64 0.4.11-7.el9
@anaconda
xmlsec1-openssl.x86_64 1.2.29-9.el9
@AppStream
What can I do for further investigation?
Thanks
Hello Brothers,
I've installed kamailio throw "apt install" on Debian and it's installed version: kamailio 5.6.3 (x86_64/linux).
Now I've a big problem that kamailio cannot running with TLSv1 and it has to be TLSv1.2+ as tls.cfg doc said:
# We do not enable anything else than TLSv1.2+
# over the public internet. Clients do not have
# to present client certificates by default.
How could I avoid this restriction please to enable TLSv1?
Thank you,
Hi
I am running kamailio 5.4 on debian
I have carrierfailureroute configured incase of primary service provider
fails. I also have Stirshaken configured to add Identity header on outbound
calls. Issue is when call fail overs to carrierfailureroute,
http_async_query changes $ru to the primary carrier
From the debug logs, when primary carrier sends a 488 (primary carrier
expects SIP TLS but my call is UDP - to test the failover scenario)
39(285) DEBUG: {1 18398 INVITE 8EmmsLqNuMRYBduMqFgX3w4JHAn4C2xn} tmx
[t_var.c:561]: pv_get_tm_reply_code(): reply code is <488>
39(285) DEBUG: {1 18398 INVITE 8EmmsLqNuMRYBduMqFgX3w4JHAn4C2xn}
carrierroute [cr_func.c:178]: set_next_domain_on_rule(): searching for
matching routing rules39(285) INFO: {1 18398 INVITE
8EmmsLqNuMRYBduMqFgX3w4JHAn4C2xn} carrierroute [cr_func.c:197]:
set_next_domain_on_rule(): next_domain is 47987
Carrier route rewrites the failover carrier
39(285) INFO: {1 18398 INVITE 8EmmsLqNuMRYBduMqFgX3w4JHAn4C2xn}
carrierroute [cr_func.c:706]: cr_do_route(): uri 14371234567 was rewritten
to sip:14371234567@sip.primaryprovider.com, carrier 1, domain 47987
Before http_async_query rd and ru are still the failover carrier
39(285) INFO: {1 18398 INVITE 8EmmsLqNuMRYBduMqFgX3w4JHAn4C2xn} <script>:
[callid: 8EmmsLqNuMRYBduMqFgX3w4JHAn4C2xn] - [cfg:2976] - Debug testing
----- rd is sip.primaryprovider.com ----- ru is
sip:14371234567@sip.primaryprovider.com
39(285) DEBUG: {1 18398 INVITE 8EmmsLqNuMRYBduMqFgX3w4JHAn4C2xn}
http_async_client [async_http.c:469]: async_send_query(): transaction
suspended [5261:1830449764]
39(285) DEBUG: {1 18398 INVITE 8EmmsLqNuMRYBduMqFgX3w4JHAn4C2xn}
http_async_client [async_http.c:625]: async_push_query(): query sent [
https://authn-uat.ccid.neustar.biz/ccid/authn/v2/identity?apiKey=randomkey]
(0x7fdcad097e60) to worker 1
However, when the route is being called after the http_async_query it
changes to the primary one:
26(272) DEBUG: tm [t_lookup.c:1612]: t_lookup_ident_filter(): transaction
found
26(272) DEBUG: http_async_client [async_http.c:235]: async_http_cb():
resuming transaction (5261:1830449764)
26(272) DEBUG: tm [t_lookup.c:1612]: t_lookup_ident_filter(): transaction
found
26(272) INFO: <script>: [callid: 8EmmsLqNuMRYBduMqFgX3w4JHAn4C2xn] -
[cfg:2995] - Debug testing ----- rd is 1.2.3.4 ----- ru is
sip:14371234567@1.2.3.4:5061;transport=TLS
Due to this, call keeps going to the primary and it fails
if ( http_async_query(STIRSHAKEN_AS_URL, "AS_RESPONSE") == -1 ) {
xlog("L_ERR ", "[cfg:$cfg(line)] Failed to connect AS service for token $fu
-> $tu \n");
return;
}
route[AS_RESPONSE] {
xlog("L_INFO", "[callid: $ci] - [cfg:$cfg(line)] - Debug testing ----- rd
is $rd ----- ru is $ru\n");
if ($http_ok) {
xlog("L_INFO", "[cfg:$cfg(line)] Resuming outbound call transaction for $fu
-> $tu Received - $http_rb \n");
# Add identity and Date headers
if (jansson_get("identity", $http_rb, "$var(identity)")) {
insert_hf("Identity: $var(identity)\n", "Content-Length");
}
if (jansson_get("date", $http_rb, "$var(date)")) {
if ($hdr(Date) != $null){
remove_hf("Date");
}
insert_hf("Date: $var(date)\n", "Identity");
}
} else {
xlog("L_ERR", "[cfg:$cfg(line)] Resuming outbound call transaction. Error -
$http_err)\n");
}
route(RELAY);
exit;
}
Please help to understand why rd / ru changes to primary carrier.
Regards,
Maharaja Azhagiah
Hi,
I recently updated my testing env to 5.8.1 and after that I’ve been receiving dns_cache.c warning “record not alone”.
I found out that it’s been added to quite recent commit: https://github.com/kamailio/kamailio/commit/d8a35b3b6c837b36779e232b65fce61…
And that’s probably the why I haven’t seen it before.
As far as I know, I have no other problem with dns or anything else than the warning appearing in the logs 😊
I can’t quite get what the warning is about?
Clearly refers to dns queries, and with debug I found out that maybe its somehow related to ip which has several domains to pointing it (and queried by one of those domains by this kamailio). Can it be something with the PTR-record?
And this warning comes ones every hour, so probably when some ttl expires, and meanwhile the cache is ok with the situation.
And as a background, I haven’t done any specific dns-configurations in my config, so settings should be pretty much in defaults.
Any advice what I should fix here to get the warning disappear?
-Pyry
Hello!
I need advice on how to intercept local SIP OPTIONS requests from the
nathelper module for some adjustments?
As far as I tested, it does not fall into the
*event_route[tm:local-request]*
Thanks in advance!
# kamailio -v
version: kamailio 5.7.1 (x86_64/linux) 1cf389-dirty
--
BR,
Denys Pozniak
Hello,
We are trying to integrate Kamailio as the IMS server with our 5G core
emulator by following the steps listed out at
https://open5gs.org/open5gs/docs/tutorial/02-VoLTE-setup/. In our case, we
have our own 5G core emulator instead of the Open5GS core.
We are using sipp scripts to generate the SIP calls. The PCRF component of
the 5G core is emulated by us and is capable of handling Diamater calls
from Kamailio over the Rx interface.
We have got the setup working to the point where the SIP Register calls are
landing on the PCSCF which in turn is sending out AA Requests to PCRF and
the PCRF is responding. However there is an internal error in the Kamailio
log
"4(3682133) ERROR: ims_qos [ims_qos_mod.c:1305]: w_rx_aar_register(): This
contact does not exist in PCSCF usrloc - error in cfg file"
Please help us in identifying if we are missing anything in the Kamailio
set up.
The packet capture and syslog excerpts from the VM where Kamailio is
running are attached; here we are trying to perform SIP Registration for
three SIP endpoints 001010123456791, 001010123456792 and 001010123456793.
If there is any additional information required, please let us know.
Regards,
Shantanu Kumar Roy
Hello,
I am considering to release Kamailio v5.6.6 (out of branch 5.6) later
this week (likely on Wednesday, July 3, 2024). If anyone is aware of
issues not yet on the bug tracker, report them there asap in order to
have a better chance to be fixed.
This is going to be the last release out of branch 5.6 to mark the end
of official/packaging maintenance.
Cheers,
Daniel
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
Hello,
I am considering to release Kamailio v5.7.6 (out of branch 5.7) on
Tuesday, July 2, 2024. If anyone is aware of issues not yet on the bug
tracker, report them there asap in order to have a better chance to be
fixed.
Cheers,
Daniel
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com