- sr-users - kamailio.org

Interactions of dmq_usrloc and usrloc w/db_mode > 0
by Alex Balashov 29 Sep '22

29 Sep '22

Hi, Are there any known contraindications for replicating contacts using dmq/dmq_usrloc, and injecting those contacts into a database on one of the nodes using usrloc with `db_mode` 1 or 2? Predictably, this is being done to support the use-case of getting registration status from database. If you think this should be done with JSONRPC, I am in complete agreement with you, but it’s not up to me. :-) I am doing this with `db_mode` 2 now, and finding that, for a small number of AORs, one can find instances where they are consistently stored in memory but not present in the `location` table. The overall proportion of these AORs, out of thousands, seems to be quite small. It was initially somewhat higher, and it went down once I increased usrloc `timer_processes` and increased the sync interval from 30 to 60 seconds. Nevertheless, it is still non-zero, and I am getting intermittent reports. I wonder if there are some prior experiences with this and anything to watch out, or if `db_mode` 1 might be a superior choice. I personally cannot see how that would be; it seems to have all the performance downsides of mode 3. But perhaps if something about it is more “problem-free” vis-a-vis DMQ, it’s worth a shot? — Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

5 7

New feature: #defexp -preprocessor define with expression
by Daniel-Constantin Mierla 29 Sep '22

29 Sep '22

Hello, following the recent new feature of #!ifexp based on snexpr (https://www.kamailio.org/w/2022/09/ifexp-conditional-preprocessor-blocks/), another preprocessor directive was added which allows defining IDs with a value computed from the evaluation of an expression, respectively: #!defexp ID EXP The EXP can be any expression supported by snexpr, including the previously defined IDs. For example: #!define IPADDR 1.2.3.4 #!define PORT 5060 #!defexp SIPURI "sip:" + IPADDR + ":" + PORT The result is that SIPURI is defined to sip:1.2.3.4:5060. Another variant is available as #!defexps, which encloses the result of the expression in double quotes, making it suitable to be used further as string value: #!defexps SIPURI "sip:" + IPADDR + ":" + PORT The result is that SIPURI is defined to “sip:1.2.3.4:5060”. More details at: - https://www.kamailio.org/wikidocs/cookbooks/devel/core/#defexp - https://www.kamailio.org/wikidocs/cookbooks/devel/core/#defexps Testing would be appreciated, feedback can be addressed to sr-users mailing list! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online Nov 7-10, 2022 (Europe Timezone) * https://www.asipto.com/sw/kamailio-advanced-training-online/

1 0

Question about the Secsipid module
by Володимир Іванець 28 Sep '22

28 Sep '22

Hello everyone! I'm testing calls with STIR/SHAKEN with a Secsipid module on a Kamailio version 5.6.1 and ran into a problem. Outbound calls work fine when the function *secsipid_add_identity* with appropriate parameters is called. But as soon as I add function *secsipid_check_identity* to my configuration, Kamilio would not start. Here is an error message I get: *kamailio: CRITICAL: <core> [core/cfg.y:3791]: yyerror_at(): parse error in config file /etc/kamailio/include/registrar.cfg, line 47, column 39: unknown command, missing loadmodule?* *loadmodule "secsipid.so"* is present and is above the function *secsipid_check_identity* call. Both secsipid.so and secsipid_proc.so module files are the correct version and present on the system. Another question is related to the rpm package build. How do you build additional modules? I made adjustment to the pkg/kamailio/Makefile file. In the *cfg* section changed *$(MAKE) -C ../../src cfg* with *$(MAKE) FLAVOUR=kamailio include_modules="secsipid secsipid_proc" -C ../../src cfg*. Required modules appeared in the modules.lst file but their rpm packages were not built. Thank you very much!

2 8

Failed to create a TLS connection when a 'loose' tls_method is configured
by Leonid Fainshtein 28 Sep '22

28 Sep '22

