Fax Versand und Fax Empfang auf FritzBox oder PC-Linux

[RalfFriedl]

Ich glaube nicht, daß es am Timer-Tackt und den 10ms liegt, schon weil mir nicht bekannt ist, daß irgenwo ein usleep-Aufruf drin wäre. 10ms entspricht 80 Abtastwerten, und das ist schon relativ kurz. Außerdem habe ich extra am Anfang der Verbindung 5 leere Buffer vorausgeschickt, damit da etwas Reserve ist.

Allerdings habe ich damit auf einem PC (nicht auf der Box) das Problem, daß die CAPI da bei längeren Faxen Fehlermeldungen bringt. Es sieht fast aus, als würde er da schneller empfangen als senden, was ja auch nicht gut sein kann.

 

[bodega]

Ich bin mir dabei nicht sicher, ob capi20_waitformessage nicht doch etwas länger blockt als es soll. Nur eine Vermutung.

 

[gfuer]

Bei mir läuft das Binary auf der 7170, FW ...37 ohne Absturz. Interessanter Weise hat bei mir -m1 gar nicht geklappt, und mit -m3 konnte ich ein paar Faxe empfangen (vielleicht kann mein Faxgerät die 4800 nicht?). Die Quote der nicht erfolgreichen Faxe ist natürlich deutlich zu hoch. CPU-Auslastung bei -m3 liegt bei mir im Bereich von 60-80%. Das ist sehr hoch, aber im Durchschnitt könnte es gerade so reichen, wenn es gelingt die Peaks zu glättern.

Ich habe auch ein wenig im Source-Code von spandsp gestöbert. Sieht ja so aus, als würde das Timing von spandsp mit den empfangenen Samples getaktet. Somit müßte der Empfänger eigentlich relativ robust gegen Jitter sein, solange keine empfangenen DATA_B3_IND verloren gehen - und einige Blöcke kann das CAPI ja puffern, wenn sie vorübergehend nicht rasch genug abgeholt werden.

Sendeseitig wird es m.E. schwieriger. Wenn spandsp die zu sendenden Daten nicht schnell genug anliefert (z.B. weil er noch rechnen muß), dann entstehen "Lücken" im gesendeten Datenstrom. Hier braucht man m.E. einen Jitter-Buffer, sodass die Daten mit einem künstlichen Delay verschickt werden. Diesen kann man voraussichtlich durchaus dadurch realisieren, dass man erst einmal ein paar Blöcke "silence" vorweg ans CAPI schickt, und CAPI puffern läßt. Aber danach muß man ununterbrochen Daten "nachschieben", und darf den Sendestream nicht abreißen lassen, sonst ist der Puffer wieder weg. IMO sollte man immer genau so viele Daten senden, wie auch empfangen wurden, weil die ISDN-Datenrate ja in beide Richtungen exakt gleich ist. Dann reißt der Sendestream nicht ab und es wird auch die Senderichtung nicht überfüllt. Und den sendeseitigen Jitter der B3_DATA_REQ gleicht dann die Pufferung im CAPI aus (durch die am Anfang vorausgeschickten Pakete).

Daraus würde sich für mich folgender Approach ableiten:

1. Bei der Initialisierung des Fax-State auch fax_set_transmit_on_idle(fax_state,TRUE) aufrufen. Dann liefert fax_tx(state, amp, max_len) immer genau max_len Samples zurück. Ggf. wird mit "silence" aufgefüllt, wenn spandsp momentan "nicht zu sagen" hat.

2. Beim Emfpang der allerersten DATA_B3_IND ein paar Blöcke "silence" vorweg als DATA_B3_REQ ans CAPI versenden (als Jitter-Buffer). Bei der in capi.c gewählten Blockgröße von 200 Samples enspricht das 25ms Delay pro Block.

3. Bei jedem Emfpang von DATA_B3_IND die empfangenen Samples mit fax_rx() an spandsp übergeben, und danach mit fax_tx() genau so viele Samples von spandsp abholen und als DATA_B3_REQ ans CAPI senden, wie in der DATA_B3_IND empfangen wurden.

