Hello,
I'd like to remove headers during async processing e.g. in a route called from http_async_client(..).
The usual textops functions are not working here.
Adding headers could be done using something like rtjson, but it do not offer a remove header function.
I could of course loop the request locally, but this is not that "nice".
Any other suggestions for this case? Or just the rtjson module needs some extensions?
Thank you,
Henning
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://gilawa.com<https://gilawa.com/>
Hi,
I had some difficulties getting Siremis 5.3 to run under Debian 11
Bullseye. It turned out that the problem was the creation of the Siremis
socket:
<UnixSockLocal name="unixsocklocal"
address="/run/siremis/siremis_rpc.sock" timeout="3.0"/>
There is a warning in siremisJRCommands.xml that points out that systemd
has to be reconfigured as sockets in /tmp are no longer shared
(PrivateTmp setting). By the same token, /run/siremis/siremis_rpc.sock
cannot be created as the httpd server is not allowed to write to /run,
i.e. it can neither create the socket nor the siremis directory. The
permanent creation of the siremis directory with suitable access rights
is also not possible, since /run is mounted as tmpfs in the default
configuration.
At least the directory has to be created at boot time, which can be done
with a small helper service.
This is working for me (siremis-helper.service):
[Unit]
Description=Siremis Helper Service
After=network.target
[Service]
Type=oneshot
ExecStartPre=/usr/bin/mkdir /var/run/siremis
ExecStart=/usr/bin/chown www-data:www-data /var/run/siremis
[Install]
WantedBy=multi-user.target
It is enabled the usual way with systemctl "systemctl start --now
siremis-helper".
Siremis now works with jsonrpc commands and the procedure would mean
that installing Siremis on a newer Debian system would definitely
require some attention.
Does anyone have any objections to the above procedure?
Hello
General overview of the infrastructure:
Client (Cisco Hardware) ---> AWS NLB ---> Kamailio Instances
The client has a time limit for the opened TCP connections - 10 minutes.
This is a hardcoded value that can't not be changed. Regardless of the
traffic that flows through the connection, it is closed after 10 minutes.
Problem: in case of long-running calls above 10 minutes it is not possible
for Kamailio to send back SIP traffic back to the client using the original
TCP connection. The client has been asked to either increase the time limit
or send SIP reinvites - none of that is possible due to some client's
infrastructure limitations.
Question: is it possible to force Kamailio to open a new TCP connection and
associate it with the call? Client has a 5060 port always opened which can
accept incoming connections.
Hello
im trying to textops module to remove headers with name length less than 5 characters with regular expression but it seems impossible or the module does not handle $ char
remove_hf_re("^.{1,5}$")
Hi,
I seem to have a problem setting up Siremis 5.3 on a Debian 11 box using
the Kamailio 5.6.0 release (installed from repo).
When I enter something like core.uptime into the JSONRPC Command Panel,
I get a "System Internal Error" alert. The Apache error log then says:
[Mon Jun 06 10:48:41.459377 2022] [php7:notice] [pid 22322] [client
192.168.xxx.xxx:45030] socket bind failed: No such file or directory,
referer: http://deb11srv1-kamailio/siremis/sipadmin/jrcmds
The path siremis/sipadmin/jrcmds obviously does not seem to exist and I
assume that one needs some internal adjustments for some paths.
As far as the socket is concerned,
siremis/modules/sipadmin/service/siremisJRCommands.xml has the definition:
UnixSockRemote name="unixsockremote"
address="/var/run/kamailio/kamailio_rpc.sock" timeout="3.0"/>
and the corresponding definition in /etc/kamailio/kamailio.cfg is:
modparam("jsonrpcs", "dgram_socket", "/var/run/kamailio/kamailio_rpc.sock")
modparam("jsonrpcs", "dgram_mode", 0666)
which looks fine to me. I also checked for the existence of the socket
and its access rights.
Any suggestions?
Hallo all,
I defined branch_failure routing block via t_on_branch_failure()
In the branch_failure route, in case of "408 Request timeout" I am sending
CANCEL with reason "t_cancel_callid("$ci", "$cs", "22", "408")".
If the t_cancel_callid("$ci", "$cs", "22", "408") is called in
branch_failure for branch idx 0, the CANCEL is sent, but Reason header is
missing there.
Why? (I expect that t_cancel_callid() should insert Reason header
regardless of branch it is called from)
If the t_cancel_callid is called in branch idx !=0, the CANCEL contains
Reason header with cause as expected.
Thanks for clarification of this behavior,
Pavel.
P.S. code snipset:
event_route[tm:branch-failure:primary]
{
if ($T(reply_code) == "408")
{
if ($avp(branch_idx) == $T_branch_idx)
{
if (t_cancel_callid("$ci", "$cs", "22", "408"))
{
xlog("L_INFO", "CANCEL sent ci:$ci, cs:$cs 408");
}
else
{
xlog("L_INFO", "CANCEL not sent ... ci:$ci, cs:$cs 408");
}
$var(_palotmp_) = "sip:" + $avp(replaced_cfnry_target_number) +
"@" + $dd + ":" + $dp + ";user=phone";
append_branch($var(_palotmp_),"1.0");
t_relay();
return;
}
}
}