[TOP~RANK] Oleksandr Usyk vs Tyson Fury 2 Live Streams@𝚁eddiT in Home free?
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4083
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4083(a)github.com>
### Description
Hi!
We are in the progress of upgrading from Kamailio 5.5 to 5.8. During our testing we have noticed a new error being reported from Kamailio. We don’t see any other errors following it.
```jsx
/usr/sbin/kamailio[201]: CRITICAL: <core> [core/tcp_main.c:5544]: tcp_timer_check_connections(): message processing timeout on connection id: 67896 (state: 3) - closing
```
It does seem to be [new code](https://github.com/kamailio/kamailio/blob/master/src/core/tcp_main.c#… in Kamailio reporting this issue.
Given that this is a fairly expected thing, cleaning up a connection which receives no traffic within the given time, is there a need for it to be reported on CRITICAL?
I’d also expect it to be caught by
```
event_route[tcp:timeout] {
xlog("L_INFO","connection $conid timeouts (unanswered keepalives)");
}
```
given that [the description](https://www.kamailio.org/docs/modules/stable/modules/tcpops.ht… of this one is `Called for connection timeouts (unanswered keepalives).`.
### Troubleshooting
We don't have any way to reproduce it, we are still investigating it to figure out the cause. It happens around every 2 hours, so we think there might some some scheduled test or job running in our test system causing this.
### Additional Information
* **Kamailio Version** - 5.8.3
* **Operating System**: Debian 12 AMI from the AWS Marketplace.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3995
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3995(a)github.com>
### Description
I encountered an issue with a specific device that is receiving a T.38 fax. The call gets established towards the device normally with inband media, then the device requests T.38 media and tries to remove the audio media via sending port 0 in the ReInvite SDP. Also it sends connection-information only on the media level and there is no "c=" on the session level.
Reading through the related RFCs and the kamailio code and discussing this on the mailing list, we came to the conclusion that kamailio is doing everything correct as per RFC. Though we were wondering if it would be possible to adjust the parser to be not as strict as it is right now, and allow a missing "c=" line on the media-level if the stream is removed/rejected via port 0, since i see no sense in requiring connection information. Of course we are also in contact with the vendor to hopefully adjust on their side.
Here are the related RFCs:
1. RFC8866 5.7
`A session description MUST contain either at least one "c=" line in each media description or a single "c=" line at the session level. It MAY contain a single session-level "c=" line and additional media-level "c=" line(s) per-media-description, in which case the media-level values override the session-level settings for the respective media.`
2. RFC3264 8.2
`Existing media streams are removed by creating a new SDP with the port number for that stream set to zero. The stream description MAY omit all attributes present previously, and MAY list just a single media format.`
At first i was especially confused by the RFC3264 8.2 part, since it seemed correct what the device is sending, but if you read carefully and keep the wording for SDP in mind only attributes ("a=") MAY be omitted. So a "c=" line should still be in the SDP for the removed media if it's not included on the session-level. Or do you see this differently?
### Expected behavior
Kamailio allows and parses the SDP when there is no session-wide "c=", a media stream is being removed via port zero and there is no "c=" for this media stream and only the remaining media streams include a "c=" line.
#### Actual observed behavior
Kamailio throws an error when trying to parse the SDP.
#### Log Messages
```
<core> [core/parser/sdp/sdp.c:523]: parse_sdp_session(): can't find media IP in the message
```
#### SIP Traffic
```
v=0
o=xmserver 1726638425 1726638427 IN IP4 169.254.1.1
s=xmserver
t=0 0
m=audio 0 RTP/AVP 8
m=image 56002 udptl t38
c=IN IP4 169.254.1.1
a=sendrecv
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:72
a=T38FaxUdpEC:t38UDPRedundancy
```
### Possible Solutions
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.8.3 (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_SEND_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 12.2.0
```
* **Operating System**:
```
Debian 12
Linux hostname 6.1.0-20-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11) x86_64 GNU/Linux
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3982
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3982(a)github.com>
### Description
ping @xkaraman
cmake is overriding distro build flags
Here is typical CFLAGS for EL distros
```
export CFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
## try to build
cd build/
make
[ 1%] Building C object src/CMakeFiles/kamailio.dir/lib/srdb1/db_row.c.o
In file included from /usr/include/bits/libc-header-start.h:33,
from /usr/include/string.h:26,
from /home/centos/src/kamailio-5.8/src/lib/srdb1/../../core/str.h:26,
from /home/centos/src/kamailio-5.8/src/lib/srdb1/db_con.h:33,
from /home/centos/src/kamailio-5.8/src/lib/srdb1/db_val.h:40,
from /home/centos/src/kamailio-5.8/src/lib/srdb1/db_row.h:37,
from /home/centos/src/kamailio-5.8/src/lib/srdb1/db_row.c:33:
/usr/include/features.h:412:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp]
412 | # warning _FORTIFY_SOURCE requires compiling with optimization (-O)
```
It is probably due to `cmake/compiler-specific.cmake`:
```
# If GCC version is greater than 4.2.0, enable the following flags
if(CMAKE_C_COMPILER_VERSION VERSION_GREATER 4.2.0)
target_compile_options(
common INTERFACE -m64 -minline-all-stringops -falign-loops
-ftree-vectorize -fno-strict-overflow -mtune=generic
)
endif()
```
Packaging for ELx requires respecting the default flags - for EL9 included here for reference
```
CFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
CXXFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
FCFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules'
FFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules'
LDFLAGS='-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 '
```
ELx packaging typically involves this dance:
```
# in practice RPM build tools have macros for all the following steps
# use standard distro flags
export CFLAGS=....
export CXXFLAGS=...
export LDFLAGS=....
./configure
```
Is there a way we can respect distro build flags with cmake?
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4082
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4082(a)github.com>
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-users.lists.kamailio…
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-dev.lists.kamailio.o…
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
Note that an issue report may be closed automatically after about 2 months
if there is no interest from developers or community users on pursuing it, being
considered expired. In such case, it can be reopened by writing a comment that includes
the token `/notexpired`. About two weeks before considered expired, the issue is
marked with the label `stale`, trying to notify the submitter and everyone else
that might be interested in it. To remove the label `stale`, write a comment that
includes the token `/notstale`. Also, any comment postpone the `expire` timeline,
being considered that there is interest in pursuing the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
`$shtcn` (and probably also `$shtcv`, but not tested) includes expired entries in count until `timer` process removes expired items.
### Troubleshooting
#### Reproduction
<!--
If the issue can be reproduced, describe how it can be done.
-->
```
#!KAMAILIO
listen=udp:127.0.0.1:9999
log_stderror=yes
loadmodule "xlog.so"
loadmodule "pv.so"
loadmodule "sl.so"
loadmodule "htable.so"
modparam("htable", "htable", "foo=>autoexpire=1;updateexpire=0")
request_route {
$sht(foo=>bar-$Ts) = 1;
xlog("$Ts count $shtcn(foo=>%~bar-)\n");
sl_send_reply("200", "Hello");
}
```
```
while true; do sleep 0.3; sipsak -vs sip:localhost:9999 ; done
```
#### Log Messages
<!--
Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
0(1415871) ERROR: <script>: 1734540011 count 1
0(1415871) ERROR: <script>: 1734540012 count 2
0(1415871) ERROR: <script>: 1734540012 count 2
0(1415871) ERROR: <script>: 1734540012 count 2
0(1415871) ERROR: <script>: 1734540013 count 3
0(1415871) ERROR: <script>: 1734540013 count 3
0(1415871) ERROR: <script>: 1734540013 count 3
0(1415871) ERROR: <script>: 1734540014 count 4
0(1415871) ERROR: <script>: 1734540014 count 4
0(1415871) ERROR: <script>: 1734540014 count 4
0(1415871) ERROR: <script>: 1734540015 count 5
0(1415871) ERROR: <script>: 1734540015 count 5
0(1415871) ERROR: <script>: 1734540015 count 5
0(1415871) ERROR: <script>: 1734540016 count 6
0(1415871) ERROR: <script>: 1734540016 count 6
0(1415871) ERROR: <script>: 1734540016 count 6
0(1415871) ERROR: <script>: 1734540016 count 6
0(1415871) ERROR: <script>: 1734540017 count 7
0(1415871) ERROR: <script>: 1734540017 count 7
0(1415871) ERROR: <script>: 1734540017 count 7
0(1415871) ERROR: <script>: 1734540018 count 8
0(1415871) ERROR: <script>: 1734540018 count 8
0(1415871) ERROR: <script>: 1734540018 count 8
0(1415871) ERROR: <script>: 1734540019 count 9
0(1415871) ERROR: <script>: 1734540019 count 9
0(1415871) ERROR: <script>: 1734540019 count 9
0(1415871) ERROR: <script>: 1734540020 count 10
0(1415871) ERROR: <script>: 1734540020 count 10
0(1415871) ERROR: <script>: 1734540020 count 10
0(1415871) ERROR: <script>: 1734540021 count 11
0(1415871) ERROR: <script>: 1734540021 count 11
0(1415871) ERROR: <script>: 1734540021 count 11
0(1415871) ERROR: <script>: 1734540022 count 12
0(1415871) ERROR: <script>: 1734540022 count 12
0(1415871) ERROR: <script>: 1734540022 count 12
0(1415871) ERROR: <script>: 1734540023 count 13
0(1415871) ERROR: <script>: 1734540023 count 13
0(1415871) ERROR: <script>: 1734540023 count 13
0(1415871) ERROR: <script>: 1734540024 count 14
0(1415871) ERROR: <script>: 1734540024 count 14
0(1415871) ERROR: <script>: 1734540024 count 14
0(1415871) ERROR: <script>: 1734540025 count 15
0(1415871) ERROR: <script>: 1734540025 count 15
0(1415871) ERROR: <script>: 1734540025 count 15
0(1415871) ERROR: <script>: 1734540026 count 16
0(1415871) ERROR: <script>: 1734540026 count 16
0(1415871) ERROR: <script>: 1734540026 count 16
0(1415871) ERROR: <script>: 1734540026 count 16
0(1415871) ERROR: <script>: 1734540027 count 17
0(1415871) ERROR: <script>: 1734540027 count 17
0(1415871) ERROR: <script>: 1734540027 count 17
0(1415871) ERROR: <script>: 1734540028 count 18
0(1415871) ERROR: <script>: 1734540028 count 2
0(1415871) ERROR: <script>: 1734540028 count 2
0(1415871) ERROR: <script>: 1734540029 count 3
0(1415871) ERROR: <script>: 1734540029 count 3
0(1415871) ERROR: <script>: 1734540029 count 3
0(1415871) ERROR: <script>: 1734540030 count 4
0(1415871) ERROR: <script>: 1734540030 count 4
0(1415871) ERROR: <script>: 1734540030 count 4
0(1415871) ERROR: <script>: 1734540031 count 5
0(1415871) ERROR: <script>: 1734540031 count 5
0(1415871) ERROR: <script>: 1734540031 count 5
0(1415871) ERROR: <script>: 1734540032 count 6
```
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
% /usr/sbin/kamailio -V
version: kamailio 5.8.4 (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_SEND_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 12.2.0
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `lsb_release -a` and `uname -a`)
-->
```
% cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4080
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4080(a)github.com>
I noticed at least two styles of CMakeLists.txt for modules:
```
❯ cat src/modules/acc/CMakeLists.txt
file(GLOB acc_SRC "*.c")
add_library(acc SHARED ${acc_SRC})
```
and
```
❯ cat src/modules/xlog/CMakeLists.txt
file(GLOB SRC_FILES "*.c")
add_library(xlog SHARED ${SRC_FILES})
# # target_link_libraries(.*PRIVATE)
```
Which one should be used? The one with `modname_SRC` (e.g., `acc_SRC`) or the one with `SRC_FILES`?
Also, I guess that the comment with `target_link_libraries()` can be removed.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4081
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4081(a)github.com>
HI devs,
In trying to solve the libssl3 issue the original attempt with
tls_threads_mode=1 turns out to be not quite correct.
Since the release of 5.8 we have consistently recommended
tls_threads_mode=2 for users of libssl 1.1.1 and 3.
For master/6.0.0-pre I will start to revert the changes of
tls_threads_mode=1.
I will also add a new simpler mode tls_threads_mode=3 based on the diff by
Ondrej Jirman <megi(a)xff.cz> (@meengu).
Regards
Richard