sr-users November 2021

sr-users@lists.kamailio.org

48 participants
52 discussions

configuration dispatcher
by sondes boughdiri 17 Nov '21

17 Nov '21

Hi ALL I need to configure dispatcher call to the server asterisk i have a 21 server and i need to dispatcher call to all the server AGENT----> kamailio --->asterisk1 ---> asteisk2 ---> - ---> - ---> - ---> asterisk21 please i need your help THANK YOU

2 1

ki_jsonrpcs_dispatch(): invalid json doc
by Patrick Karton 16 Nov '21

16 Nov '21

hello , im using kamailio and rtpengine. i use rtpengine with rtp timeout as follows rtpengine --timeout=240 --silent-timeout=600 -b2b-url=http://kamailioip:5060/RPC --xmlrpc-format=2 and in kamailio modparam("jsonrpcs", "pretty_format", 1) modparam("jsonrpcs", "transport", 7) event_route[xhttp:request] { if ($hu =~ "^/RPC") { jsonrpc_dispatch(); xhttp_reply("200", "OK", "text/xml", "<methodResponse><params><param><value><string>OK</string></value></param></params></methodResponse>"); exit; } } rtpengine successfully reaches the rpc endpoint but i have an error on the jsonrpcs module 43(50) ERROR: jsonrpcs [jsonrpcs_mod.c:1275]: ki_jsonrpcs_dispatch(): invalid json doc [[<?xml version="1.0" encoding="UTF-8"?> <methodCall> <methodName>dlg.terminate_dlg</methodName> <params> <param><value><string>1-10(a)172.22.244.139</string></value></param> <param><value><string>10SIPpTag091</string></value></param> <param><value><string>8U173ymKpc1pp</string></value></param> </params> </methodCall> ]] and so the dialog module can not ends the call Kamailio 5.5.2 on debian bullseye rtpengine 10.0.1.8 on debian bullseye Thanks.

1 0

xavp functionnality in htable
by Patrick Karton 15 Nov '21

15 Nov '21

hello, do we have something like xavp in htable or a module that implements having multiple values in stack like xavp but not tied to transaction. i want data be seen by all processes but with the functionnality of xavp. Thanks.

3 3

Info: Astricon 2021 - Asterisk and LRKProxy Session
by Mojtaba 13 Nov '21

13 Nov '21

Hello, The Asterisk conference (Astricon 2021) happened last week, I had a session about extending Asterisk with the LRKProxy module in Kamailio in terms of RTP sessions. cheers, -- --Mojtaba Esfandiari.S

2 3

corex send()
by Ross McKillop 12 Nov '21

12 Nov '21

Hi All, Is there an equivalent to corex's send_tcp (https://kamailio.org/docs/modules/5.2.x/modules/corex.html#corex.f.send_tcp <https://kamailio.org/docs/modules/5.2.x/modules/corex.html#corex.f.send_tcp>) for TLS? I have a bit of an odd edge case where I can't add Via headers etc, and send_udp and send_tcp allow me to achieve what I want, but it doesn't seem to have a means of doing the same with TLS? Essentially I want to transparently proxy what is received by Kamailio on one interface to a TLS connection e.g. A = (TCP) => Kamailio = (TLS) => Remote Host (A) in this instance is already setting a Via header of the Kamailio's external IP and transport tis. I appreciate this is a non-standard way of doing it, but (A) is a black box that I can't change, what I'm essentially trying to do is have Kamailio handle the TLS but essentially (A) thinks it's at the edge. I can make it work with send_tcp for a standard TCP connection, but if I use t_relay or even forward() to send onwards by TLS then Kamailio obviously adds its own headers as you'd expect. Ross

2 2

Kamailio dropping ACKs
by Emilio Panighetti 12 Nov '21

12 Nov '21

