[Gelöst:] chan_capi 1.1.3: Fehler beim Faxempfang

[Ralph*]

Heute morgen habe ich auf chan_capi 1.1.3 gewechselt und nach dem Neustart folgendes Problem beim Faxempfang beobachten können:

  == ISDN_TE2#02: Incoming call '07021xxxxxx' -> '666xxxxx'
    -- ISDN_TE2#02: Updated channel name: CAPI/ISDN_TE2#02/666xxxxx-d
    -- Executing [666xxxxx@from-capi:1] Set("CAPI/ISDN_TE2#02/666xxxxx-d", "[email protected]") in new stack
    -- Executing [666xxxxx@from-capi:2] Goto("CAPI/ISDN_TE2#02/666xxxxx-d", "faxempfang|s|1") in new stack
    -- Goto (faxempfang,s,1)
    -- Executing [s@faxempfang:1] NoCDR("CAPI/ISDN_TE2#02/666xxxxx-d", "") in new stack
    -- Executing [s@faxempfang:2] Set("CAPI/ISDN_TE2#02/666xxxxx-d", "FAXFILE=/var/spool/asterisk/fax/1249378859.14") in new stack
    -- Executing [s@faxempfang:3] capicommand("CAPI/ISDN_TE2#02/666xxxxx-d", "receivefax|/var/spool/asterisk/fax/1249378859.14|||k") in new stack
  == ISDN_TE2#02: Answering for 666xxxxx
       > ISDN_TE2#02: CAPI INFO 0x3490: Normal call clearing
[B] capi receivefax: fax receive failed reason=0x3490 reasonB3=0x3314[/B]
    -- Executing [h@faxempfang:1] System("CAPI/ISDN_TE2#02/666xxxxx-d", "/var/lib/asterisk/scripts/fax2mail.sh "/var/spool/asterisk/fax/1249378859.14" "" "0" "14400" "[email protected]" "07021xxxxxx"") in new stack
  == ISDN_TE2#02: CAPI Hangingup for PLCI=0xdead0000 in state 4

Nachdem ich wieder auf 1.1.2 zurück bin (und der Übertragungsversuch glücklicherweise gleich wieder stattgefunden hat) hat es funktioniert:

  == ISDN_TE1#02: Incoming call '07021xxxxxx' -> '666xxxxx'
    -- ISDN_TE1#02: Updated channel name: CAPI/ISDN_TE1#02/666xxxxx-1
    -- Executing [666xxxxx@from-capi:1] Set("CAPI/ISDN_TE1#02/666xxxxx-1", "[email protected]") in new stack
    -- Executing [666xxxxx@from-capi:2] Goto("CAPI/ISDN_TE1#02/666xxxxx-1", "faxempfang|s|1") in new stack
    -- Goto (faxempfang,s,1)
    -- Executing [s@faxempfang:1] NoCDR("CAPI/ISDN_TE1#02/666xxxxx-1", "") in new stack
    -- Executing [s@faxempfang:2] Set("CAPI/ISDN_TE1#02/666xxxxx-1", "FAXFILE=/var/spool/asterisk/fax/1249379162.0") in new stack
    -- Executing [s@faxempfang:3] capicommand("CAPI/ISDN_TE1#02/666xxxxx-1", "receivefax|/var/spool/asterisk/fax/1249379162.0|||k") in new stack
  == ISDN_TE1#02: Answering for 666xxxxx
       > ISDN_TE1#02: CAPI INFO 0x3490: Normal call clearing
[B] capi receivefax: fax receive successful.[/B]
    -- Executing [h@faxempfang:1] System("CAPI/ISDN_TE1#02/666xxxxx-1", "/var/lib/asterisk/scripts/fax2mail.sh "/var/spool/asterisk/fax/1249379162.0" "+49 7021 xxxxx     " "3" "14400" "[email protected]" "07021xxxxxx"") in new stack
  == ISDN_TE1#02: CAPI Hangingup for PLCI=0xdead0000 in state 4

