sr-users

sr-users@lists.kamailio.org

21 participants
37770 discussions

how to get all non-execluded modules to single kamailio Debian package?
by Juha Heinanen 16 Apr '26

16 Apr '26

Looks there is bug in trixie/rules comment or it is misleading: # Module groups that are packaged in separate packages (with the name # kamailio-$(group_name)-modules). # Note: the order is important (should be in dependency order, the one # on which other depend first) PACKAGE_GROUPS += mysql geoip2 json utils With the above value, modules in those groups are included in kamailio_6.1.1_amd64.deb atleast when control only includes kamailio package. -- Juha

1 0

error when installing kamailio 6.1 on Debian Trixie
by Juha Heinanen 16 Apr '26

16 Apr '26

I built Kamailio 6.1 using trixie Debian dir. I modified rules (below) by adding to modules to EXCLUDED_MODULES and using empty PACKAGE_GROUPS and EXTRA_GROUPS. Build went fine, but when I installed the package, I got systemctl error: # dpkg -i kamailio_6.1.1_amd64.deb Selecting previously unselected package kamailio. (Reading database ... 296773 files and directories currently installed.) Preparing to unpack kamailio_6.1.1_amd64.deb ... Unpacking kamailio (6.1.1) ... Setting up kamailio (6.1.1) ... Created symlink '/etc/systemd/system/multi-user.target.wants/kamailio.service' → '/usr/lib/systemd/system/kamailio.service'. Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 148. Processing triggers for man-db (2.13.1-1) ... -- Juha ---------------------- rules #!/usr/bin/make -f # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 export DEB_BUILD_MAINT_OPTIONS = hardening=+all DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/architecture.mk include /usr/share/dpkg/buildflags.mk include /usr/share/dpkg/pkg-info.mk # Enable parallel builds. NUMJOBS = 1 ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) MAKEFLAGS += -j$(NUMJOBS) endif export RADCLI=1 export WOLFSSL_INTERNAL=no # tlsa export KTLS_INCLUDE_TLSA=yes export LIBSSL_STATIC_SRCLIB=yes export LIBSSL_STATIC_SRCPATH=/usr/$(LIBDIR) # Modules not in the "main" kamailio package: EXCLUDED_MODULES = EXCLUDED_MODULES += mono geoip dnssec java berkeley acc_diameter app_jsdt auth_diameter auth_xkeys benchmark blst call_control call_obj carrierroute alias_db app_lua cfg_db cfgt counters crypto db_cluster db_flatstore db_text db2_ops debugger dialog diversion dlgs dmq dmq_usrloc domainpolicy drouting evrexec exec file_out group imc influxdbc json jsonrpcc jsonrpcs keepalive kemix log_custom log_systemd lost lrkproxy lwsc mangler math matrix mediaproxy memcached mohqueue mqueue msrp nat_traversal nosip p_usrloc pdb pdt peerstate pipelimit posops prefix_route ptimer pua_json pv_headers pvtpl qos ratelimit regex rtjson rtpproxy sca seas secfilter sipcapture sipjson siprepo sipt slack sms smsops speeddial ss7ops sst statistics statsc statsd sworker systemdops textopsx timer tlsa tmrec topoh topos topos_htable tsilo uac uid_auth_db uid_avp_db uid_domain uid_gflags uid_uri_db uri_db userblocklist xhttp_prom xhttp_rpc xprint # Extra modules to skip, because they are not compilable now: # - regardless if they go to the main kamailio package or to some module # package, they will be excluded from compile and install of all. EXTRA_EXCLUDED_MODULES += bdb EXTRA_EXCLUDED_MODULES += oracle EXTRA_EXCLUDED_MODULES += pa EXTRA_EXCLUDED_MODULES += iptrtpproxy EXTRA_EXCLUDED_MODULES += python ## --EXCLUDED-- # Module groups that are packaged in separate packages (with the name # kamailio-$(group_name)-modules). # Note: the order is important (should be in dependency order, the one # on which other depend first) PACKAGE_GROUPS = # Module groups to be packaged onto kamailio-extra-modules. EXTRA_GROUPS = INSTALL_MODULES := $(addprefix install_, $(PACKAGE_GROUPS)) # https://wiki.debian.org/ReproducibleBuilds/ export DEB_CFLAGS_MAINT_APPEND=-DVERSION_NODATE .PHONY: skip-modules $(INSTALL_MODULES) skip-modules: @echo "$(EXCLUDED_MODULES) $(EXTRA_EXCLUDED_MODULES)" %: dh $@ --buildsystem=cmake override_dh_auto_configure: dh_auto_configure -- \ -DBUILD_DOC=ON \ -DUSE_GIT=OFF \ -DEXCLUDE_MODULES="$(EXCLUDED_MODULES) $(EXTRA_EXCLUDED_MODULES)" \ -DMODULE_GROUP_NAME="KSTANDARD $(shell echo "$(addprefix K, $(PACKAGE_GROUPS) $(EXTRA_GROUPS))"| tr '[:lower:]' '[:upper:]')" execute_after_dh_auto_build: cmake --build "obj-${DEB_HOST_GNU_TYPE}" -t dbschema override_dh_auto_test:

1 0

Releasing v6.1.2
by Daniel-Constantin Mierla 16 Apr '26

16 Apr '26

Hello, the release of Kamailio v6.1.2 (out of branch 6.1) is considered to be done on Wednesday, April 22, 2026. 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 Kamailio World Conference, May 7-8, 2026 - Berlin, Germany -- kamailioworld.com

1 0

How to change name Debian Trixie Kamailio?
by Juha Heinanen 15 Apr '26

15 Apr '26

Looks like string "kamailio" is deeply buried in Kamailio CMake build system and it is hard to change the name in Debian packaging. It was quite easy in make build system. Has anyone a suggestion on how to run two independent Kamailio instances on the same host? -- Juha

6 6

How to change name Debian Trixie Kamailio?
by Juha Heinanen 14 Apr '26

14 Apr '26

Hi, I'm trying to build Kamailio on Debian Trixie using kamailio/pkg/kamailio/deb/trixie as debian directory. I need two Kamailio based deb packages, one for my SIP Proxy and another one for my Presence Server. Name of the former packages would need to be sip-proxy*.deb and the latter presence-server*.deb. And, of course, the name of the bin, etc, lib, share, etc. files and directories in the package would need to be changed accordingly. For example, /usr/bin/sip-proxy instead of /usr/bin/kamailio. Is there any easy way to accomplish that? -- Juha

1 0

What is correct way to use Async module functions in KEMI
by M S 14 Apr '26

14 Apr '26

Hi, I am trying to use *async* module functions in Python KEMI on Debian 13 with kamailio version 5.8.8, Here is an example, KSR.async.task_group_route("replication_send", "rpl_send") However, it throws following exception, kamailio[2927480]: ERROR: app_python3 [python_support.c:167]: > python_handle_exception(): mod_init: Unhandled exception in the Python > code: > File "/etc/kamailio/kemi.py", line 904 > KSR.async.task_group_route("replication_send", "rpl_send") > ^^^^^ > SyntaxError: invalid syntax This function works in kamailio.cfg but not in KEMI, even though it is documented at, https://kamailio.org/docs/tutorials/devel/kamailio-kemi-framework/modules/#… Note: I tried to use other functions of same module and get similar error. What is correct syntax to use this module's functions in KEMI Python? Please suggest. Thank you. -- Muhammad Shahzad Shafi Tel: +49 176 99 83 10 85

1 1

Failover-Failback without any Load-Balancing
by Kama User 11 Apr '26

11 Apr '26