Hi, I have a problem creating a TLS connection when tls_method is configured as one of the "loose" methods: SSLv23, TLSv1+, TLSv1.1+, TLSv1.2+. The problem doesn't happen when the tls_method is defined "strictly": TLSv1, TLSv1.1, or TLSv1.2. The problem is reproducible with the modern Yealink phones and also with sipexer. I have Kamailio v.5.5.4 installed from the Kamailio repo ( http://deb.kamailio.org/kamailio55), on Ubuntu 18.04, OpenSSL ver.1.1.1-1ubuntu2.1~18.04.20 The sipexer output: -------------------------- $ ./sipexer -register -vl 3 -co -com -ex 60 -fuser 2001 -cb -au 2001 -ap "......" -sd -sw 20000 -tk ./id_rsa tls:nnnnnnnnn.com:5061 [debug] [sipexer.go:912] main.main(): parsed socket address argument ({Val:tls:nnnnnnnnn.com:5061 Proto:tls Addr:nnnnnnnnn.com Port:5061 PortNo:5061 AType:8 ProtoId:3}) [debug] [sipexer.go:1800] main.SIPExerSendTLS(): client: 192.168.0.178:41586 connected to: 142.93.233.32:5061 [debug] [sipexer.go:1803] main.SIPExerSendTLS(): [48 130 1 34 48 13 6 9 42 134 72 134 247 13 1 1 1 5 0 3 130 1 15 0 48 130 1 10 2 130 1 1 0 222 21 229 237 77 230 193 157 183 132 186 194 65 98 162 250 243 232 189 223 115 181 41 199 130 221 201 143 254 218 254 201 82 173 233 44 158 103 150 78 210 162 187 138 5 179 11 47 208 0 117 27 186 180 197 229 94 13 63 72 227 27 169 127 197 173 67 52 182 68 140 220 132 20 241 57 24 182 29 234 58 60 214 145 225 29 251 240 190 159 43 233 53 57 121 159 81 4 200 12 193 90 91 158 78 196 25 202 74 111 106 215 164 12 178 120 129 8 81 1 245 181 149 20 47 197 165 74 126 24 249 241 187 197 249 209 192 11 204 254 110 19 248 79 122 11 131 24 101 155 237 110 186 5 214 88 79 255 185 156 52 12 29 222 254 76 71 171 142 28 69 22 34 31 111 105 87 7 108 68 6 23 199 236 134 154 42 208 199 158 190 48 193 192 179 120 189 199 117 71 104 231 127 73 128 91 234 168 175 207 55 6 191 144 209 25 10 182 27 53 182 182 96 248 198 206 220 207 102 236 194 96 67 159 34 112 81 145 2 166 207 86 247 232 117 126 158 214 215 10 226 68 81 235 169 81 2 3 1 0 1] <nil> [debug] [sipexer.go:1804] main.SIPExerSendTLS(): CN=nnnnnnnnn.com [debug] [sipexer.go:1803] main.SIPExerSendTLS(): [48 130 2 34....247 31 2 3 1 0 1] <nil> [debug] [sipexer.go:1804] main.SIPExerSendTLS(): CN=ZeroSSL RSA Domain Secure Site CA,O=ZeroSSL,C=AT [debug] [sipexer.go:1803] main.SIPExerSendTLS(): [48 130 2 34 48 ....130 15 2 3 1 0 1] <nil> [debug] [sipexer.go:1804] main.SIPExerSendTLS(): CN=USERTrust RSA Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US [debug] [sipexer.go:1806] main.SIPExerSendTLS(): client: handshake: true [debug] [sipexer.go:1807] main.SIPExerSendTLS(): client: mutual: true [info] [sipexer.go:1432] main.SIPExerDialogLoop(): local socket address: 192.168.0.178:41586 (tls) [info] [sipexer.go:1433] main.SIPExerDialogLoop(): local via address: 192.168.0.178:41586 [info] [sipexer.go:1434] main.SIPExerDialogLoop(): sending to tls 142.xx.yy.32:5061: [[--- REGISTER sip:nnnnnnnnn.com:5061;transport=tls SIP/2.0 Via: SIP/2.0/TLS 192.168.0.178:41586 ;rport;branch=z9hG4bKSG.f7a247eb-5440-4e7a-8a5a-4f849684f30d From: <sip:2001@nnnnnnnnn.com>;tag=33e66091-193c-4535-b659-d5e562aca5a4 To: <sip:2001@nnnnnnnnn.com> Call-ID: 4556156d-e8da-4632-82f7-f3ab3c4c73a1 CSeq: 621470 REGISTER Date: Sun, 04 Sep 2022 11:21:33 IDT Contact: <sip:192.168.0.178:41586;transport=tls> Expires: 60 User-Agent: SIPExer v1.0.2 Content-Length: 0 [info] [sipexer.go:1436] main.SIPExerDialogLoop(): ---]] [error] [sipexer.go:1312] main.SIPExerDialogReadBytes(): not receiving after 32000ms (bytes 0 - EOF) [debug] [sipexer.go:1009] main.SIPExerExit(): return code: -1154 The Kamailio debug log: --------------------------------- Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 46(25550) DEBUG: <core> [core/ip_addr.c:577]: print_ip(): tcpconn_new: new tcp connection: 207.232.46.53 Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 46(25550) DEBUG: <core> [core/tcp_main.c:1175]: tcpconn_new(): on port 18566, type 3, socket 72 Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 46(25550) DEBUG: <core> [core/tcp_main.c:1507]: tcpconn_add(): hashes: 1963:2250:2856, 16 Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 46(25550) DEBUG: <core> [core/io_wait.h:375]: io_watch_add(): processing io_watch_add(0x5648d2a55e40, 72, 2, 0x7f9dcaf01958) - fd_no=63 Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 46(25550) DEBUG: <core> [core/io_wait.h:600]: io_watch_del(): DBG: io_watch_del (0x5648d2a55e40, 72, -1, 0x0) fd_no=64 called Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 46(25550) DEBUG: <core> [core/tcp_main.c:4471]: handle_tcpconn_ev(): sending to child, events 1 Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 46(25550) DEBUG: <core> [core/tcp_main.c:4141]: send2child(): selected tcp worker idx:7 proc:45 pid:25549 for activity on [tls:142.xx.yy.32:5061], 0x7f9dcaf01958 Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: <core> [core/tcp_read.c:1737]: handle_io(): received n=8 con=0x7f9dcaf01958, fd=10 Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: tls [tls_server.c:244]: tls_complete_init(): completing tls connection initialization Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: tls [tls_server.c:274]: tls_complete_init(): Using initial TLS domain TLSs<default> (dom 0x7f9dc4c17078 ctx 0x7f9dc4c65da0 sn []) Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: tls [tls_domain.c:1208]: tls_lookup_private_key(): Private key lookup for SSL_CTX-0x7f9dc4c65da0: (nil) Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: tls [tls_domain.c:778]: sr_ssl_ctx_info_callback(): SSL handshake started Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: tls [tls_domain.c:979]: tls_server_name_cb(): received server_name (TLS extension): 'tmx.cpbxmt-demo187.xorcom.com' Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: tls [tls_domain.c:998]: tls_server_name_cb(): TLS cfg domain selected for received server name [tmx.cpbxmt-demo187.xorcom.com]: socket [:0] server name='' - switching SSL CTX to 0x7f9dc4c65da0 dom 0x7f9dc4c17078 (default) Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: <core> [core/tcp_main.c:2720]: tcpconn_do_send(): sending... Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: <core> [core/tcp_main.c:2753]: tcpconn_do_send(): after real write: c= 0x7f9dcaf01958 n=5435 fd=10 Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: <core> [core/tcp_main.c:2754]: tcpconn_do_send(): buf= Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: #026#003#003 Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: <core> [core/io_wait.h:375]: io_watch_add(): processing io_watch_add(0x5648d29e8c80, 10, 2, 0x7f9dcaf01958) - fd_no=1 Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: tls [tls_domain.c:1208]: tls_lookup_private_key(): Private key lookup for SSL_CTX-0x7f9dc4c65da0: (nil) Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: tls [tls_domain.c:790]: sr_ssl_ctx_info_callback(): SSL handshake done Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: tls [tls_domain.c:778]: sr_ssl_ctx_info_callback(): SSL handshake started Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: tls [tls_domain.c:782]: sr_ssl_ctx_info_callback(): SSL renegotiation initiated by client Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: tls [tls_domain.c:790]: sr_ssl_ctx_info_callback(): SSL handshake done Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: tls [tls_domain.c:778]: sr_ssl_ctx_info_callback(): SSL handshake started Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: tls [tls_domain.c:782]: sr_ssl_ctx_info_callback(): SSL renegotiation initiated by client Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: tls [tls_domain.c:790]: sr_ssl_ctx_info_callback(): SSL handshake done Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: tls [tls_server.c:470]: tls_accept(): TLS accept successful Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: tls [tls_server.c:477]: tls_accept(): tls_accept: new connection from 207.232.46.53:18566 using TLSv1.3 TLS_AES_256_GCM_SHA384 256 Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: tls [tls_server.c:480]: tls_accept(): tls_accept: local socket: 142.xx.yy.32:5061 Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: tls [tls_server.c:491]: tls_accept(): tls_accept: client did not present a certificate Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: tls [tls_server.c:1245]: tls_h_read_f(): Reading on a renegotiation of connection (n:-1) (2) Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: <core> [core/tcp_read.c:1503]: tcp_read_req(): EOF Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: <core> [core/io_wait.h:600]: io_watch_del(): DBG: io_watch_del (0x5648d29e8c80, 10, -1, 0x10) fd_no=2 called Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: <core> [core/tcp_read.c:1872]: handle_io(): removing from list 0x7f9dcaf01958 id 16 fd 10, state 2, flags 4018, main fd 72, refcnt 2 ([207.232.46.53]:18566 -> [207.232.46.53]:5061) Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: <core> [core/tcp_read.c:1656]: release_tcpconn(): releasing con 0x7f9dcaf01958, state -1, fd=10, id=16 ([207.232.46.53]:18566 -> [207.232.46.53]:5061) Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 45(25549) DEBUG: <core> [core/tcp_read.c:1660]: release_tcpconn(): extra_data 0x7f9dcaefe628 Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 46(25550) DEBUG: <core> [core/tcp_main.c:3573]: handle_tcp_child(): reader response= 7f9dcaf01958, -1 from 7 Sep 4 08:21:33 cpbxmt-demo187 kamailio[23878]: 46(25550) DEBUG: tls [tls_server.c:729]: tls_h_tcpconn_close_f(): Closing SSL connection 0x7f9dcaefe628 As far as I understood the log, the certificate was accepted but something wrong happened later. Any suggestion? Best regards, Leonid Fainshtein