Working on a proof of concept with Kamailio 5.5.2 (Installed via kamailio-5.5.2-0.el8.centos.x86_64 RPM from rpm.kamailio.org). Also note that this is using the LUA interface Running a simple SIPp scenario without registration. Routing is set with in Lua: KSR.dbg("EP: ksr_route_relay Check for Base Route\n"); if KSR.is_INVITE() and KSR.siputils.has_totag() < 0 then KSR.dbg("EP: ksr_route_relay Base Route\n"); --KSR.sl.send_reply("503", "OLGX Debug"); KSR.setdsturi("sip:192.168.1.14:5060"); --KSR.pv.sets("$du", "sip:192.168.1.12:5062"); end The problem is that Kamailio is dropping the ACK to the 200 OK from the UAS. Wireshark shows that the UAS is retransmitting the 200 OK and the ACK is not being forwarded from the UAC to the UAS. Within the Lua config script: -- Handle requests within SIP dialogs function ksr_route_withindlg() if KSR.siputils.has_totag() < 0 then return 1; end KSR.dbg("EP: ksr_route_withindlg has to-tag, it is within a dialog\n"); -- sequential request within a dialog should -- take the path determined by record-routing if KSR.rr.loose_route() > 0 then ksr_route_dlguri(); if KSR.is_BYE() then KSR.setflag(FLT_ACC); -- do accounting ... KSR.setflag(FLT_ACCFAILED); -- ... even if the transaction fails elseif KSR.is_ACK() then -- ACK is forwarded statelessly KSR.dbg("EP: ksr_route_withindlg Forwarding ACK\n"); ksr_route_natmanage(); elseif KSR.is_NOTIFY() then -- Add Record-Route for in-dialog NOTIFY as per RFC 6665. KSR.rr.record_route(); end KSR.dbg("EP: ksr_route_withindlg loose route calling ksr_route_relay\n"); ksr_route_relay(); KSR.dbg("EP: ksr_route_withindlg exit\n"); KSR.x.exit(); end if KSR.is_ACK() then if KSR.tm.t_check_trans() > 0 then -- no loose-route, but stateful ACK; -- must be an ACK after a 487 -- or e.g. 404 from upstream server KSR.dbg("EP: ksr_route_withindlg is ACK calling ksr_route_relay\n"); ksr_route_relay(); KSR.dbg("EP: ksr_route_withindlg exit\n"); KSR.x.exit(); else -- ACK without matching transaction ... ignore and discard KSR.dbg("EP: ksr_route_withindlg Unknown ACK exit\n"); KSR.x.exit(); end end KSR.sl.sl_send_reply(404, "Not here"); KSR.dbg("EP: ksr_route_withindlg exit after 404\n"); KSR.x.exit(); end And logs for the ACK: Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: <core> [core/udp_server.c:493]: udp_rcv_loop(): received on udp socket: (106/100/385) [[ACK sip:service@192.168.1.15:5060 SIP/2.0 0D 0A Via: SIP/2.0/UDP 192.168.1.12:5060;branch=z9hG4bK-1091869]] Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: <core> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 (request) flags 1 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: <core> [core/parser/msg_parser.c:677]: parse_msg(): SIP Request: Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: <core> [core/parser/msg_parser.c:679]: parse_msg(): method: <ACK> Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: <core> [core/parser/msg_parser.c:681]: parse_msg(): uri: <sip:service@192.168.1.15:5060> Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: <core> [core/parser/msg_parser.c:683]: parse_msg(): version: <SIP/2.0> Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [Via] type 1 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-1091869-1-5>; state=16 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: <core> [core/parser/msg_parser.c:555]: parse_headers(): Via found, flags=2 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: <core> [core/parser/msg_parser.c:557]: parse_headers(): this is the first via Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [From] type 4 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [To] type 3 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=4088926SIPpTag014 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: <core> [core/parser/msg_parser.c:173]: get_hdr_field(): <To> [63]; uri=[sip:service@192.168.1.15:5060] Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: <core> [core/parser/msg_parser.c:176]: get_hdr_field(): to body (39)[service <sip:service@192.168.1.15:5060>], to tag (17)[4088926SIPpTag014] Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [Call-ID] type 6 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [CSeq] type 5 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: <core> [core/parser/msg_parser.c:154]: get_hdr_field(): cseq <CSeq>: <1> <ACK> Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: <core> [core/receive.c:387]: receive_msg(): --- received sip message - request - call-id: [1-1091869(a)192.168.1.12] - cseq: [1 ACK] Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/receive.c:259]: ksr_evrt_pre_routing(): event route core:pre-routing not defined Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/receive.c:457]: receive_msg(): preparing to run routing scripts... Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: sl [sl_funcs.c:443]: sl_filter_ACK(): too late to be a local ACK! Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: app_lua [app_lua_api.c:489]: sr_lua_reload_script(): No need to reload [/etc/kamailio/kamailio.lua] is version 0 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: app_lua [app_lua_api.c:673]: app_lua_run_ex(): executing Lua function: [[ksr_request_route]] Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: app_lua [app_lua_api.c:675]: app_lua_run_ex(): lua top index is: 21 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [Contact] type 7 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [Max-Forwards] type 8 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [Subject] type 27 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [Content-Length] type 12 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/parser/msg_parser.c:187]: get_hdr_field(): content_length=0 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of header Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: app_lua [app_lua_api.c:1007]: sr_kemi_lua_exec_func_ex(): param[0] for: process_maxfwd is int: 69 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: maxfwd [mf_funcs.c:74]: is_maxfwd_present(): value = 70 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: app_lua [app_lua_api.c:1007]: sr_kemi_lua_exec_func_ex(): param[0] for: is_maxfwd_lt is int: 69 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: maxfwd [maxfwd.c:187]: ki_is_maxfwd_lt(): value = 69 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: app_lua [app_lua_api.c:1007]: sr_kemi_lua_exec_func_ex(): param[0] for: sanity_check is int: 1511 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: app_lua [app_lua_api.c:1007]: sr_kemi_lua_exec_func_ex(): param[1] for: sanity_check is int: 7 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: sanity [sanity.c:247]: check_ruri_sip_version(): check_ruri_sip_version entered Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: sanity [sanity.c:270]: check_ruri_sip_version(): check_ruri_sip_version passed Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: sanity [sanity.c:277]: check_ruri_scheme(): check_ruri_scheme entered Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: sanity [sanity.c:297]: check_ruri_scheme(): check_ruri_scheme passed Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: sanity [sanity.c:318]: check_required_headers(): check_required_headers entered Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: sanity [sanity.c:340]: check_required_headers(): check_required_headers passed Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: sanity [sanity.c:506]: check_cseq_method(): check_cseq_method entered Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: sanity [sanity.c:539]: check_cseq_method(): check_cseq_method passed Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: sanity [sanity.c:548]: check_cseq_value(): check_cseq_value entered Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: sanity [sanity.c:576]: check_cseq_value(): check_cseq_value passed Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: sanity [sanity.c:585]: check_cl(): check_cl entered Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: sanity [sanity.c:610]: check_cl(): check_cl passed Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: sanity [sanity.c:622]: check_expires_value(): check_expires_value entered Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: sanity [sanity.c:659]: check_expires_value(): no expires header found Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: sanity [sanity.c:759]: check_parse_uris(): check_parse_uris entered Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: sanity [sanity.c:763]: check_parse_uris(): parsing ruri Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: sanity [sanity.c:777]: check_parse_uris(): looking up From header Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: sanity [sanity.c:791]: check_parse_uris(): parsing From header Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=1091869SIPpTag001 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: sanity [sanity.c:817]: check_parse_uris(): parsing From URI Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: sanity [sanity.c:835]: check_parse_uris(): looking up To header Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: sanity [sanity.c:857]: check_parse_uris(): check_parse_uris(): parsing To URI Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: sanity [sanity.c:902]: check_parse_uris(): check_parse_uris passed Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: siputils [checks.c:123]: has_totag(): totag found Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: app_lua [app_lua_api.c:1003]: sr_kemi_lua_exec_func_ex(): param[0] for: dbg is str: EP: ksr_route_withindlg has to-tag, it is within a dialog Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/kemi.c:85]: sr_kemi_core_dbg(): EP: ksr_route_withindlg has to-tag, it is within a dialog Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: rr [loose.c:108]: find_first_route(): No Route headers found Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: rr [loose.c:1006]: loose_route_mode(): There is no Route HF Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: tm [t_lookup.c:1034]: t_check_msg(): msg (0x7fef983a2608) id=2/2414 global id=1/2414 T start=0xffffffffffffffff Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: tm [t_lookup.c:497]: t_lookup_request(): start searching: hash=12314, isACK=1 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: tm [t_lookup.c:455]: matching_3261(): RFC3261 transaction matching failed - via branch [z9hG4bK-1091869-1-5] Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: tm [t_lookup.c:675]: t_lookup_request(): no transaction found Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: tm [t_lookup.c:1103]: t_check_msg(): msg (0x7fef983a2608) id=2/2414 global id=2/2414 T end=(ni l) Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: app_lua [app_lua_api.c:1003]: sr_kemi_lua_exec_func_ex(): param[0] for: dbg is str: EP: ksr_route_withindlg Unknown ACK exit Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/kemi.c:85]: sr_kemi_core_dbg(): EP: ksr_route_withindlg Unknown ACK exit Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: app_lua [app_lua_api.c:1837]: sr_kemi_lua_exit(): script exit call Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: app_lua [app_lua_api.c:729]: app_lua_run_ex(): ksr error call from Lua: ~~ksr~exit~~ Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: app_lua [app_lua_mod.c:167]: sr_kemi_config_engine_lua(): execution of route type 1 with no name returned 1 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: INFO: LUA {ACK}: <core> [core/receive.c:515]: receive_msg(): request-route executed in: 364 usec Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/receive.c:606]: receive_msg(): cleaning up Nov 11 12:24:37 ol-vm1 /usr/sbin/kamailio[2413]: DEBUG: <core> [core/udp_server.c:493]: udp_rcv_loop(): received on udp socket: (106/100/577) [[SIP/2.0 200 OK 0D 0A Via: SIP/2.0/UDP 192.168.1.15;branch=z9hG4bKa103.32dd17e8a1a3458280dbbe34442737e7.0,]] Nov 11 12:24:37 ol-vm1 /usr/sbin/kamailio[2413]: DEBUG: <core> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 2 (reply(status)) flags 1 Nov 11 12:24:37 ol-vm1 /usr/sbin/kamailio[2413]: DEBUG: <core> [core/parser/msg_parser.c:687]: parse_msg(): SIP Reply (status): Nov 11 12:24:37 ol-vm1 /usr/sbin/kamailio[2413]: DEBUG: <core> [core/parser/msg_parser.c:689]: parse_msg(): version: <SIP/2.0> Nov 11 12:24:37 ol-vm1 /usr/sbin/kamailio[2413]: DEBUG: <core> [core/parser/msg_parser.c:691]: parse_msg(): status: <200> Nov 11 12:24:37 ol-vm1 /usr/sbin/kamailio[2413]: DEBUG: <core> [core/parser/msg_parser.c:693]: parse_msg(): reason: <OK> Nov 11 12:24:37 ol-vm1 /usr/sbin/kamailio[2413]: DEBUG: <core> [core/parser/parse_hname2.c:293]: parse_sip_header_name(): parsed header name [Via] type 1 Nov 11 12:24:37 ol-vm1 /usr/sbin/kamailio[2413]: DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKa103.3 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: tm [t_lookup.c:1103]: t_check_msg(): msg (0x7fef983a2608) id=2/2414 global id=2/2414 T end=(nil) Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: app_lua [app_lua_api.c:1003]: sr_kemi_lua_exec_func_ex(): param[0] for: dbg is str: EP: ksr_route_withindlg Unknown ACK exit Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/kemi.c:85]: sr_kemi_core_dbg(): EP: ksr_route_withindlg Unknown ACK exit Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: app_lua [app_lua_api.c:1837]: sr_kemi_lua_exit(): script exit call Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: app_lua [app_lua_api.c:729]: app_lua_run_ex(): ksr error call from Lua: ~~ksr~exit~~ Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: app_lua [app_lua_mod.c:167]: sr_kemi_config_engine_lua(): execution of route type 1 with no name returned 1 Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: INFO: LUA {ACK}: <core> [core/receive.c:515]: receive_msg(): request-route executed in: 364 usec Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) Nov 11 12:24:36 ol-vm1 /usr/sbin/kamailio[2414]: DEBUG: LUA {ACK}: <core> [core/receive.c:606]: receive_msg(): cleaning up The ACK is this: ACK sip:service@192.168.1.15:5060 SIP/2.0\r\n Via: SIP/2.0/UDP 192.168.1.12:5060;branch=z9hG4bK-1091869-1-5\r\n From: sipp <sip:sipp@192.168.1.12:5060>;tag=1091869SIPpTag001\r\n To: service <sip:service@192.168.1.15:5060>;tag=4088926SIPpTag014\r\n Call-ID: 1-1091869(a)192.168.1.12\r\n CSeq: 1 ACK\r\n Contact: sip:sipp@192.168.1.12:5060\r\n Max-Forwards: 70\r\n Subject: Performance Test\r\n Content-Length: 0\r\n \r\n I’ve been trying to figure this out for days and don’t know what’s wrong here. Thanks

