Hi,
We possess a code within Kamailio, which specifically handles malformed SIP
responses. Below is the code snippet:
*reply_routeCopy code if(!sanity_check("17604", "6")) { xlog("Malformed SIP
response from $si:$sp\n"); drop;*
Additionally, we have Kamailio drop request statistics as follows:
Command: *kamctl stats | grep core:drop_requests*
Output of the command: *core:drop_requests = 5*
My queries are:
1. Is the aforementioned "reply_route" related to the drop requests we are
experiencing?
2. If it is not related, what could be the cause of the drop requests?
Hello,
I am looking information about Kamailio operating as an SBC.
I saw this video of Kamailio World 2021: Kamailio As An SBC For Network Segregation:
https://www.youtube.com/watch?v=UW6l3R4OnsY&t=1381s
But where I can find more detailed technical information ?
Regards
Hi
Further trying to eliminate every possible cause of UDP drops...
We use Homer as HEP server in conjunction with the siptrace module.
So to prevent DQM traffic to be sent to Homer I added:
event_route[siptrace:msg] {
if(is_method("KDMQ")) {
drop();
}
}
And had a closer look to the traffic sent to homer.
I noticed, also xhttp:requests, as far as I see the replies, not the
requests, get mirrored to homer.
xhttp is not a sip method I could match I guess.
The event_route[siptrace:msg] docs state only method can be filtered.
So I can not filter requests on the separate http port I listen on for
xhttp json-rpc requests.
How can I prevent xhttp traffic to be mirrored to homer by the siptrace
module?
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
______________________________________________________
Hello Kamailians!
As STIR/SHAKEN seems to cross the ocean and arrive on the European shores, I’m curious on how you’ve implemented it with Kamailio. I asked on our Matrix chat and got two responses that seems to not use the Kamailio STIR/SHAKEN support but rather a 3rd party service that they’ve integrated using restful APIs.
Please help me and share how you’re implementing STIR/SHAKEN with Kamailio.
I’m not shaken, nor stirred. yet.
Regards,
/O
Hi,
regarding ndb_redis,
I have 3 sentinels like this:
"192.168.88.155:26379"
"192.168.88.156:26379"
"192.168.88.157:26379"
So was thinking that I would configure ndb_redis this way:
modparam("ndb_redis", "server",
"name=srvZ;sentinel_group=myredis;sentinel_master=1;sentinel=
192.168.88.155:26379")
modparam("ndb_redis", "server",
"name=srvZ;sentinel_group=myredis;sentinel_master=0;sentinel=
192.168.88.156:26379")
modparam("ndb_redis", "server",
"name=srvZ;sentinel_group=myredis;sentinel_master=0;sentinel=
192.168.88.157:26379")
But the samples in the documentation show an extra sentinel key in the
config lines:
# sentinel (for a redis slave)
modparam("ndb_redis", "server",
"name=srvZ;sentinel_group=group_name;sentinel_master=0;sentinel=1.2.3.4:26379
;sentinel=1.2.3.5:26379")
# sentinel (for a redis master)
modparam("ndb_redis", "server",
"name=srvZ;sentinel_group=group_name;sentinel_master=1;sentinel=1.2.3.4:26379
;sentinel=1.2.3.5:26379")
So I am not sure if my configuration is correct.
Can someone clarify?
Hi,
I have an application as follows:
Multiple Kamailio Nodes
Shared Postgres database
Auth information will be stored in DB and accessed with Authdb.
Here is the behavior I seek:
I would like all the Kamailo nodes to cooperate in updating the database, each updating data as appropriate:
When a registration comes in to any Node, and it authenticated, create or update a database record in location table.
When a registration expires on that Node, delete database record in location table.
When INVITE comes in on any Node, ignore local cache and always lookup() record from database.
#1 and #2 are used so that a third SIP system can query the database and look up the Node a NAT’d subscriber is ‘connected’ to.
#3 is to let NON-NAT’d subscribers be contacted from any Node.
Now I have something close to this now – using following settings:
modparam("usrloc", "db_mode", 1) # immediately write registrations to the database.
modparam("usrloc", "db_timer_clean", 0) # do not expire DB records separately
modparam("usrloc", "db_check_update", 1)
This takes care of #1 and #2 above. However, #3 seems to still be relying purely on local cache and does not hit the database.
Is there a way to do #3? I can set db_mode to 3 but that would seem to have other effects besides merely making lookup() read from database.
Thanks in advance,
Jawaid
Hi all,
I am using Kamailio (5.7.2, Debian 11, Python KEMI) in a
mutli-homed environment with the topos module to hide the topology.
I have noticed that when I use `set_send_socket` or `$fsn` to force the
socket it's sent from, it breaks topos and the ACK is not proxied to the
other leg of the call. I am calling record_route() *after* forcing the
socket.
If I disable TOPOS the ACK works as expected, and the signalling looks
correct.
Or, with TOPOS enabled, if I comment out set_send_socket TOPOS works as
expected.
If I disable enable_double_rr, TOPOS works as expected and the ACK is
forwarded, but without the double RR subsequent in-dialog requests use the
wrong socket.
One other observation, when I change the send socket I also see these
warnings in the logs:
24(32) WARNING: PY3 {ACK}: dialog [dlg_handlers.c:1348]: dlg_onroute():
tight matching failed for ACK with
callid='!!:MByLMlFAM.NfWxFAM.cAMxyfWjyLz.yAO.y6MxF1MxVZWG4ZMy**'/55,
ftag='2023101714101800015'/19,
ttag='2f55349a-2c59-4e37-bf58-fd84fb69ece9'/36 and direction=0
24(32) WARNING: PY3 {ACK}: dialog [dlg_handlers.c:1355]: dlg_onroute():
dialog identification elements are
callid='2023101714101800015@2900-0601-0284-80'/37, caller
tag='2023101714101800015'/19, callee
tag='2f55349a-2c59-4e37-bf58-fd84fb69ece9'/36
Is anyone using TOPOS + forcing the socket, or could someone advise where I
am going wrong?
Thanks in advance
Matthew
Hello,
I'm using Kamailio as SIP proxy between Session Manager and SBC
So here is the scenario :
Session Manager sends a call (Invite) to Kamailio, kamailio needs to relay it to SBC after doing some modification.
(-----Session Manager-----) ----------- > (----Kamailio----) ----------- > (-----SBC-----)
My routing logic is similar to the below:
route{
if ((method==OPTIONS) && (! uri=~"sip:.*[@]+.*")) {
options_reply();
}
if (is_method("INVITE")) {
sql_query("cb", "select number from pool1 order by random() limit 1", "ra");
$var(rand)=$dbr(ra=>[0,0]);
uac_replace_from($var(rand),"sip:$var(rand)@192.168.1.1");
xlog("L_INFO","Random: $var(rand)");
$var(ip) = $(ct{s.select,1,(a)}{s.select,0,;}{s.replace,>,});
remove_hf("Contact");
insert_hf("Contact: $var(rand) <sip:$var(rand)@$var(ip)>\r\n");
remove_hf("P-Asserted-Identity");
remove_hf("Route");
insert_hf("Route: <sip: 192.168.1.10>\r\n","Route");
record_route();
t_relay();
$td = "192.168.1.10";
$rd = "192.168.1.10";
t_relay();
}
}
Where:
192.168.1.1 is Kamailio IP
192.168.1.10 is SBC IP
My question here is that Kamailio handle all in dialog messages between Session Manager and SBC?
For example, after forwarding the invite packet to SBC, SBC sends 183 Session Progress to Kamailio, which in its turn relay it to the session manager, knowing that this is not mentioned in my routing logic, so how Kamailio knew that it must relay it to session manager in this case?
Also I need to add to the 183 Session Progress sent to session manager by Kamailio record route and Via headers , how to do it ?
Regards,
Hi sr-users,
In the case of dispatcher-based HA such as the Wazo example (
https://wazo-platform.org/blog/kamailio-ha-dispatcher-and-dmq)
won't the Route: headers be wrong for in-dialog requests if the request is
sent to the backup proxy?
front proxy -> proxy A, B, C, D,... -> network
Suppose the INVITE goes through proxy A, then proxy A goes down.
Based on the HA logic, an in-dialog request will go to a backup, say, proxy
B.
However, won't the Route headers be wrong (since they are placed by A) in
the original transaction?
How do you handle Route:, Record-Route: headers at the HA tier?
1. In the front proxy & HA tier don't use route headers at all ??
2. Manually check and remove route headers (i.e proxy B treats route
headers for proxy A as "myself") ??
I am curious as to what is your practice.
Regards
Shih-Ping
Hi all,
I have started using kamailio as a proxy register for asterisk's and works
fine, but in some moment kamailio show WARNINGs, ALERTS and CRITICAL logs
and restart.
I don't no how debug correctly, but the crash show this log lines
*Oct 16 21:34:26 proxy /usr/sbin/kamailio[2148]: CRITICAL: <core>
[core/mem/q_malloc.c:123]: qm_debug_check_frag(): BUG: qm: fragm.
0x7f14a27a5ab8 (address 0x7f14a27a5af0) beginning overwritten
(7f14a27a8e58)! Memory allocator was called from uac: uac_send.c:860.
Fragment marked by UH��AWAVAUATSH��:139726602009368. Exec from
core/mem/q_malloc.c:511.*
-------------------------------------------------------------
*Oct 16 21:39:46 proxy /usr/sbin/kamailio[2556]: CRITICAL: <core>
[core/mem/q_malloc.c:123]: qm_debug_check_frag(): BUG: qm: fragm.
0x7ff7ad456330 (address 0x7ff7ad456368) beginning overwritten (0)! Memory
allocator was called from uac: uac_send.c:860. Fragment marked by (null):0.
Exec from core/mem/q_malloc.c:511.Oct 16 21:39:46 proxy
/usr/sbin/kamailio[2578]: CRITICAL: <core> [core/pass_fd.c:277]:
receive_fd(): EOF on 19Oct 16 21:39:46 proxy /usr/sbin/kamailio[2539]:
ALERT: <core> [main.c:774]: handle_sigs(): child process 2556 exited by a
signal 6Oct 16 21:39:46 proxy /usr/sbin/kamailio[2539]: ALERT: <core>
[main.c:777]: handle_sigs(): core was not generatedOct 16 21:39:46 proxy
systemd[1]: kamailio.service: Main process exited, code=exited,
status=1/FAILUREOct 16 21:39:46 proxy systemd[1]: kamailio.service: Failed
with result 'exit-code'.Oct 16 21:39:46 proxy systemd[1]: kamailio.service:
Service RestartSec=100ms expired, scheduling restart.Oct 16 21:39:46 proxy
systemd[1]: kamailio.service: Scheduled restart job, restart counter is at
9.Oct 16 21:39:46 proxy systemd[1]: Stopped Kamailio - the Open Source SIP
Server.*
any advice is apreciated
--
================
**Daian Conrad**
E-mail: daian.conrad(a)gmail.com
OpenS Team (DaCoD)
Linux user: #248912
