Fax Versand und Fax Empfang auf FritzBox oder PC-Linux

Ich hatte heute auch mal die Gelegenheit, es auf einem PC auszuprobieren. Fritz!PCI-Karte, etwas älteres Linux, closed source AVM-Linux-Treiber für Fritz!PCI. PC ist an einer PBX angeschlossen (keine Ahnung, was für eine). Verbindung ebenfalls vom PC zu sich selbst, über den einen B-Kanal raus und über den anderen wieder rein. Gleiches Programm, das ich auch auf der Box benutze, nur für x86 übersetzt. Ca. 10 mal in Folge 4MB in beide Richtungen übertragen, dabei verschiedene Blockgrößen probiert. Nicht ein einziger Fehler. Auf der Box hatte ich zwar bisher insgesamt auch schon vier fehlerfreie Versuche, 4MB mit 1k Blockgröße zu übertragen, aber immer wieder auch Versuche mit Fehlern (mehr Fehlversuche, als Erfolgreiche). Bei der Mehrzahl der Fehlversuche mit 1k Blockgröße scheint sich bisher der Fehler jedoch auf eine oder zwei Blöcke von 78 oder 79 überschriebenen Bytes (mit 0xff) zu beschränken, d.h. keine eingefügten oder verlorenen Daten. Da könnte das Fax möglicher Weise mit Blockwiederholung drüber hinweg kommen. Aber eingefügte Daten kommen auch vor.

Ja, irgend etwas muß mit den CAPI-Treibern auf der Box faul sein...

So nebenbei ist mir auch noch aufgefallen, wenn "telefon" nicht läuft, geht auch kein Verbindungsaufbau übers CAPI. Wußte ich bisher nicht. Dachte immer, der CAPI-Treiber wäre im Kernel.
 
gfuer schrieb:
So nebenbei ist mir auch noch aufgefallen, wenn "telefon" nicht läuft, geht auch kein Verbindungsaufbau übers CAPI. Wußte ich bisher nicht. Dachte immer, der CAPI-Treiber wäre im Kernel.

Ich hatte festgestellt, das der interne S0 weiterhin funkioniert, nur der ext. S0 geht nicht. Der Telefon-Daemon empfängt andauernd MANUFACTURER_INDs (Debug-Mode??).
 
Hallo Ralf,

ich habe deine Binary auf einem opensuse 10.2 Server laufen. - Funktioniert super. Wollte dann gerne noch ein paar Parameter mehr zurück bekommen (z. B. die ID und Rufnummer vom Fax-Sender). Dazu habe ich das Source-File kompiliert. (Verwende spandsp-0.0.4pre6, libtiff3.8.2-25), zunächst ohne Änderungen. Allerdings, sobald ich CapiSpFax aufrufe bekomme ich die Meldung "CAPI not installed!". Außerdem ist die von mir kompilierte Datei wesentlich kleiner (36 KB) als deine (635 KB). Habe ich irgend etwas nicht beachtet? Im Rechner ist keine ISDN-Karte, daher möchte ich über Netzwerk die Fritz!Box ansprechen, was ja auch mit deiner Binary funktioniert.
 
Mein Programm enthält einige statische Libraries, daher ist es größer. Unter anderem habe ich eine CAPI mit Remote-Unterstützung verwendet, kommt aus dem Beitrag #1 nicht ganz deutlich raus, steht aber nochmal in #3.

Es gibt hier im Forum einen Beitrag über die Remote-CAPI, aber ich finde ihn im Moment nicht.
 
RalfFriedl schrieb:
Mein Programm enthält einige statische Libraries, daher ist es größer. Unter anderem habe ich eine CAPI mit Remote-Unterstützung verwendet, kommt aus dem Beitrag #1 nicht ganz deutlich raus, steht aber nochmal in #3.

Es gibt hier im Forum einen Beitrag über die Remote-CAPI, aber ich finde ihn im Moment nicht.

