Asterisk, two pri connected: works fine but strange noise on calls

I had setup two asterisk servers, connected via PRI.
Works all fine except for one problem…a strange noise like a “pr prrrr pt pt pt”.

Those are the configuration files

PRI_CPE_SERVER

/etc/dahdi/system.conf

# Span 5: WCTDM/4 "Wildcard TDM400P REV E/F Board 5" 
fxoks=13
echocanceller=mg2,13
fxoks=14
echocanceller=mg2,14
# channel 15, WCTDM/4/2, no module.
fxsks=16
echocanceller=mg2,16

# Span 6: WCT1/0 "Digium Wildcard TE110P T1/E1 Card 0" (MASTER) CCS/HDB3/CRC4 
span=6,1,0,ccs,hdb3,crc4
# termtype: te
bchan=17-31,33-47
dchan=32
echocanceller=mg2,17-31,33-47

# Global data

loadzone	= it
defaultzone	= it

/etc/asterisk/chan_dahdi.conf

[trunkgroups]
[channels]
language=it
context=local
switchtype=euroisdn
signalling=pri_cpe
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=no
canpark=yes
cancallforward=yes
callreturn=yes
context=local
echocancel=yes
channel => 1-15,17-31
echocancelwhenbridged=yes
group=1
callgroup=1
pickupgroup=1
immediate=no
#include /etc/asterisk/dahdi-channels.conf

/etc/asterisk/dahdi-channels.conf


; Span 5: WCTDM/4 "Wildcard TDM400P REV E/F Board 5" 
;;; line="13 WCTDM/4/0 FXOKS  (EC: MG2 - INACTIVE)"
signalling=fxo_ks
callerid="Channel 13" <4013>
mailbox=4013
group=0,11
context=from-internal
channel => 13

;;; line="14 WCTDM/4/1 FXOKS  (EC: MG2 - INACTIVE)"
signalling=fxo_ks
callerid="Channel 14" <4014>
mailbox=4014
group=0,12
context=from-internal
channel => 14

;;; line="16 WCTDM/4/3 FXSKS  (EC: MG2 - INACTIVE)"
signalling=fxs_ks
callerid=asreceived
group=0,13
context=from-dahdi
channel => 16

; Span 6: WCT1/0 "Digium Wildcard TE110P T1/E1 Card 0" (MASTER) CCS/HDB3/CRC4 
group=0,14
context=from-dahdi
switchtype = euroisdn
signalling = pri_cpe
channel => 17-31,33-47

/etc/dahdi/assigned_spans.conf


# Device: [] @PCI_Bus_05_Slot_06 /sys/devices/pci0000:00/0000:00:14.4/0000:05:05.0/pci:0000:05:05.0
/sys/devices/pci0000:00/0000:00:14.4/0000:05:05.0/pci:0000:05:05.0 1:6:17

# Device: [] @PCI_Bus_05_Slot_07 /sys/devices/pci0000:00/0000:00:14.4/0000:05:06.0/pci:0000:05:06.0
/sys/devices/pci0000:00/0000:00:14.4/0000:05:06.0/pci:0000:05:06.0 1:5:13

The configuration on PRI_NET SIDE is identical except for pri_cpe which became pri_net and /etc/dadhi/system.conf where the span use is own timing source.

The calls works fine, I have tried analogic-sip, sip-to-sip, etc…
but as I said there is very annoying noise in the background, here you can hear.
dahdi_tool doesn’t report nothing bad and also console doesn’t report nothing bad.

I have tried those solution:

chancing pci slot NO
remove analogic card NO
use another pri crossover cable NO
check irq and put the card in a way that will not share irq with other…NO

This is the sound, what can it be? Thanks

Select one of this (i made one mirror)

https://easyupload.io/egnpuf

https://www.file.io/hFfd/download/rd8BIkDWRseZ

Enabling debug I see those messages