Kann natürlich sein, dass der Fehler bei der anderen Seite lag und das alles Zufall war...

Muss ich irgendetwas an der Konfiguration ändern, um die 1.1.3 einsetzen zu können?

Ralph


[EDIT:]

Wer lesen kann, ist klar im Vorteil... ich habe jetzt in der extensions.conf die neuen Optionen f und u bei receivefax eingefügt:

exten => s,3,capiCommand(receivefax|${FAXFILE}|||kfu)

(Die Option f sorgt dafür, dass auch Faxe mit hoher Auflösung angenommen werden - wenn ich das auf die Schnelle richtig verstanden habe.)

Bislang funktioniert es jedenfalls.

 

[armincm]

exten => s,3,capiCommand(receivefax|${FAXFILE}|||kfu)

(Die Option f sorgt dafür, dass auch Faxe mit hoher Auflösung angenommen werden - wenn ich das auf die Schnelle richtig verstanden habe.)

In der neuen chan_capi 1.1.3 wird CAPI 'extended fax' verwendet, d.h. man kann eben auch ultrafine, JPEG, colorfax, etc. machen. Mit der Option 'u' für ultrafine solltest du aufpassen, diese features könnten einige Gegenstellen nicht verstehen und einen Fehler bringen. Mit 'f' hast du Recht. Ich werde aber in der nächsten Version den default wieder ändern. Bei genauerem Überlegen sollte der default so bleiben wie vorher und dieses 'extended' als Option auswählbar sein.

Armin

 

[Ralph*]

Dann nehme ich das u wieder raus - Danke!

Wie wäre es denn, wenn "extended fax" UND die Option f zukünftig als Default aktiviert sind?

Wenn wir schon beim Thema Faxen sind:

ClearChannel Fax und T.38 funktionieren nur, wenn zusätzlich das (leider nicht kostenlose) softIP von Dialogic installiert ist. Habe ich das richtig verstanden?

Ralph

 

[armincm]

Wie wäre es denn, wenn "extended fax" UND die Option f zukünftig als Default aktiviert sind?

Ja, darauf wird es wohl hinauslaufen (sofern extended verfügbar ist).

ClearChannel Fax und T.38 funktionieren nur, wenn zusätzlich das (leider nicht kostenlose) softIP von Dialogic installiert ist. Habe ich das richtig verstanden?

Fast
ClearChannelFax geht mit chan_capi direkt (wenn deine DIVA Karte und die Firmware nicht zu alt ist, also die DSP resourcen verfügbar sind). Mit anderen Worten, du kannst direkt von einem SIP/IAX/etc. Kanal Faxe empfangen/senden.
Genauso funktioniert auch das 'chat'. Hier können CAPI- und andere Kanäle den DSP nutzen.

T.38 steht mit der DIVA auch zur Verfügung, aber das ist noch nicht in chan_capi implementiert. Deshalb ist die einzige Software hier Dialogic's softIP. Das kann eine ganze Menge und kann parallel zu Asterisk/etc. laufen.

Armin

 

[Ralph*]

Mein Problem sind nach wie vor gelegentliche Abbrüche bei (längeren) ausgehenden Faxen, die ich über Microlink Modems an Grandstream HT487 ATAs realisiere.

Was wäre denn bei ClearChannelFax anders, wie funktioniert das und könnte mir das helfen, die Zahl der Abbrüche zu reduzieren?

DSPs sind verfügbar (das behaupte ich jetzt einfach mal, siehe Signatur).

Wenn T.38 möglich wäre, dann könnten die HT487 doch direkt per T.38 mit der Diva Karte "sprechen" und alles wäre gut?

Ralph

 

[armincm]

Mein Problem sind nach wie vor gelegentliche Abbrüche bei (längeren) ausgehenden Faxen, die ich über Microlink Modems an Grandstream HT487 ATAs realisiere.

