sr-users

sr-users@lists.kamailio.org

37388 discussions

BLF when phone boots up
by Jerry Kendall 17 Sep '21

17 Sep '21

Hi, I have looked at lots of postings but can't seem to find the answer I seek. I have 6 phones (Grandstream GXP2170, etc) connected to Kamailio 5.2.1 running default config file with changes per https://kb.asipto.com/kamailio:presence:k43-blf On x301, I have the 3 BLFs setup to monitor x302, x303 and x304. If I dial 303 from 301, the BLFs work (flash, red, then green) as expected. But, when the phone initially boots up, the BLFs are all dead - until the first PUBLISH event. So, the question is, how do I get the BLFs to become valid and with the correct status when the phone boots up??? regards, Jerry

1 0

listen directive during runtime
by Tihomir Culjaga 17 Sep '21

17 Sep '21

Hi, is it possible to add a listen directive during kamailio runtime ? The reason I'm asking this is in a situation when I add a new peering trunk (from a different network segment), I need to add a network interface to the kamailio server and then add a specific listen directive for that interface to reference the socket by name. listen=udp:10.1.1.11 name "mySN1" so i can further reference to a specific socket name when routing SIP messages. Please advise, Regards, Tihomir.

2 1

Re: [SR-Users] DMQ module issues
by Zé Santos 17 Sep '21

17 Sep '21

I don't think you understood. The issue is in v5.2.5, and I tried to update kamailio but it still remains. I honestly think this is a machine problem, since I can't even send the notifications to 0.0.0.0:5090. It is very weird. Best Regards, José Santos

2 3

xmlrpc always returns NO RESULT
by 岩間理佐 17 Sep '21

17 Sep '21