Über den Remote-CAPI Beitrag bin ich hier her gekommen (http://www.ip-phone-forum.de/showthread.php?t=94625&highlight=remote-capi).

Hast Du die dort angegebene libcapi20 verwendet? - Ich habe das Gefühl, dass ich beim kompilieren die 'normale' CAPI einbinde. Könntest du möglicherweise bitte genauer beschreiben welche Files du verwendest, bzw. zum kompilieren nötig sind?! Evt. sogar als Anhang beifügen.

Wenn es einfacher für dich wäre, dann wäre mir auch schon geholfen, wenn Du bei der CapiSpFax-i386.tar noch zwei Parameter mehr zurückgeben könntest und zwar die Anrufer-ID und die übermittelte Telefonnr. Hierüber wären evtl. noch andere Mitglieder sehr froh. Dazu müsste in capi.cpp die Zeile 403 von
Code:
sprintf (buf, "%s %s \"%s\" %d &", opt_RxProg, Con->m_FileName, Con->m_DID, status);
in
Code:
sprintf (buf, "%s %s \"%s %s %s\" %d &", opt_RxProg, Con->m_FileName, Con->m_DID, Con->m_CID, Con->m_Fax->t30_state , status);
umgeändert werden. (Ohne Gewähr, bei Con->m_Fax->t30_state bin ich mir nicht so sicher, ob das die Fax-ID ist. Möglicherweise kennst du dich da besser aus.)
 
Ich sehe gerade, DID ist ja die angerufene Nummer, das hätte CID, die Nummer des Anrufers sein sollen.
Die angerufene Nummer ist evtl. von Bedeutung, wenn man auf mehreren MSN Anrufe annehmen will.

t30_state ist nicht die Fax-Id der Gegenstelle. Diese befindet sich aber schon in der TIFF-Datei und ist daher nicht notwendig. Ich kann aber suchen, wo man die her bekommt.
 
Ich hatte mich schon gewundert, dass die eigene Nummer zurückgegeben wird. Die Fax-ID ist also in der Tiff-Datei? - Das wusste ich nicht, werde mal nachsehen, wie ich die auswerten kann...
 
Hi,

eventuell könnte man doch das T.30 an eine RTP Verbindung hängen, oder? Mir geht es ja hauptsächlich um den Empfang - was macht T.38 eigentlich viel anders?

Größeres Problem ist hierbei wohl die Latenz.
 
Zuletzt bearbeitet:
Mit T.38 kenne ich mich nicht so aus, aber wenn ich es richtig sehe, werden damit im Prinzip die gleichen Daten über Internet übertragen, die sonst über die Telefonleitung gehen. Dazu braucht man jemanden, der einem die Daten über Internet zusendet. Für einen normalen Faxempfang hätte man damit das Problem nur verlagert auf ein Gateway von ISDN nach T.38.

Und was heißt "T.38 (nur die Audioübertragung)"? Fax über VoIP? Das Problem dabei sollte weniger die Latenz sein, die ist ja nicht übermäßig groß, sonst würde es auch beim normalen Telefonieren stören. Das Problem sind wohl eher Aussetzer und Verschiebungen durch Abweichungen in der Taktrate beim Sender und Empfänger.
 
RalfFriedl schrieb:
Und was heißt "T.38 (nur die Audioübertragung)"?

Ich hatte es schon wieder wegeditiert, da ich die Frage nach Lesen für überflüssig befand.
Ich meinte damit eine ganz normale SIP Verbindung und dahinter das T.30. Also FoIP.

RalfFriedl schrieb:
Dazu braucht man jemanden, der einem die Daten über Internet zusendet. Für einen normalen Faxempfang hätte man damit das Problem nur verlagert auf ein Gateway von ISDN nach T.38
Jep.. in der Hoffnung, das der Sender keinen Schrott verschickt (das sollte hoffentlich nicht der Fall sein) und der Empfang reibungsloser funktioniert.

Mit dem Protokoll habe ich mich bisher auch nicht auseinandergesetzt, aber es wäre ein Ansatzpunkt, die CAPI zu umgehen. Aussetzer könnte man ja auffüllen und die Timing-Funktion von pjsip macht den Anschein recht genau zu sein (alle 20ms ein Frame). Ich denke, da hilft nur ausprobieren...
 
Zuletzt bearbeitet:
bodega schrieb:
eventuell könnte man doch das T.30 an eine RTP Verbindung hängen, oder?
Das ist ja genau das Prinzip von T.38. Die T.30 Daten werden nich über Modem, sondern als Datenpakete verschickt. Üblich ist allerdings UDPTL (nicht RTP) als Transport. Der Standard sieht offenbar sogar TCP als möglichen Transportkanal vor (das wäre dann besonders robust), aber das scheint wohl nicht sehr verbreitet zu sein.
 
gfuer schrieb:
Üblich ist allerdings UDPTL (nicht RTP) als Transport.

Ich hab mich da kurz reingelesen. Wenn man ein zweites INVITE abschickt, kann man UDPTL initialisieren. Daten werden dabei redundant gehalten, so das Pakete nicht verloren gehen. Bei TCP würde das sogar wegfallen. Überlegung ist hierbei nur, wie aufwendig die Implementierung wäre.

RTP ist dann wohl Glücksspiel.
 
Ja, üblich scheint es bei Fax-Gateways zu sein, erst einmal eine normale RTP-Audio-Verbindung aufzubauen, und wenn ein Faxton erkannt wird, dann mit re-INVITE zu versuchen das Medium auf image/T.38/udpctl zu wechseln, und ggf. sogar wieder auf eine RTP-Audio-Verbindung zurückzuwechseln, wenn der T.38 re-INVITE von der Gegenstelle abgelehnt wird, und in letzterem Fall notgedrungen über G.711 per Modem faxen. Vermutlich wäre es auch protokollkonform, schon beim ersten INVITE eine T38-Medien-Verbindung anzufordern.
 
Aber wenn es schon darum geht das Fax über einen externen ISDN->RTP Gateway zu empfangen, dann kann man sichs ja gleich per E-mail von dem Gateway zuschicken lassen.
Das löst ja nicht unser Problem, dass es ganz schick wäre den Empfang direkt auf der Box zu machen.

Wegen der "fehlfunktion" der CAPI. Meint ihr es bringt was sich da mal an die Entwickler von AVM zu wenden? Schon klar, dass die kein Support usw. für eigene Bastelein geben, aber wenn das wirklich nicht so funktioniert wie es sollte (und nicht nur wir es nicht richtig ansteuern), dann wäre das ja vllt. auch in deren Interesse. Am besten wäre natürlich ein AVM Entwickler, der was mit CAPI zu tun hat ließt diesen Thread hier....... HAAALOOOO AVM Programmierer !! ;-)
 