2 3

No CDR is written on failover
by Björn Klasen 28 Sep '22

28 Sep '22

Hi Community, I'm experimenting with dmq to do dialog sync between two instances of Kamailio. This works great so far. When I did my first experiments I even could create a CDR when there was a failover. Since some Versions (we are now on Version 5.6.1) I just get a acc-request in log but no acc-cdr. In former versions this worked. Both server have the same configuration and both server writes cdrs when theres no failover. In case of a failover everything is fine, the dialogs are clean and thanks to dmq all needed variables are replicated between the server. There's just no cdr. I found nothing on the issue-page on github but maybe somebody knows something about it. BR Björn -- Björn Klasen, Senior Specialist (VoIP) TNG Stadtnetz GmbH, TNG-Technik Projensdorfer Str. 324 24106 Kiel・Deutschland T +49 431 7097-10 F +49 431 7097-555 bklasen(a)tng.de www.tng.de <http://www.tng.de> Executive board (Geschäftsführer): Dr. Sven Willert (CEO/Vorsitz), Helmut Gertz, Moritz Meis, Gunnar Peter, Sven Schade, Carsten Tolkmit Amtsgericht Kiel HRB 6002 KI USt-ID: DE225201428 Die Information über die Verarbeitung Ihrer Daten gemäß Artikel 12 DSGVO können Siehier <https://tng.de/privatkunden/datenschutz/>abrufen.

2 2

Kamailio + RTPEngine SIP Proxy...
by David Walsh 24 Sep '22

24 Sep '22