[Jun 12 21:53:56] DEBUG[1025][C-00000003]: dsp.c:745 dtmf_detect: DTMF best '1' Erow=7.4323E+06 Ecol=2.6441E+06 Erc=1.0076E+07 Et=2.6308E+06
[Jun 12 21:53:56] DEBUG[1025][C-00000003]: dsp.c:745 dtmf_detect: DTMF best '4' Erow=3.1666E+07 Ecol=1.0941E+07 Erc=4.2607E+07 Et=6.4351E+06
[Jun 12 21:53:56] DEBUG[1025][C-00000003]: dsp.c:745 dtmf_detect: DTMF best '7' Erow=2.0345E+07 Ecol=3.2123E+07 Erc=5.2468E+07 Et=1.0127E+07
[Jun 12 21:53:56] DEBUG[1025][C-00000003]: dsp.c:745 dtmf_detect: DTMF best '7' Erow=5.0175E+07 Ecol=4.7725E+06 Erc=5.4948E+07 Et=8.5699E+06
[Jun 12 21:53:56] DEBUG[1025][C-00000003]: dsp.c:745 dtmf_detect: DTMF best '1' Erow=8.5346E+06 Ecol=1.6515E+06 Erc=1.0186E+07 Et=3.3304E+06
[Jun 12 21:53:56] DEBUG[1025][C-00000003]: dsp.c:745 dtmf_detect: DTMF best '1' Erow=6.4727E+04 Ecol=4.0720E+04 Erc=1.0545E+05 Et=4.3046E+05
[Jun 12 21:53:56] DEBUG[1025][C-00000003]: dsp.c:745 dtmf_detect: DTMF best '4' Erow=2.2664E+04 Ecol=3.3416E+04 Erc=5.6080E+04 Et=3.1987E+05
[Jun 12 21:53:56] DEBUG[1025][C-00000003]: dsp.c:745 dtmf_detect: DTMF best '4' Erow=6.2562E+04 Ecol=2.0170E+04 Erc=8.2732E+04 Et=1.7088E+05
[Jun 12 21:53:56] DEBUG[1025][C-00000003]: dsp.c:745 dtmf_detect: DTMF best '6' Erow=1.2836E+04 Ecol=2.7469E+04 Erc=4.0305E+04 Et=1.6320E+05
[Jun 12 21:53:56] DEBUG[1025][C-00000003]: dsp.c:745 dtmf_detect: DTMF best '5' Erow=5.7709E+04 Ecol=3.3830E+04 Erc=9.1539E+04 Et=8.5376E+04
[Jun 12 21:53:56] DEBUG[1025][C-00000003]: dsp.c:745 dtmf_detect: DTMF best 'B' Erow=4.6720E+03 Ecol=1.9114E+04 Erc=2.3786E+04 Et=5.8752E+04
[Jun 12 21:53:56] DEBUG[1025][C-00000003]: dsp.c:745 dtmf_detect: DTMF best 'B' Erow=4.6720E+03 Ecol=1.9114E+04 Erc=2.3786E+04 Et=5.8752E+04
[Jun 12 21:53:56] DEBUG[1025][C-00000003]: dsp.c:745 dtmf_detect: DTMF best 'B' Erow=4.6720E+03 Ecol=1.9114E+04 Erc=2.3786E+04 Et=5.8752E+04
[Jun 12 21:53:56] DEBUG[1025][C-00000003]: dsp.c:745 dtmf_detect: DTMF best 'A' Erow=1.4090E+04 Ecol=1.9369E+04 Erc=3.3459E+04 Et=2.0864E+04

and…


ot a member of any queue.
[Jun 12 21:53:53] DEBUG[699][C-00000003] audiohook.c: Failed to get 160 samples from write factory 0xf76113cc
[Jun 12 21:53:53] DEBUG[699][C-00000003] audiohook.c: Failed to get 160 samples from write factory 0xf76113cc
[Jun 12 21:53:53] DEBUG[699][C-00000003] audiohook.c: Failed to get 160 samples from write factory 0xf76113cc
[Jun 12 21:53:53] DEBUG[699][C-00000003] audiohook.c: Failed to get 160 samples from write factory 0xf76113cc
[Jun 12 21:53:53] DEBUG[699][C-00000003] audiohook.c: Read factory 0xf76109ac and write factory 0xf76113cc both fail to provide 160 samples
[Jun 12 21:53:53] DEBUG[562] res_timing_timerfd.c: Expected to acknowledge 1 ticks but got 20 instead
[Jun 12 21:53:53] DEBUG[493] threadpool.c: Increasing threadpool stasis/pool's size by 1
[Jun 12 21:53:53] DEBUG[698][C-00000003] audiohook.c: Flushing audiohook 0xf7610928 so it remains in sync
[Jun 12 21:53:53] DEBUG[699][C-00000003] audiohook.c: Failed to get 160 samples from write factory 0xf76113cc
[Jun 12 21:53:53] DEBUG[699][C-00000003] audiohook.c: Failed to get 160 samples from write factory 0xf76113cc
[Jun 12 21:53:53] DEBUG[699][C-00000003] audiohook.c: Read factory 0xf76109ac and write factory 0xf76113cc both fail to provide 160 samples
[Jun 12 21:53:53] DEBUG[699][C-00000003] audiohook.c: Failed to get 160 samples from write factory 0xf76113cc
[Jun 12 21:53:53] DEBUG[699][C-00000003] audiohook.c: Read factory 0xf76109ac and write factory 0xf76113cc both fail to provide 160 samples
[Jun 12 21:53:53] DEBUG[699][C-00000003] audiohook.c: Failed to get 160 samples from write factory 0xf76113cc
[Jun 12 21:53:53] DEBUG[699][C-00000003] audiohook.c: Read factory 0xf76109ac and write factory 0xf76113cc both fail to provide 160 samples
[Jun 12 21:53:53] DEBUG[699][C-00000003] audiohook.c: Failed to get 160 samples from write factory 0xf76113cc
[Jun 12 21:53:53] DEBUG[699][C-00000003] audiohook.c: Read factory 0xf76109ac and write factory 0xf76113cc both fail to provide 160 samples
[Jun 12 21:53:53] DEBUG[699][C-00000003] audiohook.c: Failed to get 160 samples from write factory 0xf76113cc
[Jun 12 21:53:53] DEBUG[699][C-00000003] audiohook.c: Read factory 0xf76109ac and write factory 0xf76113cc both fail to provide 160 samples