3 4

[ndb_redis] init_without_redis issue
by Denys Pozniak 11 Nov '21

11 Nov '21

Hello! In our architecture, Kamailio uses 2 local Redis servers to get routing information. We noticed that if at the start of Kamailio the first in the modparam list is a running Redis server (name=real), and the second in the list is not running (name=fake), then Kamailio will not even try to connect to the running one. # ----- redis server params ----- modparam("ndb_redis", "init_without_redis", 1) modparam("ndb_redis", "server", "name=real;addr=127.0.0.1;port=6379;db=1") modparam("ndb_redis", "server", "name=fake;addr=127.0.0.1;port=6479;db=2") But if the servers in the list above are reversed, then everything will work as it should. Looks the initialization order affects behavior. Syslog output: Nov 11 18:00:45 kamailio /usr/sbin/kamailio[11445]: ERROR: ndb_redis [redis_client.c:224]: redisc_init(): Failed to create REDIS returned an error: Connection refused Nov 11 18:00:45 kamailio /usr/sbin/kamailio[11445]: ERROR: ndb_redis [redis_client.c:259]: redisc_init(): error communicating with redis server [fake] (127.0.0.1:6479/2): Connection refused Nov 11 18:00:45 kamailio /usr/sbin/kamailio[11445]: WARNING: ndb_redis [redis_client.c:264]: redisc_init(): failed to initialize redis connections, but initializing module anyway. There is no established connection to the real server after Kamailio starts both through redis-cli and through ss. [root@kamailio ~]# ss -anp | grep 6379 tcp LISTEN 0 128 127.0.0.1:6379 *:* users:(("redis-server",pid=10376,fd=6)) [root@kamailio ~]# kamailio -v version: kamailio 5.6.0-dev2 (x86_64/linux) 378a2d compiled on 04:12:43 Nov 11 2021 with gcc 4.8.5 [root@kamailio ~]# cat /etc/redhat-release CentOS Linux release 7.9.2009 (Core) g -- BR, Denys Pozniak