Hi Jerry, I just joined so am unsure if you are good to go now but thought I would post my config as I also have a Freeswitch environment which I have placed Kamailio in front of to act as a load-balancing proxy. I also managed to get RTPEngine proxying through it too. Here is the config, which I have created from Daniel’s default kamailio config. I have omitted the top portions of loading the modules and their settings. My dispatcher list is just a text file. I have two groups. One for registrations and outbound calls, and one for calls inbound coming from the FreeSwitch server. In the NATMANAGE route, I currently have RTP proxying disabled as my free switch servers have external IPs and I let them handle the rtp stream. On Freeswitch, I made the following changes to accomodate user/pass and IPAuth reg: Changes to the Freeswitch servers listed in the dispatcher file Edit /usr/local/freeswitch/conf/autoload_configs/acl.conf <list name="proxy" default="deny"> <node type="allow" cidr=“IP address of Kamailio/32"/> </list> Edit /usr/local/freeswitch/conf/sip-profiles/internal-private.xml (or the sip-profile you need to edit in your instance) <param name="apply-proxy-acl" value="proxy"/> #Add this line above the one below. This tells Freeswitch to look at the X-Auth-IP header which was inserted by Kamailio. <param name="apply-inbound-acl" value="domains"/> Then, restart freeswitch (with no active calls), service freeswitch restart # or rescan the profile / reloadxml I am not proxying RTP, however, I can un-comment out the stanza in the NATMANAGE route to get it to work. The biggest gotcha for me was I was trying to use fix_nated_register when handling NAT for registrations instead of: Fix_nated_contact() or the better set_contact_alias(). Using add_path_received(); in the Dispatcher just before sending to Freeswitch ensured all traffic returned to Kamailio too. I am unsure of the SUBSCRIBE/PRESENCE stuff for you but the route should go out via the Kamailio proxy with this. ---------------------------- # main request routing logic request_route { xlog("L_WARN", "--- Going to <$ru>. src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd;src_ip=$si\n"); # per request initial checks route(REQINIT); # NAT detection route(NATDETECT); if(ds_is_from_list("33")) { setflag(FLT_FS); #xlog("L_WARN", "This source $si is from the dispatcher list.\n"); } # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) { route(RELAY); } exit; } # handle retransmissions if (!is_method("ACK")) { if(t_precheck_trans()) { t_check_trans(); exit; } t_check_trans(); } # handle requests within SIP dialogs route(WITHINDLG); # record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE")) { xlog("L_WARN", "--- Going to <$ru>. src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd;src_ip=$si\n"); xlog("L_ALERT", "Marker 1\n"); record_route(); } # account only INVITEs if (is_method("INVITE")) { setflag(FLT_ACC); # do accounting } if (isflagset(FLT_FS)) { ##t_on_reply("EXTERNAL_REPLY"); route(FROM_FS); exit; } # handle presence related requests route(PRESENCE); # handle registrations route(REGISTRAR); if ($rU==$null) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; } # dispatch destinations route(DISPATCH); return; } route[FROM_FS] { #record_route(); #loose_route_preloaded(); route(DLGURI); route(RELAY); exit; } route[RELAY] { # enable additional event routes for forwarded requests # - serial forking, RTP relaying handling, a.s.o. if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) { if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH"); } if (is_method("INVITE|SUBSCRIBE|UPDATE")) { if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY"); } if (is_method("INVITE")) { if(!t_is_set("failure_route")) t_on_failure("MANAGE_FAILURE"); } if (!t_relay()) { sl_reply_error(); } exit; } #reply_route { # if(status == 403) { # xlog("L_WARN", "Forbidden from $si:$sp blah...\n"); # xlog("L_ALERT","ALERT: pike blocking $rm from $fu (IP:$si:$sp)\n"); # } #} onreply_route[LOGRPL] { if(status == 403) { xlog("L_ALERT", "$rs response. Consider banning AVP \"ipbancandidate\" is $avp(ipbancandidate) "); } } # Per SIP request initial checks route[REQINIT] { # no connect for sending replies # Enable tracing for SNGREP ##sip_trace(); ##setflag(24); # set_reply_no_connect(); # enforce symmetric signaling # - send back replies to the source address of request force_rport(); #!ifdef WITH_ANTIFLOOD # flood detection from same IP and traffic ban for a while # be sure you exclude checking trusted peers, such as pstn gateways # - local host excluded (e.g., loop to self) if(src_ip!=myself) { if($sht(ipban=>$si)!=$null) { # ip is already blocked xdbg("request from blocked IP - $rm from $fu (IP:$si:$sp)\n"); exit; } if (!pike_check_req()) { xlog("L_ALERT","ALERT: pike blocking $rm from $fu (IP:$si:$sp)\n"); $sht(ipban=>$si) = 1; exit; } } #!endif if($ua =~ "friendly|scanner|sipcli|sipvicious|VaxSIPUserAgent|pplsip|Hello\ SIP\ Automated") { # silent drop for scanners - uncomment next line if want to reply # sl_send_reply("200", "OK"); xlog("User agent is: $ua\n"); exit; } if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if(is_method("OPTIONS") && uri==myself && $rU==$null) { sl_send_reply("200","Keepalive"); exit; } if(!sanity_check("17895", "7")) { xlog("Malformed SIP message from $si:$sp\n"); exit; } } # Handle requests within SIP dialogs route[WITHINDLG] { if (!has_totag()) return; # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { xlog("L_INFO", "Routing before DLGURI\n"); route(DLGURI); if (is_method("BYE")) { setflag(FLT_ACC); # do accounting ... setflag(FLT_ACCFAILED); # ... even if the transaction fails } else if ( is_method("ACK") ) { # ACK is forwarded statelessly route(NATMANAGE); } else if ( is_method("NOTIFY") ) { # Add Record-Route for in-dialog NOTIFY as per RFC 6665. record_route(); } route(RELAY); exit; } if (is_method("SUBSCRIBE") && uri == myself) { # in-dialog subscribe requests route(PRESENCE); exit; } if ( is_method("ACK") ) { if ( t_check_trans() ) { # no loose-route, but stateful ACK; # must be an ACK after a 487 # or e.g. 404 from upstream server route(RELAY); exit; } else { # ACK without matching transaction ... ignore and discard exit; } } sl_send_reply("404","Not here"); exit; } # Handle SIP registrations route[REGISTRAR] { if(!is_method("REGISTER")) return; xlog("L_WARN", "--- Going to <$ru>. src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd;src_ip=$si\n"); add_path_received(); $avp(ipbancandidate) = $si; if(isflagset(FLT_NATS)) { setbflag(FLB_NATB); #!ifdef WITH_NATSIPPING # do SIP NAT pinging setbflag(FLB_NATSIPPING); #!endif } route(DISPATCH); if (!save("location")) { sl_reply_error(); } exit; } # Presence server route route[PRESENCE] { if(!is_method("PUBLISH|SUBSCRIBE")) return; sl_send_reply("404", "Not here"); exit; } # Caller NAT detection route[NATDETECT] { #!ifdef WITH_NAT if (nat_uac_test("19")) { if (is_method("REGISTER")) { #fix_nated_register(); Disabled as we proxy registrations #fix_nated_contact(); set_contact_alias(); ##add_contact_alias(); #fix_nated_sdp("3"); xlog("L_ALERT", "Nat Registration nat fixed.\n"); } else { if(is_first_hop()) { set_contact_alias(); xlog("L_ALERT", "Contact NAT fixed\n"); } } setflag(FLT_NATS); xlog("L_ALERT", "FLT_NATS flag set\n"); } #!endif return; } # RTPProxy control and signaling updates for NAT traversal route[NATMANAGE] { #!ifdef WITH_NAT if (is_request()) { if(has_totag()) { if(check_route_param("nat=yes")) { setbflag(FLB_NATB); } } } if (nat_uac_test("3")) { #fix_nated_contact(); set_contact_alias(); ##add_contact_alias(); force_rport(); } if (has_body("application/sdp") && nat_uac_test("8")) { fix_nated_sdp("11"); } if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) return; ###!ifdef WITH_RTPENGINE ## xlog("RTPEngine enabled\n"); ## if(nat_uac_test("8")) { ## xlog("RTP 1\n"); ## rtpengine_manage("SIP-source-address replace-origin replace-session-connection"); ## } else { ## rtpengine_manage("replace-origin replace-session-connection"); ## } ###!else ## if(nat_uac_test("8")) { ## rtpproxy_manage("co"); ## } else { ## rtpproxy_manage("cor"); ## } ###!endif if (is_request()) { if (!has_totag()) { if(t_is_branch_route()) { add_rr_param(";nat=yes"); xlog("Nat notation added!\n"); } } } if (is_reply()) { if(isbflagset(FLB_NATB)) { if(is_first_hop()) #fix_nated_contact(); set_contact_alias(); #add_contact_alias(); } } if(isbflagset(FLB_NATB)) { # no connect message in a dialog involving NAT traversal if (is_request()) { if(has_totag()) { set_forward_no_connect(); } } } #!endif return; } # URI update for dialog requests route[DLGURI] { #!ifdef WITH_NAT if(!isdsturiset()) { handle_ruri_alias(); xlog("L_INFO", "Routing in-dialog $rm from $fu to $du\n"); } #!endif return; } # Dispatch requests route[DISPATCH] { # round robin dispatching on gateways group '1' remove_hf_re("Subject|P-.*|X-.*"); append_hf("X-Auth-IP: $si\r\n"); #add_rr_param(";nat=yes"); t_on_reply("LOGRPL"); if(!ds_select_dst("1", "0")) { send_reply("404", "No destination"); exit; } #xdbg("--- SCRIPT: going to <$ru> via <$du> (attrs: $xavp(_dsdst_=>attrs))\n"); xlog("L_WARN", "--- Going to <$ru>. src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd;src_ip=$si; $RAi; $Ri;\n"); t_on_failure("RTF_DISPATCH"); route(RELAY); } # Try next destionations in failure route failure_route[RTF_DISPATCH] { if (t_is_canceled()) { exit; } # next DST - only for 500 or local timeout if (t_check_status("500") or (t_branch_timeout() and !t_branch_replied())) { if(ds_next_dst()) { xdbg("--- SCRIPT: retrying to <$ru> via <$du> (attrs: $xavp(_dsdst_=>attrs))\n"); t_on_failure("RTF_DISPATCH"); route(RELAY); exit; } } } # Manage outgoing branches branch_route[MANAGE_BRANCH] { xdbg("new branch [$T_branch_idx] to $ru\n"); xlog("L_ALERT", "Marker 20\n"); route(NATMANAGE); return; } # Manage incoming replies reply_route { if(!sanity_check("17604", "6")) { xlog("Malformed SIP response from $si:$sp\n"); drop; } return; } # Manage incoming replies in transaction context onreply_route[MANAGE_REPLY] { xdbg("incoming reply\n"); xlog("L_ALERT", "Marker 21\n"); if(status=~"[12][0-9][0-9]") { route(NATMANAGE); } # if (has_body("application/sdp")) { # rtpengine_manage(); # } return; } # Manage failure routing cases failure_route[MANAGE_FAILURE] { xlog("L_ALERT", "Marker 23\n"); route(NATMANAGE); if (t_is_canceled()) exit; #!ifdef WITH_BLOCK3XX # block call redirect based on 3xx replies. if (t_check_status("3[0-9][0-9]")) { t_reply("404","Not found"); exit; } #!endif #!ifdef WITH_BLOCK401407 # block call redirect based on 401, 407 replies. if (t_check_status("401|407")) { t_reply("404","Not found"); exit; } #!endif #!ifdef WITH_VOICEMAIL # serial forking # - route to voicemail on busy or no answer (timeout) if (t_check_status("486|408")) { $du = $null; route(TOVOICEMAIL); exit; } #!endif return; }

