rtpproxy-ng on Centos 5.9 about rtpengine HOT 16 CLOSED

I'm not aware of any reason why it shouldn't work on CentOS 5.9, but I haven't tried it myself and I also don't recall hearing from anyone who ever did. I would suggest to just try to build it, see what happens and then go from there.

Iptables 1.3.5 should be fine, but again there might be some bumps ahead. I see 1.3.6 is hardcoded into the source, so you might have to change that. Again, just give it a go and then we can try to make it work.

from rtpengine.

Hi Richard,

Thanks for the reply.

Ok cool, I am just trying to make the daemon and Im getting;

make rtpengine
make[1]: Entering directory /usr/src/rtpengine/daemon' gcc -g -Wall -pthread -fno-strict-aliasing -std=c99pkg-config --cflags glib-2.0 pkg-config --cflags gthread-2.0 pkg-config --cflags zlib pkg-config --cflags openssl pcre-config --cflags-I../kernel-module/ -D_GNU_SOURCE -DRTPENGINE_VERSION="\"git-master-2460836\"" -DMP_PLUGIN_DIR="\"/usr/lib/rtpengine\"" -O3 -c -o call_interfaces.o call_interfaces.c call_interfaces.c: In function 'ng_list_calls': call_interfaces.c:858: error: 'GHashTableIter' undeclared (first use in this function) call_interfaces.c:858: error: (Each undeclared identifier is reported only once call_interfaces.c:858: error: for each function it appears in.) call_interfaces.c:858: error: expected ';' before 'iter' call_interfaces.c:863: warning: implicit declaration of function 'g_hash_table_iter_init' call_interfaces.c:863: error: 'iter' undeclared (first use in this function) call_interfaces.c:864: warning: implicit declaration of function 'g_hash_table_iter_next' make[1]: **\* [call_interfaces.o] Error 1 make[1]: Leaving directory/usr/src/rtpengine/daemon'
make: *** [all] Error 2

Any ideas which spring to mind? I will of course look to troubleshoot now.

Thanks

Jon

from rtpengine.

That would be from glib... Which version of glib do you have installed? Also make sure you have all the necessary devel packages installed.

from rtpengine.

Hi Richard,

Ok will check devel packages. In terms of glib;

glib.x86_64 1:1.2.10-20.el5 installed
glib2.x86_64 2.12.3-4.el5_3.1

Thanks

Jon

from rtpengine.

Ah yes, that might be a problem. GHashTableIter doesn't exist until glib 2.16. It only affects the "list" command, so I think it's easiest to just take it out if the glib version is too low. I'll commit a fix shortly.

from rtpengine.

Try again with 19e0281 installed

from rtpengine.

Thank you, I have installed latest version, and fixs the first problem, I now see;

Entering directory /usr/src/rtpengine/daemon' gcc -g -Wall -pthread -fno-strict-aliasing -std=c99pkg-config --cflags glib-2.0 pkg-config --cflags gthread-2.0 pkg-config --cflags zlib pkg-config --cflags openssl pcre-config --cflags-I../kernel-module/ -D_GNU_SOURCE -DRTPENGINE_VERSION="\"git-master-19e0281\"" -DMP_PLUGIN_DIR="\"/usr/lib/rtpengine\"" -O3 -c -o dtls.o dtls.c dtls.c: In function 'dtls_connection_init': dtls.c:451: warning: implicit declaration of function 'SSL_CTX_set_tlsext_use_srtp' dtls.c: In function 'dtls_setup_crypto': dtls.c:492: error: 'SRTP_PROTECTION_PROFILE' undeclared (first use in this function) dtls.c:492: error: (Each undeclared identifier is reported only once dtls.c:492: error: for each function it appears in.) dtls.c:492: error: 'spp' undeclared (first use in this function) dtls.c:499: warning: implicit declaration of function 'SSL_get_selected_srtp_profile' dtls.c:515: warning: implicit declaration of function 'SSL_export_keying_material' make[1]: **\* [dtls.o] Error 1 make[1]: Leaving directory/usr/src/rtpengine/daemon'
make: *** [all] Error 2

Sorry to be pain!

Thanks

Jon

from rtpengine.

Looks like your OpenSSL is too old and doesn't support DTLS/SRTP. Do you need this feature?

from rtpengine.

I certainly need to implemented SRTP, as have it running well on another Centos Server, where Im interworking RTP to SRTP.
Which version of openSSL would be required, do you know?

This server has openssl-0.9.8e-26.el5_9.1.x86_64.

from rtpengine.

According to the changelog, the lowest version to support DTLS/SRTP is 1.0.1 from March 2012. Recommended is at least 1.0.1j as a lot of bugs have been fixed in the meantime. Note that this affects only DTLS/SRTP, not SRTP per se (which theoretically could still be used through the now obsolete SDES).

from rtpengine.

Ok cool thank you leave it with me will update shortly.

from rtpengine.

Hi Richard,

I have been looking at this, and as openssl is a core package, my fear is this will impact many other packages related to it.

I assume you have to yum remove the old version, before looking to install the new version? Are there any repo's you know of that can be used for this?

If not possible I will look to move the service to a centos 6.5 box like the rest of my servers.

Thanks

Jon

from rtpengine.

I really don't have much (any) experience with Red Hat/CentOS, so I can't help you with that. One possibility that always exists is to do a manual install: download the OpenSSL source package, compile it yourself and then either don't install it at all, or install it somewhere privately, out of the way. Then when compiling rtpengine, tell it not to use the system's OpenSSL but rather the one you've compiled (possibly statically linked in).

from rtpengine.

Yes thats an idea about installing it out of the way.

so the final question Richard (and sorry for having so many) is where in the rtpengine install script should I repoint it to my new OpenSSL ?

Thanks

Jon

from rtpengine.

You'd have to modify the makefile. The makefile pulls in the necessary compiler and linker flags through pkg-config:

CFLAGS+=        `pkg-config --cflags openssl`
...
LDFLAGS+=       `pkg-config --libs libcrypto`
LDFLAGS+=       `pkg-config --libs openssl`

You'd need to take these out and replace them with appropriate compiler and linker flags to pull the library files from whatever other location you've installed them to, e.g. -I, -L and -l flags. Consider building OpenSSL only as a static library, then you don't have to worry about the final binary being able to find the correct shared object files.

As a final complication, it's possible that some of the other libraries also link against OpenSSL. The xmlrpc library is a candidate for that. If that is so, then a different static version of the same library may or may not work. If it doesn't, you can try with a dynamic library and use the LD_LIBRARY_PATH variable when starting the final binary to make it find the new file. This should work as long as there aren't any compatibility issues between the versions.

Alternatively, you can also build a new xmlrpc library which links against the new OpenSSL, same procedure. Or remove the xmlrpc dependency altogether and disable those parts of the code. Either way, prepare for a bumpy road ahead.

from rtpengine.

Thanks Richard, I have aborted mission and moved to another new Centos 6 box.

Thank you for your input as ever.

Jon

from rtpengine.