Menu

#4 No Carrier detected in sending fax with Hylafax-iaxmodem-ast

closed
nobody
None
5
2014-08-22
2009-06-15
No

Hello,

First of all I’ve attached all the debug files I’m referring to and pasted all involved configurations parts at the end of this case.

Now I hope I will find efficient help here to solve my issue below because I have intend to test the Asterisk T38 gateway with the patch xxxx. The goal is to have all TOIP features perfectly working with Asterisk solution. Most of our customers are ready to move on Asterisk but very often, and for various reasons (mostly legal, historical and economic) they are still attached to their traditional faxes. So my concern will be to get T38 Asterisk Fax to work a professional way.

That’s being said, before going through the T38 Gateway tests, I’ve tried first the Fax2mail and Mail2fax option with (Hylafax + Iaxmodem + Asterisk), to make working a well-tested Asterisk solution and I’m already facing some problems. Receiving faxes is ok but sending faxes gets stuck into “No Carrier Detected”. Debugging leads me to the following remarks:

I) Carrier or Called Station Identifier or (CED) tone from the called fax machine is received since recorded (iaxmdm-iax.wav attached)

This test has been done on 2 different faxes machines:

The called fax machine CED can be heard. On the other hand the iaxmodem-dsp file is a train of short bips. As far as I understand this file has to be the same than iax one (in dsp format). This is why I thought the issue had something to do with the case 5506 (http://bugs.digium.com/view.php?id=5506). Although if it was the case, my iaxmodem 1.2.0 should solve this issue if I refer to the 0.0.6 changes noticed in the files CHANGES. (“use ntohs instead of swapbytes improve error logging on short writes”)

By the way, how can I know ntoh is set? (Is there a linux command?)

II) Subsystem CONTROL value?
(files attached are sdfi1406.txt, iaxmdmi1406.stdout.txt, , iaxmdmi1406.stderr.txt, asterisk1406.txt)

The second path to investigate as per my analysis is the IAX exchanges at call set up. In looking deeper into the traces there is 3 requests from the faxes (both different faxes) I call, iaxmodem doesn’t understand.

CONTROL Subclass: (14?) whereas asterisk sounds to forward as CONTROL Subclass: PROGRES
Does it mean iaxmodem does not understand this subsystem control?
If so, what is the impact?

Then there is a few Subclass: LAGRQ and Subclass: LAGRP correctly exchanged between asterisk and iaxmodem.

There again could you help about the reasons of all these LAG requests. Is it a normal operation?

Then CONTROL Subclass: (255?) and CONTROL Subclass: (20?) on both side sent by the remote fax and whose the meaning are below.

14: Calling Progress
20: Message Waiting Indication
255: Unknown

Ref: http://www.en.voipforo.com/IAX/IAX-F-frames.php

III) Status/traces and all involved config files during the fax sending:

[root@venus asterisk]# faxstat -s
HylaFAX scheduler on venus.acme.fr: Running
Modem ttyIAX0 (+33.9XX.XXX.XXX): Running and idle

JID Pri S Owner Number Pages Dials TTS Status
96 126 S root O4XXXXXXXX 0:1 1:12 17:32 No carrier detected
[root@venus asterisk]#

On Asterisk side (asterisk1406.stdout extract):