1 0

MANAGE_REPLY not getting replies to PRACK?
by Benoît Panizzon 23 Sep '22

23 Sep '22

Hi all On calls with privacy enabled to customers, I want to ensure no information is disclosed. Not even if one would capture packets. A PRACK and the 200 OK to a PRACK therefore may need the To and From Header changed. Unfortunately I seem not to be able to catch the 200 OK REPLY sent to a PRACK with t_on_reply. It looks like they somehow pass completely unprocessed through Kamailio (not completely Via Header are removed accordingly) Am I missing something? -- 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

Guide to set up Kamailio as an SBC
by Unai Rodriguez 23 Sep '22

23 Sep '22

Dear List, I’m new to Kamailio and would like to set it up as a standalone general purpose SBC. I’m having a hard time finding a guide specific for this. What can you recommend? Thank you so much With best wishes, Unai Rodriguez

2 1

app_python3 crash woes
by Alex Balashov 22 Sep '22

22 Sep '22

Hi, Some exceptions generated in Python script cause a harmless traceback in the logs, while others cause Kamailio to crash: Sep 22 06:28:34 proxy /usr/sbin/kamailio[3984]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 11 Sep 22 06:28:34 proxy /usr/sbin/kamailio[3957]: ALERT: <core> [main.c:783]: handle_sigs(): child process 3965 exited by a signal 11 Sep 22 06:28:34 proxy /usr/sbin/kamailio[3957]: ALERT: <core> [main.c:786]: handle_sigs(): core was generated (gdb) where #0 0x00007fdaea729079 in vfprintf () from /lib64/libc.so.6 #1 0x00007fdaea754179 in vsnprintf () from /lib64/libc.so.6 #2 0x00007fdac45e9afd in make_message () from /usr/lib64/kamailio/modules/app_python3.so #3 0x00007fdac45e5bc9 in python_handle_exception () from /usr/lib64/kamailio/modules/app_python3.so #4 0x00007fdac45ebfde in apy_exec () from /usr/lib64/kamailio/modules/app_python3.so #5 0x00007fdac45ecef1 in python_exec2 () from /usr/lib64/kamailio/modules/app_python3.so #6 0x0000000000474ee0 in do_action () #7 0x000000000048217d in run_actions () #8 0x0000000000474d39 in do_action () #9 0x000000000048217d in run_actions () #10 0x0000000000474d39 in do_action () #11 0x000000000048217d in run_actions () #12 0x0000000000474d87 in do_action () #13 0x000000000048217d in run_actions () #14 0x00000000004828c1 in run_top_route () #15 0x00000000005e8044 in receive_msg () #16 0x00000000004df772 in udp_rcv_loop () #17 0x0000000000429f5b in main_loop () #18 0x000000000043423e in main () Is there a reasonable way to try to prevent this type of mid-air explosion? — Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

2 2

SIPp uas(SIPp)->client reINVITE late offer
by David Villasmil 20 Sep '22

20 Sep '22

Hello all, Anyone got a SIPp scenario for reINVITE with late offer? I.e.: UAT--->INVITE (sdp)--->SIPp UAT<--- 100 <---SIPp UAT<--- 183 <---SIPp UAT<--- 200 OK <---SIPp UAT----> ACK --->SIPp UAT<--- INVITE (NO sdp) <---SIPp UAT---> 100 --->SIPp UAT---> 183 --->SIPp UAT---> 200 OK (sdp) -->SIPp UAT<--- ACK (sdp) <---SIPp UAT---> BYE -->SIPp UAT<--- ACK <--SIPp I can’t get past UAT<--- INVITE (NO sdp) <---SIPp Kamailio responds with “not here” Appreciate the help! -- Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

3 4

Substdef syntax change?
by Fredrik Dahlgren 20 Sep '22

20 Sep '22

Hi, I'm looking at a kamailio config where all substdef have the syntax "!regexp!subst!flags", "!DB_URL!db.example.com!g" but i can't find this syntax in the documentation. It's currently running on a fairly modern 5.x version and as far as i know it has never been on 4.x or older. Does anyone know where this syntax is from and if it's possible/recommended to simply replace it with "/regexp/subst"? *Fredrik* *Dahlgren* | Senior SIP/VoIP Engineer fredrik.dahlgren(a)freespee.com | LinkedIn <https://www.linkedin.com/company/freespee/> | Twitter <https://twitter.com/freespee>

2 1

Kamailio stops processing requests mid script
by Joel Serrano 20 Sep '22

20 Sep '22