Hi, I have a question regarding the XMLRPC commands in the siremis GUI. 【Environment】・Centos7 ・kamailio 5.5.2 ・siremis 5.3 （installed by git clone https://github.com/asipto/siremis siremis-5.3.x）・php: $ rpm -qa | grep php php-process-5.4.16-48.el7.x86_64 php-common-5.4.16-48.el7.x86_64 php-mysqlnd-5.4.16-48.el7.x86_64 php-pdo-5.4.16-48.el7.x86_64 php-xml-5.4.16-48.el7.x86_64 php-cli-5.4.16-48.el7.x86_64 php-5.4.16-48.el7.x86_64 php-pear-1.9.4-22.el7.noarch ・apache 2.4.6 When I execute commands in command service → XMLPRC from siremis GUI, it always shows no result. It looks like the command is not being executed. I also executed these commands on server, and there are no problem. There is no error in apache log and kamailio is also working. This is what I have in /etc/kamailio/kamailio.cfg #!KAMAILIO #!define WITH_XMLRPC #!define WITH_DEBUG #!define DBURL "mysql://kamailio:kamailiorw@localhost/kamailio" # - flags #FLT_ - per transaction (message) flags #FLB_ - per branch flags #!define FLT_ACC 1 #!define FLT_ACCMISSED 2 #!define FLT_ACCFAILED 3 #!define WITH_MYSQL #!define WITH_NAT ####### Global Parameters ######### #!ifdef WITH_DEBUG debug=4 log_stderror=yes #!else debug=2 log_stderror=no #!endif #!ifdef WITH_MYSQL loadmodule "db_mysql.so" #!endif #!ifdef WITH_NAT loadmodule "nathelper.so" #!ifdef WITH_RTPENGINE loadmodule "rtpengine.so" #!else loadmodule "rtpproxy.so" #!endif #!endif #!ifdef WITH_JSONRPC loadmodule "xhttp.so" #!endif memdbg=5 memlog=5 log_facility=LOG_LOCAL0 fork=yes children=4 disable_tcp=yes auto_aliases=no port=5060 listen=udp:172.23.0.246:5060 advertise 52.69.75.254:5060 sip_warning=no ####### Modules Section ######## # set module path #mpath="/usr/local/lib/kamailio/modules/" #loadmodule "db_mysql.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "acc.so" loadmodule "dispatcher.so" loadmodule "uac.so" loadmodule "sqlops" loadmodule "rtimer" loadmodule "jsonrpcs.so" loadmodule "kex.so" loadmodule "corex.so" # ----- jsonrpcs params ----- modparam("jsonrpcs", "pretty_format", 1) modparam("jsonrpcs", "dgram_socket", "/var/run/kamailio/kamailio_rpc.sock") modparam("jsonrpcs", "dgram_mode", 0666) modparam("jsonrpcs", "dgram_user", "kamailio") modparam("jsonrpcs", "dgram_group", "kamailio") modparam("jsonrpcs", "transport", 0) # ----- xmlrpc params ----- #modparam("xmlrpc", "route", "XMLRPC") #modparam("xmlrpc", "url_match", "^/RPC") # ----- rr params ----- modparam("rr", "append_fromtag", 1) # ----- R Timer ----- modparam("rtimer", "timer", "name=cdr;interval=300;mode=1;") modparam("rtimer", "exec", "timer=cdr;route=CDRS") # ----- acc params ----- modparam("acc", "log_flag", FLT_ACC) modparam("acc", "failed_transaction_flag", FLT_ACCFAILED) modparam("acc", "log_extra", "src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd;src_ip=$si") # ----- tm params ----- modparam("tm", "fr_timer", 2000) modparam("tm", "fr_inv_timer", 40000) modparam("tm", "auto_inv_100_reason", "Trying") # ----- dispatcher params ----- modparam("dispatcher", "db_url", DBURL) modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "flags", 2) modparam("dispatcher", "xavp_dst", "_dsdst_") modparam("dispatcher", "xavp_ctx", "_dsctx_") modparam("dispatcher", "ds_ping_from", "sip:proxy@52.69.75.254") modparam("dispatcher", "ds_ping_interval", 60) modparam("dispatcher", "ds_probing_mode", 1) modparam("dispatcher", "ds_timer_mode", 1) modparam("dispatcher", "xavp_dst_mode", 0) modparam("dispatcher", "ds_ping_latency_stats", 1) modparam("dispatcher", "ds_ping_method", "OPTIONS") modparam("dispatcher", "ds_probing_threshold", 10) modparam("dispatcher", "ds_inactive_threshold", 10) modparam("dispatcher", "ds_ping_reply_codes","class=2;code=403;code=404;code=484;class=3") # ----- uac params ----- modparam("uac", "reg_db_url", DBURL) modparam("uac", "reg_contact_addr", "52.69.75.254") modparam("uac", "reg_db_table", "uacreg") # ----- mysql ----- modparam("sqlops", "sqlcon","cb=>mysql://kamailio:kamailiorw@localhost/kamailio") ####### Routing Logic ######## # main request routing logic request_route { # per request initial checks route(REQINIT); # 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); ### only initial requests (no To tag) # record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE")) { record_route(); } # account only INVITEs if (is_method("INVITE")) { setflag(FLT_ACC); # do accounting } # 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); } route[RELAY] { if (!t_relay()) { sl_reply_error(); } exit; } # Per SIP request initial checks route[REQINIT] { if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if(!sanity_check("1511", "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()) { if (is_method("BYE")) { setflag(FLT_ACC); # do accounting ... setflag(FLT_ACCFAILED); # ... even if the transaction fails } route(RELAY); } if (is_method("SUBSCRIBE") && uri == myself) { # in-dialog subscribe requests route(PRESENCE); } if ( is_method("ACK") ) { if ( t_check_trans() ) { t_relay(); exit; } else { exit; } } sl_send_reply("404","Not here"); exit; } # Handle SIP registrations route[REGISTRAR] { if(!is_method("REGISTER")) return; sl_send_reply("404", "No registrar"); exit; } # Presence server route route[PRESENCE] { if(!is_method("PUBLISH|SUBSCRIBE")) return; sl_send_reply("404", "Not here"); exit; } # Dispatch requests route[DISPATCH] { # round robin dispatching on gateways group '1' if(!ds_select_dst("1", "11")) { send_reply("404", "No destination"); exit; } xdbg("--- SCRIPT: going to <$ru> via <$du> (attrs: $xavp(_dsdst_=>attrs))\n"); t_on_failure("RTF_DISPATCH"); route(RELAY); exit; } # 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|486") 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; } } } I have tried my best to do some researches about it, but still stuck. Any help is appreciated. Thank you!

2 1

problem with LRKProxy module
by hamed r 16 Sep '21

16 Sep '21

Hello I have problem with lrkproxy module. First, I installed the packages from the link below : https://github.com/mojtabaesfandiari/pylrkproxy And the service was properly listened to the local ip (192.168.51.106:22333 ). In the next step, the parameters were added to the kamalio.cfg file : loadmodule "lrkproxy.so" modparam("lrkproxy", "lrkproxy_sock", "udp:192.168.51.106:22333") I also changed the /etc/pylrkproxy/pylrkproxy.ini to set local ip. But when I make a call, the ip inside the sdp not change. And the following error is displayed in the syslog: Sep 4 07:18:05 debian /usr/local/sbin/kamailio[1724]: INFO: {1 2 INVITE NzA0NmU0YTYwNWNkNzAwOWJiOTUyOWQ5ODhjNjRhNzk.} lrkproxy [lrkproxy.c:1507]: lrkproxy_force(): Here is SIP_REQUEST & METHOD_INVITE Sep 4 07:18:05 debian /usr/local/sbin/kamailio[1724]: ERROR: {1 2 INVITE NzA0NmU0YTYwNWNkNzAwOWJiOTUyOWQ5ODhjNjRhNzk.} lrkproxy [lrkproxy.c:1084]: select_lrkp_node(): script error -no valid set selected Sep 4 07:18:05 debian /usr/local/sbin/kamailio[1724]: ERROR: {1 2 INVITE NzA0NmU0YTYwNWNkNzAwOWJiOTUyOWQ5ODhjNjRhNzk.} lrkproxy [lrkproxy.c:1513]: lrkproxy_force(): can't ping any lrk proxy right now. Sep 4 07:18:07 debian /usr/local/sbin/kamailio[1723]: INFO: {2 2 INVITE NzA0NmU0YTYwNWNkNzAwOWJiOTUyOWQ5ODhjNjRhNzk.} lrkproxy [lrkproxy.c:1625]: lrkproxy_force(): Here is SIP_REPLY of METHOD_INVITE Sep 4 07:18:07 debian /usr/local/sbin/kamailio[1723]: ERROR: {2 2 INVITE NzA0NmU0YTYwNWNkNzAwOWJiOTUyOWQ5ODhjNjRhNzk.} lrkproxy [lrkproxy.c:1630]: lrkproxy_force(): No found entry in hash table

2 1

DMQ module issues
by Zé Santos 16 Sep '21

16 Sep '21