Ganz meine Meinung. Wenn man ein externes Fax-Gateway hat, kann das auch gleich den kompletten Empfang übernehmen.

kriegaex hatte mir ja angeboten, den Faxempfang über FritzFax zu testen mit Protokollierung, damit wir feststellen können, ob das FritzFax etwas anders macht und ob dort die Fehler im Empfang auch auftreten.

Da ich zeitlich nicht dazu gekommen bin, eine passend Protokillierung zu implementieren und das Meiste der Funktionsweise von FritzFax schon aus den Protokollen von bodega hervorging, haben wir statt dessen nur einen einfachen Faxtransfer zu seiner Box und dem FritzFax durchgeführt.

Der erste Test war gesendet mit AVM c2faxsend vom Linux-PC mit Fax-fähiger CAPI und AVM Fritz Karte auf sein FritzFax. Die Verbindung ist dabei zwar nicht abgebrochen, aber das Ergebnis war enttäuschend: mehr als die Hälfte der Fläche enthielt nicht das gesendete Punkte-Muster, sondern eine weiße Fläche. An sich hatte ich diese Übertragung nur zur Kontrolle mit der Erwartung, daß wenn ein Versuch erfolgreich ist, dann dieser.

Eine perfekte Übertragung hatten wir mit dem dritten Versuch, wo meine Box remote über die CAPI vom PC gesendet hatte. Beim Senden von PC direkt mit einem Programm und von der Box direkt mit meinem Programm war die Übertragung zunächst korrekt, ist aber dann abgebrochen.

