- sr-users - kamailio.org

Error reporting when developing a custom module to link to a third-party library
by bikq＠163.com 11 Oct '23

11 Oct '23

Dear friends, I have a question: When adding a custom module in kamailio, I referenced a third-party library. There was no problem with compilation, but when I ran it, it reported that the third-party library could not be found. What is the reason? The current Makefile is as follows： ``` # WARNING: do not run this directly, it should be run by the main Makefile include ../../Makefile.defs auto_gen= NAME=rocketmq.so THIRDPARTY=/mnt/vdd/kqbi2/3rdparty ROCKETMQ_ROOT_PATH=${THIRDPARTY}/rocketmq CXX?=g++ LD?=g++ LIBS+=-L$(LOCALBASE)/lib -L$(ROCKETMQ_ROOT_PATH)/lib/linux/x64 crocketmq.o -lstdc++ -lrocketmq DEFS+=-I$(LOCALBASE)/include -I${ROCKETMQ_ROOT_PATH}/include CXXFLAGS=$(CFLAGS:-Wno-deprecated option=) CXXFLAGS+=-Wno-write-strings -Wno-deprecated -Wno-unused-function -Wno-sign-compare -Wno-strict-aliasing include ../../Makefile.modules crocketmq.o: crocketmq.cpp crocketmq.h @echo "Compiling $<" $(CXX) -std=c++11 $(CXXFLAGS) $(CFLAGS) $(C_DEFS) $(DEFS) -c $< -o $@ rocketmq.so: crocketmq.o modclean: -@rm -f crocketmq.o crocketmq.d rocketmq_mod.o rocketmq_mod.d clean clean-modules: modclean proper realclean distclean maintainer-clean: modclean ``` There is no problem in compiling, but when running, the third-party librocketmq.so library cannot be found, and various export LD_LIBRARY_LIBRARY also does not work. ``` 0(13229) DEBUG: <core> [core/cfg.y:2053]: yyparse(): loading module rocketmq.so 0(13229) DEBUG: <core> [core/sr_module.c:516]: ksr_locate_module(): found module to load <lib64/kamailio/modules/rocketmq.so> 0(13229) DEBUG: <core> [core/sr_module.c:573]: ksr_load_module(): trying to load <lib64/kamailio/modules/rocketmq.so> 0(13229) ERROR: <core> [core/sr_module.c:591]: ksr_load_module(): could not open module <lib64/kamailio/modules/rocketmq.so>: librocketmq.so: cannot open shared object file: No such file or directory 0(13229) CRITICAL: <core> [core/cfg.y:3900]: yyerror_at(): parse error in config file /mnt/vdd/kqbi2/install/kamailio/etc/kamailio/kamailio.cfg, line 380, column 12-24: failed to load module ```

1 2

Serial Forking with differing next hop for each branch?
by Barry Flanagan 10 Oct '23

10 Oct '23

Hi I have a scenario where I need to implement serial forking but each destination has also a next hop proxy. I can do the forking using append_branch, but how can I set the destination URI for each branch? In some cases the R-URI does not change, only the next hop proxy. Example: R-URI Next Hop user1(a)domain.com XXX.XXX.XXX.XXX user1(a)domain.com YYY.YYY.YYY.YYY user2(a)domain.com XXX.XXX.XXX.XXX I was thinking I could use a htable to store the next hop using the R-URI as the key, but as can be seen above there are possibly duplicate R-URIs with only the next hop changing. Thanks. -- -Barry

4 18

0.0.0.0 in VIA header
by Lewis Hutchinson 10 Oct '23

10 Oct '23

Morning What have you got your listen / advertise address / port set as? See this link > https://www.kamailio.org/wiki/cookbooks/5.5.x/core#advertised_address I'd probably start by looking at that. Lewis Mission Labs Limited is registered in England, company number 10040088. Trading Office: The Old Milk Depot, Bacup Rd, Rossendale, BB4 7FE. Registered office: The Scalpel, 18th Floor 52 Lime Street, London, EC3M 7AF. Email confidentiality notice: This message is private and confidential. If you have received this message in error, please notify us and remove it from your system. Please consider the environment before you print this email.

1 0

0.0.0.0 in VIA header
by Ali Taher 10 Oct '23

10 Oct '23

Hello, I'm using Kamailio as SIP proxy to receive INVITE packets, randomize A-number and then relay it to a certain gateway. I noticed that a Via header is added to the INVITE sent by Kamailio to the gateway with 0.0.0.0 as address as shown below: Via: SIP/2.0/UDP 0.0.0.0;branch=z9hG4bK2d97.61de75dd58fa7ca7450cc8b9b01db62f.0 As far as I know, the IP that should be used in the new added VIA header must be Kamailio IP, but it's not the case here, knowing that Kamailio is not behind NAT. Regards, Ali Taher

2 1

CANCEL first, then INVITE.
by James Lipski 09 Oct '23

09 Oct '23

Hello, Is there a way to change the transaction order when a failure fork occurs -- to explain, endpoint 1 calls endpoint 2. Call towards endpoint 2 goes unanswered, and so the call forks to voicemail, I see that an INVITE is sent towards my voicemail server first, followed by a CANCEL towards the endpoint; can I send the CANCEL first to the endpoint and then INVITE towards my voicemail server. I'm essentially using the bundled/sample configurations for testing. Thank you.

4 10

kamailio Behind nat. How Record-Route should be added ？
by codenot＠msn.com 09 Oct '23

09 Oct '23

UA1(192.168.0.1) --> kamailio (internal:192.168.0.2 public:1.1.1.1) --> UA2(2.2.2.2) if in UA1 INVITE, I write KSR.rr.record_route(). so UA2(2.2.2.2) received sip msg (Record-Route: <sip:1.1.1.1:7080>), so Kamailio can received BYE/ACK from UA2. but，Kamailio can't received BYE/ACK from UA1. if in UA1 INVITE, i write KSR.rr.record_route_advertised_address("192.168.0.2"), then Kamailio can received BYE/ACK from UA1, but not from UA2. what can i do, let Kamailio receive BYE/ACK from both sides ？

6 10

[Dialog Module] questions about early_timeout param
by Abdoul Osséni 08 Oct '23

08 Oct '23

Hello all, Can you please clarify part of the following doc for me? -- 6.7. early_timeout (integer) The timeout (in seconds) after which the dialogs in unconfirmed or early state (no final response received) are destroyed. * Default value is “300 (5 minutes)”. * *Example 1.7. Set early_timeout parameter* ... modparam("dialog", "early_timeout", 180) --- In the case where Kamailio acts as an SBC, will kamailio send a SIP BYE message to both devices (UAC and UAC)? Or Can Kamailio send a BYE message to both parties when timer b has expired? If yes, how to do it? Regards Abdoul

1 0

kamailio Behind nat. How Record-Route should be added ？
by 城门虾米 08 Oct '23

08 Oct '23

UA(192.168.0.11) received 183, find Record-Route(36.140.122.12) then send ACK to 36.140.122.12(Kamialio public ip) not 192.168.0.2(kamailio internal ip), so Kamailio can't receive ACK. this is my config，192.168.0.11 -> Kamailio -> Other SBC(public ip) function ksr_request_route() if KSR.is_INVITE() then KSR.rr.record_route(); KSR.nathelper.fix_nated_contact() end end This question has been bothering me for a long time, help me [cid:d1ec74be-1c33-406e-80d5-68663d1cd21f] [cid:bda00d0d-e6e6-4dc9-9462-141ad42b09b8]

1 1

uac_req_send + evroute + crash
by Dr. Barabás Péter 06 Oct '23

06 Oct '23

Hi All, I use kamailio In front of Asterisk and kamailio needs to refresh registrations periodically towards Asterisk to ensure the availability of users from Asterisk side. I use uac module and call uac_req_send() for sending REGISTER requests. I set $uac_req(evroute)=1 The event_route[uac:reply] is called fine, but in kamailio logs I see the next lines: CRITICAL: <core> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f114995ada8), called from uac: uac_send.c: uac_send_tm_callback(860), first free uac: uac_send.c: uac_resend_tm_callback(732) - ignoring After some time, kamailio has crashed. CRITICAL: <core> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f114995ada8), called from uac: uac_send.c: uac_send_tm_callback(860), first free uac: uac_send.c: uac_resend_tm_callback(732) – ignoring CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 34 ALERT: <core> [main.c:774]: handle_sigs(): child process 1407950 exited by a signal 6 Any idea that is it a bug or I use something wrong in config? Thanks in advance! Péter Barabás

2 4

Crypto module AES algorithm details
by Jayesh Nambiar 04 Oct '23

04 Oct '23

*Hello,* I am running kamailio-5.3.4 on one of my setup and I intend to use the crypto module in the same. I wanted to understand the following details when the module is used: I understand it uses the AES algorithm, is that correct? Does it use AES 128, 192 or 256 bit algorithms? Does it use CBC or ECB mode for AES? The 5.3 version does not have an parameter for init-vector, so does kamailio use any init vector internally in this case? When i compared the encrypted text that kamailio produces and the ones available online, they were producing different outputs even when same shared secret was used. Hence asking for more clarification PS: Upgrading kamailio is my very last option as this is one af an old setup which only needs this feature without much changes. Thanks for any valuable response. *-- Jayesh*

2 1

error in parsing HTTP messages
by sigxcpu＠gmail.com 02 Oct '23

02 Oct '23

Hello, In reference to this issue https://github.com/kamailio/kamailio/issues/3081 I've been advised to set http_reply_parse to "no" which I did (and it is the default value anyways). # grep http_reply_parse /etc/kamailio/kamailio.cfg http_reply_parse=no After setting this, I still get these parsing errors: { "idx": 23, "pid": 102, "level": "ERROR", "module": "core", "file": "core/parser/msg_parser.c", "line": 748, "function": "parse_msg", "logprefix": "", "message": "ERROR: parse_msg: message=<HTTP/1.1 100 Continue\r\n\r\nHTTP/1.1 200 OK\r\ndate: Wed, 26 Jul 2023 16:43:19 GMT\r\ncontent-length: 224\r\ncontent-type: text/plain; charset=utf-8\r\n\r\n{\"result\": {\"ruri\":\"\",\"fU\":\"\",\"tU\":\"\",\"privacy\":\"\",\"identity\":\"\",\"error\":{\"code\":0,\"message\":\"\"},\"mb\":\"\",\"Headers\":null,\"encrypted\":\"\",\"sipsScheme\":\"\",\"attestation\":\"\",\"authUser\":\"\",\"authPassword\":\"\",\"disableStirShaken\":\"\"}}>" } Is there anything that I am missing beyond setting that parameter? Thank you, Alexandru

1 1

Software bill of materials (SBOM)
by Ivan Ribakov 30 Sep '23

30 Sep '23

Any recommendations for a tool that can generate SBOM for a Kamailio instance based on configured modules? Thanks, Ivan

6 10

periodic could not resolve hostname
by Sergiu Pojoga 28 Sep '23

28 Sep '23

Aloha, I'm experiencing this internal DNS problem with Kamailio, can't seem to figure out what's causing it. Maybe someone can help. Essentially, from time to time (one or two times a day) this situation happens, starting with logs: linux kamailio[773]: ERROR: uac [uac_reg.c:1163]: uac_reg_send(): failed to send request for [some-uuid] linux kamailio[773]: ERROR: <core> [core/resolve.c:1730]: sip_hostport2su(): could not resolve hostname: "my.domain.net" linux kamailio[773]: ERROR: tm [ut.h:309]: uri2dst2(): failed to resolve " my.domain.net" linux kamailio[773]: ERROR: tm [uac.c:480]: t_uac_prepare(): no socket found # Do a Kamailio internal DNS lookup, no results found??? root@linux:~# kamcmd dns.lookup a my.domain.net error: 400 - Not found # Do a system DNS lookup. All good. root@linux:~# dig my.domain.net ;; QUESTION SECTION: ;my.domain.net. IN A ;; ANSWER SECTION: my.domain.net. 18000 IN A 192.168.0.1 # Delete internal Kamailio DNS record root@linux:~# kamcmd dns.delete_a my.domain.net # Lookup again right away. It's there, problem fixed. Why?? root@linux:~# kamcmd dns.lookup a my.domain.net { name: my.domain.net type: A size_bytes: 120 reference_counter: 2 permanent: no expires: 7674 last_used: 0 negative_entry: no records: { { rr_idx: 0 rr_ip: 192.168.0.1 rr_permanent: no rr_expires: 7674 } } }

2 2

What is the expected behavior for dispatcher's ds_next_dst?
by geoff.goas＠interoptechnologies.com 28 Sep '23

28 Sep '23

Hello, I have some questions about dispatcher's behavior. I noticed that when I first ds_select_dst() a specific dispatcher group ID, ds_next_dst() will cycle through the active destinations in that group. When it reaches the end of the destinations in the group, it does not return "false", instead it starts to return destinations that are not a part of that group, ie. those destinations which are listed prior to the selected group in the dispatcher.list file. Is this the expected behavior? I've observed it on kamailio 5.3 and 5.5 releases. My dispatcher.list: # Group 1 1 sip:127.0.0.1:5071;transport=udp 8 0 # Group 2 2 sip:127.0.0.1:5072;transport=udp 8 0 # Group 3 3 sip:127.0.0.1:7010;transport=udp 8 0 3 sip:127.0.0.1:7011;transport=udp 8 0 3 sip:127.0.0.1:7012;transport=udp 8 0 # Group 4 4 sip:127.0.0.1:5071;transport=udp 8 0 4 sip:127.0.0.1:5072;transport=udp 8 0 I have the following in failure_route (excerpt): $var(dsFoundDestination) = 0; if (t_any_replied()) { xavp_params_implode("_dsdst_", "$var(dsDestinations)"); xlog("L_INFO", "FAILURE ROUTE: Already have replies on this transaction. Selecting next destination from: [$var(dsDestinations)]"); if (ds_next_dst()) { xavp_params_implode("_dsdst_", "$var(dsDestinations)"); xlog("L_INFO", "FAILURE ROUTE: Next destination selected: [$du] from [$var(dsDestinations)]"); $var(dsFoundDestination) = 1; } } else if (ds_select_dst("3", "8")) // Dispatcher Group 3 { xlog("L_INFO", "FAILURE ROUTE: Did not find any replies on this transaction. Selected destination: [$du]"); $var(dsFoundDestination) = 1; } if ($var(dsFoundDestination)) { $var(logString) = "FAILURE ROUTE: Relayed to [" + $du + "]"; if (t_relay()) { xlog("L_INFO", "$var(logString)"); } } Produces the following logs: FAILURE ROUTE: Did not find any replies on this transaction. Selected destination: [sip:127.0.0.1:7012;transport=udp] FAILURE ROUTE: Relayed to [sip:127.0.0.1:7012;transport=udp] FAILURE ROUTE: Already have replies on this transaction. Selecting next destination from: [grp=3;uri=sip:127.0.0.1:7012;transport=udp;] FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:7011;transport=udp] from [grp=3;uri=sip:127.0.0.1:7011;transport=udp;] FAILURE ROUTE: Relayed to [sip:127.0.0.1:7011;transport=udp] FAILURE ROUTE: Already have replies on this transaction. Selecting next destination from: [grp=3;uri=sip:127.0.0.1:7011;transport=udp;] FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:7010;transport=udp] from [grp=3;uri=sip:127.0.0.1:7010;transport=udp;] FAILURE ROUTE: Relayed to [sip:127.0.0.1:7010;transport=udp] FAILURE ROUTE: Already have replies on this transaction. Selecting next destination from: [grp=3;uri=sip:127.0.0.1:7010;transport=udp;] FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:5072;transport=udp] from [grp=2;uri=sip:127.0.0.1:5072;transport=udp;] FAILURE ROUTE: Relayed to [sip:127.0.0.1:5072;transport=udp] FAILURE ROUTE: Already have replies on this transaction. Selecting next destination from: [grp=2;uri=sip:127.0.0.1:5072;transport=udp;] FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:5072;transport=udp] from [grp=2;uri=sip:127.0.0.1:5072;transport=udp;] FAILURE ROUTE: Relayed to [sip:127.0.0.1:5072;transport=udp] FAILURE ROUTE: Already have replies on this transaction. Selecting next destination from: [grp=2;uri=sip:127.0.0.1:5072;transport=udp;] FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:5071;transport=udp] from [grp=1;uri=sip:127.0.0.1:5071;transport=udp;] FAILURE ROUTE: Relayed to [sip:127.0.0.1:5071;transport=udp] I want to stop the loop once there are no more active destinations in group 3. Is the solution simply to check that the selected destination is part of the desired group and stop processing if it is not? Thanks for your time.

5 8

Kamailio v5.7.2 Released
by Daniel-Constantin Mierla 27 Sep '23

27 Sep '23

Hello, Kamailio SIP Server v5.7.2 stable release is out. This is a maintenance release of the latest stable branch, 5.7, that includes fixes since the release of v5.7.1. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.7.x. Deployments running previous v5.7.x versions are strongly recommended to be upgraded to v5.7.2. For more details about version 5.7.2 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2023/09/kamailio-v5-7-2-released/ RPM, Debian/Ubuntu packages will be available soon as well. Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - www.kamailioworld.com

1 0

Releasing v5.7.2
by Daniel-Constantin Mierla 27 Sep '23

27 Sep '23

Hello, I am considering to release Kamailio v5.7.2 (out of branch 5.7) this week (likely on Wednesday or Thursday, Sep 27/28, 2023). 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 -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - www.kamailioworld.com

1 1

failure_route, change_reply_status, and append_hf: Not Working as Expected
by sadik.oualla.mohamed＠gmail.com 26 Sep '23

26 Sep '23

Hello Kamailio Community, I'm currently working on a project that involves complex SIP routing and handling. I've encountered some difficulties while using change_reply_status, and append_hf functions in failure_route route in Kamailio. Although the documentation does provide guidance, the behaviors I am experiencing aren't aligning with the expected outcomes. Issue 1: failure_route I've set up a failure_route to handle specific SIP response codes (>4xx). However, I've observed that it get trigered and lunched, but I can't use change_reply_status or append_hf, I was using this first in onreply_route. Issue 2: change_reply_status I tried to use the change_reply_status function to modify the status of SIP replies, but it raises an error that this command cannot be executed here. Issue 3: append_hf I've also attempted to use append_hf in my failure_route block to add headers to replies, but the headers are not being added as expected. As a workaround, I've been using send_reply and append_to_reply for adding custom headers, and they seem to be working as expected. However, I found some old messages in kamailio mailing list, I can summerize what I learned like this ``` #Functions and Context - append_hf(): Adds a header to the currently processed SIP message. If you are in a route {...} block, then this adds the header to the request. If you are in an onreply_route, it adds the header to the reply. This function always acts on the message currently under scrutiny. - append_to_reply(): This function is used to add a header to a reply that will be generated by Kamailio at a later time. This function only affects replies generated by Kamailio itself and is not applicable for messages that are simply being forwarded. #Contexts - route {...}: This is typically where the incoming SIP request gets processed. Here, append_hf() will add headers to that request, and append_to_reply() will add headers to any replies that Kamailio might generate for this request. - onreply_route: This is where incoming SIP replies are processed. Here, append_hf() will act on the reply, not the request. ``` I'd like to know if there is a way to handle sip replies in failure_route, because send_reply make a new reply from kamailio, instead I want to keep some important headers from the original reply. I'd appreciate any insights or guidance the community can offer. Best regards,

2 1

RTPengine use single port for all calls
by Mahmood Alkhalil 26 Sep '23