Ach ja. Da war doch was. War denn sichergestellt, dass das Problem nicht durch z.B. den ATA kommt?
Anyway, wäre es nicht besser diese Umwandlung durch ein Modem und ein ATA zu ersetzen? Was war hier doch gleich der Grund das zu behalten?

Was wäre denn bei ClearChannelFax anders, wie funktioniert das und könnte mir das helfen, die Zahl der Abbrüche zu reduzieren?

In diesem Fall nichts, denn du willst ja das Fax nur durch die DIVA 'durchschleifen'. Es soll ja hier nicht empfangen oder gesendet werden.

Wenn T.38 möglich wäre, dann könnten die HT487 doch direkt per T.38 mit der Diva Karte "sprechen" und alles wäre gut?

In diesem Fall würde dann eben der ATA das Fax-Piepen in T.38 wandeln, an die DIVA schicken um es hier wieder in das Fax-Piepen für die Gegenstelle zu verwandeln. Wenn man davon ausgeht, dass der ATA hier gut arbeitet (und nicht das eigentlich Problem darstellt), wäre alles gut.
Da aber die echte Ursache der Abbrüche noch nicht klar ist, wäre das auch nur 'testen'.

Armin

 

[Ralph*]

Der Faxempfang mit capicommand(receivefax) auf den Diva-Karten mit einer Weiterleitung per Mailanhang funktioniert ganz wunderbar.

Wir setzen aus folgenden Gründen jedoch noch immer Tobit Faxware bzw. David für den Faxversand ein:

- Tobit bietet eine Formular-Funktionalität, d.h. der Fax-Text wird mit einem Abbild unseres Geschäftsformulares kombiniert. Man könnte vereinfacht sagen, dass das Firmenlogo zusätzlich mitgefaxt wird.

- Tobit kann die Faxnummer, die über einen Steuercode im Dokument übergeben wird, extrahieren und als Zielrufnummer verwenden.

- Auch eine alte DOS-Applikation (läuft immerhin unter Windows) muss faxen können.

Mein Grundproblem ist, dass ich bislang keinen Weg gefunden habe, die nötige SFF-Datei für capicommand(sendfax) zu erstellen. Ein Windows Hylafax-Client wäre wohl das Mittel der Wahl, aber der muss eben das oben Genannte beherrschen.

Das ist also der Grund für die Lösung mit den 2 Modems / ATAs. Ein Modem hängt dabei an einem Grandstream HT487, ein anderes an dem ollen Zyxel. Wobei der Grandstream weniger Probleme zu machen scheint.

Die ursprüngliche Lösung mit einer ISDN-Karte im Tobit-Faxserver an einem internen ISDN-Bus am Asterisk (damals mit einer Diva Server 4BRI realisiert) hat auch nicht zuverlässig funktioniert. Timing / Abschlusswiderstand, hab leider keine Ahnung.


Wenn eines der Modems über CAPI in die weite Welt wählt, dann mache ich auch nichts anderes, als mit Dial(CAPI...) eine Verbindung herzustellen. chan_capi erkennt den Faxversand zwar am "Piepen" (Fax detected, but not configured for redirection), was dann aber passiert, weiß ich nicht.

In der überwiegenden Zahl der Fälle wird das Fax fehlerfrei übertragen, selten aber kommt es zu Fehlern (carrier lost, Fehler beim Seitenende, ...). Wie soll ich da einen Fehler suchen?

Ralph

 

[armincm]

Die Verwendung dieser Software verstehe ich, aber warum denn so ein Umstand mit Modem und umwandeln in Analog, dann Digital, dann wieder Analog. Kann denn diese Tobit Software nicht ein anderes device benutzen? So dass es glaubt ein Modem oder eine eigene ISDN Karte zu nutzen, aber es ist eigentlich direkt die DIVA per remote. Also so dass Tobit direkt die DIVA nutzt.

Armin

 

[Ralph*]