Meine Vermutung ist, daß dies eher Zufall ist. Ich bin mir recht sicher, daß der PC korrekt senden kann, weil PC an PC bei mir funktioniert. Außerdem hat es bei mir auch schon gelegentlich geklappt, einen kompletten Empfang mit der Box zu schaffen, aber eben selten.

Ich gehe daher davon aus, daß auch das FritzFax über die Box ähnliche Störungen bekommt und auch nicht unbedingt robuster ist als spandsp. Von daher bin ich froh, daß wir zuerst diesen einfachen Test gemacht haben und ich mir nicht groß Gedanken über Protokollierung von FritzFax gemacht habe.

Auch im zweiten Punkt stimme ich florixyz zu:
Dafür, daß AVM auf eine jahrelange Erfahrung mit ISDN-Karten zurückblickt und auch gerne auf ihre Marktführerschaft in diesem Bereich verweist, ist die ISDN-Hardware in den Boxen schon schwach. Vielleicht ist das Problem auch nicht die Hardware selbst, sondern der Treiber dafür, aber solange es dafür keine Quellen gibt, macht das im Ergebnis keinen Unterschied.

@florixyz
Falls Du Deine Float-Implementierung nur für den Fax-Empfang auf einer Box machst, bringt das meiner Meinung nach nichts.
Das Problem ist derzeit hauptsächlich die Hardware. Ich habe eine Remote-fähige CAPI für die Box erstellt. Damit kann ich die ISDN-Karte in meinem PC in Verbindung mit der geballten CPU-Leistung der Box nutzen. Ich kann sogar strace auf das Empfangsprogramm laufen lassen. Das geht, ohne daß jede Fließkommaberechnung im Quelltext von spandsp geändert werden müßte, was bei Deinem Ansatz erforderlich wäre.


Unabhängig davon kann man für gelegentlichen Empfang die Box mit dem Programm schon verwenden. Meistens bricht die Übertragung erst nach einigen Minuten ab, in der Zeit kann man schon ein paar Seiten empfangen. Solange der Empfänger einen Fehlermeldung bekommt und es dann nochmal versucht, kann man damit leben.
Für den Hausgebrauch reicht es, aber richtig Zuverlässig ist es leider nicht.
 
Ich wollte eigentlich schon mit der FB die Faxe empfangen und nicht über ein externes Fax-Gateway gehen. Z.B. der direkte Faxversand vom Faxgerät an eine (kostenlose!) Sipgate-Nr. - oder besser gesagt: man ist der Gateway selbst.

Ob UDPTL auch mit einem kostenlosen Account funktioniert, ist natürlich fraglich. Meine Idee war auch vorerst über eine "normale" RTP Verbindung zu faxen. Ob ein VoIP-Client oder CAPI-Client verwendet wird, ist doch erstmal wurscht.

CAPI wäre natürlich interessanter - ich hatte nur an Alternativen gedacht.
Wenn AVM uns hilft mit der CAPI-Fax Geschichte, wäre das umso besser (bevor alles über eMail abgewickelt wird ;)).
 
Zuletzt bearbeitet:
@bodega:
Ich verstehe was du meinst, erstmal die CAPI umgehen um zu testen ob dann der Faxempfang geht. Nur wie schon erwähnt wurde, dürfte es über VoIP schwierigkeiten geben. Es gibt extra Standards für FoIP, die genau diese Probleme angehen.