26 Sep '23

Hello Kamailio, Is it possible to use RTPengine with a single UDP port for all calls instead of a range of ports? For example, when an invite is received or sent, the offered SDP for RTPengine is to receive RTP packets on a single port that is the same for all other calls, so that on firewalls only one port is to be opened.

2 2

Re: Choose RTP port in routing script
by Duarte Rocha 26 Sep '23

26 Sep '23

2 1

cdr_json_pre_encoded_prefix
by Oleg Podguyko 26 Sep '23

26 Sep '23

I try to use cdr_json_pre_encoded_prefix (string) parameters from acc_json module modparam("acc_json", "cdr_extra", "spx_resp=$avp(spx_resp)") modparam("acc_json", "cdr_json_pre_encoded_prefix", "spx_resp") do restart and get next mistakes: sep 22 14:17:15 vms-vms-spx-1 kamailio[581922]: ERROR: <core> [core/modparam.c:169]: set_mod_param_regex(): parameter <cdr_json_pre_encoded_prefix> of type <1:string> not found in module <acc_json> сен 22 14:17:15 vms-vms-spx-1 kamailio[581922]: CRITICAL: <core> [core/cfg.y:3686]: yyerror_at(): parse error in config file /etc/kamailio_vmsspx/modules.cfg, line 125, column 63: Can't set module parameter sep 22 14:17:15 vms-vms-spx-1 kamailio[581922]: ERROR: bad config file (1 errors) (parsing code: 0) sep 22 14:17:15 vms-vms-spx-1 systemd[1]: kamailio_vmsspx.service: Control process exited, code=exited status=255 sep 22 14:17:15 vms-vms-spx-1 systemd[1]: kamailio_vmsspx.service: Failed with result 'exit-code'. What’s wrong? I used: [opodguyko@vms-vms-spx-1 ~]$ kamailio -version version: kamailio 5.5.3 (x86_64/linux) b02728-dirty 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_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED 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: b02728 -dirty compiled on 15:35:46 Dec 15 2021 with gcc 8.3.1 [opodguyko@vms-vms-spx-1 ~]$ This parameter was added at release 5.5.0 Oleg Podguyko

3 3

Choose RTP port in routing script
by Duarte Rocha 26 Sep '23

26 Sep '23

Hello all, I have my rtpengine configured to use ports 20000 - 50000 for RTP in rtpengine.conf. Now i want to able to select the port or the port range in a call by call basis. Is that possible? I've tried to use "media-address" flag on rtpengine_manage but i wasn't successful. Thanks in advance, Cheers, Duarte Rocha

2 1

Several crashs in prepare_new_uac
by Igor Potjevlesch 26 Sep '23

26 Sep '23

Hello! We had several crashs of Kamailio (5.3.4) in the last weeks. Each time, the last logs are: /usr/local/sbin/kamailio[20942]: CRITICAL: <core> [core/forward.c:347]: get_send_socket2(): unsupported proto 0 (*) /usr/local/sbin/kamailio[20966]: CRITICAL: <core> [core/forward.c:347]: get_send_socket2(): unsupported proto 111 (unknown) When we look to the coredump, here below the first traces: (gdb) bt #0 0x00007f70131b3d91 in prepare_new_uac (t=0x7f6fe1d45340, i_req=0x7f7016fbe208, branch=0, uri=0x7fff37142fa0, path=0x7fff37142f80, next_hop=0x7f7016fbe480, fsocket=0x0, snd_flags=..., fproto=0, flags=2, instance=0x7fff37142f70, ruid=0x7fff37142f60, location_ua=0x7fff37142f50) at t_fwd.c:463 #1 0x00007f70131b7c42 in add_uac (t=0x7f6fe1d45340, request=0x7f7016fbe208, uri=0x7f7016fbe480, next_hop=0x7f7016fbe480, path=0x7f7016fbe848, proxy=0x0, fsocket=0x0, snd_flags=..., proto=0, flags=2, instance=0x7f7016fbe858, ruid=0x7f7016fbe870, location_ua=0x7f7016fbe880) at t_fwd.c:805 #2 0x00007f70131bfebd in t_forward_nonack (t=0x7f6fe1d45340, p_msg=0x7f7016fbe208, proxy=0x0, proto=0) at t_fwd.c:1667 #3 0x00007f701316cf44 in t_relay_to (p_msg=0x7f7016fbe208, proxy=0x0, proto=0, replicate=0) at t_funcs.c:332 #4 0x00007f70131a3a11 in _w_t_relay_to (p_msg=0x7f7016fbe208, proxy=0x0, force_proto=0) at tm.c:1689 #5 0x00007f70131a4c51 in w_t_relay (p_msg=0x7f7016fbe208, _foo=0x0, _bar=0x0) at tm.c:1889 #6 0x00000000005a1f57 in do_action (h=0x7fff37143d90, a=0x7f7016bd1b10, msg=0x7f7016fbe208) at core/action.c:1071 #7 0x00000000005aeb1e in run_actions (h=0x7fff37143d90, a=0x7f7016bd1b10, msg=0x7f7016fbe208) at core/action.c:1576 #8 0x00000000005af1df in run_actions_safe (h=0x7fff37146e90, a=0x7f7016bd1b10, msg=0x7f7016fbe208) at core/action.c:1640 #9 0x000000000066aa50 in rval_get_int (h=0x7fff37146e90, msg=0x7f7016fbe208, i=0x7fff37144238, rv=0x7f7016bd1e60, cache=0x0) at core/rvalue.c:915 #10 0x000000000066f000 in rval_expr_eval_int (h=0x7fff37146e90, msg=0x7f7016fbe208, res=0x7fff37144238, rve=0x7f7016bd1e58) at core/rvalue.c:1913 #11 0x000000000066f453 in rval_expr_eval_int (h=0x7fff37146e90, msg=0x7f7016fbe208, res=0x7fff371446ec, rve=0x7f7016bd2588) at core/rvalue.c:1921 #12 0x00000000005a1a1d in do_action (h=0x7fff37146e90, a=0x7f7016bd2e08, msg=0x7f7016fbe208) at core/action.c:1047 #13 0x00000000005aeb1e in run_actions (h=0x7fff37146e90, a=0x7f7016bcbd20, msg=0x7f7016fbe208) at core/action.c:1576 #14 0x000000000059e97d in do_action (h=0x7fff37146e90, a=0x7f7016ef19b8, msg=0x7f7016fbe208) at core/action.c:695 #15 0x00000000005aeb1e in run_actions (h=0x7fff37146e90, a=0x7f7016e3f578, msg=0x7f7016fbe208) at core/action.c:1576 #16 0x000000000059e97d in do_action (h=0x7fff37146e90, a=0x7f7016c220a0, msg=0x7f7016fbe208) at core/action.c:695 #17 0x00000000005aeb1e in run_actions (h=0x7fff37146e90, a=0x7f7016c220a0, msg=0x7f7016fbe208) at core/action.c:1576 #18 0x00000000005aae93 in do_action (h=0x7fff37146e90, a=0x7f7016c23978, msg=0x7f7016fbe208) at core/action.c:1207 #19 0x00000000005aeb1e in run_actions (h=0x7fff37146e90, a=0x7f7016c20748, msg=0x7f7016fbe208) at core/action.c:1576 #20 0x00000000005a1ec6 in do_action (h=0x7fff37146e90, a=0x7f7016c576a0, msg=0x7f7016fbe208) at core/action.c:1062 #21 0x00000000005aeb1e in run_actions (h=0x7fff37146e90, a=0x7f7016c0b770, msg=0x7f7016fbe208) at core/action.c:1576 #22 0x000000000059e97d in do_action (h=0x7fff37146e90, a=0x7f7016bc9920, msg=0x7f7016fbe208) at core/action.c:695 #23 0x00000000005aeb1e in run_actions (h=0x7fff37146e90, a=0x7f7016bb9100, msg=0x7f7016fbe208) at core/action.c:1576 #24 0x00000000005af2a7 in run_top_route (a=0x7f7016bb9100, msg=0x7f7016fbe208, c=0x0) at core/action.c:1661 #25 0x00000000005bcb7a in receive_msg ( buf=0xadbd80 <buf.6971> "INVITE sip:AAAAAAAAAA@W.X.Y.Z SIP/2.0\r\nVia: SIP/2.0/UDP W.X.Y.Z;rport;branch=z9hG4bKZD8Za7p2XF7cF\r\nMax-Forwards: 69\r\nFrom: \"AAAAAAAAAA\" sip:AAAAAAAAAA@W.X.Y.Z;tag=aXy4Na2NtvKBK\r\nTo: <"..., len=1011, rcv_info=0x7fff371474c0) at core/receive.c:423 #26 0x0000000000488e7f in udp_rcv_loop () at core/udp_server.c:548 #27 0x000000000042650f in main_loop () at main.c:1673 #28 0x000000000042ec18 in main (argc=7, argv=0x7fff37147c38) at main.c:2802 Is there anything relevant in this to know what's wrong? Regards, Igor. -- Cet e-mail a été vérifié par le logiciel antivirus d'Avast. www.avast.com

3 4

Planning Kamailio Developers Meeting 2023
by Daniel-Constantin Mierla 26 Sep '23

26 Sep '23

Hello, we are considering to organize another edition of Kamailio Developers Meeting, to be hosted again by sipgate.de in Dusseldorf, Germany. There is no fee for participants (i.e., free entry), but each one has to take care of travelling and accommodation (drinks and food are provided during the day). A few developers are already on board, we are looking to see if anyone else from the broader community wants to join us. Likely it is going to be during 2 days (with the option of doing it during three days still open at this moment, if there is going to be enough interest to have it longer). The proposed time frames are: - Nov 7-9, 2023 - Nov 21-23, 2023 The event is about discussing the internals of Kamailio (e.g., architectural changes, development strategies) and writing code or documentation for it. This is not an event about learning how to use Kamailio, but to work on improving it. As a bonus, there will be a social networking event in the evening with some fun activities, drinks and food. If you want to join, state your preference for any of the two time frames (or even just for 2 days in one of the two time frames). It is not a large meeting room, if we get too many join requests, we may have to select based on past contributions, and if that is not the case, then is just the first come first served. You can reply to this thread or just write me directly if you want to join and when you prefer to happen. By mid of next week, we plan to select the event dates so everyone that comes to it can start planning the trip. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy - Training Services -- asipto.com Kamailio World Conference - kamailioworld.com

