Re: [hylafax-users] Is DID required for this application?

["Donald, Adam" <adam.donald@xxxxxxxxxxx>]

Lee

Thank you so much for taking an in-depth look at this issue.
Unfortunately, all I have left is my extensive collection of USR modems, and
I am afraid that throwing those into the mix won't help us determine where
the fault lies (they produce enough errors on their own).  I would be
willing to try a courier or a sportster, if you thought it was worth it...

Without changing *anything* (PBX, etc.) but the four DTMF lines in my ttyS2
conf, I ran some more tests.  I have included the logs from the error-free
receipt and the HDLC error receipt.  I have also included my ttyS2 conf
file.

Knowing that with everything else remaining the same, to whom should I go to
see if I can get this issue fixed?  Why does the connection proceed at 33
normally, but at 14 when the CID/DTMF is enabled?


AD 

-----Original Message-----
From: Lee Howard [mailto:faxguy@xxxxxxxxxxxxxxxx] 
Sent: Wednesday, February 23, 2005 5:05 PM
To: Donald, Adam
Cc: hylafax-users@xxxxxxxxxxx
Subject: Re: [hylafax-users] Is DID required for this application?

On 2005.02.23 11:12 "Donald, Adam" wrote:
> Lee
> 
> 
> 
> I have enabled tracing as you specified, and sent the log that
> contains the
> HDLC errors and the tracing information.
> 
> I appreciate your help with this!  Please let me know if there is
> anything
> else that I can provide.

Donald,

HylaFAX isn't at fault here (unfortunately - because now I can't fix 
this for you).

In ECM data there are "synchronization" sequences that, in the case 
that I illustrate here should appear as repeating "7E" bytes, however, 
in the blocks where you see "Bad HDLC terminating flag received" show 
up the training sequences contain "injected" "FF" bytes.  Notice:

... 7E 7E 7E FF 7E 7E ...

That "FF" doesn't belong there, and I can't tell you how it got there, 
either.  The same thing happens in those blocks in the raw (unframed) 
ECM data (after the synchronization).  Raw ECM data should not have 
"FF" bytes in it.  But yet, they appear (here two in a row):

... 04 77 2B 64 C8 FF FF 67 50 D1 13 ...

And every time they do appear they mess the ECM data up, which causes 
multiple transmissions of the data until one gets through unscathed.

Either the modem is producing them, or your PBX is.  Since you can't 
really reproduce the problem without the PBX I really don't have any 
suggestions on how to debug it, either, to know which is which.  Do you 
have a different Class 1 modem that supports voice availble to test 
with?  If it happens with a different modem (not a MultiTech) then you 
can blame the PBX.  If it doesn't happen with a different modem, then 
you can blame this modem, and MultiTech should be able to help you.

I honestly couldn't tell you why this only happens when you use 
SHIELDED_DTMF, either.

Lee.

Attachment: good
Description: Binary data

Attachment: config.ttyS2
Description: Binary data

Attachment: errors
Description: Binary data