Hello, I have a cluster of 2 kamailios v5.5 on debian 9 working flawlessly. We have added a third node, also on v5.5 but debian 11. Kamailio doesn't work correctly for some reason that I'm not seeing. The symptoms are: 1- Kamailio receives INVITEs and starts to process them per routing script. 2- There is a specific place where something happens and the calls are dropped (Kamailio is not even replying to the source). Note that the config is exactly the same on all 3 servers, only one of the three is having the issue. I enabled debug logs and I could see: [...] Sep 10 12:30:48 sbc03 sbc[956340]: exec: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.example.com} *** cfgtrace:dbg_cfg_trace(): request_route=[GET_OUTBOUND_API_DATA] c=[/etc/kamailio/sbc/api.cfg] l=61 a=5 n=route Sep 10 12:30:48 sbc03 sbc[956340]: exec: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.example.com} *** cfgtrace:dbg_cfg_trace(): request_route=[APPLY_REWRITE_RULE] c=[/etc/kamailio/sbc/extras.cfg] l=211 a=26 n=xlog Sep 10 12:30:48 sbc03 sbc[956340]: INFO: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <script>: Applying local to toll-free rewrite rules on callee number using dpid '20' Sep 10 12:30:48 sbc03 sbc[956340]: exec: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} *** cfgtrace:dbg_cfg_trace(): request_route=[APPLY_REWRITE_RULE] c=[/etc/kamailio/sbc/extras.cfg] l=212 a=63 n=assign Sep 10 12:30:48 sbc03 sbc[956340]: exec: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} *** cfgtrace:dbg_cfg_trace(): request_route=[APPLY_REWRITE_RULE] c=[/etc/kamailio/sbc/extras.cfg] l=219 a=16 n=if Sep 10 12:30:48 sbc03 sbc[956340]: exec: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} *** cfgtrace:dbg_cfg_trace(): request_route=[APPLY_REWRITE_RULE] c=[/etc/kamailio/sbc/extras.cfg] l=213 a=26 n=dp_translate Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dialplan.c:237]: dp_get_ivalue(): searching 15 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dialplan.c:245]: dp_get_ivalue(): dpid is 20 from pv argument Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dialplan.c:254]: dp_get_svalue(): searching 15 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dialplan.c:350]: dp_translate_f(): input is 67339924 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dp_repl.c:605]: dp_translate_helper(): regex operator testing over [67339924] Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dp_repl.c:605]: dp_translate_helper(): regex operator testing over [67339924] Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dp_repl.c:605]: dp_translate_helper(): regex operator testing over [67339924] Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dp_repl.c:605]: dp_translate_helper(): regex operator testing over [67339924] Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dp_repl.c:605]: dp_translate_helper(): regex operator testing over [67339924] Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dp_repl.c:605]: dp_translate_helper(): regex operator testing over [67339924] Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dp_repl.c:605]: dp_translate_helper(): regex operator testing over [67339924] Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dp_repl.c:605]: dp_translate_helper(): regex operator testing over [67339924] Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dp_repl.c:605]: dp_translate_helper(): regex operator testing over [67339924] Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dp_repl.c:605]: dp_translate_helper(): regex operator testing over [67339924] Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dp_repl.c:605]: dp_translate_helper(): regex operator testing over [67339924] Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dp_repl.c:605]: dp_translate_helper(): regex operator testing over [67339924] Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dp_repl.c:605]: dp_translate_helper(): regex operator testing over [67339924] Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dp_repl.c:605]: dp_translate_helper(): regex operator testing over [67339924] Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dp_repl.c:605]: dp_translate_helper(): regex operator testing over [67339924] Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dp_repl.c:605]: dp_translate_helper(): regex operator testing over [67339924] Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dp_repl.c:605]: dp_translate_helper(): regex operator testing over [67339924] Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dp_repl.c:605]: dp_translate_helper(): regex operator testing over [67339924] Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dp_repl.c:605]: dp_translate_helper(): regex operator testing over [67339924] Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dp_repl.c:605]: dp_translate_helper(): regex operator testing over [67339924] Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dp_repl.c:605]: dp_translate_helper(): regex operator testing over [67339924] Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dp_repl.c:605]: dp_translate_helper(): regex operator testing over [67339924] Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dp_repl.c:605]: dp_translate_helper(): regex operator testing over [67339924] Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dp_repl.c:676]: dp_translate_helper(): no matching rule Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialplan [dialplan.c:354]: dp_translate_f(): could not translate 67339924 with dpid 20 Sep 10 12:30:48 sbc03 sbc[956340]: exec: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} *** cfgtrace:dbg_cfg_trace(): request_route=[APPLY_REWRITE_RULE] c=[/etc/kamailio/sbc/extras.cfg] l=217 a=26 n=xlog Sep 10 12:30:48 sbc03 sbc[956340]: INFO: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <script>: No matching rewrite rules for '67339924' found Sep 10 12:30:48 sbc03 sbc[956340]: exec: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} *** cfgtrace:dbg_cfg_trace(): request_route=[APPLY_REWRITE_RULE] c=[/etc/kamailio/sbc/extras.cfg] l=218 a=2 n=return Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [core/receive.c:514]: receive_msg(): request-route executed in: 12245 usec Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialog [dlg_hash.c:785]: dlg_lookup_mode(): ref dlg 0x7ff1b4884b48 with 1 -> 2 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialog [dlg_hash.c:789]: dlg_lookup_mode(): dialog id=8614 found on entry 343 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialog [dlg_var.c:63]: dlg_cfg_cb(): new dialog with no transaction after config execution Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialog [dlg_hash.c:1091]: dlg_unref_helper(): unref op on 0x7ff1b4884b48 with 1 from dlg_hash.c:1109 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialog [dlg_hash.c:1095]: dlg_unref_helper(): unref dlg 0x7ff1b4884b48 with 1 -> 1 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialog [dlg_hash.c:1091]: dlg_unref_helper(): unref op on 0x7ff1b4884b48 with 1 from dlg_hash.c:1109 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialog [dlg_hash.c:1095]: dlg_unref_helper(): unref dlg 0x7ff1b4884b48 with 1 -> 0 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialog [dlg_hash.c:1095]: dlg_unref_helper(): ref <=0 for dialog 0x7ff1b4884b48 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialog [dlg_hash.c:345]: destroy_dlg(): destroying dialog 0x7ff1b4884b48 (ref 0) Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialog [dlg_hash.c:356]: destroy_dlg(): removed timer for dlg 0x7ff1b4884b48 [343:8614] with clid '5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa' and tags 'as5d31c96b' '' Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialog [dlg_db_handler.c:708]: remove_dialog_from_db(): trying to remove dialog [ 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa], update_flag is 1024 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [db_query.c:72]: db_do_submit_query(): submitted query: delete from `dialog` where `hash_entry`=343 AND `hash_id`=8614, result 0 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [db_query.c:72]: db_do_submit_query(): submitted query: delete from `dialog_vars` where `hash_entry`=343 AND `hash_id`=8614, result 0 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialog [dlg_db_handler.c:736]: remove_dialog_from_db(): callid was 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list 0x7ff1b4880370 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [core/receive.c:606]: receive_msg(): cleaning up If I go to line 61 from route GET_OUTBOUND_API_DATA, I have this: if(route(APPLY_REWRITE_RULE)) { $rU = $var(dp_user); $avp(icx_real_number) = $var(dp_user); } The very next thing is: # Query API $avp(apiUrl) = "{{ call_api_url }}/outbound/" + $avp(icx_src_number) + "/" + $avp(icx_real_number); http_client_query("$avp(apiUrl)", "$avp(apiResponseBody)"); $avp(apiResponseCode) = $rc; I see the GET_OUTBOUND_API_DATA route calling APPLY_REWRITE_RULE, and APPLY_REWRITE_RULE returning correctly then finished: Sep 10 12:30:48 sbc03 sbc[956340]: exec: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} *** cfgtrace:dbg_cfg_trace(): request_route=[APPLY_REWRITE_RULE] c=[/etc/kamailio/sbc/extras.cfg] l=218 a=2 n=return But then Kamailio is apparently just tearing down the call and ending it. Can someone help me understand what this part of the logs means or what can be causing them? Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [core/receive.c:514]: receive_msg(): request-route executed in: 12245 usec Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialog [dlg_hash.c:785]: dlg_lookup_mode(): ref dlg 0x7ff1b4884b48 with 1 -> 2 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialog [dlg_hash.c:789]: dlg_lookup_mode(): dialog id=8614 found on entry 343 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialog [dlg_var.c:63]: dlg_cfg_cb(): new dialog with no transaction after config execution Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialog [dlg_hash.c:1091]: dlg_unref_helper(): unref op on 0x7ff1b4884b48 with 1 from dlg_hash.c:1109 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialog [dlg_hash.c:1095]: dlg_unref_helper(): unref dlg 0x7ff1b4884b48 with 1 -> 1 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialog [dlg_hash.c:1091]: dlg_unref_helper(): unref op on 0x7ff1b4884b48 with 1 from dlg_hash.c:1109 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialog [dlg_hash.c:1095]: dlg_unref_helper(): unref dlg 0x7ff1b4884b48 with 1 -> 0 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialog [dlg_hash.c:1095]: dlg_unref_helper(): ref <=0 for dialog 0x7ff1b4884b48 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialog [dlg_hash.c:345]: destroy_dlg(): destroying dialog 0x7ff1b4884b48 (ref 0) Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialog [dlg_hash.c:356]: destroy_dlg(): removed timer for dlg 0x7ff1b4884b48 [343:8614] with clid '5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa' and tags 'as5d31c96b' '' Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialog [dlg_db_handler.c:708]: remove_dialog_from_db(): trying to remove dialog [ 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa], update_flag is 1024 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [db_query.c:72]: db_do_submit_query(): submitted query: delete from `dialog` where `hash_entry`=343 AND `hash_id`=8614, result 0 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [db_query.c:72]: db_do_submit_query(): submitted query: delete from `dialog_vars` where `hash_entry`=343 AND `hash_id`=8614, result 0 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} dialog [dlg_db_handler.c:736]: remove_dialog_from_db(): callid was 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list 0x7ff1b4880370 Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) Sep 10 12:30:48 sbc03 sbc[956340]: DEBUG: {1 102 INVITE 5111a7c71ec485e443099844491ef7d8(a)sip02.vozelia.com.pa} <core> [core/receive.c:606]: receive_msg(): cleaning up I can see it's related to the dialogs, but is this a cause or a consequence? I have checked the API access logs, and Kamailio doesn't get to send the request, I've also noticed that normally Kamailio replies with a 100-Trying almost instantly, in the case of this server I don't see a single 100-Trying from Kamailio. I'm pretty lost here so any tips are more than welcome. NOTE: I tried with debian11 + Kamailio 5.6 and the same issue happens too. Thanks, Joel.