1 1

Iterating Through Multiple IP Peers for DID Call Termination in Kamailio
by Shah Hussain Khattak 26 Sep '23

26 Sep '23

Hello Team, I hope you're all doing well. I'm reaching out to request your insights on the following scenario. Overview: I have successfully configured Kamailio to authenticate IP addresses, primarily for PBXs and customers unable to register. With this setup, I can flawlessly receive incoming traffic and forward it to our internal FreeSwitch servers. Current issue: Now, I'm focusing on managing traffic in the opposite direction—specifically for DIDs. I have a DID table set up in Kamailio that associates DID numbers with their respective IP peers. Upon receiving a call, a database lookup is performed to find the destination number, after which the call is terminated at the customer's IP. I'm facing difficulty in handling situations where a customer has multiple IP peers (for redundancy). My aim is to try each of these IPs sequentially when terminating a specific DID call towards them. The current logic I'm employing for the INVITE lookup looks like this: # Database lookup for INVITEs if (is_method("INVITE")) { sql_query("didrouting_db", "SELECT route_to FROM did_routing WHERE did_number='$rU'", "result"); if ($dbr(result=>rows) > 0) { $var(route_to) = $dbr(result=>[0,0]); xlog("L_INFO", "Routing DID $rU to $var(route_to)\n"); $du = "sip:" + $var(route_to) + ":5060"; } else { $du = "sip:" + FS_IP + ":5060"; } } The above logic works fine for a single IP. I intend to use a comma-separated list of IPs in my route_to column (for example 192.168.1.2,192.168.1.3, ...) and then iterate through these IPs one by one. I'm having trouble coming up with a workable logic or loop to achieve this. Would you be able to offer any guidance or suggestions? Please also recommend if there is a better approach available to handle this scenario. Thank you in advance for your valuable input. Regards, Shah Hussain

4 3

TM max_inv_lifetime being reset by downstream responses
by James Browne 25 Sep '23

25 Sep '23

Hi all I see this old thread from 2015. - https://kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio.org/t… It's about max_inv_lifetime not working properly. I have this problem today: SIP-180 responses from downstream apparently reset max_inv_lifetime, and the transaction can live for hours (apparently indefinitely) even though max_inv_lifetime is set to just over a minute. By spacing the SIP-180 responses (from downstream) slightly longer apart than than max_inv_lifetime in kamailio, I don't get the problem, so it looks to me that this is TM not matching what's in the documentation (which mentions that this should be a hard limit). With this configuration, SIP-180 responses every minute result in the transaction never ending (until the client CANCELs the call). - kamailio.cfg:modparam("tm", "fr_timer", 3000) - kamailio.cfg:modparam("tm", "fr_inv_timer", 300000) - kamailio.cfg:modparam("tm", "max_inv_lifetime", 65000) - kamailio.cfg:modparam("tm", "noisy_ctimer", 1) That other thread ends with Daniel mentioning that he'd have to look at the code, but nothing further. Running "git log --grep max_inv_lifetime" shows me that the last/only update that wasn't just documentation was in 2007. Has anyone got an ideas? James

2 2

Modifying SDP as drop-in replacement for overloaded Asterisk box - looking for help/paid consulting fast
by Markus 23 Sep '23

23 Sep '23

Hi list, I'm trying to use Kamailio 4.4.4 with rtpengine in a self-inflicted emergency situation (didn't monitor traffic growth properly and now encountering packet loss during peak times) as a drop-in replacement for an overloaded Asterisk box in a call-termination-to-upstream-carrier scenario. My test scenario is to make a call from a SIP softphone to Asterisk IP 1.1.1.1 -> Kamailio/rtpengine IP 2.2.2.2 -> Upstream carrier 3.3.3.3 sngrep on Kamailio box 2.2.2.2 - the following SDP will not work - carrier is rejecting it. Carrier is authenticating our calls based on our IP address 2.2.2.2, no username/pass involved. 2023/09/22 02:06:49.216136 2.2.2.2:5060 -> 3.3.3.3:5060 INVITE sip:+32xxxxxxxx@2.2.2.2;user=phone SIP/2.0 Record-Route: <sip:2.2.2.2;lr> Via: SIP/2.0/UDP 2.2.2.2;branch=z9hG4bKd9c3.d6fa3abe5d52b827e2054de5573028e0.0 Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bK473270e8 Max-Forwards: 69 From: "61xxxxxxxxx" <sip:+61xxxxxxxxx@1.1.1.1>;tag=as3d75aadd To: <sip:+32xxxxxxxx@2.2.2.2;user=phone> Contact: <sip:+61xxxxxxxxx@1.1.1.1:5060> Call-ID: 3f31e1622a72b6d17f24e42362f4f1d0@1.1.1.1:5060 CSeq: 102 INVITE User-Agent: Asterisk PBX 20.0.0 Date: Fri, 22 Sep 2023 00:06:50 GMT Session-Expires: 1800 Min-SE: 90 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer P-Asserted-Identity: <sip:+61xxxxxxxxx@2.2.2.2;user=phone> Content-Type: application/sdp Content-Length: 314 X-SIP: 1.1.1.1 v=0 o=root 1093000903 1093000903 IN IP4 1.1.1.1 s=Asterisk PBX 20.0.0 c=IN IP4 2.2.2.2 t=0 0 m=audio 25742 RTP/AVP 8 9 0 101 a=maxptime:150 a=rtpmap:8 PCMA/8000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=sendrecv a=rtcp:25743 a=ptime:20 I'm comparing this rejected INVITE to a successful INVITE sent by the original Asterisk box at IP 2.2.2.2 (now Kamailio box) to the carrier without Kamailio in the path, and these are the differences I noticed, and probably the things I have to mimick with Kamailio in order to make it work: INVITE sip:+32xxxxxxxxx@2.2.2.2;user=phone SIP/2.0 should be INVITE sip:+32xxxxxxxxx@3.3.3.3;user=phone SIP/2.0 To: <sip:+32xxxxxxxx@2.2.2.2;user=phone> should be To: <sip:+32xxxxxxxx@3.3.3.3;user=phone> From: "61xxxxxxxxx" <sip:+61xxxxxxxxx@1.1.1.1>;tag=as3d75aadd should be From: "61xxxxxxxxx" <sip:+61xxxxxxxxx@2.2.2.2>;tag=as3d75aadd Contact: <sip:+61xxxxxxxxx@1.1.1.1:5060> should be Contact: <sip:+61xxxxxxxxx@2.2.2.2:5060> Call-ID: 3f31e1622a72b6d17f24e42362f4f1d0@1.1.1.1:5060 should be Call-ID: 3f31e1622a72b6d17f24e42362f4f1d0@2.2.2.2:5060 o=root 1093000903 1093000903 IN IP4 1.1.1.1 should be o=root 1093000903 1093000903 IN IP4 2.2.2.2 My kamailio.cfg can be found here: https://pastebin.com/6PKcRjPU These are the Asterisk boxes I want to originate calls from to Kamailio: [root@voip30 ~]# kamctl address show +-----+-----+----------+------+------+-----------+ | id | grp | ip_addr | mask | port | tag | +-----+-----+----------+------+------+-----------+ | 195 | 1 | 1.1.1.1 | 32 | 0 | voip20.sv | | 196 | 1 | 1.1.1.2 | 32 | 0 | voip21.sv | | 197 | 1 | 1.1.1.3 | 32 | 0 | voip22.sv | | 198 | 1 | 1.1.1.4 | 32 | 0 | voip23.sv | | 199 | 1 | 1.1.1.5 | 32 | 0 | voip24.sv | | 200 | 1 | 1.1.1.6 | 32 | 0 | voip25.sv | | 201 | 1 | 1.1.1.7 | 32 | 0 | voip26.sv | | 202 | 1 | 1.1.1.8 | 32 | 0 | voip27.sv | | 203 | 1 | 1.1.1.9 | 32 | 0 | voip28.sv | +-----+-----+----------+------+------+-----------+ This is the upstream carrier I want Kamailio to proxy calls to: [root@voip30 ~]# kamctl dispatcher show dispatcher gateways +----+-------+------------------+-------+-------+------------+------+ | id | setid | destination | flags | prio. | attrs | desc | +----+-------+------------------+-------+-------+------------+------+ | 12 | 1 | sip:3.3.3.3:5060 | 0 | 0 | weight=100 | | +----+-------+------------------+-------+-------+------------+------+ (output manually slightly modified to look properly over E-Mail) As you might have guessed I'm a Kamailio noob... and don't have the resources to learn it as fast as I must to avoid further packet loss. If there's anyone available who can help me to get this done today, optionally in exchange for money, I'd be grateful. Thank you! Markus

5 11

Multi-dimensional data in htable
by Ben Kaufman 22 Sep '23

22 Sep '23

What's the best way to store multi-dimensional data within an htable? For example, storing an avp stack: $avp(foo) = "first"; $avp(foo) = "second"; $sht(bar=>foo) = $avp(foo); The result of which is that only $avp(foo[0]) is stored in the htable: kamcmd htable.dump bar { entry: 2 size: 1 slot: { { name: bar value: second type: str } } } The htable documentation shows support for lists, but it doesn't make clear if this is really usable outside of loading from a database, and looks like it's short hand for managing/creating linked lists. The other option would be to simply serialize the data before storing it in the htable - which is fine, I just want to be sure I'm not overlooking a more convenient method. Regards, Kaufman