Sind einfach nur so ein paar Gedanken, die ich loswerden wollte - ich werde kurzfristig eher nicht dazu kommen, das auszuprobieren...

Grüße
Gerhard

 

[RalfFriedl]

Hast Du denn -m0 oder -m2 versucht? Klar ist die CPU-Auslastung hoch, das ist ja das genze Problem bei der Sache.

Die Überlegungen zum Sende- und Empfangs-Timing hatte ich auch.
Auch die drei Punkte sind genau so umgesetzt, bis auf Punkt 2. Die Senden-Daten werden nicht beim ersten DATA_B3_IND generiert, sondern schon beim CONNECT_B3_IND. vielleicht paßt es auch besser ins CONNECT_B3_ACTIVE_IND. Wenn man bis zum ersten DATA_B3_IND wartet, sind schon die ersten 25ms vorbei.

Das Programm sendet auch immer genau soviel wie es empfangen hat (nach den vorab gesendeten Blöcken).

Auf einem PC, nicht auf der Box, habe ich das Problem, daß manchmal die Daten (DATA_B3_IND) schneller hereinkommen, als die Sendedaten bestätigt werden (DATA_B3_CONF). Das führt dazu, daß irgendwann nicht nur die 5 vorweg erzeugten Blöcke offen stehen, sondern 8. Und wenn er dann den nächsten Block übergeben will, kommt von der CAPI eine Fehlermeldung.

Meiner Meinung nach sollte es völlig unmöglich sein, daß mehr Daten empfangen werden, als auf der Sendeseite herausgehen, sind ja in beiden Fällen 64000 bit/s. Kann es sein, daß DATA_B3_CONF erst kommt, wenn die Gegenseite die Daten angenommen hat? Es gibt dafür ein Flag in DATA_B3_REQ, aber dies wird nicht gesetzt.

 

[gfuer]

Sehe ich genau so. Bei Einsatz von höheren Protokollen könnte ich mir ja eine end-to-end Flußkontrolle vorstellen, aber bei einer "circuit switched" Sprachverbindung gibt es ja gar keine Quittungen von der Gegenseite - die Daten gehen einfach synchron auf die Leitung. Ich denke also auch, dass das CAPI den B3_DATA_REQ spätestens dann bestätigen müßte, wenn der gesendete Block komplett auf die Leitung rausgegangen ist.

Wie groß sind eigentlich die empfangenen B3_DATA_IND? Kommen da immer Blöcke in voller Größe, oder werden auch kleinere Blöcke vom CAPI angeliefert? Falls auch kleinere Blöcke ankommen, dann würde das schon erklären, dass auch sendeseitig die gepufferten 125ms nicht mehr in Form von 5 Blöcken zu 200 Byte, sondern in Form von z.B. 8 kleineren Blöcken in der CAPI-Queue stehen (wenn immer so viel gesendet wird, wie empfangen wurde).

 

[RalfFriedl]

Das war auch mein erster Gedanke, aber die empfangen Blöcke kommen immer in voller Größe, also hier 200 Byte.

 

[hermann72pb]

Entschuldigung die Einmischung in eure fachliche Diskussion. Mir ist eine Sache nicht klar. Es wird von einem relativ hohen Rechenaufwand für den Fax- Versand/Empfang gesprochen. Die Box macht doch andere meineswissens viel mehr kompliziertere Sachen "mit links": WLAN mit WPA, Umkodierung mehrerer VOIP-Gespräche "on-the-fly" usw. Ich kann mir schlecht vorstellen, dass ein Fax zu senden / zu empfangen viel rechenaufwendiger ist. Oder liegt es daran, dass das hier diskutierte Tool fast alles in Software realisiert und wo möglich emuliert und die "normalen" Aufgaben zum Teil durch die Hardware (boxinterne Controller etc.) erledigt werden?

MfG

 

