Open AngryGami opened 4 months ago
Alpine is not a core supported environment by the project. It is community supported, and may ultimately be the cause of this. There have been no other reports of such an issue with non-Alpine environments.
Well it does work in alpine 3.11 (asterisk 16.6.2). As far as I understand this is somehow related to libssl that asterisks uses which comes with asterisk as dependency but originates in openssl project. Maybe something is different in how asterisk is built for alpine environment.. Whom could I ask and/or where?
Asterisk package for Alpine is built using openssl-dev (3.1.4-r2)
(from here), is this different from how it is built for e.g. Ubuntu?
We don't distribute packages, people generally build it themselves on the various distros or use the packages provided by those distros. A fundamental difference is that Alpine uses a different libc library to the rest, which has caused issues in the past. I don't know of differences regarding OpenSSL across things. I can just safely say that across Debian, Ubuntu, and Redhat based distros things currently work fine in this area.
You could investigate yourself such as trying to figure out the differences between Asterisk versions and identify what caused the behavior change to elicit this.
I do recall there are one or two people with Asterisk + Alpine experience, so perhaps they'll comment on here with insight too.
Thanks I understand that alpine is using musl for libc implementation but it is still strange that only this interaction is affected somehow - usually this difference manifests itself with lots of crashes and incompatibilities. Do you know which version of openssl is used when asterisk is build for e.g. Ubuntu? Or maybe know where to look for that?
I have no involvement in Ubuntu packaging. It would also depend on the version of Ubuntu in question. I don't know off the top of my head where to look.
I've reproduced exactly same issue on ubuntu .
$ docker exec hosp-asterisk cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.3 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.3 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
Asterisk 18.10.0~dfsg+~cs6.10.40431411-2 built by nobody @ buildd.debian.org on a unknown running Linux on 2022-02-12 18:24:51 UTC
The current supported version of Asterisk 18 is 18.21.0. It would need to be reproduced under that version built by yourself without any patches. If the problem reoccurs then a complete log, as well as a packet capture would be needed. We would also need to know what client is using DTLS, since using it in a non-WebRTC environment is uncommon.
Client is liblinphone
version 5.2.77, though calls between two DTLS clients just work - only when I try to make a call from DTLS to plain UDP client this error appears.
I don't know how to build asterisk myself and this version is one I've got from official ubuntu repository for jammy
- why it is not good enough... strange.
Distro packages lag behind, and they also include patches not part of Asterisk.
Ok, I guess tcpdump taken now should be fine (i.e. I don't need to build asterisk from scratch). So here it is: dump.zip Logs from asterisk for this moment:
[2024-02-02 16:54:55.920] VERBOSE[901][C-00000007] bridge_channel.c: Channel PJSIP/vlocal10011-0000000c joined 'simple_bridge' basic-bridge <923214af-925c-4aaa-a00e-511ab87d5eda>
[2024-02-02 16:54:56.460] ERROR[901][C-00000007] res_rtp_asterisk.c: DTLS failure occurred on RTP instance '0x7fec74179800' due to reason 'called a function you should not call', terminating
[2024-02-02 16:54:56.460] WARNING[901][C-00000007] res_rtp_asterisk.c: RTP Read error: Unspecified. Hanging up.
[2024-02-02 16:54:56.460] VERBOSE[901][C-00000007] bridge_channel.c: Channel PJSIP/vlocal10011-0000000c left 'simple_bridge' basic-bridge <923214af-925c-4aaa-a00e-511ab87d5eda>
[2024-02-02 16:54:56.461] VERBOSE[907][C-00000007] bridge_channel.c: Channel PJSIP/intercom1-0000000d left 'simple_bridge' basic-bridge <923214af-925c-4aaa-a00e-511ab87d5eda>
And packet that most likely caused issue is this one:
I'll try to build "proper" asterisk version later next week... though I doubt this will do anything useful.
Were you able to reproduce this using a non-distro build?
I didn't have time to setup everything I need to build asterisk from sources. So - no, I didn't.
Severity
Minor
Versions
Asterisk 20.5.2
Components/Modules
res_rtp_asterisk
Operating Environment
Alpine Linux 3.19, docker container
Frequency of Occurrence
Constant
Issue Description
I have two clients connected in following way: "Intercom" client uses udp for both sip and rtp
and "User" client that uses tls/dtsl:
When I try to make call from "User" to "Intercom" sip seems to work just fine and bridge is created on asterisk, but then suddenly call drops with following messages in the logs:
Error is
This error message most likely comes from openssl library here: https://github.com/openssl/openssl/blob/9170cc0398222778065e098e396b8eb8cd0de1d3/ssl/ssl_lib.c#L2291
which is probably called from asterisk code here: https://github.com/asterisk/asterisk/blob/master/res/res_rtp_asterisk.c#L3284
I've tried this setup on lower and lower Asterisk versions and it eventually worked on Asterisk 16.6.2 (Alpine 3.11 in container).
Relevant log output
No response
Asterisk Issue Guidelines