4 5

no corresponding socket found error
by David Escartín 22 Sep '23

22 Sep '23

Hello all we are seeing these kind of logs in a Debian GNU/Linux 11 using kamailio 5.5.6 Sep 21 17:41:13 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155702]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:164.152.22.248:5060) Sep 21 17:41:13 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155698]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:208.74.138.184:5060) Sep 21 17:41:13 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155695]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:208.74.138.181:5060) Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155693]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:38.102.250.60:5060) Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155707]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:87.1.1.27:5060) Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155707]: ERROR: tm [ut.h:302]: uri2dst2(): no corresponding socket for "87.1.1.27" af 2 Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155707]: ERROR: tm [t_fwd.c:470]: prepare_new_uac(): can't fwd to af 2, proto 1 (no corresponding listening socket) Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155697]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:208.74.138.184:5060) Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155694]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:192.40.216.97:5060) Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155694]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:208.74.138.180:5060) Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155714]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:87.1.1.27:5060) The kamailio instance we are using is receiving around 1500 calls per second in average when we do start seeing these errors more frequently In this instance we are using multihomed the listen address list is children=14 socket_workers=1 listen=udp:192.168.99.70:5081 listen=udp:192.168.99.81:5060 listen=udp:87.1.1.27:5060 listen=tcp:192.168.96.105:8095 listen=tcp:87.1.1.27:5060 tcp_children=6 port=5060 We use the first worker only to perform the OPTIONS requests from the dispatcher module. The sockets listen=udp:192.168.99.81:5060 listen=udp:87.1.1.27:5060 are used to communicate both A and B legs so when a message is received at 192.168.99.81:5060 we send it to 87.1.1.27:5060 and viceversa We were using $fs variable before doing the t_relay() function. This way is working, but when load increases, seems sometimes kamailio doesn't get the proper socket to forward the reply. I think the errors mainly are related to responses which are being forwarded, like if the function get_sock_info_list was not able to retrieve the listen interfaces we have tried to set in the onreply routes the commands set_recv_socket("udp:192.168.99.81:5060"); set_send_socket("udp:87.1.1.27:5060"); (when reply goes from private to public domain) and it seems it reduces the number of Sep 21 17:41:13 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155702]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:164.152.22.248:5060) Sep 21 17:41:13 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155698]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:208.74.138.184:5060) Sep 21 17:41:13 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155695]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:208.74.138.181:5060) Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155693]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:38.102.250.60:5060) errors But i honestly don't know why the Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155707]: ERROR: tm [ut.h:302]: uri2dst2(): no corresponding socket for "87.1.1.27" af 2 Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155707]: ERROR: tm [t_fwd.c:470]: prepare_new_uac(): can't fwd to af 2, proto 1 (no corresponding listening socket) appear We aldso tried to increase the kernel buffers rmem and wmem from 208KB (as we had by default) to 4MB Do you know a reason which could cause these logs to appear? Any setup that could mitigate them? thanks a lot and regards david escartin -- <http://www.sonoc.io/> David Escartín NOC engineer www.sonoc.io [image: LinkedIn] <https://www.linkedin.com/company/sonoc> [image: Twitter] <https://twitter.com/sonoc_> [image: Instagram] <https://www.instagram.com/sonoc.io/> This e-mail is for the exclusive use of its recipients and may contain business secrets or other confidential or privileged information. Any unauthorised use, copying, publication or distribution of this e-mail is strictly prohibited. If you are not the intended recipient, please inform us immediately by replying to this e-mail and delete it, including any attachments or copies on your system. In accordance with the GDPR (EU) 2016/679 and the LOPDGDD 3/2018, we inform you that this e-mail address and/or any other personal data you have provided us with will be treated by SONOC with absolute confidentiality and with the only purpose of providing you with the requested services, due to your condition as a client, supplier or because you have requested information from us at any time. These data will only be kept for as long as required to comply with legal obligations. You can exercise your rights at any time by sending an e-mail to: dataprotection(a)sonoc.io. <dataprotection(a)sonoc.io>

1 0

"no corresponding socket found" logs
by David Escartín 22 Sep '23

22 Sep '23

Hello all we are seeing these kind of logs in a Debian GNU/Linux 11 using kamailio 5.5.6 Sep 21 17:41:13 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155702]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:164.152.22.248:5060) Sep 21 17:41:13 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155698]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:208.74.138.184:5060) Sep 21 17:41:13 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155695]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:208.74.138.181:5060) Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155693]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:38.102.250.60:5060) Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155707]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:87.1.1.27:5060) Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155707]: ERROR: tm [ut.h:302]: uri2dst2(): no corresponding socket for "87.1.1.27" af 2 Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155707]: ERROR: tm [t_fwd.c:470]: prepare_new_uac(): can't fwd to af 2, proto 1 (no corresponding listening socket) Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155697]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:208.74.138.184:5060) Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155694]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:192.40.216.97:5060) Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155694]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:208.74.138.180:5060) Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155714]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:87.1.1.27:5060) The kamailio instance we are using is receiving around 1500 calls per second in average when we do start seeing these errors more frequently In this instance we are using multihomed the listen address list is children=14 socket_workers=1 listen=udp:192.168.99.70:5081 listen=udp:192.168.99.81:5060 listen=udp:87.1.1.27:5060 listen=tcp:192.168.96.105:8095 listen=tcp:87.1.1.27:5060 tcp_children=6 port=5060 We use the first worker only to perform the OPTIONS requests from the dispatcher module. The sockets listen=udp:192.168.99.81:5060 listen=udp:87.1.1.27:5060 are used to communicate both A and B legs so when a message is received at 192.168.99.81:5060 we send it to 87.1.1.27:5060 and viceversa We were using $fs variable before doing the t_relay() function. This way is working, but when load increases, seems sometimes kamailio doesn't get the proper socket to forward the reply. I think the errors mainly are related to responses which are being forwarded, like if the function get_sock_info_list was not able to retrieve the listen interfaces we have tried to set in the onreply routes the commands set_recv_socket("udp:192.168.99.81:5060"); set_send_socket("udp:87.1.1.27:5060"); (when reply goes from private to public domain) and it seems it reduces the number of Sep 21 17:41:13 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155702]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:164.152.22.248:5060) Sep 21 17:41:13 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155698]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:208.74.138.184:5060) Sep 21 17:41:13 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155695]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:208.74.138.181:5060) Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155693]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:38.102.250.60:5060) errors But i honestly don't know why the Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155707]: ERROR: tm [ut.h:302]: uri2dst2(): no corresponding socket for "87.1.1.27" af 2 Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155707]: ERROR: tm [t_fwd.c:470]: prepare_new_uac(): can't fwd to af 2, proto 1 (no corresponding listening socket) appear We aldso tried to increase the kernel buffers rmem and wmem from 208KB (as we had by default) to 4MB Do you know a reason which could cause these logs to appear? Any setup that could mitigate them? thanks a lot and regards david escartin -- <http://www.sonoc.io/> David Escartín NOC engineer www.sonoc.io [image: LinkedIn] <https://www.linkedin.com/company/sonoc> [image: Twitter] <https://twitter.com/sonoc_> [image: Instagram] <https://www.instagram.com/sonoc.io/> This e-mail is for the exclusive use of its recipients and may contain business secrets or other confidential or privileged information. Any unauthorised use, copying, publication or distribution of this e-mail is strictly prohibited. If you are not the intended recipient, please inform us immediately by replying to this e-mail and delete it, including any attachments or copies on your system. In accordance with the GDPR (EU) 2016/679 and the LOPDGDD 3/2018, we inform you that this e-mail address and/or any other personal data you have provided us with will be treated by SONOC with absolute confidentiality and with the only purpose of providing you with the requested services, due to your condition as a client, supplier or because you have requested information from us at any time. These data will only be kept for as long as required to comply with legal obligations. You can exercise your rights at any time by sending an e-mail to: dataprotection(a)sonoc.io. <dataprotection(a)sonoc.io>

1 0

Change in mailing list configuration related to DMARC spam filtering
by Henning Westerholt 22 Sep '23

22 Sep '23

Hello, due to some changes from certain cloud infrastructure provider related to spam filtering with DMARC, we need to change the list manager "mailman" configuration for the following lists: * sr-users * sr-user-es * sr-dev * business * sr-docs * kamailio-announce * the administrative mailing list The change will impact the "From" that is displayed in your email program. Without that change large e-mail providers (Gmail, Microsoft O365) will reject messages from a sender with certain strict DMARC policy. This is already affecting several people on the lists (for example with GitHub notice mails), but over time the problem will certainly increase. Regarding the technical change: We will munge the From: header so it doesn't contain the domain that triggers the DMARC rejection. Essentially, the Mailman list takes ownership of the message and injects its own address into the From: header. This can affect reply-to-sender, although we add the original From: address in the Reply-To: header (or sometimes the Cc: header) to reduce the impact of this. We plan to do this for all emails unconditionally, regardless of their sender DMARC policy, to have an identical behaviour for all users. Please refer to this [1] page for more details. For a general description of DMARC refer to this page [2]. This change should have not a big impact for you, but some users might need to adapt some mail filters. Therefore, we would like to gather feedback on that change from you. We expect that the most visible change is that It will be not possible anymore to just reply by e-mail to mails from GitHub and have them "automatically" added to the discussed issue. This feature was so far used rarely and only from a few people. We plan to implement this change by the end of this week, when its done it will be also shortly announced. Best regards, Henning Westerholt [1] https://wiki.list.org/DEV/DMARC [2] https://dmarc.org/overview/ -- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://gilawa.com<https://gilawa.com/>

1 1

RTP traffic through kamailio
by Shravan 22 Sep '23

22 Sep '23

2 1

insert_dlg_timer(): Trying to insert a bogus dlg
by Benoît Panizzon 22 Sep '23

22 Sep '23

