chan_capi-cm: Fehler bei Faxempfang, weil 0x349a :-(

[divB]

Hi!

Erstmal eine Frage: Wieso überhaupt capicommand(receivefax) verwenden? Bringt das irgendwelche Vorteile gegenüber RxFAX?

Nun, ich hab meinen Asterisk zum Empfang von Faxen eingerichtet und zwar so, dass ich auf der gleichen MSN telephonieren und faxen kann:

[capi-in]
exten => 563465,1,Answer()
exten => 563465,2,Playtones(ring)
exten => 563465,3,NVFaxDetect(4,dt)
exten => 563465,4,Dial(SIP/sip1)

exten => fax,1,StopPlaytones()
exten => fax,2,capicommand(receivefax,/tmp/${UNIQUEID})
exten => fax,3,Hangup()

Der Code scheint zu funktionieren, rufe ich an, erhalte ich:

  == ISDN1: Incoming call '05687283764' -> '563465'
    -- Executing Answer("CAPI/ISDN1/563465-0", "") in new stack
  == ISDN1: Answering for 563465
    -- Executing Playtones("CAPI/ISDN1/563465-0", "ring") in new stack
    -- Executing NVFaxDetect("CAPI/ISDN1/563465-0", "4|dt") in new stack
    -- Executing Dial("CAPI/ISDN1/391985-0", "SIP/sip1") in new stack
    -- Called sip1
    -- SIP/sip1-d55c is ringing
  == Spawn extension (capi-in, 563465, 4) exited non-zero on 'CAPI/ISDN1/563465-0'
  == ISDN1: CAPI Hangingup
       > CAPI INFO 0x349a: Non-selected user clearing

Sehr gut, schicke ich ein Fax, hab ich mich zuerst auch gefreut, aber chan_capi-cm bricht dann mit einem Fehler ab zu dessen Code ich nichts im Internet finden konnte :-(

  == ISDN1: Incoming call '05687283764' -> '563465'
    -- Executing Answer("CAPI/ISDN1/563465-1", "") in new stack
  == ISDN1: Answering for 563465
    -- Executing Playtones("CAPI/ISDN1/563465-1", "ring") in new stack
    -- Executing NVFaxDetect("CAPI/ISDN1/563465-1", "4|dt") in new stack
Aug 14 13:33:19 NOTICE[44]: app_nv_faxdetect.c:215 nv_detectfax_exec: Redirecting CAPI/ISDN1/563465-1 to fax extension
    -- Executing StopPlaytones("CAPI/ISDN1/563465-1", "") in new stack
    -- Executing capiCommand("CAPI/ISDN1/563465-1", "receivefax|/tmp/asterisk-6995-1155555198.2") in new stack
       > CAPI INFO 0x349a: Non-selected user clearing
    -- ISDN1: soft hangup by capi
 capi receivefax: fax receive failed reason=0x349a reasonB3=0x0000
  == Spawn extension (capi-in, fax, 2) exited non-zero on 'CAPI/ISDN1/563465-1'
  == ISDN1: CAPI Hangingup

Wo könnte das Problem liegen?
Es handelt sich um eine AVM Fritz! Card mit dem fcpci-Treiber.


Auf der anderen Seite hab ichs jetzt mit RxFAX versucht:

exten => 563465,1,Answer()
exten => 563465,2,Playtones(ring)
exten => 563465,3,NVFaxDetect(4,dt)
exten => 563465,4,Dial(SIP/sip1)

exten => fax,1,StopPlaytones()
exten => fax,2,SetVar(FAXFILE=/tmp/${UNIQUEID}.tif)
exten => fax,3,rxfax(${FAXFILE})
exten => fax,4,Hangup()

Damit geht es, TROTZ der sonderbaren Warnungen:

  == ISDN1: Incoming call '05687283764' -> '563465'
    -- Executing Answer("CAPI/ISDN1/563465-0", "") in new stack
  == ISDN1: Answering for 563465
    -- Executing Playtones("CAPI/ISDN1/563465-0", "ring") in new stack
    -- Executing NVFaxDetect("CAPI/ISDN1/563465-0", "4|dt") in new stack
Aug 14 13:59:48 NOTICE[3871]: app_nv_faxdetect.c:215 nv_detectfax_exec: Redirecting CAPI/ISDN1/563465-0 to fax extension
    -- Executing StopPlaytones("CAPI/ISDN1/563465-0", "") in new stack
    -- Executing SetVar("CAPI/ISDN1/563465-0", "FAXFILE=/tmp/asterisk-10212-1155556787.0.tif") in new stack
    -- Executing RxFAX("CAPI/ISDN1/563465-0", "/tmp/asterisk-10212-1155556787.0.tif") in new stack
Aug 14 13:59:48 NOTICE[3871]: channel.c:1347 ast_read: Dropping incompatible voice frame on CAPI/ISDN1/563465-0 of format slin since our native format has changed to alaw
DCS with final frame tag
In state 9
Coarse carrier frequency 1699.89 (64)
Training error 0.446529
Training succeeded (constellation mismatch 0.430175)
Start rx document
Start rx page - compression 2
Coarse carrier frequency 1699.96 (64)
Training error 0.416209
Training succeeded (constellation mismatch 0.542185)
EOP with final frame tag
In state 5

*CLI> DCN with final frame tag
In state 8
    -- Executing Hangup("CAPI/ISDN1/563465-0", "") in new stack
  == Spawn extension (capi-in, fax, 5) exited non-zero on 'CAPI/ISDN1/563465-0'
  == ISDN1: CAPI Hangingup

Hier seh ich eigentlich viel zu viele error und "constellation mismatch", TROTZDEM liegt das TIFF-File vor, wenn auch in schlechter Qualität, aber ich weiss nicht obs daran liegt.


Kann mir jemand sagen, was es für Vorteile bringen würde capicommand(receivefax) statt RxFAX zu verwenden?

Ich vielleicht wäre es auch möglich den chan_capi Fehler zu finden


Vielen Dank!

mfg,
divB

 

[Klingelding]

Erstmal eine Frage: Wieso überhaupt capicommand(receivefax) verwenden? Bringt das irgendwelche Vorteile gegenüber RxFAX?

Der Faxempfang wird in Hardware gemacht.
Es wird nicht noch ein zusätzliches Module mit seinen abhaengigkeiten benoetigt.

Wo könnte das Problem liegen?
Es handelt sich um eine AVM Fritz! Card mit dem fcpci-Treiber.

Genau da ist das Problem. Mit der Karte geht das nicht.

 

[divB]

Hi!

1.) Wahrscheinlich. Obwohl die Fritz! es nicht in HW machen kann, denke ich, aber ich bekomme mit capicommand eine VIEL bessere Qualität als mit RxFAX!

2.) Doch, offenbar schon ;-)
Hab gerade erfolgreich das erste Fax empfangen:

http://lists.melware.net/pipermail/chan-capi-users/2006-August/000199.html

Jedoch hab ich da das Problem dass die Nachricht "non selected user clearing" kommt (genau wie bei jedem Anruf) und die lässt das Fax einen Fehler melden.

Mit dem kleinen Patch geht es jedoch würd ich gerne wissen wieso ich die verdammte Meldung bekomme und das Problem an der Wurzel packen ;-) Wirklich elegant ist die Lösung so ja nicht ;-)

 

[derdanielder]

guckst du hier:

http://isdn.modemhelp.net/causecodes/causecodelist.shtml

 

[divB]

Danke, diese Liste kannte ich noch nicht.
Dennoch, wie ich bereits in der Mailinglist geantwortet habe, würd mich intressieren WIESO ich diese Nachricht erhalte.

Ich rufe von extern eine Nummer an.
Parallel am S0 Bus klingeln alle Geräte
Asterisk nimmt ab (Answer(), NVFaxDetect(), receivefax()...) und NACH der Übertragung krieg ich die Meldung "non selected user clearing", d.h. ein anderer hätte den Anruf angenommen!

Das stimmt ja aber genau nicht! Asterisk hat den Anruf angenommen!