- sr-users - kamailio.org

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

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