On one server I see those messages during the call.
Can be related to sound problem?
I forget to said the server is an old C3000 HPPA Server

[ 2872.283886] asterisk(3364): unaligned access to 0x00000000f79213e3 at ip=0x00000000001c93ff
[ 2872.384709] asterisk(3364): unaligned access to 0x00000000f79213e3 at ip=0x000000000020714b
[ 2872.485394] asterisk(3364): unaligned access to 0x00000000f79213f1 at ip=0x00000000001c93ff
[ 2873.733151] asterisk(3364): unaligned access to 0x00000000f792140b at ip=0x00000000001c93ff

Could well be. You are running on hardware that has probably never been tested with Asterisk, and which has to fix up unaligned accesses in software, probably taking 1000s of machine cycles to do what Intel Architecture would do in single figure numbers, in hardware.

It is also possible that the atomicity of the instruction is preserved on Intel architecture, but broken by the software emulation.

I’m not sure that one can say for certain unless you translate the IP values into a source code line number, which probably means forcing a core dump and looking at it with a debugger.

(The only commonly used architecture that might also produce this problem is ARM, but the only commonly used ARM platform is Raspberry Pi, which doesn’t support PCI or PCIe, so wouldn’t be exposed to issues with direct PRI access. I’m not sure that architecture is officially tested.)

1 Like

I will try next week when I will get another pci card with low profile(i had already a pci card but is big profile, and on my pc i had only pci-e slot, so if I try bigprofile+adapter pcie-pci become giant profile).

I have made a new hardware configuration.
I use two server with two isdn pri cards TE110p
same architecture ( x86_64)
same os (Debian 11)
and…same error.
Calls working but with crackling noise and a new strange sound like a kind of horn!

https://www.file.io/Kvs4/download/j7rHdzPzMGbD

I forgot to put my sip.conf, maybe can help

[general]
context = local
bindport = 5060
bindaddr = 0.0.0.0
tlsenable=yes
tlsbindaddr=0.0.0.0
tlscertfile=/etc/asterisk/keys/asterisk-crt.pem
tlscafile=/etc/asterisk/keys/my.crt
;tlscipher=ALL:-TLSv1.1:-TLSv1:-SSLv2:-SSLv3
tlscipher=HIGH:-TLSv1.1:-TLSv1:-SSLv2:-SSLv3
language=it
tonezone=it
progressinband=yes
srvlookup=yes
accept_outofcall_message=yes
outofcall_message_context=sms
auth_message_requests=yes
allow=!all,alaw,ulaw,g729,g723,ilbc
allowguest=no

[telefono3]
context=local
type=peer
defaultuser=telefono3
secret=secret!
qualify=200
host=dynamic
deny=0.0.0.0/0
permit=192.168.0.0/24
description=phone Soft
directmedia=yes
transport=tls
encryption=yes
textsupport=yes

The file seemed to self destruct after I played it, so I couldn’t load it into Audacity, but there seemed to combination of impulsive noise and (crosstalk of?) dialtone.

1 Like

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