Grundsätzlich wäre ich natürlich sehr froh, wenn ich Tobit und damit den alten Netware-Server abschalten könnte. Aber dazu benötige ich eben einen Windows-Client mit den genannten Funktionen der eine SFF-Datei für capicommand(sendfax) erstellt.

Tobit läuft auf einem Netware-Server und kann lokale Modems oder eine ISDN-Karte per CAPI ansprechen. Wenn es eine Remote-CAPI für die Dialogic-Karten gäbe, wäre das natürlich eine Idee...

Eine Idee, um die Fehler einzugrenzen:

Kann ich einen Store/Forward-Mechanismus einrichten, so dass die Modems ein Fax von Tobit aus an den Asterisk-Server absetzen (wird also dort von den Diva-Karten empfangen), es auf dem Asterisk-Server aber zunächst lokal gespeichert wird? Dann würde ich sehen können, auf welchem Teil der Übertragungsstrecke die Fehler auftauchen.

Das würde aber bedeuten, dass ich receivefax für einen SIP-Channel benötigen würde. Geht also nicht mit chan_capi, oder?

Ralph

 

[armincm]

Es gibt remote-CAPI für die Dialogic Karten! Um genau zu sein, für alle CAPI Karten. Hierzu brauchst du nur den rcapid (gibts auch bei ftp.melware.net) zu starten und die localen CAPI Controller (oder auch nur einer davon) werden per TCP-remote-CAPI mit dem bintec Protokoll exportiert. Auf der Client-Seite gibt es zwei Möglichkeiten:
1) unter Linux: eine neue libcapi20 (z.B. auch von ftp.melware.net) die dann nicht auf /dev/capi20, sondern eben per remote auf den anderen Server zugreift.
2) unter Windows: bintec remote capi client. Hier wird dann ein Bintec CAPI system installiert, dass aber nur die hardware von remote nutzt.
Wenn du also auf dem Server, wo du CAPI brauchst, eines der beiden installieren kannst, dann geht es.

Das Store/Forward geht. Wenn du auf dem Rechner mit der DIVA über SIP ein Fax empfangen willst, musst du nur vor dem capicommand(receivefax) ein capicommand(resource|1) machen. Siehe README.Diva.fax von chan_capi.

Armin

 

[Ralph*]

Ich sollte also eine RemoteCAPI für Netware haben... hmmm.

Ich bleibe deshalb erst mal beim Store/Forward und habe mir einen [faxtest] in der extensions.conf angelegt:

; ***********************************************
; Testfaxe an die DivaServer-Karten
; ***********************************************
exten => s,1,NoCDR()
exten => s,2,Set(FAXFILE=/var/spool/asterisk/fax/${UNIQUEID})
exten => s,3,capiCommand(resource|1-2)
exten => s,4,capiCommand(receivefax|${FAXFILE}|||kf)
exten => s,5,Hangup()

