sr-users January 2023

sr-users@lists.kamailio.org

56 participants
66 discussions

Is preloading openssl_mutex_shared necessary for Kamailio 5.6 or is it not necessary?

by Дилян Палаузов

Hello, https://www.kamailio.org/docs/modules/devel/modules/tls says: For OpenSSL (libssl) v1.1.x, it is required to preload 'openssl_mutex_shared' library shipped by Kamailio. For more details see 'src/modules/tls/utils/openssl_mutex_shared/README.md'. 'src/modules/tls/utils/openssl_mutex_shared/README.md says: **IMPORTANT: the workaround of using this preloaded shared library is no longer needed starting with Kamailio v5.3.0-pre1 (git master branch after September 14, 2019). The code of this shared library has been included in the core of Kamailio and the same behaviour is now achieved by default.** This is a shared library required as a short term workaround for using Kamailio with OpenSSL (libssl) v1.1. It has to be pre-loaded before starting Kamailio. In v1.1, libssl does not allow setting custom locking functions, using internally pthread mutexes and rwlocks, but they are not initialized with process shared option (PTHREAD_PROCESS_SHARED), which can result in blocking Kamailio worker processes. Is preloading openssl_mutex_shared necessary for Kamailio 5.6 or is it not necessary? If it is not necessary, why isn’t it removed from the source code? Greetings Дилян

1 year, 8 months

Websocket-answers sent by K. log unparseable errors

by Дилян Палаузов

Hello, when I connect to Kamailio over websocket, according to the websocket protocol K. sends “HTTP/1.1 101 Switching Protocols” and K. logs: 17(18) DEBUG: websocket [ws_handshake.c:179]: ws_handle_handshake(): found Upgrade: websocket 17(18) DEBUG: websocket [ws_conn.c:195]: wsconn_add(): connection id [14] 17(18) DEBUG: websocket [ws_conn.c:213]: wsconn_add(): new wsc => [0x7fcad6e10160], ref => [0] 17(18) DEBUG: websocket [ws_conn.c:233]: wsconn_add(): added to conn_table wsc => [0x7fcad6e10160], ref => [1] 17(18) DEBUG: sl [sl.c:310]: send_reply(): reply in stateless mode (sl) 17(18) DEBUG: <core> [core/msg_translator.c:162]: check_via_address(): (22.222.222.222, 22.222.222.222, 0) 17(18) DEBUG: <core> [core/tcp_main.c:1644]: _tcpconn_find(): found connection by id: 14 17(18) DEBUG: <core> [core/tcp_main.c:2528]: tcpconn_send_put(): send from reader (18 (17)), reusing fd 17(18) DEBUG: <core> [core/tcp_main.c:2763]: tcpconn_do_send(): sending... 17(18) DEBUG: <core> [core/tcp_main.c:2796]: tcpconn_do_send(): after real write: c= 0x7fcad6da7b38 n=238 fd=9 17(18) DEBUG: <core> [core/tcp_main.c:2797]: tcpconn_do_send(): buf= 17(18) DEBUG: <core> [core/parser/parse_fline.c:255]: parse_first_line(): bad request first line 17(18) DEBUG: <core> [core/parser/parse_fline.c:258]: parse_first_line(): at line 0 char 22: 17(18) DEBUG: <core> [core/parser/parse_fline.c:264]: parse_first_line(): parsed so far: HTTP/1.1 101 Switching 17(18) ERROR: <core> [core/parser/parse_fline.c:271]: parse_first_line(): parse_first_line: bad message (offset: 22) 17(18) DEBUG: <core> [core/parser/msg_parser.c:675]: parse_msg(): invalid message 17(18) ERROR: <core> [core/parser/msg_parser.c:749]: parse_msg(): ERROR: parse_msg: message=<HTTP/1.1 101 Switching Protocols Sia: SIP/2.0/TLS 22.222.222.222:33776 Sec-WebSocket-Protocol: sip Upgrade: websocket Connection: upgrade Sec-WebSocket-Accept: NeswoJX5ZQp7ER8hTKM5B3a3HDQ= Content-Length: 0 > 17(18) ERROR: <core> [core/msg_translator.c:3256]: build_sip_msg_from_buf(): parsing failed 17(18) DEBUG: app_lua [app_lua_api.c:1924]: sr_kemi_lua_exit(): script exit call 17(18) DEBUG: app_lua [app_lua_api.c:789]: app_lua_run_ex(): ksr error call from Lua: ~~ksr~exit~~ 17(18) DEBUG: app_lua [app_lua_mod.c:164]: sr_kemi_config_engine_lua(): execution of route type 513 with name [ksr_xhttp_event] returned 1 22.222.222.222 is my public address (the address of my router). It is not the IP-address of Kamailio. While the returned address is not parseable in terms of SIP, it is a valid Websocket-answer message. This valid condition triggers logging an error, but does not represent an error condition. How can I avoid that the above non-error is logged as an error? Thanks for your feedback Дилян

1 year, 8 months

Locally generated BYE sent to private IP

by James Lipski

Hi all, I'm doing some experimenting with kamailio -- currently looking for a replacement of our existing (aging) SIP infrastructure. One of the experiments that I'm doing is testing the dialog module's dlg_set_timeout function. The issue that I'm having is while I do see that kamailio is generating a BYE, and sends it out to the B-leg of the call properly, the BYE goes to a private address on the A-leg. To Note: - kamailio is behind a NAT (on AWS) - both UA endpoints are remote and are both behind a NAT - Not sure if this matters, but I do have the topos module enabled, though I see the same behavior regardless if it's enabled or not. - Have set nathelpers (fix_nated_register, fix_nated_contact,etc...) which helps calls between endpoints and the endpoints themselves are able to send/receive BYEs when they generate them; however doesn't seem to help if kamailio locally generates the BYE. The only thing I do see within my logs is when the BYE is being generated by kamailio, it uses the private IP of my UA and not public for the caller. Callee, the public address is referenced. If more information is needed, please let me know (just didn't want to spam my script/ logs). Thanks. Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: dialog [dlg_req_within.c:399]: send_bye(): sending BYE to caller Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: tm [uac.c:458]: t_uac_prepare(): next_hop=<sip:1000@10.0.0.47:38606;line=9k4wsgc9> Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: tm [uac.c:158]: dlg2hash(): hashid 40484 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 (request) flags 1 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:679]: parse_msg(): SIP Request: Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:680]: parse_msg(): method: <BYE> Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:682]: parse_msg(): uri: <sip:1000@10.0.0.47:38606;line=9k4wsgc9> Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:684]: parse_msg(): version: <SIP/2.0> Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Via] type 1 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_via.c:1300]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK42e9.4a962087000000000000000000000000.0>; state=16 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:555]: parse_headers(): Via found, flags=2 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:557]: parse_headers(): this is the first via Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [To] type 3 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=ueisi99vbf Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_addr_spec.c:884]: parse_addr_spec(): end of header reached, state=29 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): <To> [61]; uri=[sip:1000@fakedomain.com] Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:174]: get_hdr_field(): to body (44)[<sip:1000@fakedomain.com>], to tag (10)[ueisi99vbf] Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [From] type 4 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [CSeq] type 5 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <BYE> Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Call-ID] type 6 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Content-Length] type 12 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field(): content_length=0 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Max-Forwards] type 8 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of header Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=1132060721 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_addr_spec.c:884]: parse_addr_spec(): end of header reached, state=29 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: topos [tps_msg.c:1013]: tps_request_sent(): handling outgoing request (1, 1) Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: topos [tps_msg.c:417]: tps_pack_message(): compacted headers - x_via1: [SIP/2.0/UDP <KAMAILIO PUBLIC IP>:5060;branch=z9hG4bK42e9.4a962087000000000000000000000000.0](85) - x_via2: [](0) - x_vbranch1: [z9hG4bK42e9.4a962087000000000000000000000000.0](46) Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: topos [tps_msg.c:539]: tps_pack_message(): compacted headers - a_rr: [](0) - b_rr: [](0) - s_rr: [](0) Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: topos [tps_msg.c:544]: tps_pack_message(): compacted headers - as_contact: [](0) - bs_contact: [](0) Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: topos [tps_msg.c:1027]: tps_request_sent(): no x-uuid header - nothing to do Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/msg_translator.c:1799]: check_boundaries(): no multi-part body Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: topos [topos_mod.c:567]: tps_msg_sent(): new outbound buffer generated Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: tm [uac.c:686]: send_prepared_request_impl(): uac: 0x7f22f94448e8 branch: 0 to 10.0.0.47:38606 Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/onsend.c:50]: run_onsend(): required parameters are not available - ignoring Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: dialog [dlg_req_within.c:432]: send_bye(): BYE sent to caller Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: dialog [dlg_req_within.c:399]: send_bye(): sending BYE to callee Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: tm [uac.c:458]: t_uac_prepare(): next_hop=<sip:1001@<UA PUBLIC IP>:5066>Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: tm [uac.c:158]: dlg2hash(): hashid 40482

1 year, 8 months

Kamailio not responding after stress test

by Igor Olhovskiy

Hello, I'm continuing investigations on Kamailio and stress test. Got it again in the state where it's not accepting any new TCP/TLS connections (UDP still works though), but all looks good from lsof/netnstat part, like system is not reporting any zombie connections. Restart of Kamailio process helps This time I got output of kamctl trap Put it here: https://pastebin.com/iYrNZ8U9 kamailio --version version: kamailio 5.6.2 (x86_64/linux) 54a9c1 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 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: 54a9c1 compiled on 14:01:01 Oct 18 2022 with gcc 4.8.5 It's statically linked with tlsa pointing on openssl-1.1.1q Settings related to TLS are: fork=yes children=4 tcp_children=12 enable_tls=yes tcp_accept_no_cl=yes tcp_max_connections=63536 tls_max_connections=63536 tcp_accept_aliases=no tcp_async=yes tcp_connect_timeout=10 tcp_conn_wq_max=63536 tcp_crlf_ping=yes tcp_delayed_ack=yes tcp_fd_cache=yes tcp_keepalive=yes tcp_keepcnt=3 tcp_keepidle=30 tcp_keepintvl=10 tcp_linger2=30 tcp_rd_buf_size=80000 tcp_send_timeout=10 tcp_wq_blk_size=2100 tcp_wq_max=10485760 open_files_limit=63536 Can you please help to read gdb output and understand where I missed in config? Thanks in advance! -- Best regards, Ihor (Igor)

1 year, 8 months

Kamailio 5.6 on AlmaLinux 8 TLS crash

by Ihor Olkhovskyi

Hello! Currently testing Kamailio on Almalinux 8 (stated to be RHEL 8 binary compatible) and got this while trying to get TLS working: /usr/sbin/kamailio[32858]: INFO: tls [tls_domain.c:347]: ksr_tls_fill_missing(): TLSc<default>: ca_list='(null)' /usr/sbin/kamailio[32858]: INFO: tls [tls_domain.c:354]: ksr_tls_fill_missing(): TLSc<default>: ca_path='(null)' /usr/sbin/kamailio[32858]: INFO: tls [tls_domain.c:361]: ksr_tls_fill_missing(): TLSc<default>: crl='(null)' /usr/sbin/kamailio[32858]: INFO: tls [tls_domain.c:365]: ksr_tls_fill_missing(): TLSc<default>: require_certificate=1 /usr/sbin/kamailio[32858]: INFO: tls [tls_domain.c:372]: ksr_tls_fill_missing(): TLSc<default>: cipher_list='(null)' /usr/sbin/kamailio[32858]: INFO: tls [tls_domain.c:379]: ksr_tls_fill_missing(): TLSc<default>: private_key='(null)' /usr/sbin/kamailio[32858]: INFO: tls [tls_domain.c:383]: ksr_tls_fill_missing(): TLSc<default>: verify_certificate=1 /usr/sbin/kamailio[32858]: INFO: tls [tls_domain.c:386]: ksr_tls_fill_missing(): TLSc<default>: verify_depth=9 /usr/sbin/kamailio[32858]: INFO: tls [tls_domain.c:389]: ksr_tls_fill_missing(): TLSc<default>: verify_client=0 /usr/sbin/kamailio[32858]: INFO: tls [tls_domain.c:736]: set_verification(): TLSc<default>: Server MUST present valid certificate /usr/sbin/kamailio[32862]: ERROR: rtpengine [rtpengine.c:3070]: send_rtpp_command(): can't send command "ping" to RTPEngine <udp: 127.0.0.1:19999> /usr/sbin/kamailio[32862]: ERROR: rtpengine [rtpengine.c:2919]: rtpp_test(): proxy did not respond to ping /usr/sbin/kamailio[32883]: INFO: snmpstats [snmpstats.c:519]: spawn_sysUpTime_child(): A snmpVersion parameter was not provided. Defaulting to 3 /usr/sbin/kamailio[32883]: ERROR: snmpstats [snmpstats.c:561]: spawn_sysUpTime_child(): snmpget failed to run. Did you supply the snmpstats module with a proper snmpgetPath parameter? The kamailioSIPServiceStartTime is defaulting to zero /usr/sbin/kamailio[32881]: INFO: ctl [io_listener.c:214]: io_listen_loop(): io_listen_loop: using epoll_lt io watch method (config) /usr/sbin/kamailio[32870]: CRITICAL: <core> [core/mem/q_malloc.c:145]: qm_debug_check_frag(): BUG: qm: prev. fragm. tail overwritten(0, abcdefed)[0x7fe8375d3820:0x7fe8375d3858]! Memory allocator was called from tls: tls_init.c:293. Fragment marked by tls: tls_init.c:293. Exec from core/mem/q_malloc.c:391. /usr/sbin/kamailio[32870]: CRITICAL: <core> [core/mem/q_malloc.c:153]: qm_debug_check_frag(): BUG: qm: prev. fragm. tail overwritten [0x7fe8375d3790:0x7fe8375d37c8] - fragment marked by tls: tls_init.c:293 systemd[1]: Started Process Core Dump (PID 32923/UID 0). systemd-coredump[32924]: Process 32870 (kamailio) of user 0 dumped core.#012#012Stack trace of thread 32870:#012#0 0x00007fe841786aff raise (libc.so.6)#012#1 0x00007fe841759ea5 abort (libc.so.6)#012#2 0x00000000006eec2f qm_debug_check_frag (kamailio)#012#3 0x00000000006f09a6 qm_malloc (kamailio)#012#4 0x00000000006fc930 qm_shm_malloc (kamailio)#012#5 0x00007fe83b5b9c31 ser_malloc (tls.so)#012#6 0x00007fe83fa4090d CRYPTO_zalloc (libcrypto.so.1.1)#012#7 0x00007fe8364b8163 sc_hash_type (libnetsnmp.so.35)#012#8 0x00007fe8364b49df hash_engineID (libnetsnmp.so.35)#012#9 0x00007fe8364b4b11 search_enginetime_list (libnetsnmp.so.35)#012#10 0x00007fe8364b4f8e set_enginetime (libnetsnmp.so.35)#012#11 0x00007fe8364b4885 init_snmpv3_post_config (libnetsnmp.so.35)#012#12 0x00007fe8364b9c92 snmp_call_callbacks (libnetsnmp.so.35)#012#13 0x00007fe836f3601b register_with_master_agent (snmpstats.so)#012#14 0x00007fe836f37f14 run_alarm_check (snmpstats.so)#012#15 0x0000000000531cde compat_old_handler (kamailio)#012#16 0x000000000053284e slow_timer_main (kamailio)#012#17 0x000000000042e3e1 main_loop (kamailio)#012#18 0x0000000000438d14 main (kamailio)#012#19 0x00007fe841772d85 __libc_start_main (libc.so.6)#012#20 0x000000000041cfce _start (kamailio) /usr/sbin/kamailio[32915]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 24 /usr/sbin/kamailio[32858]: ALERT: <core> [main.c:774]: handle_sigs(): child process 32870 exited by a signal 6 ... version: kamailio 5.6.3 (x86_64/linux) fe0c4d 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: fe0c4d compiled on 11:02:26 Jan 19 2023 with gcc 8.5.0 Same config is starting without issues on CentOS 7. OpenSSL version is 1.1.1k Kamailio is installed from official RPM repos. Is core dump would be useful here or best to compile from source and redo? -- Best regards, Ihor (Igor)

1 year, 8 months

topos vs topoh, any reason for putting a private IP in the Contact header?

by Benoit Panizzon

Hi I'm trying to work around Route-Header and Via Issues with the two topology hiding modules topoh and topos and trying to figure out, which one works better for our environment. My conclusion so far: topos creates very clean header, but needs a database or redis. I'm always reluctant in adding more components which could fail or cause load. topoh also works, but it worries me a bit that according to the manual: https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask… a private IP is used to mask the contact header. I have come across a CPE which, as far as I see, is misbehaving by ALWAYS sending a PRACK to the Hostname or IP found in the Contact header, and ignoring Route and Via Header. So why using a private IP as 'mask' and not the IP or Hostname of the actual kamailio instance? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

1 year, 8 months

Re: [sr-dev] Is there any Function or parameter to check Initial Invite Response on Kamailio

by Henning Westerholt

(removed sr-dev from CC) Hello, you can do that with the reply_route and/or onreply_route, for an example check out example cfg or this: https://www.kamailio.org/docs/modules/devel/modules/tm.html#tm.f.t_on_reply Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com<https://gilawa.com/> From: HimaBindu G <himabindu.garadareddy(a)gmail.com> Sent: Tuesday, January 24, 2023 3:16 PM To: sr-users(a)lists.kamailio.org; sr-dev(a)lists.kamailio.org Subject: [sr-dev] Is there any Function or parameter to check Initial Invite Response on Kamailio Hi All, Can you please suggest any function or parameter to check Initial Invite Response from the backend. Thanks & Regards, Hima Bindu.

1 year, 8 months

RTPengine multiple setID sockets

by John Hardiman

Hi All, Hope you are all well? I am hoping you can help with a bit of syntax I am struggling to get working in the intended way. (We are using Kamailio 5.5.3 and using Kemi/python.) The scenario is in AWS where we have separate Kamailio and RTPengine instances, with a cluster of FreeSWITCH EC2's on private addresses only. In the current setup, all RTP routes via the NAT gateway and back to the private IP of the selected FreeSWITCH (and vice versa). This works in the current config, but I would want this traffic not going via the NAT gateway and use the private address and route internally on the VPC. (These EC'2 have only 1 network interface and that cannot be changed for this work.) So anything between FreeSWITCH and Kamailio/RTPengine uses the private IP's for media, the rest use public IP's. It is good to note that the RTPengine's are the same in each set (3 total RTPengine's), just using the public/private IP's based on set ID. My first aim is to use KSR.permissions.allow_source_address() to check if the source address is from the FreeSWITCH cluster and set the rtpengine setID based on this. I have used this method for different parts of the config and it works. I am failing at this first step it seems, as no matter what I use in the function (below) it defaults and uses the public IP's in SDP. (No matter if I use the same setID in each set) kamailio.cfg snippet: # ----- rtpengine params ----- modparam("rtpengine", "setid_avp", "$avp()") # Public IP's ID 1: modparam("rtpengine", "rtpengine_sock", "1 == udp:5.5.5.5:2223 udp:6.6.6.6:2223 udp:7.7.7.7:2223") # Internal IP's ID 2: modparam("rtpengine", "rtpengine_sock", "2 == udp:10.0.0.1:2223 udp:10.0.0.2:2223 udp:10.0.0.3:2223") Kemi file snippet: # RTPengine Options for different SetID def ksr_route_rtpengine(self, msg): if KSR.textops.has_body_type("application/sdp") > 0 : # Source address is private subnet - use RTPengine set 2 (private IP's) if KSR.permissions.allow_source_address(400) == 1: KSR.rtpengine.set_rtpengine_set(2) KSR.rtpengine.rtpengine_manage( "RTP/AVP replace-session-connection replace-origin port-latching ICE=remove") else: # Source address is NOT private - use RTPengine set 1 (public) KSR.rtpengine.set_rtpengine_set(1) KSR.rtpengine.rtpengine_manage( "RTP/AVP replace-session-connection replace-origin port-latching ICE=remove") KSR.xlog.xlog("L_INFO", "RTPengine handling Block") return 1 Group 400 is the private subnet of the FreeSWITCH clusters we have behind on private addresses and the list contains the subnet of private IP's. Using the above, the Kamailio starts fine and understands/loads each set of RTPengine's and calls work with audio. but regardless of the set number used (even only using set 2 in both) it defaults to public IP's in the SDP. (This is the only place in the config where this function is defined) My SDP from FreeSWITCH egress to Kamailio/RTPengine has private IP's in the SDP. The only thing I do not fully understand is the setid_avp - specifically $avp() block and if this needs to stay empty, or be duplicated with the set ID in each one. Any help would be greatly appreciated in understanding where I am going wrong here. Thanks, John.

1 year, 8 months

[SR-Users]: Port number in To: field

by Olivier

Hello, While trunking with an Oracle SBC, I was lately required to include a port number in INVITE To: field. Would you qualify this as a "legal requirement" (according to SIP Standards) ? Best regards

1 year, 8 months

dialog: db_mode => 1, enable_dmq => 1 but entries not replicated to 2nd node DB

by Benoit Panizzon

Hi I am struggling with DMQ and dialog DB storage leading to orphan or duplicate entries in database and not loading all dialog information upon restart. usrloc on the other side, also using local db storage and dmq, works flawlessly even when restarting one node. All location information is replicated between the databases via DMQ. So trying to find what is different. usrloc module: modparam("usrloc", "db_url", DBLOCAL) modparam("usrloc", "db_mode", 2) modparam("dmq_usrloc", "enable", 1) modparam("dmq_usrloc", "sync", 1) dialog module: modparam("dialog", "db_url", DBLOCAL ) modparam("dialog", "db_mode", 1 ) modparam("dialog", "db_skip_load", 0) modparam("dialog", "enable_dmq", 1) via kamcmd dlg.list I see that dialog information is being replicated between the two nodes. But I can only find the dialog in the local database of the node which is handling the call. Is this the expected behavior? I also just found how to create duplicate entries in the database... * Run a call on Node A, verify the dialog information is store in the local database and replicated to node B via DMQ. * Restart Kamailio on Node A. There I suspect, node A is restoring Dialog Information via DMQ from Node B and loading the same information from database, leaving duplicates in dialog_vars. Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

1 year, 8 months

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 January 2023