4 12

Kamailio v5.5.5 Released
by Daniel-Constantin Mierla 19 Sep '22

19 Sep '22

Hello, Kamailio SIP Server v5.5.5 stable release is out. This is a maintenance release of the stable branch 5.5 that includes fixes since the release of v5.5.4. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.5.x. Deployments running previous v5.5.x versions are strongly recommended to be upgraded to v5.5.5. Note that 5.5 is the second last stable branch, still officially maintained by Kamailio development team. The latest stable branch is 5.6, with v5.6.1 being release out of it. For more details about version 5.5.5 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2022/09/kamailio-v5-5-5-released/ RPM, Debian/Ubuntu packages will be available soon as well. Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online Oct 10-13, 2022 (Europe Timezone) * https://www.asipto.com/sw/kamailio-advanced-training-online/

1 0

Database changes required for upgrading from 5.5 to 5.6
by Leonid Fainshtein 19 Sep '22

19 Sep '22

Hi, Instructions for upgrading from 5.5 to 5.6 don't include instructions for the MySQL database schema changes: http://www.kamailio.org/wiki/install/upgrade/5.5.x-to-5.6.0 Where can I get this information? It was always published in the past. Best regards, Leonid Fainshtein

3 3

Releasing Kamailio v5.5.5
by Daniel-Constantin Mierla 19 Sep '22

19 Sep '22

Hello, I am considering to release Kamailio v5.5.5 soon, likely on Monday or Tuesday next week (Sep 19 or 20, 2022). 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 Kamailio Advanced Training - Online Oct 10-13, 2022 (Europe Timezone) * https://www.asipto.com/sw/kamailio-advanced-training-online/

1 1

Log levels severely impacts performance
by Amit 16 Sep '22

16 Sep '22

Hello, We’ve been running Kamailio 5.5.0 for a while now and recently ran into an issue where the application buffer would get full and Kamailio has a lot of difficulty keeping up with REG requests. This severely impacted Kamailio’s ability to perform and resulted in many REG timeouts. Running ‘watch netstat -ulpn’ revealed the buffer issue. We usually run the production system at log level INFO (2) and had not ran into any issues in the past. When the buffer issue occurred and after some testing, we discovered that changing the log level to NOTICE (1) was sufficient to bring the system back into operational status. For example, at log level INFO (2) we seem to achieve ~150-200 REG/s while at log level NOTICE (1) we reach ~500-700 REG/s. I did find this article in the wiki and tried using the “-“ in front of the log path but this didn’t seem to help. http://www.kamailio.org/wiki/tutorials/3.2.x/syslog Even writing the logs directly to our external log server and preventing them from being written to the local disk doesn’t seem to alleviate the issue when the log level is set to INFO (2). Does anyone have any experience with this or have any suggestions? We are finding it difficult to scale as a result of this issue. Thank you in advance. Amit

