Hello everyone!
I'm running Kamailio 5.6.2 and having a potential problem on one of the
systems. The Slow timer process slowly consumes more and more of its PKG
memory. I did not allow it to use all memory by restartink Kamailio during
afterhours so I'm not sure what the consequences might be.
I'm suspecting that this could be caused by my configuration but not sure
how exactly. Can anyone please tell me how the Slow timer process can be
debugged? Is it possible to see what it is storing in …
[View More]the memory and what
data is piling up?
Thanks a lot!
Regarts, Volodymyr Ivanets.
[View Less]
Hello all,
I'm currently working on a proxy where I need to change To and From headers
in order to normalize the numbers to +E164.
I would like to be able to restore using and $avp() or $dlg_var() and
without writing parameters on the Record-Route headers.
I've tried to use restore_mode in auto mode and restore_dlg parameter with
value 1 but still got the parameters on the inserted Record-Route.
I've tried manual mode and using the configured $avp() to restore, but the
parameters still got …
[View More]written on the Request-URI.
I thought of using restore_mode with value "none" saving original values in
an $avvp() and doing the replace, however, uac_replace() on Request Route
or branch routes. That way i can't replace the values of To and From in the
replies.
That being said, my questions are :
- Is there a way to use manual or auto mode without writing info on the
Record-Route and only using $avp() ?
- Is there a way to make changes on the To and From header on replies?
Thanks in advance,
Best Regards,
Duarte Rocha
[View Less]
Hello!
Are there any technical difficulties in adding tlsa module with the
statically linked OpenSSL v1.1.1 to the package builder (deb)?
--
BR,
Denys Pozniak
**Issue Description**
I'm encountering an issue with my Kamailio configuration related to the inclusion of the "Accounting-Record-Type" (480) and "Accounting-Record-Number" (485) AVPs in Credit-Control Request (CCR) messages sent from the S-CSCF to the OCS.
**Issue Details**
- **Problem**: The "Accounting-Record-Type" and "Accounting-Record-Number" AVPs are being added to CCR messages generated by my Kamailio instance.
- **Expected Behavior**: According to modern Diameter and 3GPP standards (…
[View More]e.g., RFC 4006 and TS 32.299), these AVPs should not be included in CCR messages.
**Configuration Details**
- **Kamailio Version**: 5.3.0
- **SigScale OCS Version**: 3.2.9
Note that I have redacted some specific information for confidentiality reasons. The actual values are placed in my Kamailio main configuration file (`kamailio.cfg`) and Diameter-specific configuration files (where applicable).
Kamailio.cfg:
modparam("ims_charging", "db_url", DB_URL)
modparam("ims_charging", "db_mode", 1)
modparam("ims_charging", "origin_host", HOSTNAME);
modparam("ims_charging", "origin_realm", NETWORKNAME);
modparam("ims_charging", "destination_host", DESTINATION_HOST);
modparam("ims_charging", "destination_realm", DESTINATION_REALM);
modparam("ims_charging","service_context_id_root", RO_ROOT);
modparam("ims_charging","service_context_id_ext", RO_EXT);
modparam("ims_charging","service_context_id_mnc", MNC);
modparam("ims_charging","service_context_id_mcc", MCC);
modparam("ims_charging","interim_update_credits",30);
modparam("ims_charging","timer_buffer",5);
SCSCF.xml:
<?xml version="1.0" encoding="UTF-8"?>
<DiameterPeer
FQDN="scscf.mncXXX.mccXXX.3gppnetwork.org"
Realm="ims.mncXXX.mccXXX.3gppnetwork.org"
Vendor_Id="10415"
Product_Name="CDiameterPeer"
AcceptUnknownPeers="1"
DropUnknownOnDisconnect="1"
Tc="30"
Workers="16"
QueueLength="32"
TransactionTimeout="5"
SessionsHashSize="128"
DefaultAuthSessionTimeout="3600"
MaxAuthSessionTimeout="3600"
>
<Peer FQDN="diameter" Realm="ims.mncXXX.mccXXX.3gppnetwork.org" port="3868"/>
<Peer FQDN="192.168.2.31" Realm="ocs.ims.mncXXX.mccXXX.3gppnetwork.org" port="3868"/>
<Acceptor port="3868" bind="eth0"/>
<Auth id="16777216" vendor="10415"/><!-- 3GPP Cx -->
<Auth id="16777216" vendor="4491"/><!-- CableLabs Cx -->
<Auth id="16777216" vendor="13019"/><!-- ETSI/TISPAN Cx -->
<Auth id="16777216" vendor="0"/><!-- ETSI/TISPAN Cx -->
<Auth id="4" vendor="10415"/> <!--3GPP Ro -->
<Acct id="4" vendor="10415" />
<!--
Supported Vendor IDs - list of values which will be sent in the CER/CEA in the
Supported-Vendor-ID AVPs
-->
<SupportedVendor vendor="10415" />
<Realm name="ocs.ims.mncXXX.mccXXX.3gppnetwork.org">
<Route FQDN="192.168.2.31" metric="10"/>
</Realm>
<DefaultRoute FQDN="diameter" metric="10"/>
</DiameterPeer>
I am using SigScale OCS as my Online Charging System. Here is the error log I received from SigScale OCS:
ERROR REPORT==== 5-Sep-2023::07:27:01.393554 ===
"DIAMETER AVP unsupported"
service_name: {ocs_diameter_acct_service,{0,0,0,0},3868}
capabilities: {diameter_caps,
{<<"host1">>, <<"scscf-1.ims.mncXXX.mccXXX.3gppnetwork.org">>},
{<<"COMPANYNAME.local">>, <<"ims.mncXXX.mccXXX.3gppnetwork.org">>},
{[{0,0,0,0}],[{172,18,0,7}]},
{50386,10415},
{<<"SigScale OCS">>,<<"CDiameterPeer">>},
{[],[]},
{[10415],[10415]},
{[4,16777238],[16777216]},
{[],[]},
{[],[]},
{[{'diameter_base_Vendor-Specific-Application-Id',10415,[16777238],[]}],
[{'diameter_base_Vendor-Specific-Application-Id',10415,[16777216],[]},
{'diameter_base_Vendor-Specific-Application-Id',4491,[16777216],[]},
{'diameter_base_Vendor-Specific-Application-Id',13019,[16777216],[]},
{'diameter_base_Vendor-Specific-Application-Id',10415,[4],[]},
{'diameter_base_Vendor-Specific-Application-Id',10415,[],[4]}]},
{[329],[]},
{[],[]}}
errors: [{5001,
{diameter_avp,480,undefined,true,false,
<<0,0,0,2>>,
'Accounting-Record-Type',2,'Enumerated',5}},
{5001,
{diameter_avp,485,undefined,true,false,
<<0,0,0,0>>,
'Accounting-Record-Number',0,'Unsigned32',6}},
{5001,
{diameter_avp,260,undefined,true,false,
<<0,0,1,10,64,0,0,12,0,0,40,175,0,0,1,2,64,0,0,12,0,0,0,4>>,
'Vendor-Specific-Application-Id',
{'3gpp_ro_Vendor-Specific-Application-Id',10415,[4],[]},
'Grouped',10}}]
I would greatly appreciate it if someone from the community could provide insights into the following:
1. Possible Configurations: Are there specific configurations or modules in Kamailio that might cause the inclusion of non-standard AVPs in CCR messages?
2. IMS Ro Interface Behavior: Does anyone have experience with IMS Ro interface behavior using Kamailio that could shed light on this?
If you have any guidance, suggestions, or solutions to help me troubleshoot and resolve this problem, please share them. Thank you for your assistance.
[View Less]
Hello,
Running ”kamcmd permissions.trustedReload” it instantly returns “Reload OK” but I cannot repeat the reload for about 8 seconds. This is the same for dialplan.reload and dispatcher.reload.
root@superman.local:/# kamcmd permissions.trustedReload
Reload OK
root@superman.local:/# kamcmd permissions.trustedReload
error: 500 - ongoing reload
root@superman.local:/# kamcmd permissions.trustedReload
error: 500 - ongoing reload
There are scenarios where I might need to reload the permission …
[View More]table multiple times within this 8 second window. Is this some kind of intended block or is something at fault?
modparam("db_mysql", "ping_interval", 60)
modparam("db_mysql", "timeout_interval", 4)
modparam("db_mysql", "auto_reconnect", 1)
modparam("db_mysql", "opt_ssl_mode", 0)
modparam("permissions", "db_url", "mysql://kamailio:xxxxx@aws-rds-database /kamailio")
version: kamailio 5.7.1 (x86_64/linux)
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 10.2.1
/M
[View Less]
Is there any specific reason why shared memory can be configured via the
config files ("shm_mem_size") AND CLI flags ("-m") but package memory can
only be set via CLI flags ("-M")?
Did no one ever came across the need to configure the package memory limit
so far, or is there another way to achieve it without using the CLI flag?
--
Ivan Ribakov
Software Engineer
www.zaleos.net
Bastian,
According to mine stats all seems ok...
# kamctl stats shmem
{
"jsonrpc": "2.0",
"result": [
"shmem:fragments = 330",
"shmem:free_size = 1889418024",
"shmem:max_used_size = 258962624",
"shmem:real_used_size = 258065624",
"shmem:total_size = 2147483648",
"shmem:used_size = 248809096"
],
"id": 212042
}
pkg.stats also not showing any signs of exhausting.
For me what is working is server can send packets, but not receive em
back even. And …
[View More]it's happening only on 1 interface.
Le 30/08/2023 à 21:44, Bastian Triller a écrit :
> I'm asking, because we kind of observed similar behaviour after
> overload. We've did some load testing and at some point SHM was
> exhausted and that didn't recover itself. One process was using nearly
> 100% CPU. And I guess that at least sl replies still works at that point.
>
> On Wed, Aug 30, 2023 at 9:28 PM Ihor Olkhovskyi
> <igorolhovskiy(a)gmail.com> wrote:
>
> Bastian,
>
> I'm fine with retransmissions and so, but for me it's really
> interesting, that server is not restoring it's state after a while
> and only restart helps. And this is happening only with UDP on one
> interface, others are working fine over UDP
>
> Le 30/08/2023 à 17:19, Bastian Triller a écrit :
>> Maybe it's not beneficial to have a receive buffer that high. If
>> your presence server is stateful, it will send retransmissions if
>> packets get dropped. But it will also send retransmissions if
>> your proxy does not reply fast enough. So your proxy may be
>> damped by retransmissions. Did you check SHM/active transactions
>> on your proxy?
>>
>> Regards,
>> Bastian
>>
>> On Wed, Aug 30, 2023 at 3:56 PM Ihor Olkhovskyi
>> <igorolhovskiy(a)gmail.com> wrote:
>>
>> They are increasing, actually
>>
>> # ss -l -u -m src X.X.X.X/Y
>> State Recv-Q Send-Q Local
>> Address:Port Peer Address:Port
>> UNCONN 25167616 0 X.X.X.X:sip *:*
>> skmem:(r25167616,rb25165824,t0,tb65536,f2304,w0,o0,bl0,d514894)
>>
>> Le mer. 30 août 2023 à 15:04, Bastian Triller
>> <bastian.triller(a)gmail.com> a écrit :
>>
>> Are drops increasing on that socket while it is happening?
>> ss -l src <local_interface> -u sport 5060 -m
>>
>> On Tue, Aug 29, 2023 at 3:26 PM Ihor Olkhovskyi
>> <igorolhovskiy(a)gmail.com> wrote:
>>
>> Just to add some info
>>
>> netstat -nlp
>> Active Internet connections (only servers)
>> Proto Recv-Q Send-Q Local Address Foreign Address
>> State PID/Program name
>> ...
>> udp 25167616 0 <local_interface>:5060
>> 0.0.0.0:* 211759/kamailio
>> ...
>>
>> So I see a huge Receive Queue on UDP for Kamailio
>> which is not clearing.
>>
>> Le mar. 29 août 2023 à 14:29, Ihor Olkhovskyi
>> <igorolhovskiy(a)gmail.com> a écrit :
>>
>> Hello,
>>
>> I've faced a bit strange issue, but a bit of
>> preface. I have Kamailio as a proxy (TLS/WS <->
>> UDP) and second Kamailio as a presence server. At
>> some point presence server accepts around 5K
>> PUBLISH within 1 minute and sending around the
>> same amount of NOTIFY to proxy Kamailio.
>>
>> Proxy is "transforming" protocol to TLS, but at
>> sime point I'm starting to get these type of errors
>>
>> tm [../../core/forward.h:292]: msg_send_buffer():
>> tcp_send failed
>> tm [t_fwd.c:1588]: t_send_branch(): sending
>> request on branch 0 failed
>> <script>: [RELAY] Relay to
>> <sip:X.X.X.X:51571;transport=tls> failed!
>> tm [../../core/forward.h:292]: msg_send_buffer():
>> tcp_send failed
>> tm [t_fwd.c:1588]: t_send_branch(): sending
>> request on branch 0 failed
>>
>> Some of those messages are 100% valid as client
>> can go away or so. Some are not, cause I'm sure
>> client is alive and connected.
>>
>> But the problem comes later. At some moment proxy
>> Kamailio just stops accept UDP traffic on this
>> interface (where it also accepts all NOTIFY's),
>> at the start of the "stopping accepting" Kamailio
>> sends OPTIONS via DISPATCHER but not able to
>> receive 200 OK.
>>
>> Over TLS on the same interface all is ok. On
>> other (loopback) interface UDP is being processed
>> fine, so I don't suspert some limit on open files
>> here.
>>
>> Only restart of Kamailio proxy process helps in
>> this case.
>>
>> I've tuned net.core.rmem_max and
>> net.core.rmem_default to 25 Mb, so in theory
>> buffer should not be the case.
>>
>> Is there some internal "interface buffer" in
>> Kamailio that is not freed upon failure send or
>> maybe I've missed somethig?
>>
>> Kamailio 5.6.4
>>
>> fork=yes
>> children=12
>> tcp_children=12
>>
>> enable_tls=yes
>>
>> tcp_accept_no_cl=yes
>> tcp_max_connections=63536
>> tls_max_connections=63536
>> tcp_accept_aliases=no
>> tcp_async=yes
>> tcp_connect_timeout=10
>> tcp_conn_wq_max=63536
>> tcp_crlf_ping=yes
>> tcp_delayed_ack=yes
>> tcp_fd_cache=yes
>> tcp_keepalive=yes
>> tcp_keepcnt=3
>> tcp_keepidle=30
>> tcp_keepintvl=10
>> tcp_linger2=30
>> tcp_rd_buf_size=80000
>> tcp_send_timeout=10
>> tcp_wq_blk_size=2100
>> tcp_wq_max=10485760
>> open_files_limit=63536
>>
>> Sysctl
>>
>> # To increase the amount of memory available for
>> socket input/output queues
>> net.ipv4.tcp_rmem = 4096 25165824 25165824
>> net.core.rmem_max = 25165824
>> net.core.rmem_default = 25165824
>> net.ipv4.tcp_wmem = 4096 65536 25165824
>> net.core.wmem_max = 25165824
>> net.core.wmem_default = 65536
>> net.core.optmem_max = 25165824
>>
>> # To limit the maximum number of requests queued
>> to a listen socket
>> net.core.somaxconn = 128
>>
>> # Tells TCP to instead make decisions that would
>> prefer lower latency.
>> net.ipv4.tcp_low_latency=1
>>
>> # Optional (it will increase performance)
>> net.core.netdev_max_backlog = 1000
>> net.ipv4.tcp_max_syn_backlog = 128
>>
>> # Flush the routing table to make changes happen
>> instantly.
>> net.ipv4.route.flush=1
>> --
>> Best regards,
>> Ihor (Igor)
>>
>>
>>
>> --
>> Best regards,
>> Ihor (Igor)
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial
>> Discussions
>> To unsubscribe send an email to
>> sr-users-leave(a)lists.kamailio.org
>> Important: keep the mailing list in the recipients,
>> do not reply only to the sender!
>> Edit mailing list options or unsubscribe:
>>
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> To unsubscribe send an email to
>> sr-users-leave(a)lists.kamailio.org
>> Important: keep the mailing list in the recipients, do
>> not reply only to the sender!
>> Edit mailing list options or unsubscribe:
>>
>>
>>
>> --
>> Best regards,
>> Ihor (Igor)
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not
>> reply only to the sender!
>> Edit mailing list options or unsubscribe:
>>
>>
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> To unsubscribe send an email tosr-users-leave(a)lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to the sender!
>> Edit mailing list options or unsubscribe:
>
[View Less]
Hi people,
I installed Kamailio 5.3 on Ubuntu Server 22 LTS, but I am not able to resolve several PHP errors that occur when I try to open the website http://localhost/siremis/.
Which Linux distro and version is best suited for installation?
Is Kamailio version 5.3 operational or is it better to use version 4.4?
Att.,
Daniel Hilário
INFRACOM/UFRGS
51 3308 4801