[Kvenus*CLI> *^M-- SIP/Fax-To-Freephonie-08432030 is making progress passing it to IAX2/iaxmodem-7289
[Kvenus*CLI> *^MTx-Frame Retry[000] -- OSeqno: 003 ISeqno: 003 Type: CONTROL Subclass: RINGING
[Kvenus*CLI> *^M Timestamp: 02071ms SCall: 07289 DCall: 02285 [127.0.0.1:59386]
[Kvenus*CLI> *^MTx-Frame Retry[000] -- OSeqno: 004 ISeqno: 003 Type: CONTROL Subclass: PROGRES
[Kvenus*CLI> *^M Timestamp: 02074ms SCall: 07289 DCall: 02285 [127.0.0.1:59386]
[Kvenus*CLI> *^MRx-Frame Retry[ No] -- OSeqno: 003 ISeqno: 004 Type: IAX Subclass: ACK
[Kvenus*CLI> *^M Timestamp: 02071ms SCall: 02285 DCall: 07289 [127.0.0.1:59386]
[Kvenus*CLI> *^MTx-Frame Retry[001] -- OSeqno: 004 ISeqno: 003 Type: CONTROL Subclass: PROGRES

[Kvenus*CLI> *^MRx-Frame Retry[ No] -- OSeqno: 002 ISeqno: 002 Type: IAX Subclass: ACK
[Kvenus*CLI> *^M Timestamp: 00015ms SCall: 02286 DCall: 00962 [127.0.0.1:59386]
[Kvenus*CLI> *^MTx-Frame Retry[000] -- OSeqno: 005 ISeqno: 003 Type: IAX Subclass: LAGRQ
[Kvenus*CLI> *^M Timestamp: 10008ms SCall: 07289 DCall: 02285 [127.0.0.1:59386]
[Kvenus*CLI> *^MRx-Frame Retry[ No] -- OSeqno: 003 ISeqno: 006 Type: IAX Subclass: ACK
[Kvenus*CLI> *^M Timestamp: 10008ms SCall: 02285 DCall: 07289 [127.0.0.1:59386]
[Kvenus*CLI> *^MRx-Frame Retry[ No] -- OSeqno: 003 ISeqno: 006 Type: IAX Subclass: LAGRP
[Kvenus*CLI> *^M Timestamp: 10008ms SCall: 02285 DCall: 07289 [127.0.0.1:59386]

[Kvenus*CLI> *^MTx-Frame Retry[000] -- OSeqno: 011 ISeqno: 008 Type: CONTROL Subclass: (255?)
[Kvenus*CLI> *^M Timestamp: 25795ms SCall: 07289 DCall: 02285 [127.0.0.1:59386]
[Kvenus*CLI> *^MTx-Frame Retry[000] -- OSeqno: 012 ISeqno: 008 Type: CONTROL Subclass: (20?)
[Kvenus*CLI> *^M Timestamp: 25798ms SCall: 07289 DCall: 02285 [127.0.0.1:59386]

On iaxmodem side (iaxmdmi1406.stdout extract):

Rx-Frame Retry[ No] -- OSeqno: 002 ISeqno: 002 Type: CONTROL Subclass: RINGING
Timestamp: 01474ms SCall: 12913 DCall: 02280 [127.0.0.1:4569]
Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 003 Type: IAX Subclass: ACK
Timestamp: 01474ms SCall: 02280 DCall: 12913 [127.0.0.1:4569]
[2009-06-14 19:22:15] Ringing heard.
Rx-Frame Retry[ No] -- OSeqno: 003 ISeqno: 002 Type: CONTROL Subclass: (14?)

Tx-Frame Retry[000] -- OSeqno: 021 ISeqno: 016 Type: IAX Subclass: LAGRQ
Timestamp: 60006ms SCall: 07289 DCall: 02285 [127.0.0.1:59386]
Rx-Frame Retry[ No] -- OSeqno: 016 ISeqno: 022 Type: IAX Subclass: ACK
Timestamp: 60006ms SCall: 02285 DCall: 07289 [127.0.0.1:59386]
Rx-Frame Retry[ No] -- OSeqno: 016 ISeqno: 022 Type: IAX Subclass: LAGRP
Timestamp: 60006ms SCall: 02285 DCall: 07289 [127.0.0.1:59386]

Rx-Frame Retry[ No] -- OSeqno: 011 ISeqno: 008 Type: CONTROL Subclass: (255?)
Timestamp: 25285ms SCall: 12913 DCall: 02280 [127.0.0.1:4569]
Rx-Frame Retry[ No] -- OSeqno: 012 ISeqno: 008 Type: CONTROL Subclass: (20?)
Timestamp: 25288ms SCall: 12913 DCall: 02280 [127.0.0.1:4569]

Involved config parts:

iax.conf

[general]
context=default
port = 4569
udpbindaddr=0.0.0.0
disallow=all
;allow=alaw
allow=ulaw
srvlookup=yes

[iaxmodem]
type=friend
secret=faxy
port=4570
host=dynamic
context=fax-out
disallow=all
allowalalaww
allow=alaw

sip.conf
[general]

context=default
allowguest=no ;
match_auth_username=yes
allowoverlap=no
allowtransfer=yes

realm=asterisk

udpbindaddr=0.0.0.0
srvlookup=yes

tcpenable=no
tcpbindaddr=0.0.0.0
defaultexpiry=1800

srvlookup=yes
dtmfmode=auto
t38pt_udptl = yes

register=>09XXXXXXXX:ABCDE1234NVh@freephonie.net

useragent = ipbx
localnet = 192.168.0.0/255.255.255.0
externip = 82.238.189.8

[authentication]
auth = 09XXXXXXXX:ABCD1234tft@freephonie.net

[Fax-To-Freephonie]
type = peer
defaultuser = 09XXXXXXXX
secret = ABCDE1234NVh
fromuser = 09XXXXXXXX
host = freephonie.net
qualify = yes
fromdomain = freephonie.net
;context = fax-out
;insecure = invite
nat = yes
transport = udp,tcp
disallow = all
allow = alaw
allow = ulaw
dtmfmode = inband

extensions.conf
[general]
static=yes
writeprotect=no
autofallthrough=yes
extenpatternmatchnew=yes
clearglobalvars=no

[fax-out]

exten => _X.,1,NoOp(Fax should come out from the context ${CONTEXT})
exten => _X.,n,Dial(SIP/Fax-To-Freephonie/${EXTEN})
exten => _X.,n,Hangup

Discussion

  • Frederic Morteau

    Compressed files with all traces & debugs files

     
  • Lee Howard

    Lee Howard - 2009-07-13

    Your recording "iamdmi-iax.wav" shows severe audio corruption. I suspect that you are not using actual TDM interfaces and thus the corruption is likely due to trying to pass fax audio over internet-run VoIP channels. Doing that often causes audio corruption. Please see:

    http://hylafax.sourceforge.net/docs/fax-over-voip.pdf

    I am closing this ticket now. If you believe my analysis to be in error feel free to reopen.

     
  • Lee Howard

    Lee Howard - 2009-07-13
    • status: open --> closed