1 0

Forcing Outbound Socket
by Ross McKillop 11 Nov '21

11 Nov '21

Hi All, Try as I may I cannot force an outbound TCP request to use a non-ephemeral source port. Looking at the documentation it seems that as long as I have a line like listen=tcp:10.30.0.55:3339 I should be able to force an outbound connection to originate from that host and port, i.e. to establish a persistent connection from a specific socket to a remote host, but having tried to set it via $fs and set_send_socket() it always uses an ephemeral port. Ideally I would like kamailio to use a specific source port for contacting a specific remote host and keep the TCP socket established, and it seems like it should be simple enough to do but it's not working as expected. Best, Ross

4 6

TCP Persistent Connections
by Ross McKillop 10 Nov '21

10 Nov '21

Hopefully the collective hive mind can help with this one, as I have little experience of using TCP in this manner and neither does a friendly Kamailio expert I know personally. I'm replacing a closed box thing that accepts connections from various nodes over TCP. They send INVITEs and REGISTERs over that TCP socket and expect to receive inbound calls over the same established TCP socket. Struggling to make Kamailio behave the same way, but it should be possible. The first time it receives a message, I add the sender to the dispatcher as follows; jsonrpc_exec('{"jsonrpc": "2.0", "method": "dispatcher.add", "params": [5, "sip:$si:$sp;transport=tcp", 0, "socket=tcp:127.0.0.1:5776"], "id": 1}'); This works great, but despite setting the socket to use there, when a call later comes in and it's routed to one of the dispatcher nodes that's been added in this way it fails because Kamailio attempts to open a new connection to the IP / PORT rather than having kept the socket open from the earlier message and reusing the same connection/. Any ideas? I get the feeling I'm missing something obvious! Ross

3 3

Re: [SR-Users] htable.get issues
by Igor Olhovskiy 10 Nov '21

10 Nov '21

Yup, this is works! Thanks! Not reflected in docs, though... ср, 10 нояб. 2021 г. в 16:13, Fred Posner <fred(a)palner.com>: > > On 11/10/21 11:10 AM, Igor Olhovskiy wrote: > > Hello, > > I'm getting issues with *htable.get* rpc command > > Running > > kamctl rpc htable.get client_to_re 65825 > > What happens when you try: > > s:65825 vs 65825 > > > > Fred Posner | palner.com > Matrix: @fred:matrix.lod.com > o: +1 (212) 937-7844 > -- Best regards, Igor

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 November 2021