asterisk users - Aug 2005 - [Asterisk-Dev] Severe ISDN signal distortion in CVS-HEAD with octoBRI

BUG/SYMPTOMS:
 1.Under certain circumstances, octoBRI (and most likely quadBRI) ISDN 
cards (Junghanns/CologneChip) severely distort certain ISDN payload.
 2.Although these claims relate to the bristuff patch, the problem might 
not be limited to bristuff and in fact be rather asterisk/zaptel/libpri 
related.
 3.Signal distortion is limited to the use of the CVS version of the 
Bristuff patch for asterisk (tested on 
Bristuff-0.2.0-RC8f-CVS/Asterisk-CVS-05.29.05). The Stable versions of 
the Bristuff patch do not have the problem (tested on 
Bristuff-0.2.0-RC8f/Asterisk-1.0.7 and Bristuff-0.2.0-RC8n/Asterisk-1.0.9).
 4.Signal distortion is limited to calls with an ISDN Transfer 
Capability of 0x00 (SPEECH) or 0x10 (3K1AUDIO). Calls with an ISDN 
Transfer Capability of 0x08 (DIGITAL) are not being effected.
 5.The amount of signal distortion is of such severity that it is almost 
impossible to reliably send a fax call through the ISDN card.
 6.The amount of signal distortion also appears to render the echo 
cancellation useless.
 
SOLUTION:
 None yet.

NEEDED:
 Someone with knowledge of the asterisk/zaptel/libpri internals, to 
guide me.

TEST SETUP:
 The following hardware and software has been used to test the problem:
 - 1.7GHz Intel P4 / 512M
 - CologneChip octoBRI ISDN card (not tested with Junghanns.NET versions 
yet)
 - Debian Sarge / 2.6.12 kernel
 - Asterisk (CVS-05.29.05 / 1.0.7 / 1.0.9) + Bristuff (RC8f-CVS / RC8f / 
RC8n)
 - Elmeg and DeTeWe OpenCom PBX as analog channel banks.

TEST RESULTS:
 asterisk + bristuff version:        ISDN L1 Bit Error Rate:
 05-29-05 + RC8f-CVS                 >1%
 1.0.7 + RC8f                        0
 1.0.9 + RC8n                        0

SITUATION/BACKGROUND:
 I'm new to asterisk development and uncertain about reporting this in 
mantis. Because the cause of the mentioned symptoms hasn't been pinned 
down yet, and therefor might be something else than currently suspected, 
I will try to explain the context in which the problem has surfaced and 
the rationale by which I came to my assertions. Because of this, and the 
fact that I couldn't find any related material on the web, this document 
has become quite lengthy. Hopefully a bit of reading won't scare off 
most, for the implications of this problem might be related to a large 
set of other problems.

 For a while I've been deploying asterisk PBXs on a commercial basis. 
Most of those sites use asterisk with an octoBRI ISDN card. The ISDN 
card is used to hook up to the telco and, if the site already has an 
existing telephony infrastructure, to a conventional PBX acting as an 
analog channel bank to facilitate the existing infrastructure.

 After been plagued by problems with call transfers and some other 
issues with BT101s, I decided to switch from the stable 
bristuff/asterisk to the CVS-HEAD version. Although this switch has 
solved a lot of problems for me, there have been considerably more 
complaints about echo since. More frustrating, nothing seems to help to 
get rid of the echo.

 One month ago, I converted a site that used a hylafax solution. The 
hylafax machine was connected to a DeTeWe PBX with an analog (POTS) 
line. After the conversion the DeTeWe PBX was merely an analog channel 
bank that connected the hylafax machine to the asterisk machine. The 
asterisk machine had taken over all the functionality of old PBX. Both 
were connected to each other by 4 ISDN interfaces. For reasons unknown 
to me at that time, it wasn't possible to consistently receive faxes on 
the hylafax machine. Only 1 out of 20 faxes was received without errors. 
The strange thing was that sending faxes worked fine. Because I couldn't 
find the cause of the problem with receiving faxes, I devised another 
solution that is far from perfect and goes beyond the scope of this 
document.

 A week ago, still annoyed by not knowing what caused the fax problem, I 