exten => h,1,System(/var/lib/asterisk/scripts/fax2mail.sh "${FAXFILE}" "${FAXID}
" "${FAXPAGES}" "${FAXRATE}" "${MAILEMPF}" "${CALLERID(num)}")

Wenn ich vom Tobit Faxserver aus ein Fax an den FaxTest schicke, erhalte ich den Fehler "Out of FAX resources (protocol T.30)"

    -- Executing [0666@mydefault:1] Set("SIP/966-40449f90", "[email protected]") in new stack
    -- Executing [0666@mydefault:2] Goto("SIP/966-40449f90", "faxtest|s|1") in new stack
    -- Goto (faxtest,s,1)
    -- Executing [s@faxtest:1] NoCDR("SIP/966-40449f90", "") in new stack
    -- Executing [s@faxtest:2] Set("SIP/966-40449f90", "FAXFILE=/var/spool/asterisk/fax/1249557615.278") in new stack
    -- Executing [s@faxtest:3] capicommand("SIP/966-40449f90", "resource|1-2") in new stack
  == SIP/966-40449f90-DATAPLCI: Setting up DTMF detector (PLCI=0x101, flag=1)
    -- Executing [s@faxtest:4] capicommand("SIP/966-40449f90", "receivefax|/var/spool/asterisk/fax/1249557615.278|||kf") in new stack
       > SIP/966-40449f90-DATAPLCI: CAPI INFO 0x2006: [B]Out of FAX resources (protocol T.30)[/B]
 capi receivefax: fax receive failed reason=0x0000 reasonB3=0x0000
    -- Executing [h@faxtest:1] System("SIP/966-40449f90", "/var/lib/asterisk/scripts/fax2mail.sh "/var/spool/asterisk/fax/1249557615.278" "" "" "" "[email protected]" "966"") in new stack
       > SIP/966-40449f90-DATAPLCI: CAPI INFO 0x3303: Protocol error layer 3
       > SIP/966-40449f90-LINEPLCI: CAPI INFO 0x3303: Protocol error layer 3

Klappt da capicommand(resource) nicht? Die Angaben zur Ausstattung in der Signatur stimmen (2 x Dialogic Diva Server BRI-2M Rev. 2.0 / Melware v3 3.1.2-109.50-1).

Ralph

 

[armincm]

Ich sollte also eine RemoteCAPI für Netware haben... hmmm.

Wenn die Brickware darauf läuft, ja.

Wenn ich vom Tobit Faxserver aus ein Fax an den FaxTest schicke, erhalte ich den Fehler "Out of FAX resources (protocol T.30)"

Okay, ich müsste etwas präziser sein. Bei der BRI kann man resourcePLCI nur verwenden, wenn der DSP nicht anderweitig benutzt wird. Also entweder keine andere Verbindung (über ISDN) läuft, oder die Karte im resource-Mode betrieben wird (S0 deaktiviert, Karte steht nur als Resource zur Verfügung).

Armin

 

[Ralph*]

Brickware - aha, ich schau mich mal um...

Also entweder keine andere Verbindung (über ISDN) läuft...
Armin

Keine aktuell aktive Verbindung? Zum Testzeitpunkt war ziemlich sicher keine ISDN-Aktivität.

oder die Karte im resource-Mode betrieben wird (S0 deaktiviert, Karte steht nur als Resource zur Verfügung).
Armin

In meinem jugendlichen Leichtsinn dachte ich, dass ich mit capicommand(resource) die Karte (für den Zeitraum der Verbindung) eben in den Resource-Mode versetze...

Wie mache ich das denn richtig? Und wie stelle ich die Karte (den Port?) danach wieder Asterisk / ISDN / CAPI zur Verfügung?

Offensichtlich habe ich das Konzept von ClearChannelFax noch nicht durchschaut.

Ralph

 

[Ralph*]

Ich wurde bei BinTec fündig, was den Novell-Teil der RemoteCAPI betrifft. Danke, das hört sich gut an!

Hierzu brauchst du nur den rcapid (gibts auch bei ftp.melware.net) zu starten und die localen CAPI Controller (oder auch nur einer davon) werden per TCP-remote-CAPI mit dem bintec Protokoll exportiert.Armin

Wie sieht es mit dem Zusammenspiel zwischen rcapid und Asterisk aus? Kann Asterisk auf die Karte(n) trotzdem zugreifen, erkennt er, wenn Ports durch die remoteCAPI belegt sind?

Ralph

 

[armincm]

Wenn du mit rcapid CAPI-controller exportierst, ist das genau wie wenn eine weitere Application CAPI nutzt. Die einzelnen Applikationen wissen nichts voneinander. D.h. wenn eine Applikation (z.B. fax über rcapid) einen Kanal belegt, bekommt das Asterisk nicht mit. Du solltest auch darauf achten, dass die andere Applikation nicht auf die gleichen Nummern 'hört' wie Asterisk. Denn ankommende Rufe werden an allen Applikationen signalisiert. So kann dein Fax einen Anruf für Asterisk vorher annehmen.

Wenn du keine Verbindung mit der DIVA hattest und trotzdem resourcePLCI nicht geht, gehe ich davon aus, dass die BRI doch komplett im ResourceMode stehen muss.
Mit capicommand(resource) allokierst du kurz den DSP. Der resourceMode der Karte ist eine feste Einstellung über Config der Karte, hierbei wird S0 auch abgeschaltet.

Armin

 

[Ralph*]

... wenn eine Applikation (z.B. fax über rcapid) einen Kanal belegt, bekommt das Asterisk nicht mit. Du solltest auch darauf achten, dass die andere Applikation nicht auf die gleichen Nummern 'hört' wie Asterisk. Denn ankommende Rufe werden an allen Applikationen signalisiert.

Wie verhält sich chan_capi, wenn es ausgehend einen Port ansprechen will, dieser aber durch die remoteCAPI belegt ist? Sucht es sich automatisch einen neuen?

Der resourceMode der Karte ist eine feste Einstellung über Config der Karte, hierbei wird S0 auch abgeschaltet.

Dann kann ich das im Regelbetrieb wohl vergessen.

Frech gefragt: Ist T.38 in chan_capi denn ein geplantes Feature für kommende Versionen?

Auf alle Fälle schon jetzt Danke für Deine Bemühungen, Du bist wie immer eine große Hilfe!

Ralph

 

[armincm]

Wie verhält sich chan_capi, wenn es ausgehend einen Port ansprechen will, dieser aber durch die remoteCAPI belegt ist? Sucht es sich automatisch einen neuen?

chan_capi ist hier wie jede andere CAPI Applikation auch: es kennt den Status des Ports, bzw. der Kanäle nicht. Wenn ein Dial-Versuch gemacht wird, dann meldet ISDN (die Karte, bzw. auch die switch) dass kein B-Kanal zur Verfügung steht.
Eine automatische Suche für einen freien Kanal auf einem anderen Port wird in diesem Fall von chan_capi nicht gemacht, das ist einfach nicht implementiert.
Man könnte das auch im Dialplan machen, wenn man HANGUPCAUSE auswertet.

Frech gefragt: Ist T.38 in chan_capi denn ein geplantes Feature für kommende Versionen?

Ich würde es zwar gerne machen, aber auf der Liste ist es noch nicht. Bei dem Umfang gehen Kundenprojekte dann doch vor. Und mir ist auch noch nicht ganz klar wie Asterisk/Digium mit dem Thema T.38 wirklich umgeht.

Armin

 

[Ralph*]

Dass Kundenprojekte priorisiert behandelt werden, versteht sich von selbst.

T.38 wäre halt eine der Möglichkeiten, die in unserer derzeitigen Konfiguration (vermutlich) zum Ziel führen würden.

Ich bleibe aber an den Alternativen dran und danke Dir für Deine - wie immer großartige - Unterstützung.

Ralph

 

[armincm]

Naja, T.38 wäre doch in deinem Fall auch wieder nur eine 'Krücke', da das Fax mehrfach umgewandelt wird. Also ich sehe als beste Lösung wenn dein Fax-System direkt die Fax-Hardware (also die DIVA) ansprechen könnte (so habe ich es übrigens auch schon in einer Firma umgesetzt, zwar nicht Tobit, aber ein Hylfax-Server der die DIVA des TelefonSystems nutzt).
Und falls es mit den 'belegten Kanälen' ein Problem gibt, finden wir dafür auch eine Lösung.

Armin

 

[Ralph*]

Noch ein kleines Update: Ich habe die letzten Tage damit verbracht, unseren Faxversand größtenteils auf capicommand(sendfax) umzustellen - das klappt nun auch ganz gut.

Jetzt muss ich einfach mal warten, bis im Regelbetrieb auch mal Faxe mit mehreren Seiten auftauchen. Dann werde ich ja sehen, ob auch die fehlerfrei übertragen werden.

Ralph