@RalfFriedl:
die Float Sache entwickle ich im Moment gar nicht weiter, hab zu viele andere Sachen zu tun. Ich würde sie auch nicht nur für die Box entwickeln, sowas ließe sich ja auch in vielen anderen Applikationen einsetzen. Man könnte das Programm ohne Code-Änderung (nur mit einem define) mal mit Festkomma, Float, oder diversen anderen Formaten rechnen lassen (natürlich vorausgesetzt der Algorithmus überschreitet bei keinem Format den zulässigen Bereich). Aber das wird wohl noch eine Weile dauern bis das mal soweit ist das ichs veröffentlichen kann.

Zurück zum Thema: Ich finde die Idee Interessant, das Ganze auf der CPU der Box laufen zu lassen aber die Remote CAPI eines PCs zu benutzen (natürlich nicht die Fax Funktionen dort). Wie ist denn da der Stand der Dinge? Geht das ohne Probleme? Also so:
Absender ein Faxgerät (Analog, reine Hardware) -> ISDN Karte im PC -> Remote CAPI geht übers LAN auf die Box -> CapiSpFax mit spandsp auf der Box speichert das Tiff.
Bzw. erstmal Tests mit dem praktischen Testtool von gfuer durchführen....

Damits nicht so viel kostet: Man kann von einem PC zum internen Controller der Box senden. Entweder: Am PC die MSN 1234 einstellen und dann am Controller 3 diese Anrufen ODER auf der Box ein Listen an Controller 3 und MSN 0 durchführen und dann reicht am internen Controller das Abheben aus um die Verbindung herzustellen (zumindest bei meiner 7170 mit der alten Firmware, aber warum sollte es in einer neuen FW anders sein...)
 
So wie es aussieht, werden von Version zu Version mehr Teile von Spandsp auf Integerarithmetik umgestellt. Lohnt sich möglicher Weise nicht, hier großen Aufwand zu spendieren - reicht wahrscheinlich, etwas Geduld zu haben. Seit vorgestern gibt es offenbar wieder eine neue Version 0.0.4pre8.
 
Was ist denn "C2FaxSend von AVM"? Ist das ein Synonym für Fritz!Fax? Wie gesagt, habe ich beim Senden und Empfangen von Faxen am PC keine Probleme. Abbrüche gibt es mal ab und zu, das passiert mit einem Papierfax auch. Aber alles in allem ist Fritz!Fax zuverlässig. Die CPU-Last von capiotcp_server während des Empfangs von Ralfs ellenlangen Faxen lag immer zwischen 1 und 2%, ich habe das mit top stichprobenartig beobachtet.

Ich weiß, das interessiert Euch wenig, weil Ihr ja nicht über den PC faxen wollt sondern das Gegenteil, aber es rückt die Perspektive ein wenig zurecht. Spekulationen, woran es gelegen haben könnte, daß das erste Fax von Ralf nicht so aussieht wie erwartet, helfen da auch nicht. Bedenkt auch, daß die Jungs von AVM auch nicht auf der Brennsuppe daher geschwommen kommen und ihr Handwerk verstehen. Ich nehme an, wenn es eine sinnvolle, ressourcenschonende Möglichkeit zum Faxen über die Box gäbe, hätten wir sie evtl. schon in einer Labor-Firmware gesehen. (Auch das ist spekulativ, ja.)

Jedenfalls ist ein Fax-Prozeß, der mehr als 20 oder 30% CPU zieht, aus meiner Sicht nicht akzeptabel für einen Router, der ja noch "nebenbei" DSL, VoIP, WLAN und LAN versorgen soll. Selbst, wenn das Faxen zuverlässig bei >50% CPU funktionieren sollte, was Ihr ja vielleicht noch hinbekommt, ist das sicher nicht das, was man sich wünscht, sofern man in das (veraltete) Medium Fax nicht wirklich schwer verliebt ist. Ich würde hier lieber die Kirche im Dorf lassen und eine Fax-Box oder ein Papierfax an der Fritz!Box anschließen, die gehen auch ohne PC - oder gleich ein Fax-zu-E-Mail-Gateway verwenden.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.