Erro Loading SRTP on Asterisk 20 and Centos 9

Asterisk Asterisk Support
1

I’am installing a new Asterisk Vanilla Server using CentOS 9 and Asterisk 20, but I am getting a error when try to execute load asterisk.

[Feb 15 13:32:02] WARNING[168489]: res_srtp.c:1238 res_srtp_init: Failed to initialize libsrtp
[Feb 15 13:32:02] ERROR[168489]: loader.c:2513 load_modules: *** Failed to load module res_srtp.so
[Feb 15 13:32:02] ERROR[168489]: asterisk.c:4039 check_init: Module initialization failed. ASTERISK EXITING!

How can I fix this issue?

CentOS Stream release 9
Asterisk 20.1.0
libsrtp-2.3.0-7.el9.x86_64

Thanks for help

2

This is with the libsrtp itself. I recall a previous reporter ended up building libsrtp themselves which resolved the issue.

3

Thanks for reply and help, I did download source and test with libsrtp 1.6.0 and 2.5.0, both show me the same issue

[Feb 15 14:59:01] ERROR[180995]: loader.c:2513 load_modules: Error loading module ‘res_srtp.so’: libsrtp2.so.1: cannot open shared object file: No such file or directory

Than i linked a file to /usr/lib64 but after that it show me other error.

[Feb 15 15:44:46] ERROR[181205]: loader.c:2513 load_modules: Error loading module ‘res_srtp.so’: /lib64/libsrtp2.so.1: invalid ELF header

Do you have some clue?

4

What is the output of Linux the shell command file run against the .so and the shell command ldd run against res_srtp.so?

5

Thanks for your help.

Here it is

# ldd /usr/lib64/asterisk/modules/res_srtp.so
/usr/lib64/asterisk/modules/res_srtp.so: error while loading shared libraries: /lib64/libsrtp2.so.1: invalid ELF header

# ldd /lib64/libsrtp2.so.1
        not a dynamic executable
6

and the output from file?

(It is fairly clear that /lib64/libsrtp2.so.1 is not a valid file, but the output from file may tell us what it actually is, and give a clue as to why an invalid file ended up here.)

The output should be similar to:

$ file /usr/lib/x86_64-linux-gnu/libsrtp2.so.1
/usr/lib/x86_64-linux-gnu/libsrtp2.so.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=253ec3df7298ab513ee583fbe694e13d96b0bdda, stripped

This is from Debian, not CentOS. This version is not being used with Asterisk and may or may not be compatible.

If it says symbolic link, you should repeat file on the link target.

7

Thanks david551, it show me the way, I will describe how I did solve at CentOS 9 and now work.

  1. Download last version LIBSRTP 2.5 (GitHub - cisco/libsrtp: Library for SRTP (Secure Realtime Transport Protocol))
  2. Build a Shared Library
./configure --enable-openssl
make shared_library
sudo make install
  1. Link the library to the /usr/lib64/, because they will install it in other directory
ln -s /usr/local/lib/libsrtp2.so.1 /usr/lib64/libsrtp2.so.1

And this solve the issue to me.

Thanks to David and JColp

2 Likes
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

9

I wanted to append a reply to Erro Loading SRTP on Asterisk 20 and Centos 9 to explain what the real issue is and how to fix it properly but it is closed so I cannot. If a friendly moderator wants to merge this new topic with that one then that is fine by me.

The version of libsrtp as shipped by Red Hat for RHEL 9 is missing the patch for the problem reported against Fedora 34 1948729 – srtp_init() always returns srtp_err_status_cipher_fail and the patch that is required is linked off that and applies cleanly to the RHEL 9 libsrtp-2.3.0-7.el9 SRPM and fixes the problem. As a new user I am not allowed to link to 3 things or I would link direct to teh required patch.

I have reported this to RH via issue RHEL-15105 on their JIRA so hopefully it will get fixed by them at some point in the not too distant future.

10

All are the same issue and all would be fixed with the patch. Basically libsrtp that ships with RHEL 9 up to and included 9.2 is totally broken.

11

https://community.asterisk.org/t/rhel-9-and-clones-for-asterisk-installation/93411/4

Two more that it won’t let me post in one go.

12

The link to the required patch https://bugzilla-attachments.redhat.com/attachment.cgi?id=1772232