Hi. I'm trying to make failover-failback without any Load-Balancing with kamailio paired with HiPath 3800. Ubuntu 20.04, kamailio 5.5.7 # dispatcher.list 1 sip:192.168.1.10:5060 0 0 p=primary 1 sip:192.168.1.11:5060 0 0 p=secondary # IP Addresses of Kamailio Server listen=udp:10.0.0.203:5060 listen=tcp:10.0.0.203:5060 listen=tls:10.0.0.203:5060 # --- Module Parameters --- modparam("tm", "fr_timer", 10000) modparam("tm", "fr_inv_timer", 60000) modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list") modparam("dispatcher", "flags", 2) modparam("dispatcher", "force_dst", 1) modparam("dispatcher", "ds_ping_method", "OPTIONS") modparam("dispatcher", "ds_ping_interval", 10) modparam("dispatcher", "ds_probing_mode", 1) # Probes all nodes, even if inactive modparam("dispatcher", "ds_probing_threshold", 2) modparam("dispatcher", "ds_inactive_threshold", 5) # --- Routing Logic --- request_route { if (is_method("INVITE|REGISTER")) { if (!ds_select_dst("1", "8")) { sl_send_reply("503", "No servers available"); exit; } xlog*("Selected Destination $rd/$du \n"); t_on_failure("FAILOVER"); t_relay(); } } failure_route[FAILOVER] { if (t_check_status("503|408")) { xlog("Failed Destination $rd/$du \n"); if (ds_next_dst()) { t_on_failure("FAILOVER"); t_relay(); } } } When both PBXs are online I check the log file and see that Selected Destination is 10.0.0.203/sip:10.0.0.65. I also check via sngrep: if both PBXs are up I see OPTIONS to both of them 10.0.0.65 and 10.0.0.75 When I shutdown 10.0.0.65, log file says Failed Destination is 10.0.0.203/sip:10.0.0.65 and that's it. ds_next_dst not triggering at all. Thanks in advance.

4 12

Per-branch SDP modification (strip video) in parallel forking
by e.titovets＠gmail.com 11 Apr '26

11 Apr '26

Hi All, I am using Kamailio with rtpengine and have a parallel forking scenario (single INVITE -> multiple branches via append_branch()). Incoming INVITE has SDP with video Goal: - For Main branch : keep audio + video - For Forked branch: strip video (audio only) Problem: SDP manipulation seems to be applied globally to the message, not per branch. What I tried: 1. Using textops: sdp_remove_media("video"); msg_apply_changes(); 2. Trying to do it per branch: I attempted to move this logic into branch_route, but msg_apply_changes() is not allowed there, so SDP changes are not applied. Documentation stated that it can be used from from REQUEST_ROUTE or REPLY_ROUTE. 3. Using rtpengine: According to rtpengine NG protocol, "offer" supports: "sdp-media-remove": ["video"] However, I cannot find a way to pass this parameter via Kamailio's rtpengine module. Tried to add flag sdp-media-remove=video to the rtpengine_manage() but it doesn't work. Environment: - Kamailio version: 6.0.6 - rtpengine version: 13.5.1.6 Question: What is the correct way to modify SDP per branch in a parallel forking scenario in Kamailio? My test routing config: ``` request_route { if (is_method("CANCEL")) { if (t_check_trans()) { route(RELAY); } exit; } if (!is_method("ACK")) { if(t_precheck_trans()) { t_check_trans(); exit; } t_check_trans(); } # remove unused codecs and media # if (has_body("application/sdp")) { # sdp_remove_media("video"); # msg_apply_changes(); # } if (is_method("INVITE") && !has_totag()) { dlg_manage(); } remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE")) { record_route(); } if ($rU==$null) { sl_send_reply("484","Address Incomplete"); exit; } route(LOCATION); return; } route[RELAY] { if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) { if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH"); } if (is_method("INVITE|SUBSCRIBE|UPDATE")) { if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY"); } if (is_method("INVITE")) { if(!t_is_set("failure_route")) t_on_failure("MANAGE_FAILURE"); } if (!t_relay()) { sl_reply_error(); } exit; } route[LOCATION] { route(ADD_FORK); route(RELAY); } route[ADD_FORK] { $avp(extNum) = "abcd(a)192.168.106.34"; append_branch("sip:" + $(avp(extNum))); } branch_route[MANAGE_BRANCH] { route(NATMANAGE); } onreply_route[MANAGE_REPLY] { # remove video media # if (has_body("application/sdp")) { # sdp_remove_media("video"); # msg_apply_changes(); # } if(status=~"[12][0-9][0-9]") { route(NATMANAGE); } } failure_route[MANAGE_FAILURE] { route(NATMANAGE); if (t_is_canceled()) exit; } route[NATMANAGE] { if (is_request()) { if (has_body("application/sdp")) { xlog("L_INFO","Negotiate RTP offer for branch $T_branch_idx\n"); if ($ru =~ "^sip:1[0-9]{4}@v") { xlog("L_INFO","Main leg\n"); rtpengine_manage("replace-origin RTP/AVP external internal"); } else if ($ru =~ "192.168.106.34") { xlog("L_INFO","Forked leg\n"); rtpengine_manage("replace-origin RTP/AVP codec-mask=telephone-event transcode=PCMA always-transcode external internal via-branch=1"); //rtpengine_manage("label=$fu--->$ru sdp-media-remove=video replace-origin RTP/AVP codec-mask=telephone-event transcode=PCMA always-transcode ptime=20 external internal via-branch=1"); # only with patched module } } } if (is_reply()) { if (has_body("application/sdp") && (status=="200")) { xlog("L_INFO","Negotiate RTP answer for branch $T_branch_idx\n"); } } return; } ```