Hi Team Could anyone point me in the direction where I could find out more what's going wrong and what could be the cause of messages like: Sep 22 07:32:29 dev-core02 kamailio[915066]: CRITICAL: dialog [dlg_timer.c:129]: insert_dlg_timer(): Trying to insert a bogus dlg tl=0x7f9617d967b0 tl->next=0x7f9618e11198 tl->prev=0x7f9617e20548 Sep 22 07:32:29 dev-core02 kamailio[915066]: CRITICAL: dialog [dlg_dmq.c:314]: dlg_dmq_handle_msg(): Unable to insert dlg timer 0x7f9617d96750 [1598:12168] Are the numbers in brackets [hash_id:hash_entry] ? -- 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 ______________________________________________________

1 0

Dialog: bogus event 2 in state 3
by Benoît Panizzon 21 Sep '23

21 Sep '23

Hi Team I'm still hunting dialog errors which cause my dialog counters to divert and stick around, basically exploding in my face now and then. I suppose they are DMQ related (maybe packet loss, maybe retransmissions, maybe generic overloading of the virtualized kamailio instances) causing issues with inserting dialog timers on the peer etc. So for the moment I'm running only one instance, no DMQ peer. What I still occasionally see are messages: INVITE]dialog [dlg_hash.c:1182]: next_state_dlg(): bogus event 2 in state 3 for dlg 0x7ff906294be8 [2482:872] with clid 'A8459C74@7f33ff47' and tags '7f33ff47+1+7d820120+89494caf' '3904288054-1882699775' I found an ancient post, confirming this to be an open bug in Kamailio 1.4 and race condition between the 200 OK reply to an INVITE and the ACK confirming the 200 OK. Someone attempted to backport a fix for opensips to kamailio. Indeed, I see this message occur occasionally after managing the 200 OK reply and routing the ACK. Does anyone know, if this is still a open bug with Kamailio 5.5? Or what else could be the cause of this message? -- 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 ______________________________________________________

1 0

Floating Point in variables and arithmetic
by Barry Flanagan 21 Sep '23

21 Sep '23

Hi I need to take in a priority (from 0 to 100, 0 being highest prio) and convert this into a Q value between 0 and 1.0 My idea was to simply do: q_value = 1 - ($var(priority)/100) However, it seems Kamailio only deals in integers in the config. A Previous post suggested using xavp vars, but this ends up the same result. Apart from doing a pseudo SQL query "SELECT 1 - (20/100)" is there any way within the config I can do such maths? Thanks -- -Barry Flanagan

2 8

uac_auth() in KEMI Python - Drop 401 sent to caller
by Marrold 21 Sep '23

21 Sep '23

Hi all, I'm attempting to use the uac module in KEMI (Python) to authenticate outbound requests. When the downstream replies with a 401 the proxy correctly re-sends the request with a Authorization header, but the 401 is also relayed to the caller. As far as I can tell I've converted the example to KEMI correctly, but no matter what I try the 401 is still sent to the caller. Any ideas? The config I'm using is below - The avps are set when the request is sent so aren't visible here. Thanks def ksr_failure_manage(self, msg): if self.ksr_route_natmanage(msg)==-255 : return 1 if KSR.tm.t_is_canceled()>0 : return 1 if KSR.tm.t_check_status("401|407") >0 : KSR.info(f"Got a 40X, should attempt authentication") if KSR.uac.uac_auth()>0: KSR.tm.t_relay() KSR.info (f"Dropping further replies") KSR.set_drop() exit() return 1

2 1

Handle the DNS SRV to manage failover
by Massimo Dal Sasso 20 Sep '23

20 Sep '23

I need to manage failover in the connection between SCSCF and AS. I need to understand how it is possible to configure Kamailio to handle the DNS SRV to manage failover for UAS transaction like REGISTER. I see that it works for UAC transaction like INVITE, but I am not able to configure Kamailio to work for UAS transaction. Thanks, Massimo ________________________________ Massimo Dal Sasso SW Developer massimo.dalsasso(a)ext.athonet.com [Athonet logo]<https://www.athonet.com/> the mobile core that works for you Athonet Italy Via Cà del Luogo 6/8 36050 Bolzano Vicentino Vicenza-Italy +39 0444 750045 This email and any attachments are confidential and intended solely for the use of the intended recipient. If you are not the named addressee, please be aware that you shall not distribute, copy, use or disclose this email. If you have received this email by error, please notify us immediately and delete this email from your system. Email transmission cannot be guaranteed to be secured or error-free or not to contain viruses. Athonet S.r.l. processes any personal data exchanged in email correspondence in accordance with EU Reg. 679/2016 (GDPR) - you may find here the privacy policy with information on such processing and your rights. Any views or opinions presented in this email are solely those of the sender and do not necessarily represent those of Athonet S.r.l.

1 0

Creating CDRs for Missed and failed calls
by Marrold 19 Sep '23

19 Sep '23

Hi all, I'm using the acc module along with postgres to generate CDRs. For connected calls the CDRs are created as expected, but in the scenario where a lookup() fails and Kamailio sends a stateless 404 there's no CDR logged. I'm setting the FLT_ACCMISSED and FLT_ACCFAILED flags in the initial request route, but perhaps I have a misunderstanding of how these work? Thanks Matthew

2 2

How to validate re-invites without challenging them?
by Benoit Panizzon 19 Sep '23

19 Sep '23

Hi List At the moment, we challenge every invite (and re-invite) to make sure the customer is authenticated. Now we have one kind of PBX, which never does not authenticate when we challenge a Re-Invite. According to the vendor of that PBX's RFC interpretation, answering a challenge to a re-invite is optional. If that is ignored by the PBX, then the existing established dialog shall not end. Unfortunately this causes the session timer to run out. I am therefore wondering, if there is a safe way not to challenge re-invites. A Re-Invite contains a To-Tag. So I could bypass authentication on presence of a to-Tag. But then, how do I prevent a customer to just set a spoofed To-Tag to circumvent authentication? Is there a feasible way? Mit freundlichen Grüssen -Benoît Panizzon- -- 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 ______________________________________________________

4 3

DBTEXT + TOPOS
by James Lipski 19 Sep '23

19 Sep '23