[RalfFriedl]

Ich vermute, daß die WPA Verschlüsselung von einem Baustein auf dem Board vorgenommen wird.
Umkodierung von VOIP-Codecs ist vermutlich auch nicht so wild, wobei es natürlich auf den Codec ankommt.
DSL Codierung/Decodierung ist wieder ein anderes Thema, aber dafür gibt es einen speziellen DSP, der das übernimmt.

Das spandsp verwendet überwiegend Fließkomma-Berechnungen, und die CPU hat keine Fließkomma-Unterstützung. Auf einem 100MHz PC, der von der normalen Rechnenleistung in der gleichen Größenordnung liegt, der aber eine Fließkomma-Einheit hat, ist das überhaupt kein Problem.

 

[bodega]

Ist das Binary schon fixed-point kompiliert?

Ansonsten hier noch ein Link kurz reingeworfen (dürfte aber bekannt sein).

EDIT:
ich hab es nun mit dem Kompilieren hinbekommen. Hatte lrintf falsch gecastet.

 

[meimi039]

Hi Marco!

Ich habe noch etwas experimentiert: SegFault kommt nur, wenn ich das Binary direkt aus einem Webdav-Mount starte. Liegt es schon auf der Box klappt alles. Nun versuche ich mal was vernünftiges damit...

 

[drahtjacke]

@all
Kann mir jemand genau die Parameter geben?
Habe

CapiSpFax -m2 -i xxxxxxxx

gestartet. xxxxxxxx natürlich eine meiner MSN (allerdings VOIP). Ich habe dann versucht an diese Nummer zu faxen. CapiSpFax ist leider nicht dran gegangen.

Gruß Ralph

 

[RalfFriedl]

Mit VOIP habe ich es nicht ausprobiert, ich weiß auchnicht, was man tun müßte, um solche Anrufe anzunehmen.

Fax über VOIP ist aber sowieso problematisch, siehe dazu auch den Link von bodega.

@bodega
In spandsp hatte ich --enable-fixed-point aktiviert.
Ich habe aber den Eindruck, daß es noch ein grundsätzliches Problem mit spandsp gibt, möglicherweise sogar unabhängig von fixed-point.
Bei einem sehr großen (extra dafür konstruiertem) Test-Fax kommt es auch im Laufe der Übertragung zu Störungen, und zwar auch ohne fixed-point auf einen PC und auch ohne CAPI, sondern direkt zwischen zwei Fax-Instanzen und daher ganz ohne Frame-Slips.

Update:
Ein Fax das in der ersten Zeile die Bits immer abwechselnd hat, also 010101...010101 wird von spandsp bei T.6 Kodierung falsch empfangen, und dies hat nichts mit Frame-Slips oder CPU-Auslastung zu tun. Es könnte auch generell passieren, wenn ein solches Muster vorkommt und auch wenn es nicht über die ganze Zeile geht.
Ich melde mich wieder, wenn ich genaueres zu den Ursachen bzw. eine Lösung dafür habe.

 

[Schmide1]

Hallo Ralf,

kann man die Faxfunktion z.B mit Hylafax (BS Debian) nutzen?


Gruß
Schmide

 

[RalfFriedl]

Mit Hylafax senden, empfangen oder beides?
Prinzipiell geht es, sofern das Programm den Faxtransfer an sich schafft. Bisher hat noch keiner geschrieben, daß es zuverlässig funktionieren würde.

Für Hylafax muß man folgendes machen:

• Zum Senden in ~fax/etc/config eine Zeile "SendFaxCmd:/path/faxsend.sh" eintragen. Dann ein Skript /path/faxsend.sh erstellen, das aus der Hylafax Job Datei die Nummer holt, das Fax sendet und entsprechend dem Sende-Status die Job Datei anpaßt.
• Zum Empfangen reicht es, wenn die TIFF-Dateien im Verzeichnis ~fax/recvq/ abgelegt werden und danach evtl. noch das ~fax/bin/faxrcvd aufgerufen wird.

 