3 6

event tm:local-response blocks transactions
by Sergio Charrua 10 Apr '26

10 Apr '26

Hello all! I have stumbled in a weird behaviour which I cannot understand why it happened now. Hope someone can explain why. For some reason, calls are blocked with an error message saying that there is no transactions available right at the beginning/start of the call. I am using some event routes like the one below: event_route[tm:local-response] { xlog("L_INFO", "local-response - replied locally to $rm with $T_reply_code \n"); if ( is_method("OPTIONS") ) { xlog("L_INFO","tm:local-response - local response to $rm with $T_reply_code $Ri:$Rp $RAi:$RAp \n"); } } it is very simple, only logs a line in case method is OPTIONS when replied by Kamailio. And this **was** working fine for weeks having processed thousands of test calls. I also have a tm:local-request event route: # TM Event Routes - Catches BYE sent from local event_route[tm:local-request] { xlog("L_INFO", "tm:local-request - sending $rm from $$ua=$ua\n"); if ($rm == "BYE" && $ua =~ "kamailio") { $var(type) = "CALL_FINISH"; $var(_ev_type) = "CALL_FINISH"; $var(_ev_hint) = "local-bye"; $var(islocal) = 1; xlog("L_INFO", "tm:local-request - setting islocal=1 - $rm from $$ua=$ua\n"); route(TRACK_BYE); # sets $dlg_var(ts_bye_usec) and $dlg_var(finished_by) # Protect empty branch_stats before it reaches jansson later if ($var(_branch_stats) == $null || $var(_branch_stats) == "") $var(_branch_stats) = "[]"; # Lock only for the atomic write block - no module calls inside. sht_lock("local_bye=>$ci"); $sht(local_bye=>$ci|tkg_eid) = $dlg_var(tkg_eid); $sht(local_bye=>$ci|bye_time) = $dlg_var(ts_bye_usec); $sht(local_bye=>$ci|ack_time) = $dlg_var(ts_ack_usec); $sht(local_bye=>$ci|180_time) = $dlg_var(first_180_ts); $sht(local_bye=>$ci|183_time) = $dlg_var(first_183_ts); $sht(local_bye=>$ci|branch_stats) = $dlg_var(branch_stats); $sht(local_bye=>$ci|finished_by) = $dlg_var(finished_by); $sht(local_bye=>$ci|is_local) = 1; sht_unlock("local_bye=>$ci"); xlog("L_INFO", "tm:local-request - cached all dlg_vars for ci=$ci tkg_eid=$dlg_var(tkg_eid) bye_time=$dlg_var(ts_bye_usec)\n"); } if ($rm == "OPTIONS" && $ua =~ "kamailio") { # Override fr_timer just for OPTIONS transactions t_set_fr(7000, 0); # 7s instead of 10s, closer to dispatcher's 5s ping interval; if not, the result is a timing drift 60s-70s-80s $var(local_ip_port) = $shv(local_ip_port); $var(statuskey) = $du; xlog("L_DBG", "tm:local-request - DISPATCHER PROBE: Sending from $var(local_ip_port) to $var(statuskey) ( $var(statuskey) has $sht(sbcstatus=>$var(statuskey)) failures | probe=$sht(gw_probe=>$var(statuskey))) \n"); if ( $sht(sbcstatus=>$var(statuskey)) >= SBC_FAILURE_THRESHOLD) { xlog("L_DBG","tm:local-request - counter for $du is $sht(sbcstatus=>$var(statuskey)), probing... \n"); route(NOTIFY_ENDPOINT_DOWN); } $sht(sbcstatus=>$var(statuskey)) = $(sht(sbcstatus=>$var(statuskey)){s.int}) + 1; } } The main route looks like: request_route { $avp(START_TIME)=$utimef(%Y-%m-%d %H:%M:%S); $var(send_sock) = $null; $var(EVENT_TIME) = $TV(Sn); // in case KXP is not connected, do not process any SIP messages // (except OPTIONS or any method from an ongoing dialog) and reply with 503 to INVITEs if ( $sht(evapistatus=>state) == 0 && is_method("INVITE") ) { sl_reply("503", "Service Unavailable"); exit; } #!ifdef WITH_ACL $var(GROUPID) = allow_address("100", "$si", "$sp"); // group ID 100 sets denied IPs and subnets if ( !$var(GROUPID) ) // if client is in denied group (group ID 100) { xlog("L_WARN", "INIT - $si:$sp is not in the allowed ACL Group ID !\n"); # uncoment below if you wish to return SIP 401 error to non-allowed clients #sl_reply("401", "Address not allowed"); exit; } #!endif if (is_method("OPTIONS") && $sht(evapistatus=>state) > 0 ) { // reply to OPTIONS only if Kamailio has an EVAPI connection active // as we do not want Kamailio to receive SIP messages if no KXP available sl_send_reply("200","OK"); exit; } #!ifdef WITH_DMQ route(HANDLE_DMQ); #!endif # handle retransmissions route(HANDLE_RETRANS); # per request initial checks route(REQINIT); # CANCEL processing route(HANDLE_CANCEL); # handle requests within SIP dialogs route(WITHINDLG); # record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE")) { record_route(); route(RESET_VARS); xlog("L_INFO","MAIN_ROUTE - initializing dlg_manage()\n"); dlg_manage(); route(HANDLE_INVITE); exit; } route(RELAY); exit; } route[HANDLE_INVITE] { # Send INVITE details to Python script # Convert headers to JSONc route(TRACK_INVITE); // keeps track of timestamp when INVITE was received route(HEADERS_TO_JSON); // converts SIP headers to JSON struct using jsdt_run function # Send to Python via EVAPI $var(evmsg) = "INVITE:" + $T(id_index) + ":" + $T(id_label) + ":" + $var(json_headers); // no need to t_suspend() request as evapi_async_relay already suspends the request xlog("L_INFO", "HANDLE_INVITE - suspended transaction for INVITE / CALL_ATTEMPT. Index: $T(id_index) - Label: $T(id_label) \n" ); evapi_async_relay("CALL_ATTEMPT:$T(id_index):$T(id_label):$var(json_headers)"); exit; } At some given point, the HANDLE_INVITE makes use of an EVAPI script (Python) that requests routes from a routing engine, applies rules (like header manipulation,etc...) and then RELAYs the calls. This is all working fine and has been working for many months (still under test environments). For some reason, after restarting, Kamailio started producing the below debug logs and stopped processing calls. In fact, Calls where received and the only message that Kamailio would reply was SIP 100 Trying until the ingress endpoint gives up with timeout. I restarted Kamailio many time, increased shared and private memory to 2048 (just in case), but no luck. I think the issue is identified in these lines (also highlighted in log lines below): {105415 2}: tm: add_blind_uac(): no transaction context {105415 2}: tm: t_suspend(): failed to add the blind UAC {105415 2}: evapi: w_evapi_async_relay(): failed to suspend request processing And then back in Context 1 we can find: {105415 1}: HANDLE_INVITE - Index: <null> - Label: <null> I thought that it could be some stale Dialogs in DB causing the issue, so I connected to DB and checked dialog and dialog_vars tables, but they were both empty. After extensive testing and analysis, the solution was to **comment** the full event_route[tm:local-response] route block. Once restarted, everything worked as before! No other lines of code were modified. So the question remains: why this behaviour? Why Kamailio stopped creating transactions, processing calls, until I commented the event_route[tm:local-response] ? This was tested using Kamailio 5.8.4 and Kamailio 6.1.1 {1775747310.015114 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <script>: HANDLE_INVITE - suspended transaction for INVITE. {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} tm [t_lookup.c:1868]: t_newtran(): msg (0x7f5720e45020) id=62/105415 global id=62/105415 T start=(nil) {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} tm [t_lookup.c:781]: t_lookup_request(): start searching: hash=46408, isACK=0 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} tm [t_lookup.c:499]: matching_3261(): RFC3261 transaction matching failed - via branch [z9hG4bK00B1b0918b41312488f] {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} tm [t_lookup.c:981]: t_lookup_request(): no transaction found {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} tm [h_table.c:532]: tm_xdata_swap(): copy X/AVPs from msg context to txdata {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} tm [t_hooks.c:301]: run_reqin_callbacks_internal(): trans=0x7f56a2f20d50, callback type 1, id 0 entered {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} dialog [dlg_hash.c:780]: dlg_lookup_mode(): ref dlg 0x7f56a2f02110 with 1 -> 2 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} dialog [dlg_hash.c:784]: dlg_lookup_mode(): dialog id=115027 found on entry 83302 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} dialog [dlg_handlers.c:819]: dlg_onreq(): dialog added to tm callbacks {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} dialog [dlg_hash.c:1088]: dlg_unref_helper(): unref op on 0x7f56a2f02110 with 1 from dlg_hash.c:1106 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} dialog [dlg_hash.c:1092]: dlg_unref_helper(): unref dlg 0x7f56a2f02110 with 1 -> 1 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} tm [h_table.c:551]: tm_xdata_swap(): restore X/AVPs msg context from txdata {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/crypto/md5utils.c:67]: MD5StringArray(): MD5 calculated: b00467ce86b2fae8ac84d50ec8899e2e {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} tm [h_table.c:415]: build_cell(): created new cell 0x7f56a2f20d50 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/msg_translator.c:162]: check_via_address(): (10.246.252.2, 10.246.252.2, 0) {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} dialog [dlg_cseq.c:116]: dlg_cseq_prepare_new_msg(): prepare new msg for cseq update operations {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/parse_fline.c:247]: parse_first_line(): first line type 2 (reply(status)) flags 1 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/msg_parser.c:731]: parse_msg(): SIP Reply (status): {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/msg_parser.c:732]: parse_msg(): version: <SIP/2.0> {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/msg_parser.c:734]: parse_msg(): status: <100> {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/msg_parser.c:736]: parse_msg(): reason: <trying -- your call is important to us> {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/parse_hname2.c:314]: parse_sip_header_name(): parsed header name [Via] type 1 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/parse_via.c:1309]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK00B1b0918b41312488f>; state=6 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/parse_via.c:1309]: parse_via_param(): Found param type 235, <rport> = <5168>; state=16 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/parse_via.c:2663]: parse_via(): end of header reached, state=5 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/msg_parser.c:591]: parse_headers(): Via found, flags=2 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/msg_parser.c:593]: parse_headers(): this is the first via {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} dialog [dlg_cseq.c:59]: dlg_cseq_prepare_msg(): prepare msg for cseq update operations {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/parse_hname2.c:314]: parse_sip_header_name(): parsed header name [From] type 4 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/parse_hname2.c:314]: parse_sip_header_name(): parsed header name [To] type 3 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/parse_addr_spec.c:904]: parse_addr_spec(): end of header reached, state=10 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/msg_parser.c:172]: get_hdr_field(): <To> [54]; uri=[ sip:+32-254-84211@10.242.17.145:5060] {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/msg_parser.c:174]: get_hdr_field(): to body (54)["+3225484211" <sip:+32-254-84211@10.242.17.145:5060>#015#012], to tag (0)[] {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/parse_hname2.c:314]: parse_sip_header_name(): parsed header name [Call-ID] type 6 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/parse_hname2.c:314]: parse_sip_header_name(): parsed header name [CSeq] type 5 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <929293> <INVITE> {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/parse_hname2.c:314]: parse_sip_header_name(): parsed header name [Server] type : {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/parse_hname2.c:314]: parse_sip_header_name(): parsed header name [Content-Length] type 12 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/msg_parser.c:187]: get_hdr_field(): content_length=0 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of header {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} dialog [dlg_cseq.c:87]: dlg_cseq_prepare_msg(): no second via in this message {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/parse_fline.c:247]: parse_first_line(): first line type 2 (reply(status)) flags 1 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/msg_parser.c:731]: parse_msg(): SIP Reply (status): {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/msg_parser.c:732]: parse_msg(): version: <SIP/2.0> {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/msg_parser.c:734]: parse_msg(): status: <100> {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/msg_parser.c:736]: parse_msg(): reason: <trying -- your call is important to us> {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/parse_hname2.c:314]: parse_sip_header_name(): parsed header name [Via] type 1 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/parse_via.c:1309]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK00B1b0918b41312488f>; state=6 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/parse_via.c:1309]: parse_via_param(): Found param type 235, <rport> = <5168>; state=16 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/parse_via.c:2663]: parse_via(): end of header reached, state=5 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/msg_parser.c:591]: parse_headers(): Via found, flags=2 {1775747310.015146 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/msg_parser.c:593]: parse_headers(): this is the first via {1775747310.015490 105415 2 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/parse_hname2.c:314]: parse_sip_header_name(): parsed header name [From] type 4 {1775747310.015490 105415 2 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/parse_hname2.c:314]: parse_sip_header_name(): parsed header name [To] type 3 {1775747310.015490 105415 2 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/parse_addr_spec.c:904]: parse_addr_spec(): end of header reached, state=10 {1775747310.015490 105415 2 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/msg_parser.c:172]: get_hdr_field(): <To> [54]; uri=[ sip:+32-254-84211@10.242.17.145:5060] {1775747310.015490 105415 2 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/msg_parser.c:174]: get_hdr_field(): to body (54)["+3225484211" <sip:+32-254-84211@10.242.17.145:5060>#015#012], to tag (0)[] {1775747310.015490 105415 2 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/parse_hname2.c:314]: parse_sip_header_name(): parsed header name [Call-ID] type 6 {1775747310.015490 105415 2 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/parse_hname2.c:314]: parse_sip_header_name(): parsed header name [CSeq] type 5 {1775747310.015490 105415 2 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <929293> <INVITE> {1775747310.015490 105415 2 138422366_133841090(a)10.246.252.2 INVITE} tm [t_lookup.c:1565]: t_check_msg(): msg (0x7ffe7d59aec0) id=63/105415 global id=62/105415 T start=0x7f56a2f20d50 {1775747310.015490 105415 2 138422366_133841090(a)10.246.252.2 INVITE} tm [t_lookup.c:1542]: t_reply_matching(): failure to match a transaction {1775747310.015490 105415 2 138422366_133841090(a)10.246.252.2 INVITE} tm [t_lookup.c:1637]: t_check_msg(): msg (0x7ffe7d59aec0) id=63/105415 global id=63/105415 T end=(nil) {1775747310.015490 105415 2 138422366_133841090(a)10.246.252.2 INVITE} tmx [t_var.c:554]: pv_get_tm_reply_code(): reply code is <0> *{1775747310.015490 105415 2 138422366_133841090(a)10.246.252.2 <138422366_133841090(a)10.246.252.2> INVITE} <script>: local-response - replied locally to INVITE with 0* *{1775747310.015542 105415 2 138422366_133841090(a)10.246.252.2 <138422366_133841090(a)10.246.252.2> INVITE} tm [t_reply.c:634]: _reply_light(): reply sent out - buf=0x7f57209fd0d0: SIP/2.0 100 trying -... shmem=0x7f56a2f02920: SIP/2.0 100 trying - {1775747310.015542 105415 2 138422366_133841090(a)10.246.252.2 <138422366_133841090(a)10.246.252.2> INVITE} tm [t_reply.c:650]: _reply_light(): finished {1775747310.015542 105415 2 138422366_133841090(a)10.246.252.2 <138422366_133841090(a)10.246.252.2> INVITE} tm [t_fwd.c:721]: add_blind_uac(): no transaction context {1775747310.015542 105415 2 138422366_133841090(a)10.246.252.2 <138422366_133841090(a)10.246.252.2> INVITE} tm [t_suspend.c:101]: t_suspend(): failed to add the blind UAC {1775747310.015542 105415 2 138422366_133841090(a)10.246.252.2 <138422366_133841090(a)10.246.252.2> INVITE} evapi [evapi_mod.c:364]: w_evapi_async_relay(): failed to suspend request processing* {*1775747310.015566 105415 1 138422366_133841090(a)10.246.252.2 <138422366_133841090(a)10.246.252.2> INVITE} <script>: HANDLE_INVITE - suspended transaction for INVITE / CALL_ATTEMPT. Index: <null> - Label: <null>* {1775747310.015570 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/receive.c:531]: receive_msg(): request-route executed in: 2404 usec {1775747310.015570 105415 1 138422366_133841090(a)10.246.252.2 INVITE} dialog [dlg_hash.c:780]: dlg_lookup_mode(): ref dlg 0x7f56a2f02110 with 1 -> 2 {1775747310.015570 105415 1 138422366_133841090(a)10.246.252.2 INVITE} dialog [dlg_hash.c:784]: dlg_lookup_mode(): dialog id=115027 found on entry 83302 {1775747310.015570 105415 1 138422366_133841090(a)10.246.252.2 INVITE} dialog [dlg_hash.c:1088]: dlg_unref_helper(): unref op on 0x7f56a2f02110 with 1 from dlg_hash.c:1106 {1775747310.015570 105415 1 138422366_133841090(a)10.246.252.2 INVITE} dialog [dlg_hash.c:1092]: dlg_unref_helper(): unref dlg 0x7f56a2f02110 with 1 -> 1 {1775747310.015570 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil) {1775747310.015570 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil) {1775747310.015570 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil) {1775747310.015570 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil) {1775747310.015570 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil) {1775747310.015570 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil) {1775747310.015570 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/xavp.c:630]: xavp_destroy_list(): destroying xavp list (nil) {1775747310.015570 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/xavp.c:630]: xavp_destroy_list(): destroying xavp list (nil) {1775747310.015570 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/xavp.c:630]: xavp_destroy_list(): destroying xavp list (nil) {1775747310.015570 105415 1 138422366_133841090(a)10.246.252.2 INVITE} <core> [core/receive.c:635]: receive_msg(): cleaning up Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua* *www.kahea.ai <http://www.kahea.ai> / www.voip.pt <http://www.voip.pt>* *OpenTelecom* - Consulting for Telecoms, Lda Tel.: +351 <callto:+351+91+104+12+66>91 631 11 44 Email : *sergio.charrua(a)voip.pt <sergio.charrua(a)voip.pt>* This message and any files or documents attached are strictly confidential or otherwise legally protected. It is intended only for the individual or entity named. If you are not the named addressee or have received this email in error, please inform the sender immediately, delete it from your system and do not copy or disclose it or its contents or use it for any purpose. Please also note that transmission cannot be guaranteed to be secure or error-free.

1 0

make[3]: --libs: No such file or directory
by Juha Heinanen 09 Apr '26

09 Apr '26

I built latest Kamailio 6.1 and noticed that several modules produced these kind of error messages: LD (gcc) [M permissions.so] permissions.so make[3]: --libs: No such file or directory make[3]: --libs: No such file or directory LD (gcc) [M pv.so] pv.so make[3]: --libs: No such file or directory make[3]: --libs: No such file or directory Is it just me who sees them? -- Juha

3 7

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users