Hi guys, I am currently using kamailio v5.2.5 and running it inside a container. I already attempted to upgrade the kamailio to the latest version however the problem persists. This is the core dump that I got from using gdb: Core was generated by `/usr/sbin/kamailio -f > /etc/kazoo/kamailio/kamailio.cfg -m 512 -M 64 -x tlsf -w'. > Program terminated with signal 11, Segmentation fault. > #0 0x000000000071c63c in select_cfg_var (res=0x7ffd57d49b10, > s=0x7f2649395040, msg=0x7ffd57d4c340) at core/cfg/cfg_select.c:211 > 211 i = *(int *)p; It seems that the problem is with this line: modparam("dmq", "notification_address", "sip:DMQ_NOTIFY_ADDRESS") > Also, I only have this issue while running on an AWS instance, I have the same setup on my local computer, however kamailio is able to start correctly. While kamailio is starting, I have this line #!substdef "!DMQ_NOTIFY_ADDRESS!10.10.10.10:5090!g" It seems that after DMQ is able to obtain the IP address, when it comes to actually sending the message, it is interpreting the ip address of the DMQ_NOTIFY_ADDRESS as an integer and then it gives out a segmentation fault and the module stops. Another interesting thing is that if the DMQ_NOTIFY_ADDRESS is the MY_IP_ADDRESS variable instead of the 10.10.10.10, it seems to work properly. #!substdef "!DMQ_NOTIFY_ADDRESS!MY_IP_ADDRESS:5090!g" It also doesn't seem related to the ip being in a variable, since I already tried using a DNS record, and once again, it is able to obtain the IPs from the DNS record, and the same issue applies. Has anyone ever seen anything like this? I can't find any evidence of this actually happening. Thank you kindly for your time. Best Regards, José Santos

3 3

Best practice for Kamailio "cluster" front for many TLS connections
by Angelo Sipper 15 Sep '21

15 Sep '21

Hello, We are thinking to use kamailio to fully support our current voip service. I would like to know what is the best practice to use kamailio for several thousands for clients that connect to us via TLS. We would like to have a front "cluster" to be able to handle all these connections in balanced way. All clients register to us and the do calls that we statefully forward to the provider. On our test we have already created a single kamailio that successfully accepts and handles registration, do the control and routing to next provider with dispatcher and also do the accounting with cdrs. We want to separate this controlling, routing, accounting and dispatching from the front end and create a front "cluster" to offload the TLS and also be redundant to as many connections by adding more kamailio's. What would be the best kamailio module and topology as solution to this requirement? Thank you in advance. Kind Regards, Angelo

7 12

Fwd: Catching an overall timeout after dropping replies
by Marrold 15 Sep '21

15 Sep '21

Hi, This is partially related to a previous thread - https://lists.kamailio.org/pipermail/sr-users/2021-August/113128.html We are using the TSILO module to suspend transactions whilst we wait for mobile app users to register after receiving a push notification. In the time we are waiting for the app to register, other UAs might reject the call (DND, Busy, etc). To avoid this failure response being relayed to the caller, we use t_drop_replies in the failure_route. Eventually if all devices have rejected the call Kamailio times out and sends a 408 Request Timeout. Is there any way we can catch this error, and replace it with the last response we got from an actual UA? t_is_expired() and t_branch_timeout() don't seem to apply as they're on the *called* side. Is there another option to catch this overall timeout? As a side note, failure_route is quite limited in the actions that can take place there. Is it safe to access variables and update a htable? Thanks Matthew

1 0

Re: [SR-Users] Empty Subnets in Permissions Module
by Henning Westerholt 14 Sep '21

14 Sep '21

Hello, please keep the list in CC. Let’s look into the two issues one by one: 1) I had to explicitly configure the parameter: modparam("permissions", "mask_col", "mask") Although the documentation suggests "mask" is the default - the JSON output from "kamctl address dump" did not output this value on K5.5. (On K5.3 it outputted properly) Do you get an error if you do not specify the mask_col like this, or something else? From the source code the default should be “mask”. When I run the "kamcmd permissions.subnetDump" on Kamailio 5.3, it returns everything as expected - including the 0.0.0.0/0<http://0.0.0.0/0> subnets. However, when running the same commands on Kamailio 5.5, it only returns a small subset (of only 20) subnets/groups - and the selection does not appear to follow a logical selection criteria. Additionally, it does not return any groups with a 0.0.0.0/0<http://0.0.0.0/0> subnet either. It seems that the behaviour has changed regarding the “0” subnet, checkout the docs: https://kamailio.org/docs/modules/devel/modules/permissions.html#permission… It will convert them to 32/128 respectively. Can you see a 0.0.0./32 in your dump? This was changed in commit f376c82a9f8 during an extension for text files. Maybe Daniel can comment here if this was done by purpose. Otherwise, you can open an issue on our tracker about it. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com<https://gilawa.com/> From: Tom Dworakowski <dworakowski.tom(a)gmail.com> Sent: Tuesday, September 14, 2021 5:00 PM To: Henning Westerholt <hw(a)skalatan.de> Subject: Re: [SR-Users] Empty Subnets in Permissions Module Hello Henning, Thank you for looking into this for me. I made two interesting discoveries this morning: 1) I had to explicitly configure the parameter: modparam("permissions", "mask_col", "mask") Although the documentation suggests "mask" is the default - the JSON output from "kamctl address dump" did not output this value on K5.5. (On K5.3 it outputted properly) 2) When I run the "kamcmd permissions.subnetDump" on Kamailio 5.3, it returns everything as expected - including the 0.0.0.0/0<http://0.0.0.0/0> subnets. However, when running the same commands on Kamailio 5.5, it only returns a small subset (of only 20) subnets/groups - and the selection does not appear to follow a logical selection criteria. Additionally, it does not return any groups with a 0.0.0.0/0<http://0.0.0.0/0> subnet either. From my logs - I have noted this: Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4353, 0.0.0.0, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <3769, 0.0.0.0, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4355, 0.0.0.0, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4359, 0.0.0.0, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <1955, 84.XX.XX.66, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4361, 91.X.X.231, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4361, 91.X.X.33, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4361, 91.X.X.34, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4363, 80.X.X.25, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4363, 85.X.X.124, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4363, 212.X.X.19, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4365, 0.0.0.0, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4367, 0.0.0.0, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <4371, 0.0.0.0, 0> inserted into address hash table Sep 14 03:07:25 webrtc kamailio[5407]: 0(5407) DEBUG: permissions [address.c:118]: reload_address_insert(): Tuple <3991, 0.0.0.0, 0> inserted into address hash table At the moment of querying group id 3983 (where there is only 0.0.0.0/0<http://0.0.0.0/0>), the function returns false: DEBUG: permissions [address.c:671]: allow_source_address(): looking for <3983, [IPv4 in hex, reversed octet order], 62281> However, None of those addresses appear in the "kamcmd permissions.subnetDump" output. Moreover, if "my" group has the address 0.0.0.0/0<http://0.0.0.0/0> listed as an approved address - it will fail the test; but if I register 0.0.0.0/1<http://0.0.0.0/1> it will let me through (as my IP is < 128.0.0.0), kamcmd permissions.subnetDump will display this address. My thoughts are that there might be another table that is not being populated - or there is a filter during the import that either drops 0.0.0.0/0<http://0.0.0.0/0> or filters it out completely? Regards, Tom On Tue, Sep 14, 2021 at 4:10 AM Henning Westerholt <hw(a)skalatan.de<mailto:hw@skalatan.de>> wrote: Hello Tom, I’ve done a quick comparison of the main function and the called function. On a first view it looked identically, but I looked only a few levels deep. Do you have maybe some means to reproduce this on a test system? Then it would be probably interesting to look to the DEBUG logging of this cases. Maybe you can compare if you spot some obvious differences from the logic. Cheers, Henning From: sr-users <sr-users-bounces(a)lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>> On Behalf Of Tom Dworakowski Sent: Tuesday, September 14, 2021 4:10 AM To: sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org> Subject: [SR-Users] Empty Subnets in Permissions Module Greetings all! I have two deployments of Kamailio: one running version 5.3 and one 5.5 with practically identical configurations, same (MySQL and REDIS) data sources. We have customers that we assign an ACL "group" to, where the ID of this group resolves to records in the "address" table in our MySQL database - using the "grp" field. On the box running Kamailio 5.5, we have noticed that if a group has ip_addr=0.0.0.0, mask=0, port=0 - and we try to run the allow_source_address() - it will return false, thus failing this phase of the authentication process. However, on Kamailio 5.3 we are not seeing this issue, i.e. if a customer is assigned a group where the ACL is 0.0.0.0/0<http://0.0.0.0/0> - it will let him through. Has something changed that I'm not aware of? Any suggestions on how to resolve this? My best, Tom

2 1

Capturing response from uac_reg module
by Ross McKillop 14 Sep '21

14 Sep '21

Hi, What's the best way to capture the response from REGISTER requests automatically initiated by the uac_reg module? I was looking to use event_route[uac:reply] {} but that is only triggered if the evroute flag is set on the initial call made to uac_req_send() Is there a way to set this globally so that uac:reply is called for all requests initiated for peers in the uacreg table or a better way to capture the response? Best, Ross

3 4

Jump to page:

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