Re: [asterisk-dev] EVS codec for Asterisk 16

[sean darcy]

On 9/4/20 1:49 PM, Michael Maier wrote:

On 03.09.20 at 21:41 Alexander Traud wrote:

/usr/lib64/asterisk/modules/codec_evs.so


Please,
1) do an "ldd" on that. Does it find all dependencies?


Just for info. The expected result would be something like that:

[root@myast ~]# ldd /usr/lib64/asterisk/modules/codec_evs.so
 linux-vdso.so.1 =>  (0x7ffc4034e000)
 lib3gpp-evs.so => /lib64/lib3gpp-evs.so (0x7fedadb2)
 libpthread.so.0 => /lib64/libpthread.so.0 (0x7fedad904000)
 libc.so.6 => /lib64/libc.so.6 (0x7fedad536000)
 /lib64/ld-linux-x86-64.so.2 (0x7fedae118000)

[root@myast ~]# ldd /usr/lib64/asterisk/modules/codec_amr.so
 linux-vdso.so.1 =>  (0x7fff96bc9000)
 libopencore-amrnb.so.0 => /lib64/libopencore-amrnb.so.0 
(0x7fa96835a000)
 libopencore-amrwb.so.0 => /lib64/libopencore-amrwb.so.0 
(0x7fa968146000)
 libvo-amrwbenc.so.0 => /lib64/libvo-amrwbenc.so.0 (0x7fa967f2c000)
 libpthread.so.0 => /lib64/libpthread.so.0 (0x7fa967d1)
 libc.so.6 => /lib64/libc.so.6 (0x7fa967942000)
 libm.so.6 => /lib64/libm.so.6 (0x7fa96764)
 /lib64/ld-linux-x86-64.so.2 (0x7fa968789000)



2) Which version/variant of Asterisk do you use?



Thanks
Michael


Thanks for the quick responses.

I'm on Fedora 32, asterisk-16.13-rc2.

Rebooted and all is now well.

Only thing odd is that my codec_evs.so does not show libpthread.so as a 
dependency:


ldd /usr/lib64/asterisk/modules/codec_evs.so
linux-vdso.so.1 (0x7ffe8c7b)
lib3gpp-evs.so => /lib64/lib3gpp-evs.so (0x7f368797b000)
libc.so.6 => /lib64/libc.so.6 (0x7f36877b1000)
/lib64/ld-linux-x86-64.so.2 (0x7f3687bd3000)

Does it matter? Should I care ?

sean


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] EVS codec for Asterisk 16

[sean darcy]

On 8/23/20 6:02 AM, Michael Maier wrote:

Hello!

Alexander Traud provided patches for Asterisk 13 for the EVS codec[1]. Those 
patches can be applied to Asterisk 16, too. I attached a tar file, which 
contains all patches from
Alexander in one file and a spec file for building the evs codec library from 
www.etsi.org (tested on CentOS 7).

At first, you have to build the lib3gpp-evs library with
rpmbuild -ba lib3gpp-evs.spec

This creates 4 packages: a src, a devel and the library package itself and the 
corresponding debuginfo package.
On the machine, you are building Asterisk at next, you have to install the 
library and the devel package. On the machine Asterisk runs, you only need the 
library package.

To build Asterisk, you have to apply the evs-asterisk.16.patch (which contains 
all changes necessary in one patch file as described at [1] - the patch here 
wants to have this
patch[2] already applied before). Any further information how to build Asterisk 
after the patch file has been applied can be found here[1].

If all went fine, there are at the end two more modules in 
/usr/lib64/asterisk/modules:
codec_evs.so
res_format_attr_evs.so

After restarting of Asterisk, you can check if everything went fine by:

asterisk -r
core show codecs
(-> evs must be part of the list)

core show translation
(evs must be part of the list)

After adding the codec to be allowed for a trunk, you may test it - I couldn't 
test it so far, because I didn't have any device using the evs codec.


Thanks
Michael