[Schmide1]

Danke für deine Antwort.
Ich werde wohl abwarten müßen bis jemand so ein Script schreibt, da ich mich leider gar nicht auskenne mit Programmierung.

Dann kann ich vielleicht mal mit der Fritz-Box oder mit meinem Lancom-Router Faxe senden und empfangen.

 

[RalfFriedl]

So ein Skript würde ich auch selbst schreiben, da ich auch Hylafax verwende.
Aber solange die Faxübertragung auf diese Art nicht zuverlässig funktioniert, lohnt es sich nicht, sich die Arbeit für den "Rahmen" zu machen.

 

[ichego1]

Hallo

ralf

meinst du denn das es grundsätzlich mit halyfax geht

ich höre immer wieder das dieses die beste linux variante sei
oder wo gibt es da noch probs

 

[RalfFriedl]

Natürlich meine ich, daß es grundsätzlich mit Hylafax geht. Ich habe doch geschrieben, daß ich sogar vorhabe, es in der Richtung zu verwenden, also zumindest auf dem PC-Linux mit Hylafax. Auf einer Fritzbox wird dann vermutlich der Speicher eng.

Im Moment verwende ich auf einem PC-Linux Hylafax mit capi4linux und AVM ISDN-Karte mit Fax-fähigem CAPI Treiber.
Wie ich aber schon im ersten Beitrag geschrieben habe, übergibt das Sendeprogramm von capi4linux, c2faxsend, munter eine ganze, auch mehrseitige, Fax-Datei an die CAPI und meint sie erfolgreich übertragen zu haben, selbst wenn die Verbindung schon vor Übertragung der ersten Seite abgebrochen wurde. Das heißt also, daß unter Umständen ein Fax als gesendet betrachtet wird, von dem nicht einmal die erste Seite angekommen ist. Das ist natürlich nicht gut.

Hylafax selbst besteht aus zwei Teilen. Zum einen die Verwaltung der Fax-Warteschlange, zum anderen Treiber für analog-Modems. Diese kann man für ISDN nicht verwenden. Man kann aber beliebige andere Programm zum Senden und Empfangen nutzen, das habe ich einige Beiträge weiter oben geschrieben.

Das Problem im Moment ist, daß dieses Fax-Programm noch nicht zuverlässig funktioniert. Ich habe zwar schon einige Testfaxe damit übermitteln können, manchmal gibt es aber auch bei den gleichen Testdateien Probleme. Und auch sonst hat hier noch niemand geschrieben, daß von einer größeren Anzahl von Versuchen der überwiegende Teil funktioniert hätte.

Nun weiß ich zwar, daß sich die Leute eher melden, wenn etwas nicht geht, aber in diesem Fall gehe ich mal davon aus, daß sich auch mal jemend gemeldet hätte um zu sagen, daß es funktioniert.

 

[kriegaex]

Ich werde wohl abwarten müßen bis jemand so ein Script schreibt, da ich mich leider gar nicht auskenne mit Programmierung.

Dann kann ich vielleicht mal mit der Fritz-Box oder mit meinem Lancom-Router Faxe senden und empfangen.

Semi-OT: Nichtprogrammierer sind oft Windows-Benutzer. Du auch? Dann könntest Du ja einfach das AVM-Programm "Fritz!Fax" nehmen, das funktioniert sehr gut. Ich bin sehr zufrieden damit. Hier wird ja im wesentlichen eine reine Linux-Lösung diskutiert. Falls Windows für Dich eine Option ist und es okay ist, daß ein PC eingeschaltet sein muß zum Faxempfang/-versand, ist es das Richtige für Dich, weil die Firmware den entsprechenden Programmteil capiotcp_server bereits enthält, nur das Windows-Programm muß nachinstalliert werden.

 

[meckerfritz]

Hier wird nicht diskutiert, ob Windows oder Linux, sondern ob man den Faxempfang auf den Router legen kann, damit der PC aus bleiben kann !