Hello, I'm doing an experiment with the DB_TEXT module. I have the topos module enabled; however it doesn't seem to function properly with db_text. Going over my syslog I see the following, and not quite understanding why it's failing to insert the row; I was hoping someone can point me in the right direction. This is a fresh install/ fresh DB. Thank you. Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:227]: dbt_load_file(): column[5] is actually STRING! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:195]: dbt_load_file(): column[6] is STR! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:227]: dbt_load_file(): column[6] is actually STRING! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:195]: dbt_load_file(): column[7] is STR! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:227]: dbt_load_file(): column[7] is actually STRING! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:200]: dbt_load_file(): column[8] is INT! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:195]: dbt_load_file(): column[9] is STR! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:227]: dbt_load_file(): column[9] is actually STRING! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:239]: dbt_load_file(): column[9] NULL flag set! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:195]: dbt_load_file(): column[10] is STR! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:227]: dbt_load_file(): column[10] is actually STRING! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:195]: dbt_load_file(): column[11] is STR! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:227]: dbt_load_file(): column[11] is actually STRING! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:239]: dbt_load_file(): column[11] NULL flag set! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:195]: dbt_load_file(): column[12] is STR! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:227]: dbt_load_file(): column[12] is actually STRING! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:239]: dbt_load_file(): column[12] NULL flag set! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:195]: dbt_load_file(): column[13] is STR! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:227]: dbt_load_file(): column[13] is actually STRING! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:239]: dbt_load_file(): column[13] NULL flag set! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:195]: dbt_load_file(): column[14] is STR! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:227]: dbt_load_file(): column[14] is actually STRING! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:195]: dbt_load_file(): column[15] is STR! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:227]: dbt_load_file(): column[15] is actually STRING! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:195]: dbt_load_file(): column[16] is STR! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:227]: dbt_load_file(): column[16] is actually STRING! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:195]: dbt_load_file(): column[17] is STR! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:227]: dbt_load_file(): column[17] is actually STRING! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:195]: dbt_load_file(): column[18] is STR! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:227]: dbt_load_file(): column[18] is actually STRING! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:195]: dbt_load_file(): column[19] is STR! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:227]: dbt_load_file(): column[19] is actually STRING! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:195]: dbt_load_file(): column[20] is STR! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:227]: dbt_load_file(): column[20] is actually STRING! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:195]: dbt_load_file(): column[21] is STR! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:227]: dbt_load_file(): column[21] is actually STRING! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:195]: dbt_load_file(): column[22] is STR! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:227]: dbt_load_file(): column[22] is actually STRING! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:195]: dbt_load_file(): column[23] is STR! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:227]: dbt_load_file(): column[23] is actually STRING! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:195]: dbt_load_file(): column[24] is STR! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:227]: dbt_load_file(): column[24] is actually STRING! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:195]: dbt_load_file(): column[25] is STR! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_file.c:227]: dbt_load_file(): column[25] is actually STRING! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:119]: db_new_result(): allocate 56 bytes for result set at 0x7fd70c7f4c40 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:156]: db_allocate_columns(): allocate 160 bytes for result names at 0x7fd70cacabf8 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:167]: db_allocate_columns(): allocate 80 bytes for result types at 0x7fd70c7f4ce0 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_api.c:73]: dbt_get_columns(): allocate 16 bytes for RES_NAMES[0] at 0x7fd70cacad00 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_api.c:73]: dbt_get_columns(): allocate 16 bytes for RES_NAMES[1] at 0x7fd70cacad78 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_api.c:73]: dbt_get_columns(): allocate 16 bytes for RES_NAMES[2] at 0x7fd70cacadf0 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_api.c:73]: dbt_get_columns(): allocate 16 bytes for RES_NAMES[3] at 0x7fd70cacae68 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_api.c:73]: dbt_get_columns(): allocate 16 bytes for RES_NAMES[4] at 0x7fd70cacaee0 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_api.c:73]: dbt_get_columns(): allocate 16 bytes for RES_NAMES[5] at 0x7fd70cacaf58 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_api.c:73]: dbt_get_columns(): allocate 16 bytes for RES_NAMES[6] at 0x7fd70cacafd0 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_api.c:73]: dbt_get_columns(): allocate 16 bytes for RES_NAMES[7] at 0x7fd70cacb048 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_api.c:73]: dbt_get_columns(): allocate 16 bytes for RES_NAMES[8] at 0x7fd70cacb0c0 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_api.c:73]: dbt_get_columns(): allocate 16 bytes for RES_NAMES[9] at 0x7fd70cacb138 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_api.c:73]: dbt_get_columns(): allocate 16 bytes for RES_NAMES[10] at 0x7fd70cacb1b0 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_api.c:73]: dbt_get_columns(): allocate 16 bytes for RES_NAMES[11] at 0x7fd70cacb228 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_api.c:73]: dbt_get_columns(): allocate 16 bytes for RES_NAMES[12] at 0x7fd70cacb2a0 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_api.c:73]: dbt_get_columns(): allocate 16 bytes for RES_NAMES[13] at 0x7fd70cacb318 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_api.c:73]: dbt_get_columns(): allocate 16 bytes for RES_NAMES[14] at 0x7fd70c7c2368 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_api.c:73]: dbt_get_columns(): allocate 16 bytes for RES_NAMES[15] at 0x7fd70c7c23e0 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_api.c:73]: dbt_get_columns(): allocate 16 bytes for RES_NAMES[16] at 0x7fd70c7c2458 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_api.c:73]: dbt_get_columns(): allocate 16 bytes for RES_NAMES[17] at 0x7fd70c7c24d0 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_api.c:73]: dbt_get_columns(): allocate 16 bytes for RES_NAMES[18] at 0x7fd70c7c2548 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_api.c:73]: dbt_get_columns(): allocate 16 bytes for RES_NAMES[19] at 0x7fd70c7c25c0 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} topos [tps_storage.c:1244]: tps_db_load_branch(): no stored record for <z9hG4bK22d5.7fedda308f2b91b2c0c83021c6adfaec.0> Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:79]: db_free_columns(): freeing 20 columns Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:83]: db_free_columns(): freeing RES_NAMES[0] at 0x7fd70cacad00 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:83]: db_free_columns(): freeing RES_NAMES[1] at 0x7fd70cacad78 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:83]: db_free_columns(): freeing RES_NAMES[2] at 0x7fd70cacadf0 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:83]: db_free_columns(): freeing RES_NAMES[3] at 0x7fd70cacae68 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:83]: db_free_columns(): freeing RES_NAMES[4] at 0x7fd70cacaee0 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:83]: db_free_columns(): freeing RES_NAMES[5] at 0x7fd70cacaf58 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:83]: db_free_columns(): freeing RES_NAMES[6] at 0x7fd70cacafd0 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:83]: db_free_columns(): freeing RES_NAMES[7] at 0x7fd70cacb048 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:83]: db_free_columns(): freeing RES_NAMES[8] at 0x7fd70cacb0c0 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:83]: db_free_columns(): freeing RES_NAMES[9] at 0x7fd70cacb138 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:83]: db_free_columns(): freeing RES_NAMES[10] at 0x7fd70cacb1b0 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:83]: db_free_columns(): freeing RES_NAMES[11] at 0x7fd70cacb228 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:83]: db_free_columns(): freeing RES_NAMES[12] at 0x7fd70cacb2a0 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:83]: db_free_columns(): freeing RES_NAMES[13] at 0x7fd70cacb318 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:83]: db_free_columns(): freeing RES_NAMES[14] at 0x7fd70c7c2368 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:83]: db_free_columns(): freeing RES_NAMES[15] at 0x7fd70c7c23e0 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:83]: db_free_columns(): freeing RES_NAMES[16] at 0x7fd70c7c2458 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:83]: db_free_columns(): freeing RES_NAMES[17] at 0x7fd70c7c24d0 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:83]: db_free_columns(): freeing RES_NAMES[18] at 0x7fd70c7c2548 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:83]: db_free_columns(): freeing RES_NAMES[19] at 0x7fd70c7c25c0 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:96]: db_free_columns(): freeing result names at 0x7fd70cacabf8 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:101]: db_free_columns(): freeing result types at 0x7fd70c7f4ce0 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [db_res.c:138]: db_free_result(): freeing result set at 0x7fd70c7f4c40 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} <core> [core/utils/sruid.c:214]: sruid_nextx(): new sruid is [tpsh-6508d6d9-14577b-1] (1 / 22) Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} topos [tps_storage.c:451]: tps_storage_fill_contact(): td->bs <sip:leg_a@host1.sip-example.com;ccr=btpsh-6508d6d9-14577b-1> Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} topos [tps_storage.c:454]: tps_storage_fill_contact(): td->as <sip:leg_b@host1.sip-example.com;ccr=atpsh-6508d6d9-14577b-1> Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} topos [tps_storage.c:552]: tps_storage_link_msg(): downstream: yes - acontact: [sip:133@172.16.1.169:33880;line=g2l0pi9q;alias=72.255.5255.255~33880~1] - bcontact: [] Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: DEBUG: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_lib.c:285]: dbt_db_get_table(): cache or mtime succeeded for [topos_t] Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: ERROR: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_tb.c:468]: dbt_table_check_row(): null value not allowed - field 2 Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: ERROR: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} db_text [dbt_base.c:525]: dbt_insert(): cannot insert the new row!! Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: ERROR: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} topos [tps_storage.c:1004]: tps_db_insert_branch(): failed to store message Sep 18 23:01:59 localhost /opt/kamailio/sbin/kamailio[1333115]: ERROR: {1 2 INVITE e0d608658658-eqkmzxcvr8vd} topos [tps_storage.c:615]: tps_storage_record(): failed to store

2 1

Using maxload in dispatcher list
by Calvin E. 19 Sep '23

19 Sep '23

Should maxload work with all dispatcher algorithms? I'm trying to add a test node to dispatcher.list with maxload=1 and it is getting a lot more than one concurrent call. The test node is the last one in the list. 16 sip:10.x.x.43:5070 0 0 duid=duid01;user=+10007787878;sockname=floating-internal-ip;maxload=0 16 sip:10.x.x.44:5070 0 0 duid=duid02;user=+10007787878;sockname=floating-internal-ip;maxload=0 16 sip:10.x.x.47:5070 0 0 duid=duid03;user=+10007787878;sockname=floating-internal-ip;maxload=0 16 sip:10.x.x.48:5070 0 0 duid=duid04;user=+10007787878;sockname=floating-internal-ip;maxload=0 16 sip:10.x.x.56:5070 0 0 duid=duid05;user=+10007787878;sockname=floating-internal-ip;maxload=0 16 sip:10.x.x.57:5070 0 0 duid=duid06;user=+10007787878;sockname=floating-internal-ip;maxload=0 16 sip:10.x.x.58:5070 0 0 duid=duid07;user=+10007787878;sockname=floating-internal-ip;maxload=0 16 sip:10.x.x.x:5070 0 0 duid=duid08;user=+10007787878;sockname=floating-internal-ip;maxload=0 16 sip:10.x.x.104:5060 0 0 duid=duid09;user=+10007787878;sockname=floating-internal-ip;maxload=1

2 1

SIP Registartion Sharing between two kamailio
by Lewis Hutchinson 19 Sep '23

19 Sep '23

On the understanding that you have checked the INVITE to 802 and it looks OK but not getting there then I would probably start digging on the networking side of it. You have said no Firewalls however there may be Security Groups and VPC bits going on in AWS. It's hard to say as the level of detail is not in the ticket. Can 802 call 801? What happens if you log 802 into Kamailio 1 and 801 into Kamailio 2 and call either way. Lewis Mission Labs Limited is registered in England, company number 10040088. Trading Office: The Old Milk Depot, Bacup Rd, Rossendale, BB4 7FE. Registered office: The Scalpel, 18th Floor 52 Lime Street, London, EC3M 7AF. Email confidentiality notice: This message is private and confidential. If you have received this message in error, please notify us and remove it from your system. Please consider the environment before you print this email.

1 0

SIP Registartion Sharing between two kamailio using AWS NLB having issue.
by pra.savaliya1987＠gmail.com 19 Sep '23

19 Sep '23

Hello All, I have two kamailio servers and shared the database between two kamailio. version: kamailio 5.5.6 (x86_64/linux) . I have used AWS network load balancer. domain pointed to AWS network load balancer IP address,AWS Network Load Balancer (NLB) to distribute incoming requests to kamailio servers. I have two users in same domain(dev.domain.com). 1. 801(a)dev.domain.com --> Registered on kamailio 1 2. 802(a)dev.domain.com --> Registered on kamailio 2 Two call invites have been received, one for extension 801 and another for extension 802. These call invites will reach kamailio Server 1. kamailio Lookup the users and send call invite to both the devices. 801 registered user will get a ring because it is registered from kamailio 1. but 802 will not get a ring because it's register from kamailio 2. I can able see kamailio send call invite to the both registered devices using sngrep. but it not reach to the 802 device. there i no firewalls so far. also i have took 802 Registered device IP phone logs but there is no Call Invite reach to the 802 device. I have also tried by using "dmq" and "dmq_usrloc" module but the same behavior. what could be the reason? It will be appreciable if anyone help to resolve the issue. Thank you in advance! Pratik Svaliya.

2 1

Increase MAX_BRANCHES_LIMIT
by Lars Jansson 18 Sep '23

18 Sep '23