7 20

TM Module, avp not present during handling of ack, prack and cancel?
by Benoît Panizzon 16 Sep '22

16 Sep '22

Hi List If I'm correctly reading the documentation, all avp variables should exist during a transaction until it's final ACK. ACK, PRACK and CANCEL are part of that transaction. But I seem not to be able to access the content of avp during those messages. Strangely during MANAGE_REPLY of the 487 following a cancel, the avp are present so that 487 clearly is part of the transaction. What am I missing? (Yes, I am still working on mirroring al username (phone number) translations and filtering unwanted header to prevent information leakage, any hints welcome if there is a simpler way to achieve this) -- 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 ______________________________________________________

2 1

Modules changes query
by Satyaprakash Chiramchetty 16 Sep '22

16 Sep '22

Hi team, I have added a few lines more in the SCA module, So if I want to compile again only the sca, So what command I need to use? Thanks and Regards, Satyaprakash. -- * <https://www.ecosmob.com/> * *Disclaimer* In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded. *Confidentiality* This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error. *Caution for viruses, malware etc.* This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.

2 1

Kamailio v5.4.9 Released
by Daniel-Constantin Mierla 16 Sep '22

16 Sep '22

Hello, Kamailio SIP Server v5.4.9 stable release is out. This is a maintenance release of the old stable branch, 5.4, that includes fixes since the release of v5.4.8. 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.9 or even better to v5.5.x or 5.6.x series. For more details about version 5.4.9 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2022/09/kamailio-v5-4-9-released/ RPM, Debian/Ubuntu packages will be available soon as well. Note: the branch 5.4 is an old stable branch, v5.4.9 being the last planned release out of it, to mark the end of official maintenance. The maintained stable branches are now 5.5 and 5.6, at this time with v5.6.1 being the latest stable release. 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

1 0

Releasing Kamailio v.5.4.9
by Daniel-Constantin Mierla 16 Sep '22

16 Sep '22

Hello, I am planning to release a new version from branch 5.4, respectively 5.4.9, sometime soon, maybe on Friday or Monday. Unless a major regression comes out with this release, this is going to be the last official packaged version from branch 5.4. The latest two stable branches 5.5 and 5.6 will be maintained further. As usual, if anyone is aware of issues not yet reported to bug tracker or missing backports, report them in order to try to get the fixes in this release. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

1 1

ndb_redis value substitution or escaping spaces
by Brooks Bridges 15 Sep '22

15 Sep '22

I am aware of, and have used sucessfully, the %s substitution option in redis_cmd, however when trying to do 4 values I'm getting a parse error about too many arguments. A review of the module's source appears to indicate that there is a hard limit of 3 substitution values when using this method. Is there a suitable workaround anyone has for this to enable insertion of values with spaces in them that won't get interpreted by Kamailio itself? Escaping the value, even by using $_s to eval a dynamic string, ends up with Kamailio itself apparently trying to parse the escape and breaking things further. Thanks! Confidentiality Notice: This e-mail, and any attachment to it, contains privileged and confidential information intended only for the use of the individual(s) or entity named on the e-mail. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that reading this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system.

2 5

New feature: #!ifexp - conditional preprocessor blocks
by Daniel-Constantin Mierla 15 Sep '22

15 Sep '22

Hello, a new feature has landed to Kamailio devel version, bringing in more flexibility for preprocessing of the kamailio.cfg file. It is about #!ifexp, which allows to evaluate an expression created with defined IDs, string and number values. Based on evaluation result, being true or false, parts of the config file can be enabled or disabled. An extensive number of operators can be used in expressions, such as: +, -, *, /, ==, !=, <, >, <=, >=, ||, &&, etc. The evaluation is done using snexpr (https://github.com/miconda/snexpr), which was embedded inside Kamailio code. Here are some simple kamailio.cfg examples: #!ifexp KAMAILIO_VERSION >= 5006000 loadmodule "tlsa.so" #!else loadmodule "tls.so" #!endif #!ifexp MOD_xlog && (OS_NAME == "darwin") xlog("running on MacOS\n"); #!endif Documentation and more examples can be found on the wiki portal at: - https://www.kamailio.org/wikidocs/cookbooks/devel/core/#ifexp Testing would be appreciated, feedback can be addressed to sr-users mailing list! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

1 0

kamailio.org short unavailability
by Daniel-Constantin Mierla 15 Sep '22

15 Sep '22

Hello, kamailio.org system needs a reboot and it will become unavailable for a short time frame about 08:00UTC (20 min from now). Website, mailing list, wiki, and a few other web services will be affected. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

1 1

evapi_async_relay() and workers
by Alex Balashov 14 Sep '22

14 Sep '22

Hi, When a transaction suspended by evapi_async_relay() is resumed, in which child processes is it resumed? Is it in the dedicated “EVAPI RELAY” workers defined by the ‘workers’ modparam to ‘evapi’? If this is so, just trying to work out the concurrency implications and the optimal size for the worker pool for maximal throughput. It sounds, at first glance, like it should be roughly similar to the sizing considerations for listener children. Thoughts welcome! Cheers, — Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

2 3

Kamailio + RTPEngine SIP Proxy...
by Jerry Kendall 12 Sep '22

12 Sep '22

Hi There, It's been a few years since I joind the group and I have watched and learnt and played but, I am stuck... I have searched hi & low but I can't seem to find what I am looking for. Is is do-able to have SIP Phones proxy through Kamailio/RTPengine and have the connection relayed to a freeswitch system where all the work is done. I need to have Kamailio act as proxy ONLY - no need to do AUTH, and I need Kamilio to have the RTPEngine have the media but only as proxy. I have FreeSWITCH doing all the IVR/VM/CONF/etc.... So: 1) The SIP Phone sends everything to the Kamailio system, the Kamailio system will relay everything to the FreeSWITCH system (requests and replies) 2) The FreeSWITCH system will send everything to the Kamailio system which will relay everything back to the SIP Phone (requests and replies) 3) The SIP phones are behind NAT 4) The Kamailio and FreeSWITCH systems are on the public internet with public IP addresses I have found a few sample kamailio.cfg files but, I can get REG to make it through but no SUBCRIBE wont get NOTIFYs back, etc... I seem to get parts but not all the way. If this is doable, and I assume it is, is there a config file someone can share with me? or point me to? Jerry

3 6

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