tried to route some personal calls (including a fax) through the 
asterisk machine. To my surprise the fax was mangled as well, which let 
me to believe the problem wasn't in the hylafax machine nor the DeTeWe 
PBX. Next, I asked a friend to test the asterisk machine with a 
professional ISDN testing device. An ISDN (layer 1) Bit Error Rate test 
resulted in almost 1% of errors for voice call and fax call (TC 0x00 and 
0x10), whereas ISDN should have a BER less than 1 billionth percent. It 
explained why the faxes got mangled. The fact that the transmission of 
faxes went well, turned out to be because those calls got a DIGITAL TC 
(0x08) from the conventional PBX. Those digital ISDN call, as intended 
for G4 faxes (e.g.) weren't distorted in any way.

 Puzzled by the fact that I couldn't find anything on the wiki, mailing 
lists or mantis about the inability to properly send faxes through an 
octoBRI, I tried to determine the cause myself. First I installed the 
latest stable version of bristuff (0.2.0-RC8n). To my surprise this 
version did not distort any calls, indiscriminate of the call's TC. 
Since I normally use RC8f-CVS version of bristuff, I also tested the 
RC8f version. This version also did not distort calls. This let me to 
believe that the problem is not in the bristuff driver (qozap), but 
rather in some difference(s) between the stable and the CVS-HEAD version 
of asterisk. In fact, a test on an asterisk CVS-HEAD system without 
bristuff, but with a TE410P card also showed some signal distortion, 
though far less severe.

 Because Junghanns.NET appears to have stopped development of the CVS 
versions of their bristuff drivers and the last version is a little 
outdated (uses CVS 05-29-05), it's impossible to say if the distortion 
of fax calls might be something resolved by now in CVS-HEAD. I'm not 
very familiar with the inner workings of the bristuff code, therefor I 
feel very reluctant to rewrite/tweak the RC8f-CVS patch to make it work 
on the current CVS-HEAD version. I also don't think that would solve 
anything since mantis didn't have any related issues (that I could find) 
since.

 From a theoretical viewpoint I can imagine that it might be useful to 
put an ISDN voice call (TC 0x00 SPEECH) through a band or low-pass 
filter to reduce noise and eliminate inaudible components. If the 
measured call distortion isn't a bug, this might be what's happening in 
CVS-HEAD. If that is true, apparently the same thing is done for non-G4 
fax calls (TC 0x10 3K1AUDIO). This apparently screws the fax data 
signal, thus rendering faxing through asterisk practically useless. It 
also is dubious if filtering on a voice call might be helpful, for in 
theory it can severely disrupt/disable an echo cancellation algorithm.

 For anyone thinking of using the SetTransferCapability application in a 
dial plan to circumvent the problem by setting the TC of fax calls to 
DIGITAL (0x10), this is not an option. As soon as that call will arrive 
at another PBX with an analog fax machine attached to it, the call will 
be rejected (as per ISDN specification). Therefor it seems the only 
solution is to figure out what's going wrong with ISDN calls with a TC 
of 0x00 and 0x10 in the CVS-HEAD version of asterisk.

 I'm unable to find any code that might cause any (band/low-pass) 
filtering of calls. I'm not even sure where to look for it, if any. My 
best guess would be in the zaptel or maybe libpri driver, but I'm not 
familiar with that level of protocol workings. At least not yet.

 I would be very pleased if anyone could point me the right direction 
with this one. I'm willing to put quite some effort in resolving this 
problem. I'm currently out of options, for I lack the knowledge of the 
inner structure and workings of asterisk.

 If my assertions are right and there is an issue with the quality of 
fax and voice call  in the CVS-HEAD, it might better be fixed before 
asterisk 1.2 gets out (from a PR standpoint that is). Therefor I realy 
hope someone can lend me a hand.

sincerely,

Elwin Andriol
elwin@heuveltop.nl

"There are management solutions to technical problems,
but no technical solutions to management problems"

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