Hi, I am building a configuration script where for some traffic flows parallel forking will be needed, and in this case I need to go beyond the default max limit of the max amount of branches. Apart from this specific case the traffic load that kamailio will need to handle is very low, let's say just one second here and there with up to 5 concurrent calls at most. This limit is as far as I understand set here: usr/local/src/kamailio-5.6/kamailio/src/core/config.h And the default limit is: #define MAX_BRANCHES_LIMIT 32 /*!< limit of maximum number of branches per transaction */ Here are the questions I have related to this: 1) If I increase the value of this constant in config.h, how high is it reasonable to set this value and still have a stable system? 2) If I increase MAX_BRANCHES_LIMIT beyond 32, are there also other parameters that needs to be changed for the system to be able to cope, and if so whichparameters? Regards, Lars

4 9

. Re: Multiple headers in http client request
by Lewis Hutchinson 18 Sep '23

18 Sep '23

Hi Matteo I have used http_async_client and http_client in both Native & KEMI to good affect for handling SUBSCRIBE & NOTIFY flows however did have a few issues with formatting which took a bit of work to get right. Just to note, something you may want to test. Initially I set about my task using http client within Python (aiohttp and ayncio) and stepped in and out of it from various points in the logic depending on the config I was using at the time. Under load this proved to be a bottle neck and failed load testing. The best options under load were using http_async_client or http_client modules which offered significantly better performance. In the end we took a different approach of using Kafka Module as that had even better performance but that was a decision taken our side not through any fault of the http_async_client or http_client modules Lewis Mission Labs Limited is registered in England, company number 10040088. Trading Office: The Old Milk Depot, Bacup Rd, Rossendale, BB4 7FE. Registered office: The Scalpel, 18th Floor 52 Lime Street, London, EC3M 7AF. Email confidentiality notice: This message is private and confidential. If you have received this message in error, please notify us and remove it from your system. Please consider the environment before you print this email.

1 0

Add Header to reply on failure_route
by Benoit Panizzon 18 Sep '23

18 Sep '23

Hi List I'm attempting to add a header to a reply message on failure. Situation: Registrar => Core => (dispatcher list) => Various IC I would like to know on the registrar, which of the dispatcher groups failed. What I attempted sofar: failure_route[DISPATCH_FAILURE] { append_to_reply("X-RR: (append reply) Final Dispatch Failure $avp(dispgroup):$avp(trunkname)\r\n"); append_hf("X-RR: (append hf) Final Dispatch Failure $avp(dispgroup):$avp(trunkname)\r\n"); $avp(rstatus) = t_get_status_code(); $avp(rtext) = $T_rpl($rr); $avp(rtext) = "REMOTE REPLY: " + $T_rpl($rr); t_send_reply("$avp(rstatus)", "$avp(rtext)"); } I only get status text is getting through to my reply. I would much prefer to add a header which I could then extract on the registrar. Am I missing something which could prevent addition of a header in a reply? Mit freundlichen Grüssen -Benoît Panizzon- -- 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 ______________________________________________________

1 1

Multiple headers in http client request
by Matteo Brancaleoni 17 Sep '23

17 Sep '23

Hello all :) I'm struggling to add two headers to an http client request, but cannot find a proper way to do it. The headers are Authorization and Content-Type. The first try is with http_client module, beside undocumented, is possible to add multiple headers separating them with "\r\n". What I see is the correct Authorization header, and two Content-Type headers, one with my content type the other with x-www-form-urlencoded, which no one sets ? Second try is with http_async_client which supports multiple headers, but since I'm calling it from an xhttp event route, there's no transaction and request cannot be suspended, so I cannot get results before sending out xhttp response... Any hint? br, Mat

2 3

Orphan Dialog Vars: Probable cause found!
by Benoît Panizzon 15 Sep '23

15 Sep '23

Hi List I wonder if some of the devs could look at the dialog code and maybe confirm my observation of this supposed Bug in Kamailio 5.6 Situation: Two Kamailio, dialog counters synced via DMQ and each node using a local DB as dialog backend. Goal is to count channel usage per customer. modparam("dialog", "db_mode", 1 ) modparam("dialog", "enable_dmq", 1) modparam("dialog", "h_id_start", -1) # Use server_id modparam("dialog", "h_id_step", 2) modparam("dialog", "profiles_with_value", "custcallcounter") If 'JohnDoe' is involved in a call, I do: set_dlg_profile("custcallcounter","JohnDoe"); To check how many calls are busy by JohnDoe I do: get_profile_size("custcallcounter","JohnDoe","$var(channel_use)"); Picture this situation: JohnDoe is initiating a first call via Node1: Node1 created the dialogue and variables, writes them to the database and replicates the dialog vars to Node2 => IN MEMORY Nothing about the running dialog is being written to the Database on Node2, but get_profile_size returns the count on Node2. So while the first call aka dialog is running via Node1, JohnDoe is initiating a second call, this time via Node2. Node2 creates the dialog and writes this to the database. Then the profile with Name 'JohnDoe' is INCREASED on Node2. This is when I suddenly find the dialog_vars on the Node2 database containing information about the dialog started on Node1. So I guess writing to a dialog counter triggers the dialog_vars being written to the Database. When JohnDoe is ending it's first call, then the dialog and dialog_vars are cleaned out of the database on Node1, but NOT on Node2 What I fear happens next: They dialog_vars remaining on the Database of Node 2 accumulate more and more, making the database slower. When a call happens to re use the same hash id and entry, things start going really badly. Could I be right? -- 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 ______________________________________________________

1 0

Set a License for Kamailio
by Ali Taher 15 Sep '23

15 Sep '23

Hello, Is it possible to put a kind of license for Kamailio, in a way that it works for 1 week for example, and after that it will not process new requests? Regards,

3 4

client sending message and refresh register normal. But KSR.uac.uac_req_send() ERROR
by riffs＠sina.cn 14 Sep '23

14 Sep '23

The client uses the TLS protocol registered and TCP Connection established . There is a problem now, sending message KSR.uac.uac_req_send() from the kamilio server to client failed sometimes,and the error is as follows： “2023-09-04T17:22:01.515763+08:00 (3429) ERROR: tm [../../core/forward.h:292]: msg_send_buffer(): tcp_send failed 2023-09-04T17:22:01.515763+08:00 (3429) ERROR: tm [uac.c:678]: send_prepared_request_impl(): Attempt to send to precreated request failed ”. meantime, the client sending message to Kamalio server succeded, and the register status and tcp connection is normal. After 30s, obtained the $uac_req(evcode) from the event_route[uac:reply] is 408.After this error appears, all the messages sent to this client are 408. " 2023-08-29T03:48:43.738152+08:00 (3349) NOTICE: <script>: ===uac reply received, callid = 0B6ECB534AE24281AED9BBBC56B140A6`yangwang2`1693252093, code is: 408 2023-08-29T03:48:43.738825+08:00 (3349) NOTICE: <script>: ===uac reply received, callid = 0B6ECB534AE24281AED9BBBC56B140A6`yangwang2`1693252093, code is: 408 " But from other information, the TCP connection is normal. Because from Kamailio to querying this user's Location, it has not changed all day. The client sends messages is also normal. That is, the user's registration and sending messages can receive 200 OK. We use netstat commands to view the user's TCP connection information on the client and server, and the connection status is also normal.The status of the corresponding port of the TCP connection is ESTABLISHED. client: netstat -ano | findstr 49957 "172. 17. 47.125:49957 XXX.96.XXX.XXX:5061 ESTABLISHED 10516" server: "tcp 0 0 10.11.xx.xx:5061 xxx.xxx.xxx.xxx:49957 ESTABLISHED 3467/kamailio" This client is normal after logging in, and the problem that occurs after a period of use (maybe some hours), and once it occurs, it fails until the user creates a new connection and logs back in. Not all users will appear. Why is this the case? The socket connection is fine, but uac_req_send () get an ERROR? I found a problem from the log file. Is it caused by duplicate callids pushed to the same user at the same second? Looking forward to your answer, thank you very much Script information that may be required kamailio.cfg ： tm mode # ----- tm params ----- # auto-discard branches from previous serial forking leg modparam("tm", "failure_reply_mode", 3) # default retransmission timeout: 30sec modparam("tm", "fr_timer", 30000) # default invite retransmission timeout after 1xx: 120sec modparam("tm", "fr_inv_timer", 120000) modparam("tm", "auto_inv_100", 1) kamalio.lua uac_req_send() " --uac_req_send KSR.pv.sets("$uac_req(hdrs)", hdrs) KSR.pv.sets("$uac_req(method)", "MESSAGE") KSR.pv.sets("$uac_req(ruri)", "sip:" .. to .. "@" .. KAM_DOMAIN) KSR.pv.sets("$uac_req(furi)", "sip:" .. from .. "@" .. KAM_DOMAIN) KSR.pv.sets("$uac_req(turi)", "sip:" .. to .. "@" .. KAM_DOMAIN) KSR.pv.seti("$uac_req(evroute)", 1) KSR.pv.sets("$uac_req(body)", content) local ouri = (row.received ~= "" and row.received) or row.contact KSR.pv.sets("$uac_req(ouri)", ouri) local callid = rows[i].clientid .. "`" .. rows[i].username .. "`" .. os.time() KSR.pv.sets("$uac_req(callid)", callid) KSR.uac.uac_req_send()

1 0

MS Teams and ca_list.pem
by Social Boh 13 Sep '23

13 Sep '23

Hello, I'd like to know where i can download/search ca_list.pem file to use in tls.cfg configuration file for MS TEAMS. Without the file: ERROR: tls [tls_util.h:50]: tls_err_ret(): TLS write:error:0A000086:SSL routines::certificate verify failed (sni: unknown) ERROR: tls [tls_server.c:1336]: tls_h_read_f(): src addr: 52.114.76.76:506 ERROR: tls [tls_server.c:1339]: tls_h_read_f(): dst addr: KamailioIP:0 ERROR: <core> [core/tcp_read.c:1476]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7fb6a23ba4f8 r: 0x7fb6a23ba620 (-1) Thank you Regards -- --- I'm SoCIaL, MayBe

1 0

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