Music On Hold and Conference Bridge Voice quality poor


#1

It appears to be a timing issue on the affected pbx’es by the zaptel driver. When I run the sudo /sbin/zttest when the MoH is garbled as well as when voice quality gets degraded it will respond with a value under 99%. From what I have found online, this driver is called on when using the Conference bridges and MoH.

This is what I am referring to:
forums.asterisk.org/viewtopic.ph … 75&start=0
last comment referring to test results when the quality is degraded:
Well, It appears that my timing issue was WITH my TDM400P, here’s the results of zttest:

— Results after 237 passes —

Best: 100.000000 – Worst: 91.613770 – Average: 99.483625

As you can see, there were significant drops in there that were causing my issues.

Here is the same tests on our pbx’es. Note 11 is suppose to be working as properly.

pbx11 results:
— Results after 57469 passes —
Best: 100.000 – Worst: 99.045 – Average: 99.954601, Difference: 99.992325
Which is expected as no quality issues reported there.
However on 14 and 16 i get much worse results:
pbx14
— Results after 56114 passes —
Best: 100.000 – Worst: 70.218 – Average: 97.568579, Difference: 102.421440
pbx16
— Results after 56165 passes —
Best: 100.000 – Worst: 47.164 – Average: 97.761109, Difference: 102.238612

the-asterisk-book.com/unstab … eetme.html
MeetMe conferences require a Zaptel interface to be installed in the Asterisk server; these provide a time source for synchronization of the participating channels. If no Zaptel interface is available, the ztdummy driver may be used.
MeetMe conferences always use the ulaw codec internally. The more conference participants use other codecs such as GSM or alaw, the higher the processor load due to transcoding.

Here is an end user report of the issue:

  1. The breaking up of the music is exactly like the breaking up of the voice signal.
    a. While it might be they are disparate signals, common sense tells me that since the issue is so exactly the same for both the music and the voice, it’s hard to believe it’s not related or that the issue is not manifested by the same underlying problem. The same “breaking up” of the signal at the trailing end of a word or the music sounds exactly the same for voice and is so disruptive that is renders the conference call unusable.

#2

Digium’s TDM400 was End of Life’d back in 2008 and completely expired from all Support in 2010. It was replaced by the Digium TDM410. One of the benefits of the TDM410 is its ability to tolerate long periods of latency across the PCI bus that otherwise prohibit the TDM400 from operating properly. Long periods of latency may be due to any number of things, but arise because some other device is blocking the bus for a lengthy period that’s not ideal for real-time telephony.


#3

I dont actually have any hardware DSPs… i believe that is all done through ztdummy correct? any idea how i can check if ztdummy is working properly? from my output i posted originally i would guess not but need to know what to tweak.

thanks!


#4

Why not try the new ConfBridge10 application ?


#5

the software we use, voiceaxis, intergrates the application the configuration portal calls on. Doing manual entries for a multitenant enivironment would be a nightmare


#6

any idea how i can confirm ztdummy is working properly? Or better yet what to look for on my good pbx that works?


#7

also not sure if this helps, but the pbx that is working shows the source being RTC instead of Linux26 when I run this command:

vmfs01aCLI> zap show status
Description Alarms IRQ bpviol CRC4
ZTDUMMY/1 (source: Linux26) 1 UNCONFIGUR 0 0 0
The ‘zap show status’ command is deprecated and will be removed in a future release. Please use ‘dahdi show status’ instead.
vmfs01a
CLI> da
dahdi database
vmfs01a*CLI> dahdi show status
Description Alarms IRQ bpviol CRC4
ZTDUMMY/1 (source: Linux26) 1 UNCONFIGUR 0 0 0


#8

Here are the versions I believe I am using on all servers:

PBX11 who is not experiencing the problem seems to be running the same version as the problem pbx14.

Looks like our working pbx11 is running this:

[tfiore@fs11(pbx11 primary) ~]$ sudo /sbin/modinfo /lib/modules/2.6.18-194.8.1.el5/kernel/misc/zaptel.ko

filename: /lib/modules/2.6.18-194.8.1.el5/kernel/misc/zaptel.ko

version: 1.4.9.2

license: GPL

description: Zapata Telephony Interface

author: Mark Spencer markster@digium.com

srcversion: 09F9962E84B1D28F6C7CD09

depends: crc-ccitt

vermagic: 2.6.18-194.8.1.el5 SMP mod_unload 686 REGPARM 4KSTACKS gcc-4.1

parm: debug:int

parm: deftaps:int

[tfiore@fs11(pbx11 primary) ~]$

[tfiore@fs16(primary) ~]$ sudo /sbin/modinfo /lib/modules/2.6.18-274.7.1.el5/kernel/misc/zaptel.ko

filename: /lib/modules/2.6.18-274.7.1.el5/kernel/misc/zaptel.ko

version: 1.4.9.2

license: GPL

description: Zapata Telephony Interface

author: Mark Spencer markster@digium.com

srcversion: 09F9962E84B1D28F6C7CD09

depends: crc-ccitt

vermagic: 2.6.18-274.7.1.el5 SMP mod_unload 686 REGPARM 4KSTACKS gcc-4.1

parm: debug:int

parm: deftaps:int

[tfiore@fs16(primary) ~]$

[tfiore@fs14(fs14) ~]$ sudo /sbin/modinfo /lib/modules/2.6.18-194.32.1.el5/kernel/misc/zaptel.ko

filename: /lib/modules/2.6.18-194.32.1.el5/kernel/misc/zaptel.ko

version: 1.4.9.2

license: GPL

description: Zapata Telephony Interface

author: Mark Spencer markster@digium.com

srcversion: 09F9962E84B1D28F6C7CD09

depends: crc-ccitt

vermagic: 2.6.18-194.32.1.el5 SMP mod_unload 686 REGPARM 4KSTACKS gcc-4.1

parm: debug:int

parm: deftaps:int

[tfiore@fs14(fs14) ~]$