[Home]

Summary:ASTERISK-01879: fax problems with V.17
Reporter:Lee Howard (faxguy)Labels:
Date Opened:2004-06-23 15:22:46Date Closed:2011-06-07 14:10:03
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) typescript
Description:Here's the communication chain:

PSTN -- X100P -- Asterisk -- SP-2000 -- fax modem (HylaFAX)

Asterisk forwards incoming faxes to the appropriate FXS port on the Sipura.  All is well.

Faxes are received and sent just fine when the high-speed data carrier uses V.27, V.29, or V.34.  However, when V.17 is used the data is completely garbled.

I don't know what information would be useful to you in debugging this matter.  Let me know what you need, and I can   provide it.

****** ADDITIONAL INFORMATION ******

I do see this message on the console during any fax.  I'm not sure that it's relevant, though:

rtp.c:473 ast_rtp_read: Unknown RTP codec 100 received.
Comments:By: Mark Spencer (markster) 2004-06-24 09:01:57

I'm not sure there's *anything* we'll be able to do with this, but I'll give you a few moments to try to see if there's anything at all that is useful.

First, the "Unknown RTP codec 100" means that they're sending us something on codec 100, which we did not negotiate.  If you look at the SIP debug (or post it, uncompressed, as an attachment) then that might be helpful to see what it is trying to send us.

Secondly, when you say the "data is completely garbled" can you clarify what you mean?
By: Lee Howard (faxguy) 2004-06-24 11:55:43

I've attached the sip debug.

As for the alleged V.17 problem, it turned out to be a timings issue (needed to increase the pauses between carrier transitions).  So thank you, but please ignore that part.  The data looked garbled because the synchronization was lost between sender and receiver, and the garbled data was due to that.
By: Mark Spencer (markster) 2004-06-25 11:30:14

Great, thanks for the info.  The trace you attached doesn't show anything being negotiated for RTP 100, so it would seem to be a bug (albeit a harmless one) in the ATA device.