sr-users October 2020

sr-users@lists.kamailio.org

66 participants
83 discussions

by Daniel-Constantin Mierla

Hello, I am planning to release Kamailio v5.3.7 sometime next week, likely on Monday or Tuesday, this being the usual prior notice for heads up to identify issues not reported yet on bug tracker as well as the commits you are aware of that were not backported yet. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

3 years, 5 months

Confusion about TCP worker ports

by Noah Mehl

Hey all, I’m a little stuck on an implementation of a set of dispatchers via TCP. There are some oddities about the behavior of the TCP source port of the Kamailio tcp worker/s, and maybe this is expected, but it doesn’t seem valid. For instance, I have a dispatcher: "RECORDS": [{ "SET": { "ID": 1, "TARGETS": [{ "DEST": { "URI": “sip:2.2.2.2:5060;transport=tcp", "FLAGS": "AP", "PRIORITY": 5 } }] } }] But when Kamailio sends an OPTIONS keep alive, the source port for the worker is 33940, and not 5060 (which is the TCP listen port), as received by Freeswitch: recv 447 bytes from tcp/[1.1.1.1]:33940 at 18:58:24.958720: ------------------------------------------------------------------------ OPTIONS sip:2.2.2.2:5060;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 1.1.1.1;branch=z9hG4bK1525.80a9e442000000000000000000000000.0 To: <sip:2.2.2.2:5060;transport=tcp> From: <sip:inbound-kamailio-01>;tag=3c52ba62ee4c4621b9660728159919d3-cda8066f CSeq: 10 OPTIONS Call-ID: 3aa18693487268dc-2790(a)1.1.1.1 Max-Forwards: 70 Content-Length: 0 User-Agent: kamailio (5.4.2 (x86_64/linux)) ------------------------------------------------------------------------ Also, I get weird debug messages when this tcp worker is spun up (specifically about Resource temporarily unavailable): 11(2790) DEBUG: dispatcher [dispatch.c:3340]: ds_ping_result_helper(): probe all, mode DS_PROBE_ALL 11(2790) DEBUG: dispatcher [dispatch.c:3383]: ds_ping_set(): probing set #1, URI sip:2.2.2.2:5060;transport=tcp 11(2790) DEBUG: dispatcher [dispatch.c:3414]: ds_ping_set(): Default ping_from: sip:inbound-kamailio-01 11(2790) DEBUG: dispatcher [dispatch.c:3424]: ds_ping_set(): Default outbound proxy: 11(2790) DEBUG: tm [uac.c:450]: t_uac_prepare(): next_hop=<sip:2.2.2.2:5060;transport=tcp> 11(2790) DEBUG: tm [uac.c:158]: dlg2hash(): hashid 21073 11(2790) DEBUG: <core> [core/tcp_main.c:1993]: tcp_send(): no open tcp connection found, opening new one 11(2790) DEBUG: <core> [core/ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: 2.2.2.2 11(2790) DEBUG: <core> [core/tcp_main.c:1175]: tcpconn_new(): on port 5060, type 2, socket -1 11(2790) DEBUG: <core> [core/tcp_main.c:1494]: tcpconn_add(): hashes: 2712:0:0, 1 11(2790) DEBUG: <core> [core/tcp_main.c:2886]: tcpconn_1st_send(): pending write on new connection 0x7f24e64c1e18 sock 8 (-1/447 bytes written) (err: 11 - Resource temporarily unavailable) 11(2790) DEBUG: tm [uac.c:678]: send_prepared_request_impl(): uac: 0x7f24e65285a8 branch: 0 to 2.2.2.2:5060 11(2790) DEBUG: <core> [core/onsend.c:50]: run_onsend(): required parameters are not available - ignoring 27(2806) DEBUG: <core> [core/tcp_main.c:3792]: handle_ser_child(): read response= 7f24e64c1e18, 5, fd 46 from 11 (2790) 27(2806) DEBUG: <core> [core/io_wait.h:375]: io_watch_add(): DBG: io_watch_add(0x56490f0f8060, 46, 2, 0x7f24e64c1e18), fd_no=37 27(2806) DEBUG: <core> [core/io_wait.h:782]: io_watch_chg(): DBG: io_watch_chg (0x56490f0f8060, 46, 0x1, 0xffffffff) fd_no=38 called 27(2806) DEBUG: <core> [core/io_wait.h:600]: io_watch_del(): DBG: io_watch_del (0x56490f0f8060, 46, -1, 0x0) fd_no=38 called 27(2806) DEBUG: <core> [core/tcp_main.c:4457]: handle_tcpconn_ev(): sending to child, events 1 27(2806) DEBUG: <core> [core/tcp_main.c:4127]: send2child(): selected tcp worker idx:0 proc:19 pid:2798 for activity on [tcp:1.1.1.1:5060], 0x7f24e64c1e18 19(2798) DEBUG: <core> [core/tcp_read.c:1749]: handle_io(): received n=8 con=0x7f24e64c1e18, fd=8 19(2798) DEBUG: <core> [core/tcp_read.c:1548]: tcp_read_req(): content-length=0 19(2798) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): SIP Reply (status): 19(2798) DEBUG: <core> [core/parser/msg_parser.c:622]: parse_msg(): version: <SIP/2.0> 19(2798) DEBUG: <core> [core/parser/msg_parser.c:624]: parse_msg(): status: <200> 19(2798) DEBUG: <core> [core/parser/msg_parser.c:626]: parse_msg(): reason: <OK> 19(2798) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK1525.80a9e442000000000000000000000000.0>; state=6 19(2798) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 235, <rport> = <33940>; state=16 19(2798) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 19(2798) DEBUG: <core> [core/parser/msg_parser.c:498]: parse_headers(): Via found, flags=2 19(2798) DEBUG: <core> [core/parser/msg_parser.c:500]: parse_headers(): this is the first via 19(2798) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=1mB9HryQ8ZBFc 19(2798) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 19(2798) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [59]; uri=[sip:2.2.2.2:5060;transport=tcp] 19(2798) DEBUG: <core> [core/parser/msg_parser.c:174]: get_hdr_field(): to body (39)[<sip:2.2.2.2:5060;transport=tcp>], to tag (13)[1mB9HryQ8ZBFc] 19(2798) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <10> <OPTIONS> 19(2798) DEBUG: <core> [core/receive.c:319]: receive_msg(): --- received sip message - reply - call-id: [3aa18693487268dc-2790(a)1.1.1.1] - cseq: [10 OPTIONS] 19(2798) DEBUG: <core> [core/parser/msg_parser.c:185]: get_hdr_field(): content_length=0 19(2798) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header Are these SIP messages expected to come from other ports than the listen port (5060 in this case)? Also, if the worker source port is not 5060, shouldn’t the SIP message get updated with the correct port? In the case of OPTIONS, Freeswitch is replying correctly to the source port: 33940. However, in the case of an in dialog BYE, Freeswitch is NOT replying to the source port of the Kamailio messages, but only to port 5060. Here is an example (relayed from web sockets to freeswitch over TCP) INVITE (as received from Freeswitch): recv 1481 bytes from tcp/[1.1.1.1]:33940 at 16:56:47.920698: ------------------------------------------------------------------------ INVITE sip:991012@sip.domain <sip:991012@sip.domain>.com SIP/2.0 Record-Route: <sip:1.1.1.1;transport=tcp;r2=on;lr;nat=yes> Record-Route: <sip:1.1.1.1:5061;transport=tls;r2=on;lr;nat=yes> Via: SIP/2.0/TCP 1.1.1.1;branch=z9hG4bKd408.3f53e940ccb20c1033df4b3a8ebd8a34.0;i=1 Via: SIP/2.0/TLS 172.22.199.110:55304;received=5.5.5.5;rport=39518;branch=z9hG4bKPj5Css6JomCt9Cli2cCINbXi4FbPM5wewG;alias Max-Forwards: 69 From: "Noah Mehl" <sip:5135555555@inbound-jail>;tag=s3i3y2tiOCgnUId5TD4Vp0UChf9GyEy9 To: <sip:991012@inbound-jail> Contact: <sip:74895612@172.22.199.110:54887;transport=tls;alias=5.5.5.5~39518~3> Call-ID: 5aoRBMBHahxqSLzrIpFnlfRz.UcGsmfq CSeq: 27271 INVITE Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, REFER Supported: replaces, norefersub, gruu User-Agent: Blink Pro 4.6.0 (MacOSX) Content-Type: application/sdp Content-Length: 528 v=0 o=- 3812979407 3812979407 IN IP4 5.5.5.5 s=Blink Pro 4.6.0 (MacOSX) t=0 0 m=audio 50016 RTP/SAVP 113 0 101 c=IN IP4 5.5.5.5 a=rtcp:50017 a=rtpmap:113 opus/48000/2 a=fmtp:113 useinbandfec=1 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:UhHq6hth9HqALmiJ3AEeoGkixObBzkLURG60wJKT a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:VKYaSCVwgvXCPaRvudTrgLORhWmOA7wyDJVeGjcu a=sendrecv a=oldmediaip:172.22.199.110 a=oldmediaip:172.22.199.110 ------------------------------------------------------------------------ This doesn’t seem valid, as the top Via doesn’t have a port specified? For reference, just rebuilt form the 5.4 branch today: commit 62dff5b8b157236cae7defe64291a6e4a8ae27b5 (upstream/5.4) Author: Kamailio Dev <kamailio.dev(a)kamailio.org> Date: Wed Oct 28 20:16:28 2020 +0100 modules: readme files regenerated - modules ... [skip ci] Thanks! ~Noah

3 years, 5 months

Double port in TO header

by David Villasmil

Hello guys, This happened to me a long time ago but i totally forgot the reason. I using a simple dispatcher, and when relaying out to the destination, kamailio is adding an additional :5060 port to the To header: To: <sip:910609738@172.31.6.1:5080:5060> The Destination is actually 172.16.6.1:5080, i don't know why Kamailio is adding that :5060 The dispatcher is if (!ds_select_dst($var(dispatcher_outbound), "4")) { xlog("[DISPATCH]: ds_select_dst FAILED!\n"); send_reply("404", "No destination"); exit; } else { xlog("[DISPATCH]: ds_select_dst was succesful\n"); } xlog("L_DBG", "[DISPATCH]: going to <$ru> via <$du>\n"); t_on_failure("RTF_DISPATCH"); route(RELAY); Any ideas? I totally forgot... and it's late, i guess... Thanks! David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

3 years, 5 months

Re: [SR-Users] Building db_postgres with PostgreSQL headers and libs in non-standard location

by Chaigneau, Nicolas

Perfect, that's what I was looking for. :) Thanks! > This is what I have always done: > > # export PATH=$PATH:/usr/pgsql-${MAJOR_VER}/bin > # cd src/modules/db_postgres > # make install > > The `pg_config` utility in /usr/pgsql-${MAJOR_VER}/bin ensures that the proper header include path is supplied. > > -- Alex This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

3 years, 5 months

Building db_postgres with PostgreSQL headers and libs in non-standard location

by Chaigneau, Nicolas

Hello, I'd like to build Kamailio module db_postgres, with the PostgreSQL headers and libs in a non-standard location. I'm trying to figure out how to do that, if it's possible, without having to edit db_postgres/Makefile. I see in the Makefile that it's trying to find the files relative to $(LOCALBASE): # use standard know paths # libpq-fe.h locations DEFS +=-I$(LOCALBASE)/include -I$(LOCALBASE)/pgsql/include \ -I$(SYSBASE)/include/pgsql -I$(SYSBASE)/include/postgresql \ -I$(SYSBASE)/include/postgresql/8.0 LIBS +=-L$(LOCALBASE)/lib -L$(LOCALBASE)/pgsql/lib \ -L$(LOCALBASE)/lib/pgsql -lpq However, LOCALBASE (which defaults to /usr/local) is used for many things other than PostgreSQL, so changing that is not a great idea, I think... Any idea ? Regards, Nicolas. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

3 years, 5 months

www.kamailio.org maintenance on 29th October 2020, 10:00 CET

by Henning Westerholt

Hello, there will be a short planned maintenance on www.kamailio.org<http://www.kamailio.org> on 29th October 2020 at 10:00 CET. Relevant services including main homepage and documentation wiki will be unavailable for about 10-15 minutes. Best regards, Henning -- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://gilawa.com<https://gilawa.com/>

3 years, 5 months

Kamailio unresponsive with Dialog+DMQ

by Patrick Wakano

Hello list, Hope all are doing well! We are running load tests in our Kamailio server, that is just making inbound and outbound calls and eventually (there is no identified pattern) Kamailio freezes and of course all calls start to fail. It does not crash, it just stops responding and it has to be killed -9. When this happens, SIP messages are not processed, dmq keepalive fails (so the other node reports as down), dialog KA are not sent, but Registrations from UAC seem to still go out (logs from local_route are seen). We don't have a high amount of cps, it is max 3 or 4 per sec, and it gets around 1900 active calls. We are now using Kamailio 5.2.8 installed from the repo on a CentOS7 server. Dialog has KA active and DMQ (with 2 workers) is being used on an active-active instance. >From investigation using GDB as pasted below, I can see UDP workers are stuck on a lock either on a callback from t_relay... #0 0x00007ffb74e9bbf9 in syscall () from /lib64/libc.so.6 #1 0x00007ffb2b1bce08 in futex_get (lock=0x7ffb35217b90) at ../../core/futexlock.h:108 #2 0x00007ffb2b1bec44 in bcast_dmq_message1 (peer=0x7ffb35e8bf38, body=0x7fff2e95ffb0, except=0x0, resp_cback=0x7ffb2a8a0ab0 <dlg_dmq_resp_callback>, max_forwards=1, content_type=0x7ffb2a8a0a70 <dlg_dmq_content_type>, incl_inactive=0) at dmq_funcs.c:156 #3 0x00007ffb2b1bf46b in bcast_dmq_message (peer=0x7ffb35e8bf38, body=0x7fff2e95ffb0, except=0x0, resp_cback=0x7ffb2a8a0ab0 <dlg_dmq_resp_callback>, max_forwards=1, content_type=0x7ffb2a8a0a70 <dlg_dmq_content_type>) at dmq_funcs.c:188 #4 0x00007ffb2a6448fa in dlg_dmq_send (body=0x7fff2e95ffb0, node=0x0) at dlg_dmq.c:88 #5 0x00007ffb2a64da5d in dlg_dmq_replicate_action (action=DLG_DMQ_UPDATE, dlg=0x7ffb362ea3c8, needlock=1, node=0x0) at dlg_dmq.c:628 #6 0x00007ffb2a61f28e in dlg_on_send (t=0x7ffb36c98120, type=16, param=0x7fff2e9601e0) at dlg_handlers.c:739 #7 0x00007ffb2ef285b6 in run_trans_callbacks_internal (cb_lst=0x7ffb36c98198, type=16, trans=0x7ffb36c98120, params=0x7fff2e9601e0) at t_hooks.c:260 #8 0x00007ffb2ef286d0 in run_trans_callbacks (type=16, trans=0x7ffb36c98120, req=0x7ffb742f27e0, rpl=0x0, code=-1) at t_hooks.c:287 #9 0x00007ffb2ef38ac1 in prepare_new_uac (t=0x7ffb36c98120, i_req=0x7ffb742f27e0, branch=0, uri=0x7fff2e9603e0, path=0x7fff2e9603c0, next_hop=0x7ffb742f2a58, fsocket=0x7ffb73e3e968, snd_flags=..., fproto=0, flags=2, instance=0x7fff2e9603b0, ruid=0x7fff2e9603a0, location_ua=0x7fff2e960390) at t_fwd.c:381 #10 0x00007ffb2ef3d02d in add_uac (t=0x7ffb36c98120, request=0x7ffb742f27e0, uri=0x7ffb742f2a58, next_hop=0x7ffb742f2a58, path=0x7ffb742f2e20, proxy=0x0, fsocket=0x7ffb73e3e968, snd_flags=..., proto=0, flags=2, instance=0x7ffb742f2e30, ruid=0x7ffb742f2e48, location_ua=0x7ffb742f2e58) at t_fwd.c:811 #11 0x00007ffb2ef4535a in t_forward_nonack (t=0x7ffb36c98120, p_msg=0x7ffb742f27e0, proxy=0x0, proto=0) at t_fwd.c:1699 #12 0x00007ffb2ef20505 in t_relay_to (p_msg=0x7ffb742f27e0, proxy=0x0, proto=0, replicate=0) at t_funcs.c:334 or loose_route... #0 0x00007ffb74e9bbf9 in syscall () from /lib64/libc.so.6 #1 0x00007ffb2b1bce08 in futex_get (lock=0x7ffb35217b90) at ../../core/futexlock.h:108 #2 0x00007ffb2b1bec44 in bcast_dmq_message1 (peer=0x7ffb35e8bf38, body=0x7fff2e9629d0, except=0x0, resp_cback=0x7ffb2a8a0ab0 <dlg_dmq_resp_callback>, max_forwards=1, content_type=0x7ffb2a8a0a70 <dlg_dmq_content_type>, incl_inactive=0) at dmq_funcs.c:156 #3 0x00007ffb2b1bf46b in bcast_dmq_message (peer=0x7ffb35e8bf38, body=0x7fff2e9629d0, except=0x0, resp_cback=0x7ffb2a8a0ab0 <dlg_dmq_resp_callback>, max_forwards=1, content_type=0x7ffb2a8a0a70 <dlg_dmq_content_type>) at dmq_funcs.c:188 #4 0x00007ffb2a6448fa in dlg_dmq_send (body=0x7fff2e9629d0, node=0x0) at dlg_dmq.c:88 #5 0x00007ffb2a64da5d in dlg_dmq_replicate_action (action=DLG_DMQ_STATE, dlg=0x7ffb363e0c10, needlock=0, node=0x0) at dlg_dmq.c:628 #6 0x00007ffb2a62b3bf in dlg_onroute (req=0x7ffb742f11d0, route_params=0x7fff2e962ce0, param=0x0) at dlg_handlers.c:1538 #7 0x00007ffb2e7db203 in run_rr_callbacks (req=0x7ffb742f11d0, rr_param=0x7fff2e962d80) at rr_cb.c:96 #8 0x00007ffb2e7eb2f9 in after_loose (_m=0x7ffb742f11d0, preloaded=0) at loose.c:945 #9 0x00007ffb2e7eb990 in loose_route (_m=0x7ffb742f11d0) at loose.c:979 or t_check_trans: #0 0x00007ffb74e9bbf9 in syscall () from /lib64/libc.so.6 #1 0x00007ffb2a5ea9c6 in futex_get (lock=0x7ffb35e78804) at ../../core/futexlock.h:108 #2 0x00007ffb2a5f1c46 in dlg_lookup_mode (h_entry=1609, h_id=59882, lmode=0) at dlg_hash.c:709 #3 0x00007ffb2a5f27aa in dlg_get_by_iuid (diuid=0x7ffb36326bd0) at dlg_hash.c:777 #4 0x00007ffb2a61ba1d in dlg_onreply (t=0x7ffb36952988, type=2, param=0x7fff2e963bf0) at dlg_handlers.c:437 #5 0x00007ffb2ef285b6 in run_trans_callbacks_internal (cb_lst=0x7ffb36952a00, type=2, trans=0x7ffb36952988, params=0x7fff2e963bf0) at t_hooks .c:260 #6 0x00007ffb2ef286d0 in run_trans_callbacks (type=2, trans=0x7ffb36952988, req=0x7ffb3675c360, rpl=0x7ffb742f1930, code=200) at t_hooks.c:28 7 #7 0x00007ffb2ee7037f in t_reply_matching (p_msg=0x7ffb742f1930, p_branch=0x7fff2e963ebc) at t_lookup.c:997 #8 0x00007ffb2ee725e4 in t_check_msg (p_msg=0x7ffb742f1930, param_branch=0x7fff2e963ebc) at t_lookup.c:1101 #9 0x00007ffb2eee44c7 in t_check_trans (msg=0x7ffb742f1930) at tm.c:2351 And the DMQ workers are here: #0 0x00007ffb74e9bbf9 in syscall () from /lib64/libc.so.6 #1 0x00007ffb2b1d6c81 in futex_get (lock=0x7ffb35217c34) at ../../core/futexlock.h:108 #2 0x00007ffb2b1d7c3a in worker_loop (id=1) at worker.c:86 #3 0x00007ffb2b1d5d35 in child_init (rank=0) at dmq.c:300 Currently I will not be able to upgrade to latest 5.4 version to try to reproduce the error and since 5.2.8 has already reached end-of-life, maybe is there anything I can do on the configuration to avoid such condition? Any ideas are welcome! Kind regards, Patrick Wakano

3 years, 5 months

Kamailio v5.4.2 Released

by Daniel-Constantin Mierla

Hello, Kamailio SIP Server v5.4.2 stable release is out. This is a maintenance release of the latest stable branch, 5.4, that includes fixes since the release of v5.4.1. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.4.x. Deployments running previous v5.4.x versions are strongly recommended to be upgraded to v5.4.1. For more details about version 5.4.2 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2020/10/kamailio-v5-4-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

3 years, 6 months

Releasing Kamailio v5.4.2

by Daniel-Constantin Mierla

Hello, I am considering to release Kamailio v5.4.2 sometime next week, likely on Tuesday, October 27, 2020. This is the usual heads up notification to see if anyone is aware of issues not yet reported to bug tracker and if yes, do it as soon as possible to give them a chance to be fixed. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla

3 years, 6 months

KEMI and Native mixing

by Marcin Kowalczyk

Hi, Is it possible to mix both KEMI (lua) and Native configs in one kamailio instance? So some blocks are called from native script and some others from KEMI (lua)? Marcin

3 years, 6 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

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 October 2020