Technische Informationen zur Realisierung des DirectFax-Service des Rechenzentrums der Uni-Koblenz. 

Um das gesteckte Ziel zu erreichen, nämlich die Möglichkeit jedem Mitarbeiter der Uni eine persönliche Faxnummer zu vergeben, die aus einem Prefix + seiner Durchwahl  besteht, ist der Betrieb der B1-Karte am Anlagenanschluß  wesentlich. In dieser Konfiguration wertet die Alcatel-Telefonanlage lediglich einen vom Anrufer gewählten Prefix aus, der dazu führt, das die weitere Verbindungskontrolle durch die B1-Karte und die darauf arbeitende Software ausgeführt wird. Der für die Uni gewählte Prefix ist 100. Da die Basiisnummer der Uni (Campus Metternich) 0261 287 ist, wird durch Wählen von 0261 287 100 die Kontrolle über die eingehende Verbindung von der Alcatel Telefonanlage an die unter Linux laufende Anwendung delegiert, die die B1-Karte steuert.  Diese Anwendung baut erst dann eine Verbindung auf, wenn hinter dem Prefix vier weitere Ziffern gewählt werden. Da die Durchwahl jedes Mitarbeiers vierstellig ist, können diese vier Ziffern dazu verwendet werden das Fax einem bestimmten Mitarbeiter eindeutig zuzuordnen, wodurch die "persönliche" Faxnummer  möglich wird. Die Zustellung des Fax erfolgt über eine Mail, die das Fax als Attachment enthält.

Der eigentliche Fax-Empfang wird mit Hilfe der der  CAPI-basierten Anwendung capifaxrcvd realisiert, die Teil der isdn4k-utils ist. Um capifaxrcvd an einem Anlagenanschluß betreiben zu können mußte die Anwendung entsprechend angepaßt werden. Darüber hinaus muß das Linux-ISDN-Subsystem für diesen Arbeitsmodus  leicht umkonfiguriert werden. Hinweise hierzu finden sich im Linux ISDN-FAX Howto.  Die Anpassung der CAPI-Anwendung capifaxrcvd betrifft den Bereich des Handling der eingehenden Nummern:

Die CAPI ist Message-orientiert, d.h. beim Eintreten bestimmter Ereignisse versendet die CAPI eine Nachricht an die Anwendung, das etwas "passiert" ist. Diese Nachrichten werden Indications genannt. Die Anwendung kann (und meistens sollte sie auch) die Indication mit einer Response quittieren. Zusätzlich darf eine Anwendung die CAPI um weitere Services bitten. Dies erfolgt über einen sogenannten Request von der Anwendung an die CAPI, der mit einer Confirmation von der CAPI an die Anwendung beantwortet wird (z.B. mit der Aussage OK, geht nicht ...). Bei einer eingehenden Verbindung sendet die CAPI (siehe capi.c, Funktion Handle_Indication()  aus den isdn4k-utils)  eine CONNECT-Meldung an die Anwendung ( wie z.B. capifaxrcvd). Aus dieser Nachricht kann die Anwendung die gewählte Rufnummer entnehmen.  Um jetzt auf weitere Ziffern zu warten, muß ein LISTEN_REQ mit gesetztem Bit 7 der Info Mask (siehe CAPI-Specs 5.37 called party number) an die CAPI gesendet werden, damit die CAPI bei weiteren gewählten Ziffern jeweils eine CAPI_INFO Nachricht an die Anwendung sendet, der die gewählte Ziffer entnommen werden kann. Bei jeder erhaltenen Ziffer muß die Anwendung nun wieder prüfen, ob bereits ausreichend (und evtl. die richtigen) Ziffern erhalten wurden und eine Verbindung aufgebaut, abgelehnt oder auf weitere Ziffern, also weitere CAPI_INFO Nachrichten  gewartet werden soll. Die Entscheidung ob eine Verbindung hergestellt wird, wird in der Regel von der Zahl der Ziffern abhängig gemacht, weil man eben nach der Basisnummer wie z.B. 0261287100 z.B. genau vier weitere  Ziffern erwartet. Alternativ kann natürlich auch die Nummer selbst untersucht werden, so daß z.B. nur eine Verbindung aufgebaut wird, wenn z.B. 287100 1111 - 287100 1199 gewählt wird, also wenn die ersten beiden Ziffern nach der Basisnummer eine "1" sind

Soweit die klare, reine Theorie. Leider gibt es in der Praxis wiedereinaml ein paar Eventualitäten, die das Leben ein wenig schwerer machen:

Der erste Punkt ist, das es beim Wählen wohl verschiedene Übertragungsarten für die Nummer gibt: Ich will die beiden Verfahren  als Einzelwahl und Blockwahl bezeichnen. Bei der Einzelwahl wird von der Telekom Ziffer für Ziffer an den Empfänger übertragen. Ganz anders funktioniert die Blockwahl: hier wird die Nummer als Ganzes in einem Stück an dem Empfänger übermittelt. Natürlich gibts auch eine Kombination von beidem. Also ein Stück Nummer en Block und den Rest ziffernweise.  Die Blockwahl z.B. tritt auf, wenn man von einem ISDN Telefon aus wählt, wobei vor dem Abheben des Hörers die komplette zu wählende Nummer eingegeben wurde. Die Einzelwahl hingegen wird wohl bei analogen Telefonen verwendet und auch, wenn erst der Hörer abgehoben und dann gewählt wird. Was hat das nun für eine Bedeutung für  die capifaxrcvd-Anwendung? Die Bedeutung liegt darin, das bei der Programmierung der Reaktion auf die CAPI_CONNECT-Meldung darauf geachtet werden muß, das hier evtl. nur die Basisnummer (beim Betrieb an einer Telefonanlage evtl. auch nur die "0") vorliegt oder aber schon die gesamte gewählte Nummer oder ein Teil davon. Die Nummer muß also schon bei der CONNECT -Meldung untersucht werden. Evtl. fällt an dieser Stelle dann der LISTEN_REQ schon flach, wenn nämlich schon alle Nummern zu dieser Zeit "eingetroffen" sind.

Ein weiteres Problem sind die Anrufer (die User :-) ), die natürlich auch für Probleme sorgen können. Die Anrufer können "böser" Weise nicht die komplette Nummer wählen, also z.B. nur die Basisnummer oder die Basisnummer mit nicht genügend weiteren Nummern. Schließlich kann ein Anwender auch anrufen, die Verbindung herstellen, aber kein Fax senden und einfach warten (also eine Denial of Service Attack ausführen). In allen Fällen muß die CAPI-Anwendung Timeouts vorsehen, damit der Anschluß nicht lahm gelegt werden kann.  Die standard capifaxrcvd-Anwendung fällt hierbei auf den Bauch.

Die angepaßte Version des capifaxrcvd-Quellcodes kann unter der URL 

http://www.uni-koblenz.de/~admin/Dienste/download/capifax/

bezogen werden. Der Code enthält das capifax Verzeichnis, das Teil der isdn4k-utils ist. 
Damit ein eingehendes Fax automatisch zugestellt werden kann, wird nach Eingang eines Fax von capifaxrcvd ein Skript aufgerufen (hierzu auf der Kommandozeile -n <rcvd-scriptname> angegeben), das Parameter über das empfangene Fax übergeben bekommt. In der Originalversion von capifaxrcvd wurden nur wenige  Parameter übergeben. In der von mir angepaßten Version erhält das Received-Skript folgende Parameter (in der Reihenfolge, in der sie auf der Kommandozeile übergeben werden):

1. Dateiname des Fax.
2. Anzahl der Seiten des Fax.
3. Die vom Anrufer gewählte Zielnummer (davon lediglich die "Durchwahl", also 4 Ziffern, s.u.).
4. Die Nummer des Anrufers, falls diese Übertragen wurde.
5. Die als Teil des Fax-Protokolls übertragene TSI des Anrufers.
6. Die Auflösung des Fax (normal, fein).
7. Die Übertragungsgeschwindigkeit.

Die erste Annahme ist, das die Faxdurchwahl vierstellig ist. Soll die Durchwahl (wie z.B. bei 875-000 bis 875-999) dreistellig sein, muß der Code an zwei Stellen angepaßt werden  (capi.c und capifaxrcvd.c ) damit eine Verbindung jeweils nach der richtigen Zahl der Ziffern angenommen wird.  Eine weitere (potentielle) Besonderheit besteht darin, das die capifaxrcvd Anwendung von mir an einer ALCATEL-Anlage betrieben wird. Das potentiell Besondere (habe leider keinen Vergleich) ist, daß bei der initialen CONNECT-Meldung der CAPI niemals die gewählte  Basisnummer (also z.B. die 0261287100) zur Verfügung gestellt wird, sondern immer die Zahl 0 (bei Blockwahl werden alle hinter der Basisnummer gewählten Ziffern an die 0 angehängt). Wurde also per Blockwahl die 0261287100-123 gewählt ist die in der CAPI_CONNECT Indication zur Verfügung stehende  Nummer gleich 0123.  Daher kann an das Received-Skript auch niemals die Komplette vom Anrufer gewählte Nummer übergeben werden, sondern lediglich die Durchwahl, also die letzten vier Ziffern, was voll ausreicht, da diese vier Ziffern ja genau dem Empfänger bestimmen. Der Rest der gewählten Nummer ist eh immer konstant. 

Editor: Rainer Krienke 
krienke@uni-koblenz.de
Letzte Änderung: 10.03.2000