[1] https://github.com/traud/asterisk-evs
[2] https://www.mail-archive.com/asterisk-dev@lists.digium.com/msg45213.html




Thanks for the patches. All seemed to go smoothly:

ls  /usr/lib64/asterisk/modules/*evs.so
/usr/lib64/asterisk/modules/codec_evs.so
/usr/lib64/asterisk/modules/res_format_attr_evs.so

And

core show codecs
..
  ID TYPE  NAME FORMAT   DESCRIPTION

   4 audio evs  evs  (3GPP EVS)
.
   1 audio amr  amr  (AMR)
   2 audio amrwbamrwb(AMR-WB)


But "core show translation" does not show evs (or amr, which I also built):

core show translation
 Translation times between formats (in microseconds) for one 
second of data

  Source Format (Rows) Destination Format (Columns)

   ulaw  alaw   gsm  g726 g726aal2 adpcm slin8 slin12 slin16 
slin24 slin32 slin44 slin48 slin96 slin192 lpc10 speex8 speex16 speex32 
ilbc  g722 siren7 siren14 testlaw  opus silk8 silk12 silk16 silk24

.

Any suggestions?

sean


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] build xmpp without iksemel

[sean darcy]

iksemel is no longer maintained. 16.6.1 still wants iksemel for 
res_xmpp,but openssl seems ok:


Depends on: iksemel(E)
   Can use: openssl(E)

openssl installed:

checking for OpenSSL installations..
checking openssl/ssl.h usability... yes
checking openssl/ssl.h presence... yes
checking for openssl/ssl.h... yes
checking for ERR_load_BIO_strings in -lcrypto... yes
checking for SSL_CTX_new in -lssl... yes
OpenSSL library found, SSL support enabled
checking for EVP_aes_128_gcm in -lcrypto... yes
OpenSSL has AES GCM support, SRTP will use OpenSSL

But: XXX res_xmpp

And chan_motif dies because it wants res_xmpp.

Any suggestions appreciated.

sean


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] pjsip asterisk 13.24: sips / srtp and Deutsche Telekom doesn't work because of missing mediasec parameters

[sean darcy]

On 1/15/19 1:49 PM, Michael Maier wrote:

Hello!

Deutsche Telekom introduced sips and srtp. I tested it and it works partly. 
Partly means: sips is working - but not srtp. srtp doesn't work, because of 
missing additional
headers in the REGISTER and INVITE packages (according an enhancement of RFC 
3329).


Example:

UACRegistrar
|   |
|(1) REGISTER-->|
|Security-Client: sdes-srtp;mediasec|
|Proxy-Require: mediasec|
|Require: mediasec  |
|   |
|<---(2) 401|
|Security-Server: msrp-tls;mediasec |
|Security-Server: sdes-srtp;mediasec|
|Security-Server: dtls-srtp;mediasec|
|   |
|(3) REGISTER(with Authorization Header)--->|
|Security-Client: sdes-srtp;mediasec|
|Proxy-Require: mediasec|
|Require: mediasec  |
|Security-Verify: msrp-tls;mediasec |
|Security-Verify: sdes-srtp;mediasec|
|Security-Verify: dtls-srtp;mediasec|
|   |
|<---(4) 200 OK-|
|   |
|   |
|(5) INVITE>|
|Security-Verify: msrp-tls;mediasec |
|Security-Verify: sdes-srtp;mediasec|
|Security-Verify: dtls-srtp;mediasec|
|a=3ge2ae:requested |
|a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:EpcgtOdT5qd...
|   |
|<---(8) 200 OK-|
|a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:lnfakjh2sd1..



You can find a complete description here (english language):
https://www.telekom.de/hilfe/downloads/1tr114.pdf
The example can be found on page 115.

They need those mediasec parameters because of there compatibility with the 
3GPP standards
(http://www.qtc.jp/3GPP/Specs/33328-920.pdf) which would require an additional 
signaling of the media plane security.


Is this already implemented or did I miss something else?



Thanks,
regards,
Michael


You may want to contact pjsip.

sean


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 15 RC1 and RTP/RTCP leak ?

[sean darcy]

On 09/26/2017 03:04 PM, Sean Bright wrote:

On 9/26/2017 12:37 PM, sean darcy wrote:

Are there any RTP/RTCP leak issues with 15 RC1 ?


What kind of leak? Memory leak?


Should have been more precise:

Asterisk Project Security Advisory - AST-2017-008


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Asterisk 15 RC1 and RTP/RTCP leak ?

[sean darcy]

Are there any RTP/RTCP leak issues with 15 RC1 ?

sean


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] dahdi: module signature verification on fedora

[sean darcy]

installing newly built dahdi kernel modules, I get:

INSTALL 
/home/asterisk/rpmbuild/BUILD/dahdi-linux-changes-for-4.11/drivers/dahdi/../staging/echo/echo.ko

At main.c:160:
- SSL error:02001002:system library:fopen:No such file or directory: 
bss_file.c:175

- SSL error:2006D080:BIO routines:BIO_new_file:no such file: bss_file.c:182
sign-file: certs/signing_key.pem: No such file or directory
.

for all the modules.

googling taught me that Fedora has turned on "Module Signature 
Verification", which seems to require a signing certificate. It seems 
ubuntu also has it.


dahdi is the only time I build and install kernel modules. AFAICT, the 
modules were installed, and did load.


Anybody else seeing this? How do you handle without getting your own pem 
certificate ?


sean


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] dahdi 2.11.1 build fails with kernel 4.11.3

[sean darcy]

Building dahdi-2.11.1 using gcc-6.3.1 for kernel-4.11.3:

..
make[1]: Entering directory '/usr/src/kernels/4.11.3-200.fc25.x86_64'
  CC [M] 
/home/asterisk/rpmbuild/BUILD/dahdi-linux-2.11.1/drivers/dahdi/dahdi-base.o
/home/asterisk/rpmbuild/BUILD/dahdi-linux-2.11.1/drivers/dahdi/dahdi-base.c: 
In function 'dahdi_ioctl_iomux':
/home/asterisk/rpmbuild/BUILD/dahdi-linux-2.11.1/drivers/dahdi/dahdi-base.c:5954:7: 
error: implicit declaration of function 'signal_pending' 
[-Werror=implicit-function-declaration]

   if (signal_pending(current))

For whatever reason signal_pending has been moved in 4.13. dahdi-base.o 
needs:


#include 

But then:


  CC [M] 
/home/asterisk/rpmbuild/BUILD/dahdi-linux-2.11.1/drivers/dahdi/dahdi_dynamic.o
/home/asterisk/rpmbuild/BUILD/dahdi-linux-2.11.1/drivers/dahdi/dahdi_dynamic.c: 
In function '_destroy_dynamic':
/home/asterisk/rpmbuild/BUILD/dahdi-linux-2.11.1/drivers/dahdi/dahdi_dynamic.c:470:18: 
error: passing argument 1 of 'atomic_read' from incompatible pointer 
type [-Werror=incompatible-pointer-types]

  if (atomic_read(&d->kref.refcount) > 2) {
  ^
In file included from ./arch/x86/include/asm/msr.h:66:0,
 from ./arch/x86/include/asm/processor.h:20,
 from ./arch/x86/include/asm/cpufeature.h:4,
 from ./arch/x86/include/asm/thread_info.h:52,
 from ./include/linux/thread_info.h:25,
 from ./arch/x86/include/asm/preempt.h:6,
 from ./include/linux/preempt.h:80,
 from ./include/linux/spinlock.h:50,
 from ./include/linux/seqlock.h:35,
 from ./include/linux/time.h:5,
 from ./include/linux/stat.h:18,
 from ./include/linux/module.h:10,
 from 
/home/asterisk/rpmbuild/BUILD/dahdi-linux-2.11.1/drivers/dahdi/dahdi_dynamic.c:27:
./arch/x86/include/asm/atomic.h:24:28: note: expected 'const atomic_t * 
{aka const struct  *}' but argument is of type 'refcount_t * 
{aka struct refcount_struct *}'

 static __always_inline int atomic_read(const atomic_t *v)

About which I have no clue.

sean


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 14.0.1 Now Available

[sean darcy]

On 09/27/2016 03:47 PM, Asterisk Development Team wrote:

The Asterisk Development Team has announced the release of Asterisk 14.0.1.
This release is available for immediate download at
http://downloads.asterisk.org/pub/telephony/asterisk

The release of Asterisk 14.0.1 resolves an issue reported by the
community and would have not been possible without your participation.
Thank you!

The following is the issue resolved in this release:

Improvements made in this release:
---
 * ASTERISK-26409 - codec_opus: Update Asterisk to support the
  translation codec. (Reported by Kevin Harwell)

For a full list of changes in this release, please see the ChangeLog:

http://downloads.asterisk.org/pub/telephony/asterisk/ChangeLog-14.0.1

Thank you for your continued support of Asterisk!

Does this mean that opus is included natively ? No longer necessary to 
patch the source ?


sean


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] dahdi-tools 2.11.1 : fix for relocation error on build

[sean darcy]

On 03/06/2016 04:50 AM, Oron Peled wrote:

Hi,

On Saturday 05 March 2016 18:07:48 sean darcy wrote:

...
Running standard Fedora 23.


Me too (but didn't use it for RPM build).


Here's the bootstrap and configure in the rpm build:
...
+ LDFLAGS='-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld'


Bingo. A failure can now be achieved by:
./configure LDFLAGS='-specs=/usr/lib/rpm/redhat/redhat-hardened-ld'


FWIW, if -fPIC is not in CFLAGS the .configure compiler check fails:
configure:3875: checking whether we are cross compiling
configure:3883: gcc -o conftest -O2 -march=native -mtune=native
-ftree-vectorize -ffast-math  -Wl,-z,relro
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld conftest.c  >&5
/usr/bin/ld: /tmp/cciqZ1hg.o: relocation R_X86_64_32 against
`.rodata.str1.1' can not be used when making a shared object; recompile with 
-fPIC
/tmp/cciqZ1hg.o: error adding symbols: Bad value


OK, the /usr/lib/rpm/redhat/redhat-hardended-ld contain:
   *self_spec:
   + %{!shared:%{!r:-pie}}
   *link:
   + -z now

So generating a "pie" (Position-Independent-Executable) logically require
linking object files compiled with -fPIC (Position-Independent-Code)
just like a shared library.

Now I add '-fPIC' (and --with-dahdi=..., so configure can complete):
./configure LDFLAGS='-specs=/usr/lib/rpm/redhat/redhat-hardened-ld' 
CFLAGS=-fPIC --with-dahdi=$PWD/../linux

And it pass the ./configure step.

However, with the original Makefile.am any executable we try to link fails
with the same error as the previous "conftest". By running "make V=1"
we can verify that the "-fPIC" isn't passed to the compiler.

Replacing in Makefile.am "CFLAGS = ..." with "CFLAGS += ..." fixed the bug.

I'll bet that until now this bug caused many compilations to pass with
wrong (but non-fatal) CFLAGS.

Thanks,



Interestingly, fedora koji doesn't need -fPIC to build dahdi-tools (at 
least 2.10.0, the latest package), even though LDFLAGS includes 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld


https://kojipkgs.fedoraproject.org//packages/dahdi-tools/2.10.0/6.fc23/data/logs/x86_64/build.log

sean




--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] dahdi-tools 2.11.1 : fix for relocation error on build

[sean darcy]

On 03/03/2016 04:34 PM, Oron Peled wrote:

Hi,

On Wednesday 02 March 2016 15:14:11 sean darcy wrote:

Building dahdi-tools 2.11.1:

gcc -DHAVE_CONFIG_H -I. -g -Wall -O2
-I/home/asterisk/rpmbuild/BUILD/dahdi-tools-2.11.1/include  -c -o
fxstest.o fxstest.c
/bin/sh ./libtool  --tag=CC   --mode=link gcc  -g -Wall -O2
-I/home/asterisk/rpmbuild/BUILD/dahdi-tools-2.11.1/include
-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o fxstest
fxstest.o libtonezone.la -lpthread -lm
libtool: link: gcc -g -Wall -O2
-I/home/asterisk/rpmbuild/BUILD/dahdi-tools-2.11.1/include -Wl,-z
-Wl,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o .libs/fxstest
fxstest.o  ./.libs/libtonezone.so -lpthread -lm -Wl,-rpath -Wl,/usr/lib64
/usr/bin/ld: fxstest.o: relocation R_X86_64_32 against `.rodata.str1.1'
can not be used when making a shared object; recompile with -fPIC

Even though:

+ CFLAGS='-O2 -march=native -mtune=native -ftree-vectorize -ffast-math
-fPIC'
+ export CFLAGS
+ CXXFLAGS='-O2 -march=native -mtune=native -ftree-vectorize -ffast-math
-fPIC'
+ export CXXFLAGS

because CFLAGS doesn't override the Makefile CFLAGS. Notice no -fPIC above.


OK, this is my bad:
  * The fix to Makefile.am is to replace the first CFLAGS assignment from "=" to 
"+="
  * Also note that CFLAGS should be passed to ./configure and not make (as 
"./configure --help" nicely mention).

Here is a patch:

diff --git a/Makefile.am b/Makefile.am
index d43ce91..9dd64b2 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5,7 +5,7 @@ LEGACY_MAKE = \
 top_srcdir=$(top_srcdir) \
 srcdir=$(srcdir)

-CFLAGS = -g -Wall -O2 $(DAHDI_INCLUDE)
+CFLAGS += -g -Wall -O2 $(DAHDI_INCLUDE)
  if DAHDI_DEVMODE
  CFLAGS += \
 -Werror \


The fix: add -fPIC to CFLAGS in Makefile.am, ./bootstrap.sh, build.


Normally, "-fPIC" isn't needed when linking an executable (only on shared 
objects).

Can you share more info about the build environment?
  * Linux distribution and version (some redhat?)
  * Primary tools versions (e.g: the output of "rpm -q rpm -q gcc make libtool 
automake autoconf rpm")
  * Extra stuff? maybe building an RPM? (which adds some extra 
distribution-specific CFLAGS, etc.)

The reason, is that I didn't encounter this failure either with/without "-fPIC"
and I'd like to try and re-create it.

Thanks for the report,



Thanks for the quick response.

Running standard Fedora 23.

rpm -q gcc make libtool automake autoconf rpm | sort
autoconf-2.69-21.fc23.noarch
automake-1.15-4.fc23.noarch
gcc-5.3.1-2.fc23.x86_64
libtool-2.4.6-8.fc23.x86_64
make-4.0-5.1.fc23.x86_64
rpm-4.13.0-0.rc1.12.fc23.x86_64

Here's the bootstrap and configure in the rpm build:

+ cd dahdi-tools-2.11.1
+ ./bootstrap.sh
Generating the configure script ...
+ CFLAGS='-O2 -march=native -mtune=native -ftree-vectorize -ffast-math 
-fPIC'

+ export CFLAGS
+ CXXFLAGS='-O2 -march=native -mtune=native -ftree-vectorize -ffast-math 
-fPIC'

+ export CXXFLAGS
+ FFLAGS='-O2 -march=native -mtune=native -ftree-vectorize -ffast-math 
-fPIC -I/usr/lib64/gfortran/modules'

+ export FFLAGS
+ FCFLAGS='-O2 -march=native -mtune=native -ftree-vectorize -ffast-math 
-fPIC -I/usr/lib64/gfortran/modules'

+ export FCFLAGS
+ LDFLAGS='-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld'
+ export LDFLAGS
+ '[' 1 = 1 ']'
+++ dirname ./configure
++ find . -name config.guess -o -name config.sub
+ for i in '$(find $(dirname ./configure) -name config.guess -o -name 
config.sub)'

++ basename ./auxdir/config.guess
+ '[' -f /usr/lib/rpm/redhat/config.guess ']'
+ /usr/bin/rm -f ./auxdir/config.guess
++ basename ./auxdir/config.guess
+ /usr/bin/cp -fv /usr/lib/rpm/redhat/config.guess ./auxdir/config.guess
'/usr/lib/rpm/redhat/config.guess' -> './auxdir/config.guess'
+ for i in '$(find $(dirname ./configure) -name config.guess -o -name 
config.sub)'

++ basename ./auxdir/config.sub
+ '[' -f /usr/lib/rpm/redhat/config.sub ']'
+ /usr/bin/rm -f ./auxdir/config.sub
++ basename ./auxdir/config.sub
+ /usr/bin/cp -fv /usr/lib/rpm/redhat/config.sub ./auxdir/config.sub
'/usr/lib/rpm/redhat/config.sub' -> './auxdir/config.sub'
+ '[' 1 = 1 ']'
+ '[' x '!=' x-specs=/usr/lib/rpm/redhat/redhat-hardened-ld ']'
++ find . -name ltmain.sh
+ for i in '$(find . -name ltmain.sh)'
+ /usr/bin/sed -i.backup -e 
's~compiler_flags=$~compiler_flags="-specs=/usr/lib/rpm/redhat/redhat-hardened-ld"~' 
./auxdir/ltmain.sh

++ pwd
+ ./configure --build=x86_64-redhat-linux-gnu 
--host=x86_64-redhat-linux-gnu --program-prefix= 
--disable-dependency-tracking --prefix=/usr --exec-prefix=/usr 
--bindir=/usr/bin --sbindir=/usr/sb

[asterisk-dev] dahdi-tools 2.11.1 : fix for relocation error on build

[sean darcy]

Building dahdi-tools 2.11.1:

gcc -DHAVE_CONFIG_H -I. -g -Wall -O2 
-I/home/asterisk/rpmbuild/BUILD/dahdi-tools-2.11.1/include  -c -o 
fxstest.o fxstest.c
/bin/sh ./libtool  --tag=CC   --mode=link gcc  -g -Wall -O2 
-I/home/asterisk/rpmbuild/BUILD/dahdi-tools-2.11.1/include 
-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o fxstest 
fxstest.o libtonezone.la -lpthread -lm
libtool: link: gcc -g -Wall -O2 
-I/home/asterisk/rpmbuild/BUILD/dahdi-tools-2.11.1/include -Wl,-z 
-Wl,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o .libs/fxstest 
fxstest.o  ./.libs/libtonezone.so -lpthread -lm -Wl,-rpath -Wl,/usr/lib64
/usr/bin/ld: fxstest.o: relocation R_X86_64_32 against `.rodata.str1.1' 
can not be used when making a shared object; recompile with -fPIC


Even though:

+ CFLAGS='-O2 -march=native -mtune=native -ftree-vectorize -ffast-math 
-fPIC'

+ export CFLAGS
+ CXXFLAGS='-O2 -march=native -mtune=native -ftree-vectorize -ffast-math 
-fPIC'

+ export CXXFLAGS

because CFLAGS doesn't override the Makefile CFLAGS. Notice no -fPIC above.

The fix: add -fPIC to CFLAGS in Makefile.am, ./bootstrap.sh, build.

sean



--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] CentOS packaging

[Sean Darcy]

On 02/26/2014 02:02 AM, Tzafrir Cohen wrote:

On Tue, Feb 25, 2014 at 05:04:26PM -0500, Sean Darcy wrote:

On 02/25/2014 02:03 PM, Ben Langfeld wrote:

After a conversation with Rusty last week, I've become aware that for a
simple installation of asterisk (11) from the CentOS repositories at
http://packages.asterisk.org/centos/, the 'current' repo at
http://packages.digium.com/centos is required to satisfy the dependency
of the 'asterisk' package on 'asterisk-dahdi'.

I understand that there are licensing reasons for this package to not be
available from the community repo, and I'm not going to get into the
complexity of that, but this situation is rather odd. It's required to
add a total of three repos, from two different domains, just to do 'yum
install asterisk' and get something from this decade. This seems
excessively complex, and likely unnecessary.

Is there anything that can be done to simplify this? Is the dependency
on asterisk-dahdi really necessary? Is there a reason not to publish the
contents of the 'current' repo to all of the 'asterisk-MAJOR' repos, to
reduce the required repo-count to 1?

Cheers,
Ben Langfeld



Does there need to be a dependency on asterisk-dahdi? Asterisk works
just fine without dahdi. Can it be an "add-on" if dahdi is wanted?
Is it required to specify dahdi at compilation to use the dahdi
package later?


dpkg has not only Depends but also Recommends (packages that SHOULD BE
installed for the package to work properly, but can not a strict
dependency) and Suggests (nice-to-have provisions).

We currently have asterisk-dahdi as a Suggests.


If asterisk is built with dahdi, does it need the dahdi package? All
of the dahdi package? or just the tools? Perhaps asterisk-dahdi
could just be the tools (which would meet the Fedora criterion,
right?), and the kernel modules an "add-on" package.


Asterisk uses libtonezone from dahdi-tools (right? Just chan_dahdi?).
Asterisk-dahdi are all the modules that will not work without DAHDI
support: chan_dahdi, app_meetme, res_timing_dahdi, codec_dahdi, and a
few other minor modules.

The kernel modules are from a different package that is independent of
Asterisk. It is also a package that will not get into Fedora any time
soon. It has two licensing issues:

1. binary-only objects optionally used to build some of the modules.
2. firmware files.

(2) can be fixed in retrospect at distribution time. But (1) has to be
tended to at build time. The Debian packages thus fail to include (1)[1]
and sort-of-work-around (2) with a package in non-free[2].

[1] 
http://patch-tracker.debian.org/patch/series/view/dahdi-linux/1:2.7.0.1~dfsg-1/no_firmware_download

[2] Debian's firmware policy is stricter than Fedora's, and some of the
firmwares will be legal for Fedora. The ones not currently not even
included in the Debian package will not.



Thanks for the description. I understand better now.

If I understand correctly, to build asterisk with chan_dahdi selected in 
menuseelect, libtonezone from dahdi-tools is required. Once built, dahdi 
and it's various modules will only work if those modules, the firmware 
and the kernel modules are present. If they are not present, dahdi will 
just fail to load, the rest of asterisk will work just fine. Correct?



If so, why can't Fedora (and Debian) have an asterisk package with 
chan_dahdi selected, requiring libtonezone.so, which doesn't cause any 
issues with the packaging criteria. This way, all users can run yum 
install asterisk from the fedora repo. If they need dahdi, they will 
need to specify another repo which would have a dahdi package with the 
modules and firmware.


sean


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] CentOS packaging

[Sean Darcy]

On 02/25/2014 02:03 PM, Ben Langfeld wrote:

After a conversation with Rusty last week, I've become aware that for a
simple installation of asterisk (11) from the CentOS repositories at
http://packages.asterisk.org/centos/, the 'current' repo at
http://packages.digium.com/centos is required to satisfy the dependency
of the 'asterisk' package on 'asterisk-dahdi'.

I understand that there are licensing reasons for this package to not be
available from the community repo, and I'm not going to get into the
complexity of that, but this situation is rather odd. It's required to
add a total of three repos, from two different domains, just to do 'yum
install asterisk' and get something from this decade. This seems
excessively complex, and likely unnecessary.

Is there anything that can be done to simplify this? Is the dependency
on asterisk-dahdi really necessary? Is there a reason not to publish the
contents of the 'current' repo to all of the 'asterisk-MAJOR' repos, to
reduce the required repo-count to 1?

Cheers,
Ben Langfeld


Does there need to be a dependency on asterisk-dahdi? Asterisk works 
just fine without dahdi. Can it be an "add-on" if dahdi is wanted? Is it 
required to specify dahdi at compilation to use the dahdi package later?


If asterisk is built with dahdi, does it need the dahdi package? All of 
the dahdi package? or just the tools? Perhaps asterisk-dahdi could just 
be the tools (which would meet the Fedora criterion, right?), and the 
kernel modules an "add-on" package.


FWIW, I actually use koji to build rc asterisk packages without dahdi.

sean


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Media Format Work

[Sean Darcy]

On 01/21/2014 10:14 AM, Joshua Colp wrote:

Greetings everyone,

I thought I'd give an update on this. The wiki page[1] is now at a state
where I'm happy with the design aspect of it. Matt Jordan has also
contributed test cases to the wiki page which will be implemented so
that the existing code (and new code) will have tests that cover various
scenarios. If there are any critical scenarios that have been missed
don't hesitate to say something. I've also created a branch[2] where
implementation of the proposed design will occur. If there is an aspect
of the implementation (or tests) that you would like to help with don't
hesitate to respond to this email or join us on the #asterisk-dev IRC
channel. Have a spectacular day!

[1] https://wiki.asterisk.org/wiki/display/AST/Media+Format+Rewrite
[2] http://svn.asterisk.org/svn/asterisk/team/group/media_formats/

Cheers,



Somewhat off topic, but is there a silk codec for 12?


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 3101: rasterisk needlessly prints the AST-2013-007 warning

[Sean Darcy]

On 01/05/2014 04:03 PM, Tzafrir Cohen wrote:

On Sun, Jan 05, 2014 at 02:34:35PM -0500, Sean Darcy wrote:


I agree on asterisk -rx, but as someone who just recently stopped
living dangerously I suggest you keep it for a remote login.

I never see asterisk start up. It's part of the systemd process. I
would only see it on a remote login. And only after saw it for some
number of times, did I actually get motivated. I may not be alone in
needing prodding to fix things, especially where it's not the
problem I'm immediately trying to fix.

It's only one line. There's a lot of lower hanging fruit spamming
the log file.


(It's already commited)

Technically it would be a trivial change to the patch.

Anyway, if I decided to live dangerously, it would be annoying. This is
not the only overly-verbose message Asterisk has, and users learn to
ignore loud noise.



Well, I wouldn't suggest we have the warning if someone explicitly opts 
to live dangerously, just if it's the default behavior.


sean


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 3101: rasterisk needlessly prints the AST-2013-007 warning

[Sean Darcy]

On 01/03/2014 02:23 PM, Paul Belanger wrote:

This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3101/


Ship it!

Ship It!


- Paul Belanger


On January 3rd, 2014, 7:14 p.m. UTC, Tzafrir Cohen wrote:

Review request for Asterisk Developers.
By Tzafrir Cohen.

/Updated Jan. 3, 2014, 7:14 p.m./

*Bugs: * ASTERISK-23084

*Repository: * Asterisk


  Description

Even since the fixes of AST-2013-007, Asterisk prints the following warning on 
startup if the user decided to live dangerously:

Privilege escalation protection disabled!
See https://wiki.asterisk.org/wiki/x/1gKfAQ for more details.

I believe that this warning is intended to be one-time and thus makes no sense 
when asterisk is run as a remote terminal. It certainly makes no sense when 
Asterisk is run to issue a remote command (asterisk -rx). This patch disables 
the warning on those two cases.


  Testing

Checked with asterisk 11


  Diffs

  * /branches/1.8/main/asterisk.c (404783)

View Diff 




I agree on asterisk -rx, but as someone who just recently stopped living 
dangerously I suggest you keep it for a remote login.


I never see asterisk start up. It's part of the systemd process. I would 
only see it on a remote login. And only after saw it for some number of 
times, did I actually get motivated. I may not be alone in needing 
prodding to fix things, especially where it's not the problem I'm 
immediately trying to fix.


It's only one line. There's a lot of lower hanging fruit spamming the 
log file.


sean

sean


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev