Otto-von-Guericke-Universität Magdeburg · Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut für Verteilte Systeme Diplomarbeit Computerfax im VoIP-Netzwerk

Otto-von-Guericke-Universität Magdeburg

Fakultät für InformatikInstitut für Verteilte Systeme

Diplomarbeit

Computerfax im VoIP-Netzwerk auf T.38-BasisImplementation und Test des IP-Faxversands

auf einem Unified-Messaging-Controller

Verfasser:

Johann Deutinger17. Juni 2005

Betreuer:

Dipl.-Inform. Spiro TrikaliotisUniversität MagdeburgFakultät für Informatik

Postfach 4120, D–39016 MagdeburgGermany

Deutinger, Johann:Computerfax im VoIP-Netzwerk auf T.38-BasisImplementation und Test des IP-Faxversandsauf einem Unified-Messaging-ControllerDiplomarbeit, Otto-von-Guericke-UniversitätMagdeburg, 2005.

i

Vorwort

Die vorliegende Diplomarbeit ist im Rahmen des Fernstudiengangs Informatik an derUniversität Magdeburg entstanden. Die Ausgabe des Themas erfolgte am 15. Februar2005. Passend zur Intention des Fernstudiums beschäftigt sich die Arbeit mit einemGebiet aus dem beruflichen Umfeld des Bearbeiters.

ii

Danksagung

Für die intensive und sachkundige Betreuung dieser Diplomarbeit bedanke ich michsehr herzlich bei Dipl.-Inform. Spiro Trikaliotis. Seine konstruktive Kritik hat viel zumvorliegenden Ergebnis beigetragen.

Außerdem bedanke ich mich bei meiner Familie für die vielfältige Unterstützung.Meine Frau Gitta hielt mir jederzeit den Rücken für das berufsbegleitende Studiumfrei, obwohl sie mich jahrelang mit der Uni Magdeburg teilen musste und zusammen mitunseren drei Söhnen zeitweise vier Studenten am Hals hatte. Den Jungs (Kalle, Christianund Peter) danke ich vor allem für die Mathe-Hilfe im Grundstudium – das hat mir denWiedereinstieg in dieses Gebiet erleichtert und uns allen viel Spaß bereitet.

Desweiteren danke ich meinem ehemaligen Kollegen Dr.-Ing. Rolf Fiedler, der die ver-wendete Hardware und Firmware im Wesentlichen „erfunden“ und nach seinem Wechselin die Selbständigkeit1 weiterhin betreut hat. Durch seine umfangreiche Erfahrung inder Entwicklung eingebetteter Kommunikationssysteme hat er mir wertvolle Tipps ge-ben können.

Mein Kollege Waldemar Sennert hat mir mit akribischer Suche nach verbliebenenFehlern im Text sehr geholfen – dafür danke ich ihm herzlich. Gido Küchler hat einenwichtigen Beitrag geleistet, indem er „auf die Schnelle“ die benötigte SIP-Software gebauthat, ohne die ich keine Tests durchführen hätte können.

1siehe http://www.innoventif.com

INHALTSVERZEICHNIS iii

Inhaltsverzeichnis

Abbildungsverzeichnis vii

Tabellenverzeichnis ix

Verzeichnis der Abkürzungen xi

1 Motivation und Zielsetzung/Abstract 1

2 Grundlagen der Faxkommunikation 3

2.1 Geschichtliche Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Fax im Telefonnetz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.1 Ablauf einer Faxübertragung . . . . . . . . . . . . . . . . . . . . . 5

2.2.2 Der Gruppe-3 Faxstandard . . . . . . . . . . . . . . . . . . . . . . 10

2.2.3 Der Gruppe-4 Faxstandard . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Faxübertragung in IP-basierten Netzwerken . . . . . . . . . . . . . . . . 13

2.3.1 IP-Fax via Store and Forward . . . . . . . . . . . . . . . . . . . . 13

2.3.2 Realtime Fax over IP . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.3 T.38 Realtime Fax over IP im Detail . . . . . . . . . . . . . . . . 17

2.3.4 Quality of Service (QoS) Aspekte bei Fax over IP . . . . . . . . . 21

3 Auswahl des zu implementierenden Verfahrens 25

3.1 Zielvorgaben des Auftraggebers . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Fax-Eigenschaften gängiger Gateways . . . . . . . . . . . . . . . . . . . . 26

3.3 Betrachtung des Mitbewerbs . . . . . . . . . . . . . . . . . . . . . . . . . 26

iv INHALTSVERZEICHNIS

3.4 Beurteilung der möglichen Alternativen . . . . . . . . . . . . . . . . . . . 27

3.5 Designentscheidungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4 Entwurf und Realisierung 31

4.1 Umfeld für die T.38-Implementation . . . . . . . . . . . . . . . . . . . . 31

4.1.1 OfficeMaster Card als Hardware Basis . . . . . . . . . . . . . . . 31

4.1.2 Softwarekomponenten . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1.3 Modem Interface Layer (ILAPI) . . . . . . . . . . . . . . . . . . . 36

4.2 Vorgaben und Programmierkonventionen . . . . . . . . . . . . . . . . . . 37

4.3 Entwurf und Implementierung der T38LAPI . . . . . . . . . . . . . . . . 38

4.3.1 Gliederung der Software . . . . . . . . . . . . . . . . . . . . . . . 38

4.3.2 Zustandsautomat für den UDPTL-Empfang . . . . . . . . . . . . 40

4.3.3 Steuerung des Zeitverhaltens . . . . . . . . . . . . . . . . . . . . . 42

5 Tests mit verschiedenen Gegenstellen 47

5.1 Cisco 2801-Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.2 Mediatrix 2102 mit analogen Faxempfängern . . . . . . . . . . . . . . . . 52

5.3 (Noch) nicht untersuchte Umgebungen . . . . . . . . . . . . . . . . . . . 54

6 Zusammenfassung und Ausblick 55

Anhang 57

A Ergänzende Details zu den Grundlagen 57

A.1 Textabschnitte im T.30-Standard 07/2003 . . . . . . . . . . . . . . . . . 57

A.2 Untersuchung der Verbreitung von Faxoptionen . . . . . . . . . . . . . . 59

A.3 Kodierung der Faxeigenschaften in DIS/DCS . . . . . . . . . . . . . . . . 60

A.4 Kodierung/Komprimierung von Faxdokumenten . . . . . . . . . . . . . . 67

A.5 Modulationsverfahren bei Gruppe-3 Fax . . . . . . . . . . . . . . . . . . 71

B Implementationsdetails 77

B.1 T.38 (1998) ASN.1-Notation . . . . . . . . . . . . . . . . . . . . . . . . . 77

INHALTSVERZEICHNIS v

B.2 ILAPI Events und Nachrichten . . . . . . . . . . . . . . . . . . . . . . . 79

Literaturverzeichnis 83

vi INHALTSVERZEICHNIS

ABBILDUNGSVERZEICHNIS vii

Abbildungsverzeichnis

2.1 Bakewells Copying telegraph . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Zeitlicher Ablauf einer Faxübertragung. . . . . . . . . . . . . . . . . . . . 5

2.3 Beispielarchitektur eines H.323-Endgeräts . . . . . . . . . . . . . . . . . . 16

2.4 Arten von T.38-Faxeinrichtungen . . . . . . . . . . . . . . . . . . . . . . 18

2.5 UDPTL Paketstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1 OfficeMaster Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2 OfficeMaster Softwarestruktur . . . . . . . . . . . . . . . . . . . . . . . . 34

4.3 Struktur des Faxprozesses . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.4 UDPTL-Empfangszustände . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.5 Zeitverhalten beim T.38-Faxversand von einem Internet-Faxgerät . . . . 45

5.1 Testaufbau mit Cisco 2801 . . . . . . . . . . . . . . . . . . . . . . . . . . 49

A.1 Beispiel für Faxkomprimierung . . . . . . . . . . . . . . . . . . . . . . . . 67

A.2 Zweidimensionale Faxkomprimierung . . . . . . . . . . . . . . . . . . . . 69

A.3 Signalkonstellation bei V.29 und 9600 bps . . . . . . . . . . . . . . . . . 73



viii ABBILDUNGSVERZEICHNIS

TABELLENVERZEICHNIS ix

Tabellenverzeichnis

3.1 Faxeigenschaften gängiger VoIP-Gateways . . . . . . . . . . . . . . . . . 26

4.1 Übersicht über die OfficeMaster Card Gerätetypen . . . . . . . . . . . . . 32

4.2 Timing der Trainingssequenzen . . . . . . . . . . . . . . . . . . . . . . . 44

A.1 Kodierung der Faxeigenschaften (Seite 1/6) . . . . . . . . . . . . . . . . . 61






A.7 Faxkodierung eines Zeilenabschnitts . . . . . . . . . . . . . . . . . . . . . 67

A.8 Tabelle der vorbereitenden Make-Up Codes . . . . . . . . . . . . . . . . . 69

A.9 Tabelle der Terminating Codes (Längen bis max. 63 Pixel) . . . . . . . . 70

A.10 Ermittlung der Amplitude bei V.29 . . . . . . . . . . . . . . . . . . . . . 72

x TABELLENVERZEICHNIS

xi

Verzeichnis der Abkürzungen

ACD Automatic Call DistributionAPI Application Programming InterfaceASN.1 Abstract Syntax Notaion OneATA Analoger TerminaladapterBFF Binary Fax FormatBFT Binary File TransferBPS Bits per SecondBRI Basic Rate InterfaceCCITT Comité Consultatif International Télégraphique et TéléphoniqueCED Called Terminal IdentificationCFR Confirmation To ReceiveCLI Command-Line InterfaceCMOS Complementary Metal Oxide SemiconductorCNG bei Fax: Calling Tone, bei VoIP: Comfort Noise GenerationCSI Called Subscriber IdentificationCSV Comma Separated ValuesCVS Concurrent Versions SystemDCN DisconnectDCS Digital Command SignalDIS Digital identification SignalDSL Ditigal Subscriber LineDSP Ditigal Signal ProcessorDTC Digital Transmit CommandECM Error Correction ModeEDI Electronic Data InterchangeEOM End Of MessageEOP End Of ProcedureERP Enterprise Resource PlanningESMTP Extended Simple Mail Transfer ProtocolFCS Frame Check SequenceFEC Forward Error CorrectionFoIP Fax over IPFSK Frequency Shift Keying

xii

FTT Failure To TrainFTZ Fernmeldetechnisches ZentralamtG3 Gruppe 3 (Fax)GNU GNU’s Not UnixGSTN Global Switched Telephone NetworkHDLC High Level Data Link ControlHE HöheneinheitHFX Hawthorne Facsimile CipherHKM Hawthorne Key ManagementIAF Internet Aware Fax DeviceIETF Internet Engineering Task ForceIFP Internet Facsimile ProtocolIFT Internet Facsimile TransferILAPI ISDN Line APIILID ISDN line interface driverIMAP4 Internet Mail Access Protocol Version 4IOS Internetworking Operating SystemIP Internet ProtocolISDN Integrated Services Digital NetworkISO International Standardization OrganizationITU International Telecommunications UnionIVR Interactive Voice ResponseLAPI Line Application Programming InterfaceLED Light Emitting DiodeMCF Message ConfirmationMGCP Media Gateway Control ProtocolMH Modified HuffmannMIME Multipurpose Internet Mail ExtensionsMMR Modified Modified ReadMPS Multi Page SignalMR Modified ReadNAT Network Address TranslationNSF Non Standard FacilitiesNSS Non Standard Facilities SetupNT Network TerminationOEM Original Equipment ManufacturerOSI Open Systems InterconnectionPCI Peripheral Component InterconnectPCM Pulse Code ModulationPER Packet Encoding RulesPMC PCI Mezzanine CardPOP3 Post Office Protocol Version 3PPR Partial Page Received

xiii

PPS Partial Page SignalPRI Primary Rate InterfacePSTN Public Switched Telephone NetworkQAM Quadratur Amplituden ModulationQoS Quality of ServiceRead Relative Element Address DifferentiationRFC Request For CommentsRISC Reduced Instruction Set ComputerRNR Receive Not ReadyRTN Retrain NegativeRTP Retrain Positive, bei VoIP: Real Time ProtocolSDP Session Description ProtocolSIP Session Initiation ProtocolSMS Short Message ServiceSMTP Simple Mail Transfer ProtocolSSH Secure ShellTCF Training CheckTCP/IP Transmission Control Protocol/Internet ProtocolTE Terminal EquipmentTIFF Tagged Image File FormatTPKT Transport Protocol Data Unit PacketTSI Transmitting Subscriber IdentificationUDP User Datagram ProtocolUDPTL UDP Transport LayerUM Unified MessagingUMS Unified Messaging SystemVAD Voice Activity DetectionVoIP Voice over IP

xiv

Kapitel 1. Motivation und Zielsetzung/Abstract 1

Kapitel 1

Motivation und Zielsetzung/Abstract

Fax in konvergenten Netzen

Mit der Einführung des Gruppe-3 Standards Anfang der achtziger Jahre begann derweltweite Durchbruch der Faxkommunikation. Auch wenn das Thema nicht mehr imMittelpunkt der Berichterstattung steht, ist Fax weiterhin ein wichtiger Bestandteil ins-besondere der geschäftlichen Kommunikation. Gerade im europäischen Raum hat dieweite Verbreitung und umfassende Standardisierung von ISDN-Anschlüssen diese Ent-wicklung gefördert. ISDN ist eine ideale Basis für einfach zu realisierende virtuelle Fax-Durchwahlen zur komfortablen Integration in Mailsysteme, wodurch jeder Benutzer Faxedirekt ins elektronische Postfach zugestellt bekommt. Solche Lösungen verbinden hoheBenutzerakzeptanz mit einer nicht unerheblichen Kostenersparnis.

Seit einigen Jahren verändert sich diese Infrastruktur zusehends. Die Konvergenzvon Sprach- und Datennetzen wirkt sich auch auf die Verfügbarkeit interner ISDN-Anschlüssen aus. Besonders bei Neubauten auf der sprichwörtlichen „grünen Wiese“ wirdoft sämtliche Kommunikation von vornherein auf IP-Basis gestellt – allenfalls zum öffent-lichen Telefonnetz existieren noch ISDN-Anschlüsse. Hausintern installierte Faxservermüssen sich diesen Gegebenheiten anpassen und mit der IP-Telefonie kooperieren. Hier-für gibt es eine Reihe von Ansätzen, unter denen der Fax-over-IP (FoIP) Kommunikationauf Basis des T.38-Protokolls eine besondere Bedeutung zukommt.

Hintergrund der Aufgabenstellung

Die Ferrari electronic AG1, für die diese Arbeit erstellt wird, ist seit vielen Jahren ei-ner der führenden deutschen Hersteller im Bereich des Unified Messaging [1], zu demhauptsächlich die Dienste Fax, Voicemail und SMS zählen. Neben Softwarelösungen,

1http://www.ferrari-electronic.de

2

die in alle wichtigen Plattformen2 integriert werden können, entwickelt und vermarktetdie Firma auch dazu passende Kommunikations-Controller. Als Computerfax-Pionierbrachte sie 1991 die erste über einen eigenen Mikroprozessor gesteuerte Faxkarte aufden deutschsprachigen Markt. Später entstand eine Familie von Nachfolgern mit ISDN-Schnittstellen. Die 2003 vorgestellte OfficeMaster Card stellt bereits die dritte Generationdar. Zug um Zug müssen die aktuellen Controller nun für die Integration in VoIP-Netzeweiterentwickelt werden. Da der Faxdienst bei den vom Auftraggeber verkauften Lösun-gen nach wie vor eine Hauptrolle spielt, ist die Erweiterung um Fax-over-IP besonderswichtig. Mit der vorliegenden Arbeit soll diese Entwicklung in wichtigen Teilen umgesetztwerden. Die Priorität liegt zunächst vor allem bei der Möglichkeit des Faxversands.

Aufbau und wesentliche Inhalte dieser Arbeit

Nach der Einleitung (Kapitel 1) wird im Kapitel 2 in den Gruppe-3-Faxdienst eingeführt,dessen Verständnis für Fax-over-IP eine wichtige Voraussetzung ist. Die verschiedenentechnischen Möglichkeiten der Faxkommunikation in IP-Netzen werden erläutert und dasT.38-Protokoll näher betrachtet. In Kapitel 3 werden zunächst die Anforderungen an diezu entwickelnde Lösung beschrieben. Anschließend erfolgt eine Bewertung der in Fragekommenden Verfahren und darauf basierend eine Auswahl für die Implementation. Ka-pitel 4 (Entwurf und Realisierung) beschreibt das Umfeld der Entwicklung, den Entwurfder Software sowie exemplarische Details der Implementation. Messung und Bewertungdes Verhaltens in Verbindung mit Geräten bzw. Gateways verschiedener Hersteller wer-den in Kapitel 5 beschrieben. Zusammenfassung und Ausblick (Kapitel 6) beschließendie Arbeit. Im Anhang sind vertiefende Informationen zu wichtigen Aspekten der Arbeitzu finden.

English Abstract

After more than twenty years of great success, G3 fax devices are installed and used inalmost every office worldwide. Despite new alternatives like E-Mail, people still like theidea of reliable end to end transmission of important business documents. Enterprisesare using cost-effective fax server solutions in combination with existing mail serversor ERP systems. Especially in Germany ISDN is typically used by fax servers as aconnection point to provide for simple installation, fast dialling and routing of incomingfaxes through extension numbers. Nowadays customers are heading toward IP telephony,where internal ISDN interfaces often are not available anymore. Vendors like Ferrarielectronic AG are challenged to support IP technology in their fax controllers to continueproviding professional fax services with their products. This Diploma Thesis selects,describes and implements a solution which fulfills these requirements.

2Dazu zählen vor allem Microsoft Exchange Server, Lotus Domino Server, SAP R/3 sowie verschie-dene, meist Linux-basierte Systeme.

Kapitel 2. Grundlagen der Faxkommunikation 3

Kapitel 2

Grundlagen der Faxkommunikation

2.1 Geschichtliche Entwicklung

Der heute gängige Begriff Fax ist eine Abkürzung der Bezeichnung Telefax, die wieder-um eine Vereinfachung des Wortes Telefaksimile (Fernbildabschrift) darstellt. AlexanderBain, ein schottischer Uhrmacher, entwarf bereits 1842 einen Kopiertelegraphen, der einJahr später patentiert wurde. Erst 1851 wurde ein Gerät auf dieser Basis von Bakewellin London vorgestellt.

Abbildung 2.1: Bakewells Copying telegraph – ein Vorläufer des modernen Faxgeräts.Wie bei diesem wird die Vorlage zeilenweise abgetastet.(Quelle: http://www.hffax.de/history/

Eine wichtige Faksimile-Komponente ist die Bildabtastung. Bakewells Copying tele-graph (Abbildung 2.1) benutzte hierfür einen Lesekopf, der durch ein Führungsgewindefortbewegt wurde, um die Vorlage spiralförmig abzutasten. Das Prinzip ist heute noch

http://www.hffax.de/history/

4 2.2. Fax im Telefonnetz

dasselbe. Bildhafte Informationen werden zeilenweise in kleinen Abständen abgetastetund das Ergebnis parallel auf der Empfängerseite zu Papier gebracht. Anfangs musstedie Vorlage diese Informationen in Form einer isolierenden Tinte auf leitfähigem Papierbereitstellen, was die Abtastung und Umwandlung in elektrische Signale erleichterte.Sender und Empfänger verfügten über synchronisierte rotierende Trommeln. Nach jederUmdrehung wurden Lese- und Schreibkopf um 0,5 mm weiter bewegt. Die Übertragungeiner 20×15 cm großen Fotografie dauerte so etwa eine halbe Stunde.

Wichtige Fortschritte brachte 1902 die Entwicklung einer Faxmaschine mit optischerAbtastung in Deutschland durch Dr. Arthur Korn. Vor allem während des ersten Welt-kriegs wurde mit solchen Geräten eine brauchbare Qualität bei der Übertragung vonBildern und Landkarten erzielt. Dr. Ing. Rudolf Hell entwickelte 1949 einen Bildtelegra-phen, der als Vorläufer der heute üblichen Faxgeräte gilt.

Bereits in den 30er Jahren wurde in Amerika versucht, die Faksimile-Übertragungvon Nachrichten auch in private Haushalte zu bringen. Mit der rasanten Entwicklungder Fernsehtechnik wurden derartige Projekte jedoch schnell wieder begraben. Erst abetwa 1960 entstanden einigermaßen kostengünstige Faxgeräte, die über öffentliche Te-lefonnetze untereinander kommunizieren konnten. Befördert wurde diese Entwicklungdurch nachlassende Qualität der Postdienste in den USA und vor allem durch den großenBedarf aus Japan. Wegen des grafischen Charakters der dort verwendeten Schriftzeichenwar der Bedarf an Faksimileübertragung ungleich höher als in Ländern mit lateinischerSchrift, die auch mit Fernschreibern relativ gut übermittelt werden konnte.

Die verbesserte Interoperabilität der Geräte durch Standardisierung im CCITT för-derte die weltweite Entwicklung des Faxdienstes. Der 1968 verabschiedete Gruppe 1Standard litt noch unter Kompatibilitätsproblemen der unterschiedlichen Implementatio-nen,1 zudem dauerte die Übertragung einer Seite sechs Minuten. 1976 wurde der Gruppe2 Standard festgelegt, der die Übertragungszeit halbierte und die Auflösung auf ca. 100Zeilen/Zoll vergrößerte. Erst die Einführung der Gruppe 3 Spezifikation 1980 brachte denendgültigen Durchbruch. Die Verwendung schnellerer Modemverfahren, höherer Auflö-sung (ca. 200dpi), sowie digitaler Techniken zur Komprimierung der Bilddaten führtezur schnellen Verbreitung und damit auch zur Verbilligung derartiger Geräte. Bis heuteist Gruppe 3 der fast ausschließlich genutzte Standard für die Faxkommunikation – diespäter festgelegte Gruppe 4 hat sich nicht durchgesetzt (mehr dazu in Kapitel 2.2.3).

2.2 Fax im Telefonnetz

In diesem Abschnitt wird der Ablauf einer Faxübertragung im Detail beschrieben. An-schließend werden die Standards, auf denen dieser Ablauf basiert, erläutert. Beides isteine wichtige Grundlage für das Verständnis des IP-Faxprotokolls T.38, das den Kernder Diplomarbeit bildet.

1Kompatibitlitätsprobleme sind auch in heute gängigen Faxgeräten zu finden, allerdings treten sienur mehr sehr selten auf.


2.2.1 Ablauf einer Faxübertragung

Abbildung 2.2: Zeitlicher Ablauf einer Faxübertragung.


Abbildung 2.2 zeigt eine typische Faxübertragung. Zu diesem Zweck wurden währenddes Versands einer einzelnen Faxseite die Nutzdaten an der ISDN-Schnittstelle mit einemProtokolltester als Stereo-Wave-Datei aufgezeichnet. Die analogen Sendedaten2 sind inder linken Spalte in roter Farbe, die vom Empfänger gesendeten Informationen rechts ingrün zu sehen. Dabei ist zu erkennen, dass das Protokoll halbduplex arbeitet, das heißt,dass beide Seiten abwechselnd senden.3

Die Übermittlung eines Faxes gliedert sich in fünf Phasen, die – korrespondierend mitden kommentierten Ereignissen in Abbildung 2.2 – im folgenden kurz erläutert werden.Da die ursprünglichen Standards (T.30 [2], T.4 [3] und T.6 [4]) in englischer Spracheverfasst sind, wird für die Auswahl der deutschen Bezeichnungen auf den Standard FTZ18TR53 [5] vom Januar 1994 zurückgegriffen. Die englischen Begriffe sind den obengenannten Originaldokumenten entnommen.

Phase A – Verbindungsaufbau(Call Establishment)

Phase A beginnt mit dem Abheben und Wählen auf der rufenden Seite (bzw. den ent-sprechenden Signalisierungsphasen im ISDN). Anschließend wird ein wiederholter Ruftongesendet, bis eine Antwort vom gerufenen Gerät erkannt wird oder ein Überwachungs-timer abläuft. Die Ruftonsequenz besteht jeweils aus einem 0,5 Sekunden langen Ton(CNG, 1100 Hz) und einer anschließenden Pause von drei Sekunden. Das gerufene Geräthebt ab, wartet zwei Sekunden und sendet dann drei Sekunden lang einen Antwortton(CED, 2100 Hz). Der Rufton dient vor allem dazu, einem Telefonbenutzer zu signali-sieren, dass es sich bei dem Anrufer um ein Faxgerät handelt. Der Antwortton hat füreinen Telefonanrufer dieselbe Funktion, zudem sorgt er für die Abschaltung von Echoun-terdrückern auf dem Übertragungsweg.

Phase B – Einleitungsphase(Pre-message procedure)

Bevor die Dokumentenübertragung beginnt, erfolgt in Phase B die Aushandlung wichti-ger Details zur geplanten Übermittlung. Dazu meldet sich das gerufene Gerät zunächstmit seinen Eigenschaften und möglichen Optionen, um dem Absender eine passendeAuswahl zu erlauben. Dies erfolgt durch folgende Nachrichten:

• NSF (non standard facilities), signalisiert herstellerspezifische Eigenschaften

• CSI (called subscriber identification), übermittelt die Faxkennung des gerufenenTeilnehmers

2Die für die Faxkommunikation verwendeten Modulationsverfahren werden im Anhang A.5 erläutert.3Gleichzeitiges Senden kann in Fehlersituationen passieren, in denen die Protokollzustände der bei-

den Geräte nicht identisch sind, sowie am Ende, wenn beide Seiten vor dem Auflegen das DisconnectKommando (DCN) senden.


• DIS (digital identification signal), informiert über die Fähigkeiten des Geräts, z.B.Übertragungsverfahren, Auflösung, Papierformat

Während NSF und CSI optional sind, muss DIS zwingend gesendet werden, damitdas rufende Faxgerät entscheiden kann, welche Verfahren und Möglichkeiten es bei derÜbertragung nutzen kann.

Das sendende Gerät antwortet daraufhin mit folgenden Informationen:

• NSS (non standard facilities setup), signalisiert eine Nutzung der angebotenenherstellerspezifischen Fähigkeiten (diese Möglichkeit wird in der Praxis sehr seltenwahrgenommen)

• TSI (transmitting subscriber identification), übermittelt die Faxkennung des ru-fenden Teilnehmers

• DCS (digital command signal), beschreibt die Auswahl aus den angebotenen Ei-genschaften und Verfahren, vor allem Auflösung, Übertragungsrate bzw. Modula-tionsverfahren und weitere standardisierte Optionen

• TCF (training check), ein Testdatenblock in der ausgehandelten Geschwindigkeit

Ähnlich wie beim Empfänger sind auch hier die ersten beiden Kommandos (NSS undTSI) optional, die Übermittlung von DCS ist vorgeschrieben („mandatory“). Alle bishergenannten Informationen werden mit 300 Baud und V.21-FSK-Modulation gesendet. ZurSicherung der Integrität wird jedes Kommando als HDLC-Frame übermittelt, damit derEmpfänger verfälschte Blöcke verwerfen kann. In diesem Falle wartet der Absender ei-ner Nachricht vergeblich auf die erforderliche Antwort und wiederholt sein Kommandonach Ablauf eines Überwachungstimers. Alle Informationen, die nicht der Dokumenten-übermittlung dienen, werden auf diese Weise übertragen, mit einer Ausnahme: Nachdemder Absender mit dem DCS-Kommando unter anderem das gewählte Übermittlungs-verfahren mitgeteilt hat, wechselt er anschließend in diesen Modus und sendet für dieDauer von 1,5 Sekunden ein Signal, das ausschließlich aus logischen Nullen besteht. DerEmpfänger schaltet gleichzeitig in dieselbe Betriebsart und prüft, ob die Empfangsda-ten ausschließlich aus Nullen bestehen. In diesem Falle4 wird dem Absender durch dasKommando CFR (confirmation to receive) mitgeteilt, dass die Übertragungsstrecke dasausgewählte Verfahren „verkraftet“. Nach der Übermittlung von CFR beginnt die PhaseC. Sollte die Auswertung des TCF-Blocks ergeben, dass die Leitungsqualität nicht aus-reicht, wird dies mit dem Kommando FTT (failure to train) negativ quittiert. Daraufhinkann der Absender mit DCS eine niedrigere Geschwindigkeit wählen und erneut überTCF die Qualität prüfen. In der Regel wird nach zweimaligem erfolglosen Reduzierender Übertragungsrate vom Absender ein DCN- (disconnect-) Kommando gesendet unddie Verbindung abgebaut.

4Manche Geräte tolerieren auch einen gewissen Prozentsatz an Bits, die ungleich Null sind. Häufigkann diese Schwelle durch Servicepersonal eingestellt werden.


Phase C – Dokumentenübertragung(In-message procedure/Message transmission)

In Phase C wird das Dokument übertragen (die Kodierung der grafischen Seiteninhaltewird im Anhang A.4 beschrieben). Nach jeder Seite – bzw. Teilseite im Falle des optionalausgehandelten Fehlerkorrekturmodus (ECM - Error Correction Mode)5 – wird in PhaseD übergegangen.

Phase D – Schlussphase(Post-message procedure)

Nach Übertragung einer (Teil-) Seite wird der Empfänger zur Quittierung oder zumBeenden der Verbindung aufgefordert. Der Absender schickt hierfür eines der folgendenKommandos:

• EOP (end of procedure), teilt dem Empfänger mit, dass das gesamte Dokumentübertragen wurde

• MPS (multi page signal), signalisiert ein Seitenende, wobei mindestens noch eineweitere Seite zu senden ist

• EOM (end of message), wird bei älteren Faxgeräten mit manueller Papierzufuhrverwendet und signalisiert, dass die aktuelle Seite zu Ende ist und gegebenenfalls ei-ne weitere folgen könnte (sofern der Benutzer noch ein Blatt einlegt); im Anschlussan die Quittung wird deshalb zurück zur Phase B verzweigt

• PPS (partial page signal), wird im Fehlerkorrekturmodus benutzt, um das Endeder aktuellen Teilseite anzuzeigen

• DCN (disconnect), kann jederzeit, vor allem nach erfolgter Bestätigung der letz-ten Seite, gesendet werden, um der Gegenseite anzuzeigen, dass anschließend dieVerbindung beendet wird

Die Bestätigung, die (außer bei DCN) erwartet wird, hängt von der Betriebsart ab.Ohne Fehlerkorrekturmodus wird eine Seite positiv durch MCF (message confirmation)bzw. negativ durch RTP oder RTN (retrain positive/negative) quittiert. Bei Nutzungdes ECM wird vom Empfänger entweder durch Senden von MCF angezeigt, dass alleHDLC-Frames korrekt empfangen wurden oder im Fehlerfalle ein PPR- (partial pagereceived) Block gesendet, der für jeden Teilframe ein Bit beinhaltet, das anzeigt, ob derFrame korrekt (0) oder fehlerhaft (1) empfangen wurde. Anschließend wiederholt der

5ECM ermöglicht eine fehlerfreie Übertragung. Hierzu wird die Information in maximal 256 durch-nummerierte HDLC-Frames mit je 256 (selten auch 64) Bytes Nutzinformation verpackt und gesendet.Am Ende dieser maximal 65536 Bytes wird ebenfalls in Phase D gewechselt, auch wenn eine Seite nochnicht vollständig übermittelt wurde. In Phase D kann der Empfänger eine Wiederholung von Frames,die er nicht korrekt erhalten hat, anfordern.


Sender die als fehlerhaft gemeldeten Teilblöcke. Ohne ECM wird eine empfangene Sei-te abhängig von der Anzahl fehlerhafter Zeilen bewertet, wobei der prozentuale Anteildefekter Zeilen an der Gesamtzeilenzahl ein Kriterium darstellt (meist auf 10 Prozenteingestellt). Ein weiterer wichtiger Punkt ist die Feststellung, wie viele aufeinander fol-gende Pixelzeilen gestört waren, da es möglich ist, dass auch bei nur 5 Prozent defekterZeilen durch eine ungünstige Häufung eine ganze Textzeile des Originaldokuments beimEmpfänger fehlt. Deshalb wird eine empfangene Seite auch nach mehreren6 aufeinanderfolgenden gestörten Zeilen negativ quittiert.

Phase E – Zurückschalten auf Fernsprechbetrieb(Call release)

Diese Phase beendet die Faxverbindung entweder nach erfolgreicher Faxübermittlungoder nach Auftreten eines nicht behebbaren Protokoll- oder Übertragungsfehlers. Soferndie Verbindung ursprünglich manuell von zwei Telefonteilnehmern begonnen wurde undkeiner inzwischen den Hörer aufgelegt hat, wird nach Trennen der Faxverbindung aufTelefonie zurückgeschaltet.

Weitere Betriebsarten

Neben der hier beschriebenen üblichen Faxübertragung vom Anrufer zum Gerufenen gibtes zwei abweichende Möglichkeiten:

1. Faxabruf (polling) – der rufende Teilnehmer versucht, von der Gegenstelle ein Faxabzuholen. Diese informiert am Anfang im DIS-Block durch ein entsprechendesBit, ob überhaupt ein Dokument bereit liegt, ist dieses Bit nicht gesetzt, bricht dasrufende Gerät den Polling-Vorgang ab.

2. Senden mit anschließendem Abruf (reverse polling) – nachdem der Anrufer ein Faxgesendet hat, wird anschließend die Richtung umgekehrt und ein Dokument vomangerufenen Teilnehmer abgeholt (diese Möglichkeit wird nur sehr selten genutztund auch nicht von allen Geräten unterstützt).

Beide Verfahren nutzen zusätzliche Signalisierungsblöcke, die bisher nicht aufgeführtwurden. Auf eine detaillierte Beschreibung dieser optionalen Abläufe wird der Übersicht-lichkeit halber verzichtet. Sie können in [2] nachgelesen werden.

6vier bis acht – je nach verwendeter Auflösung


2.2.2 Der Gruppe-3 Faxstandard

Die Faxkommunikation erfolgt heute fast ausschließlich auf Basis des Gruppe-3 Stan-dards. Dieser ist in den ITU-Dokumenten T.30 [2] und T.4 [3] beschrieben.

ITU-T Recommendation T.30 – „Procedures for document facsimile trans-mission in the general switched telephone network“ [2]

Die 1980 vom CCITT, dem Vorläufer der ITU, verabschiedete T.30-Empfehlung be-schreibt die Gruppe-3-Faxkommunikation. Im Laufe der Jahre wurden nach und nachweitere Optionen hinzugefügt, wobei viele dieser neuen Möglichkeiten nur von einem ge-ringen Prozentsatz der aktuell installierten Faxgeräte unterstützt werden (siehe AnhangA.2).

Der oben beschriebene Ablauf des Faxversands ist detailliert im T.30-Standard be-schrieben. Hinzu kommen zahlreiche Parameter, die in Form von Bitkombinationen vorallem in den Nachrichten DIS und DCS kommuniziert werden. Die aktuelle tabellarischeListe dieser Eigenschaften ist inzwischen knapp sechs Seiten lang (siehe Anhang A.3).

Einen groben Überblick über die gewachsene Vielfalt an Optionen gibt die Aufzählungder T.30-Kapitelüberschriften im Anhang A.1. Einige der Überschriften sind selbsterklä-rend, wo dies nicht der Fall ist, werden die entsprechenden Kapitelinhalte kurz skizziertbzw. kommentiert.

Von wesentlicher Bedeutung im T.30-Standard ist die Festlegung, welche Endgerä-teeigenschaften wie angeboten bzw. genutzt werden können (siehe Anhang A.3). Siedokumentiert auch anschaulich, wie die Spezifikation im Laufe der Jahre weiterentwi-ckelt wurde. Ein Vergleich von vier verschiedenen T.30-Versionen soll die Fortschreibungdieses Standards skizzieren – insbesondere wird dabei auf den jeweiligen Umfang derwählbaren Optionen eingegangen. Die wichtigsten Neuerungen gegenüber der vorherigenVersion innerhalb dieser Reihe werden ebenfalls herausgearbeitet.

Beispiele für die Evolution des T.30-Standards

11/1988[6] Dieser im sogenannten „Blue Book“7 enthaltene Faxstandard (Bestandteil von Vo-lume VII – Fascicle VII.3) erschien noch als CCITT-Standard und bildete denNachfolger des „Red Book“, das 1984 veröffentlicht wurde. Die Signalisierung dernutzbaren Geräteeigenschaften erstreckt sich auf maximal 40 Bits (fünf Oktette).Die Minimallänge der Nachrichten, die diese Informationen transportieren (DIS,DTC, DCS) beträgt drei Oktette – erst danach gibt es die Möglichkeit, über das„Extend field“-Bit zu signalisieren, dass jeweils ein weiteres Oktett folgt. DieseVersion enthält bereits den „Error Correction Mode“, der inzwischen von einemGroßteil der Faxgeräte unterstützt wird (siehe Anhang A.2). Weniger verbreitetsind die zahlreichen unterschiedlichen Papierformate, die in [6] definiert wurden.

7Die vom CCITT verabschiedeten Telekommunikationsstandards erschienen in vierjährigem Abstandals gedruckte Sammelbände, die leicht am farbigen Einband unterschieden werden können. Das BlueBook von 1988 enthält rund 20.000 Seiten.


03/1993[7] In diesem bereits als ITU-T Standard erschienenen Dokument sind 72 Bits (neunOktette) für Eigenschaften bzw. Optionen vorgesehen. Hinzugekommen ist dieÜbertragung mit V.33-Modulation, die bald danach durch die Anwendung vonV.17 ersetzt wurde. Neu sind auch Auflösungen von 300 und 400 dpi sowie „binaryfile transfer“.

07/1996[8] Die maximale Übertragungsrate wurde mit dieser Spezifikation auf 33.600 bpserhöht (V.34 mit V.8-Handshake). Gleichzeitig ist die Möglichkeit, farbige Doku-mente zu übertragen, hinzugekommen. Die Eigenschaftenliste wurde nur um einOktett erweitert.

07/2003[2] Gegenüber der Version von 1996 gibt es in dieser (derzeit aktuellen) Ausgabe 48weitere Bits, um Eigenschaften zu kodieren. Dazu gehören zum Beispiel höhe-re Farbauflösungen und diverse Verschlüsselungsmöglichkeiten. Wie Anhang A.2zeigt, sind Geräte, die diese Optionen unterstützen, derzeit kaum zu finden.

Da die Signalisierung der Geräteoptionen nur mit 300 bps erfolgt, wurde bei der Standardi-sierung versucht, die Nachrichten möglichst kompakt zu halten, um die Übertragungszeit nichtunnötig zu verlängern. Dieses Bestreben führte sogar dazu, dass gelegentlich einzelne Bits oderBitkombinationen, deren Nutzung sich in der Praxis als sehr gering erwies, später mit einer neu-en Bedeutung belegt wurden. In seltenen Fällen führt dies naturgemäß zu Inkompatibilitäten.Ein Beispiel hierfür ist die vorübergehende Nutzung der V.33-Modulation – die Bitkombinationzur Ankündigung dieser Eigenschaft wurde später zur Anzeige der V.17-Kompatibilität umdefi-niert. Geräte, die V.33 nach dem 1994 erschienenen Standard beherrschen, unterstellen neuerenFaxgeräten, dass sie V.33 können, obwohl diese V.17 angeboten haben.8

Im weiteren Verlauf dieser Arbeit sind für die Implementation einige Entscheidungen zutreffen, die davon abhängen, wie weit bestimmte Geräteoptionen verbreitet sind. Um hierfüreine Grundlage zu schaffen wurde ein Programm entwickelt, das eine Liste von Faxnummernder Reihe nach anruft, die gemeldeten Eigenschaften aufzeichnet und danach wieder auflegt.Ein zweites Programm wertet anschließend aus, welche Optionen wie oft angetroffen wurden.Diese Untersuchung wurde mit willkürlich ausgewählten Faxnummern durchgeführt und dieAuswertung auf Basis von 1000 erreichten Geräten vorgenommen. Mehr dazu im Anhang A.2.

ITU-T Recommendation T.4 – „Standardization of Group 3 facsimile termi-nals for document transmission“ [3]

Im T4-Standard werden Eigenschaften von Faxgeräten der Gruppe 3 beschrieben. Auch T.30befasst sich am Rande mit diesen Eigenschaften, beschränkt sich aber auf die Kodierung der-selben im Rahmen der Kommunikation zwischen Geräten.

8Anmerkung aus [2] hierzu: In the case of setting (1, 1, 0, 1) in DIS/DTC bits 11-14 in order toannounce the capability to receive in ITU-T V.17, some terminals which conform to the 1994 versionand earlier versions of this Recommendation recognize the capability to receive in ITU-T V.33 and mayset (0, 0, 1, 0) or (0, 1, 1, 0) in DCS bits 11-14. Therefore, the terminal which has the capability toreceive, using the modulation system defined in ITU-T V.17, may optionally support the capability toreceive using the modulation system defined in ITU-T V.33.


Wichtige Inhalte von T.4 sind:

• Festlegung von Papierformaten und Auflösungen

• Beschreibung der zu verwendenden ein- und zweidimensionalen Kodierung. Dieser Kern-abschnitt in T.4 definiert das Modified-Huffmann Komprimierverfahren (MH), das alleGeräte unterstützen müssen. Zusätzlich wird eine optionale zweidimensionale Erweite-rung spezifiziert (MR – Modified Read). Dabei wird die Tatsache genutzt, dass zweiaufeinander folgende Pixelzeilen meist große Ähnlichkeit aufweisen, so dass nur die Dif-ferenz übermittelt werden muss. Da sich bei Übertragungsstörungen Fehler innerhalb ei-ner Zeile auf alle folgenden Zeilen fortpflanzen würden, wird in regelmäßigen Abständen(die von der vertikalen Auflösung abhängen) zur Neusynchronisierung eine herkömmlichkodierte Pixelzeile gesendet. Falls durch Nutzung von ECM gewährleistet wird, dass In-formationen fehlerfrei ankommen, ist es möglich, eine weitere Option zu nutzen, die einegesamte Seite mit zweidimensionaler Kodierung überträgt. Diese Modified-Modified-Read(MMR) Kodierung sorgt für eine durchschnittliche Reduzierung der Datenmenge um 35Prozent gegenüber eindimensionaler Komprimierung. Das Verfahren ist im T6-Standard[4] beschrieben, der ursprünglich für Gruppe-4 Geräte gedacht war. Einzelheiten zu dengenannten Kodierungen finden sich im Anhang A.4.

• Verweise auf Standards für die Modulation und Demodulation der Signale

• Sonstige Festlegungen: Sendepegel, Fehlerkorrekturmodus (ECM), Filetransfer, CharacterMode, Kodierung von Farbdokumenten u.a.

2.2.3 Der Gruppe-4 Faxstandard

Als Nachfolger des Gruppe-3 Standards wurde in der CCITT Study Group VIII, die auch dieGruppe 3 definiert hatte, ein Nachfolger erarbeitet. Diese 1984 erstmals vorgestellte Spezifika-tion für Fax Gruppe 4 ist unter anderem gekennzeichnet durch:

• Ausrichtung am Open Systems Interconnection (OSI) Referenzmodell der InternationalStandardization Organization (ISO)

• Höhere Auflösung (mindestens 400 dpi)

• T.6-Komprimierung (MMR) als Basismerkmal (durch die zwingend vorgeschriebene Si-cherungsschicht möglich)

• gedacht für hohe Übertragungsraten (typisch 64 kbps im ISDN)

• verwendete Standards: T.6 für Geräteeigenschaften und Kodierung, T.62 für die OSI-basierte Kommunikation (ursprünglich für Teletex spezifiziert, das wiederum als Nachfol-ger des Telex-Dienstes geplant war, aber nach wenigen Jahren wieder eingestellt wurde)

Gruppe-4 Geräte haben sich nicht durchgesetzt. Hierfür gibt es eine Reihe von Gründen:

• Die benötigten ISDN-Anschlüsse existierten anfangs nicht.


• Scanner- und Druckerbaugruppen für 400 dpi wurden Mitte der achtziger Jahre nur inkleinen Stückzahlen gefertigt und waren dehalb sehr teuer.

• Parallel wurde die Geschwindigkeit der G3-Faxkommunikation durch verbesserte Kom-primierung und schnellere Modemstandards erhöht.

• G4-Geräte mussten die komplette G3-Funktion parallel beinhalten, um zu bestehendenFaxgeräten kompatibel zu sein.

Der hohe Preis der ersten Geräte und das Fehlen passender Gegenstellen verhinderten ei-ne weitere Verbreitung – damit blieben die Preise mangels größerer Produktionsstückzahlenhoch. Ein weiteres Problem ist eher technisch bedingt: Bei Verbindungen mit höheren Latenzen(z.B. über Satellitenstrecken) entsteht durch schichtweisen Aufbau der OSI-Protokollebeneneine Verzögerung von etlichen Sekunden, bevor die Dokumentenübertragung beginnen kann.Diese Zeit ist unter Umständen länger als die für das Senden des eigentlichen Faxes benötigteDauer (ausführliche Informationen hierzu finden sich im Vortrag von Alan Pugh auf der Eurofax’90 Conference [9]). Als Alternative wurde deshalb T.30 Annex C definiert – dabei wird dasGruppe-3 Protokoll mit 64 kilobit digital im ISDN abgewickelt.9

2.3 Faxübertragung in IP-basierten Netzwerken

Die zunehmende Umstellung der Telefonie von leitungsvermittelten Verbindungen auf IP-ba-sierte Netzwerke verlangt nach passenden Migrationsmöglichkeiten für die Faxkommunikation.Innerhalb der letzten Jahre sind zu diesem Zweck verschiedene Verfahren entwickelt worden, diezum Teil als internationale Standards erschienen, vielfach aber auch herstellerspezifisch bzw.proprietär geprägt sind. Ausgangsbasis für die Festlegung der ITU-T Internet-Faxstandardsist das Dokument F.185 (siehe [10]). Für Fax-over-IP wird im folgenden Text analog zu VoIP(Voice-over-IP) die Abkürzung „FoIP“ verwendet.

Der folgende Abschnitt erläutert kurz die wichtigsten Techniken und befasst sich anschlie-ßend detaillierter mit dem T.38-Standard [11].

2.3.1 IP-Fax via Store and Forward

Seit längerem gibt es Anbieter von Faxdienstleistungen,10 die den Faxversand für Auftraggeberrealisieren. Hauptaspekt für eine solche Vorgehensweise war ursprünglich die Einsparung vonÜbertragungskosten, die die Anbieter dadurch erzielten, dass sie die Faxdokumente über eigeneVerbindungen kostengünstig zu einem Ort in der Nähe des jeweiligen Empfängers transportier-ten. Von dort erfolgt dann der Faxversand über preiswerte Nahverbindungen (diese Vorgehens-weise wird auch als „least-cost-routing“ bezeichnet). Daneben werden solche Angebote auch fürden Massenfaxversand genutzt, der durch hohe Parallelität innerhalb kurzer Zeit abgewickeltwerden kann. Ursprünglich wurden die zu versendenden Dokumente an den Dienstleister per

9Außer der Ferrari electronic AG sind dem Verfasser keine weiteren Firmen bekannt, die diese Vari-ante jemals implementiert haben.

10Dazu gehört beispielsweise der Telefax 400 Dienst der Deutschen Telekom, der seit 1993 angebotenwird.

14 2.3. Faxübertragung in IP-basierten Netzwerken

Fax übermittelt. Mit der starken Verbreitung des Internets Mitte der 90er Jahre wurde die-ser Transport meist auf IP-Protokolle unter Nutzung anbieterspezifischer Software umgestellt.Diese Lösungen können somit dem Bereich der proprietären Store and Forward IP-Faxlösungenzugerechnet werden.

T.37-Standard für Store-and-Forward IP-Fax

Parallel dazu wurde Mitte 1998 der offizielle T.37-Standard [12] vorgestellt, der alle Aspekteeiner nicht-Echtzeit IP-Faxübertragung umfasst. Er baut auf vorhandenen Standards auf, zumBeispiel:

• (E)SMTP zur Kommunikation zwischen den beteiligten Einrichtungen

• POP3, IMAP4 für Client/Server-Operationen

• Internet Mail Adressierung

• E.164 Telefonnummern-Syntax

• TIFF gemäß RFC 2301 Profile S (Modified Huffmann) zur Kodierung der Faxdokumente

• MIME für das „Verpacken“ des Inhalts

Der T.37-Standard besteht hauptsächlich aus Verweisen auf RFC-Papiere der Internet En-gineering Task Force (IETF). Er definiert zwei Betriebsarten:

• Den Simple Mode müssen alle T.37-fähigen Geräte beherrschen. In dieser Betriebsartwerden keine Geräteeigenschaften ausgehandelt, zudem gibt es keine Empfangsbestäti-gungen. (Beides gehört hingegen beim herkömmlichen Faxverkehr zu den Grundfunktio-nen!)

• Der optionale Full Mode ist in [12] nur angedeutet („for further study“).

Im 1999 erschienenen Nachtrag 1 [13] wird der Full Mode ausführlicher beschrieben. Dabeihandelt es sich fast ausschließlich um die Definition verschiedener TIFF-Profile für unterschied-liche Dokumenteneigenschaften (Auflösung, Größe, Farbe etc.). Für die zu benutzenden Proze-duren wird auf RFC 2532 verwiesen. Nachtrag 2 (2001) [14] und Nachtrag 3 (2002) [15] bringennur kleinere Korrekturen und Ergänzungen.

2.3.2 Realtime Fax over IP

Als Alternative zur store-and-forward Methode wurden Echtzeit-Verfahren erarbeitet, die denvom Telefonnetz her gewohnten Faxbetrieb im IP-Netz nachbilden können. Auch hier gibt esverschiedene Möglichkeiten, die sich hinsichtlich Implementierungsaufwand, Qualität und Ein-satzgebiet zum Teil erheblich unterscheiden. Die verbreitetsten Verfahren werden im folgendenText kurz beschrieben. Auf den T.38-Standard [11] wird dann etwas ausführlicher eingegangen.Allen Methoden gemeinsam sind die nutzbaren Signalisierungsverfahren, also die Art und Wei-se, wie eine Verbindung zur Gegenstelle hergestellt und am Ende wieder abgebaut wird. Diese


Protokolle werden zu Beginn des Abschnitts eingeführt. Das Kapitel endet mit einer Betrach-tung der Frage, in welchen Bereichen Quality-of-Service Aspekte bei Fax over IP eine Rollespielen.

Signalisierungsverfahren für Realtime Fax over IP

Da Fax over IP eine Komponente im Umfeld von Voice over IP darstellt, ist es naheliegend,bereits definierte Standards soweit wie möglich mitzunutzen. Dies gilt insbesondere für dieSignalisierung, da zum Auf- und Abbau von Faxverbindungen nur einfache Grundfunktionenbenötigt werden, die in jeder Ausprägung der Telefonie unterstützt werden. Derzeit existierenfür Endgeräte zwei konkurrierende Technologien für die Signalisierung von Voice (bzw. Fax)over IP:

• Die 1996 verabschiedete H.323-Protokollfamilie [16] ist ein Dachstandard für die paket-basierte Multimediakommunikation, der eine Reihe weiterer Standards integriert. Für dieVermittlung von Telefon- und Faxverbindungen baut H.323 unter anderem auf Q.931 auf,einem Signalisierungsprotokoll im ISDN. Ein Beispiel für ein H.323-Endgerät ist in Ab-bildung 2.3 zu sehen. Das Diagramm zeigt die Schnittstellen für die Benutzereinrichtun-gen, Codecs, Telematiksteuerung, H.225.0-Protokollschicht, Systemsteuerung sowie dieSchnittstelle zum Paketnetz. Jedes H.323-Gerät beinhaltet zumindest Systemsteuerung,H.225.0-Protokoll, Netzwerkinterface sowie Audio Codecs. Alle anderen Komponentensind optional. H.225.0 spezifiziert die Nutzung von Audio, Video, Daten und Steuerunginklusive Kodierung, sowie Transport und die Ansteuerung von Gateways.

• Als Alternative startete 1999 das Session Initiation Protocol (SIP) und stellt inzwi-schen eine ernsthafte Konkurrenz zu H.323 dar. Es vermeidet die Komplexität der ISDN-basierten Protolldetails und wurde vom IETF so spezifiziert, dass es anderen Internet-Protokollen sehr viel ähnlicher ist. Jegliche Information wird beispielsweise im Klartextübermittelt und viele nicht unbedingt benötigten Details aus der traditionellen Telefonietauchen bei SIP gar nicht auf. Andererseits ist SIP einfach erweiterbar und wird inzwi-schen von allen namhaften Herstellern unterstützt. Für die Steuerung von Verbindungenkennt SIP sechs Anforderungen (Requests):

1. INVITE – hiermit wird die Gegenstelle „angerufen“

2. ACK – bestätigt die Verbindung

3. BYE – signalisiert dem Partner das Ende der Verbindung

4. CANCEL – bewirkt einen Abbruch

5. OPTIONS – übermittelt zusätzliche Informationen

6. REGISTER – meldet Standortinformationen an einen Server

Signalisierungsfunktionen werden nicht nur von Endgeräten (Telefone, Faxgeräte, etc.) be-nötigt, sie sind auch Bestandteil von Gateways, die eine Umsetzung zwischen unterschiedlichenÜbertragungswegen realisieren. In diesem Bereich gibt es weitere Verfahren zur Steuerung vonVerbindungen, allen voran das Media Gateway Control Protocol (MGCP). Auch diese Proto-kolle werden zur Signalisierung von T.38-Verbindungen benutzt, allerdings nur in Gateways –deshalb wird hier nicht weiter darauf eingegangen.


Abbildung 2.3: Beispielarchitektur eines H.323-Endgeräts (nach [16]). H.323 umfasstals „Dachstandard“ eine Reihe weiterer Standards. Die Gestaltung der Hardware- undBenutzerschnittstellen ist nicht vorgegeben.

G.711 Fax Pass-Through

Nachdem die Faxübertragung im Telefonnetz wie normale Sprachkommunikation abgewickeltwird, ist es naheliegend, auch im IP-Netz gleiche Mechanismen zu verwenden. Dies bedeutet,dass die für Fax benötigten analogen Informationen (Töne und Modemsignale) mit denselbenMitteln wie VoIP-Daten kodiert und unter Nutzung des bei VoIP verwendeten Real-Time-Protocol (RTP) übermittelt werden. Dies funktioniert jedoch nur unter bestimmten Bedingun-gen und auch da nur begrenzt (siehe unten). Folgende Voraussetzungen müssen zwingend erfülltsein:

• Die Daten müssen ohne zusätzliche Komprimierung im PCM-Format (G.711) übermitteltwerden. Häufig wird erst während einer Sprachverbindung durch Erkennung eines Ant-worttons oder von V.21-Daten festgestellt, dass eine Faxübertragung vorliegt. In diesemFalle muss innerhalb der Verbindung mit geeigneten Mitteln vom bisherigen Codec aufG.711 „umverhandelt“ werden.

• Voice activity detection (VAD) – also die Erkennung von Sprechpausen und deren ver-einfachte Signalisierung – darf nicht aktiv sein, da es bei diesem Verfahren am Anfangund Ende aktiver Abschnitte zu Informationsverlusten kommt (die bei Sprache wenigerAuswirkung haben als bei Datenübertragung).

• Comfort noise generation (CNG) sollte nicht verwendet werden. Bei dieser Option werdenSprechpausen durch leichtes Rauschen dargestellt, da absolute Stille von Telefonteilneh-mern als „tote Leitung“ wahrgenommen wird. Solches Rauschen kann beim Faxempfängerbei der Erkennung von Phasen ohne Informationsübermittlung zu Problemen führen.


• Echounterdrückung muss ebenfalls deaktiviert sein, da sie sich negativ auf die Faxüber-tragung auswirkt (vgl. [17] Seite 1-6).

Die hier beschriebene Pass-Through Methode wird unter anderem auch „bypass mode“ oder„clear channel fax“ genannt.

IP-Fax nach T.38-Standard

Um eine Echtzeit-IP-Faxübertragung auch von längeren Dokumenten und unter nicht optimalenBedingungen zu ermöglichen, wurde die ITU-T T.38-Spezifikation [11] erarbeitet. Sie zeichnetsich unter anderem durch folgende Eigenschaften aus:

• Alle für das T.30-Protokoll relevanten Ereignisse und Informationen werden über IP-Protokolle übermittelt, was die Informationsmenge gegenüber sprachkodierten Analogsi-gnalen drastisch reduziert. Dies ermöglicht die Nutzung von Redundanz-basierten Feh-lerkorrekturverfahren, um Paketverluste zu überstehen.

• Die Entkopplung der Übertragungsarten ermöglicht eine Aufrechterhaltung der Taktsyn-chronisation mit dem Telefonnetz

• Neben der Anbindung herkömmlicher Faxgeräte an Gateways mit analogem oder ISDN-Anschluss sind auch Endgeräte vorgesehen, die direkt mit den IP-kodierten Informationenarbeiten können (sogenannte „Internet-aware fax devices“ – IAF) und somit eine Konver-tierstufe vermeiden. Wenn zwei Geräte dieser Art aufeinandertreffen, können sie besonderseinfach rein digital miteinander kommunizieren, was einen sehr viel höheren Durchsatzermöglicht (mehr dazu weiter unten).

2.3.3 T.38 Realtime Fax over IP im Detail

Dieser Abschnitt beschreibt die wichtigsten Eigenschaften von T.38, das im Rahmen dieserArbeit soweit implementiert wird, dass ein Versand an gängige Gegenstellen (meist Gateways,die den Übergang zur herkömmlichen Faxübertragung realisieren) möglich ist. Zu diesem Zweckmüssen nicht alle möglichen Optionen unterstützt werden – eine Gewichtung der verschiedenenin T.38 angebotenen Alternativen erfolgt deshalb auch im folgenden Text.

Überblick

Entstehungsgeschichte und Bedeutung des T.38-Protokolls wurden Anfang 2004 von James P.Rafferty in einem Artikel der Zeitschrift „Internet Telephony“ übersichtlich beschrieben [19].Rafferty war selbst maßgeblich an der Ausarbeitung dieses Standards beteiligt11. Im folgendenAbsatz wird aus diesem Text der einführende Teil gekürzt zitiert:12

11Der Autor der vorliegenden Diplomarbeit hatte anlässlich der Faxdirection Conference in San Diegoin den Jahren 1999 und 2000 Gelegenheit zu ausführlichen Gesprächen mit James P. Rafferty undanderen Spezialisten aus dem Bereich der Faxstandardisierung.

12Übersetzung durch den Autor der vorliegenden Arbeit


„Mitte der 90er Jahre erkannten sowohl die Faxexperten der ITU als auch die E-Mail-Spezialisten der IETF angesichts der aufkommenden VoIP-Technologien einen Bedarf für eineStandardisierung von Fax-over-IP (FoIP). Deshalb wurde eine Zusammenarbeit vereinbart mitdem Ziel, geeignete Standards zu erarbeiten. Als Ergebnis entstanden zwei grundverschiedeneAusprägungen: die IETF konzentrierte sich auf die Erweiterung von E-Mail um effiziente Fax-übertragung (RFC 2301-2306), die von der ITU als T.37 verabschiedet wurde, worin direkt aufdie entsprechenden IETF-Dokumente verwiesen wird. Parallel dazu entwickelte die ITU-T mitT.38 einen Standard für die Echtzeit-Faxkommunikation. Im Zuge der Verbreitung von VoIPstellte sich T.38 als Schlüsseltechnologie für die Faxübertragung in IP-Netzwerken heraus.“

Anwendungsbereich von T.38

Abbildung 2.4 zeigt Einrichtungen, die das T.38-Protokoll nutzen. Standard-Faxgeräte oderFaxserver müssen über Analog- oder ISDN-Schnittstellen an Gateways betrieben werden, indenen die Umwandlung zwischen Faxsignalen und IP-Paketen erfolgt. Faxgeräte, die direktT.38 beherrschen (IAF-devices) kommunizieren ohne die Zwischenschaltung von Gateways.

Abbildung 2.4: Arten von T.38-Faxeinrichtungen: Standard-Faxgeräte in Verbindung mitGateways sowie internetfähige Faxmaschinen.

Bei der für die Faxübertragung genutzten IP-Strecke kann es sich sowohl um das Internet, alsauch um ein lokales Netzwerk handeln, wobei in letzterem Fall die technischen Randbedingungen(Jitter, Paketverlust) meist wesentlich günstiger sind.

Aufbau der T.38-Spezifikation

Der einführende Teil (Abschnitt 1-5) beinhaltet Verweise auf verwendete Standards, Defini-tionen und Abkürzungen sowie eine kurze Erläuterung des Anwendungsbereichs von T.38. ImAbschnitt 6 werden Details der Kommunikation beschrieben. Abschnitt 7 definiert das Internet


Facsimile Transfer (IFT) Protokoll. Das Management der Übertragungsrate wird im Abschnitt8 festgelegt. Abschnitt 9 beschreibt die Nutzung von UDP als Transport für das IFT-Protokoll.Hierbei werden die Pakete im sogenannten UDP Transport Layer (UDPTL) verpackt. Erst spä-ter wurde als Option die Möglichkeit, TCP statt UDP zu verwenden, eingefügt. Im Abschnitt 10wird der V.8-basierte Nachrichtenfluss für die Aushandlung von V.34-basierter Faxübertragungdokumentiert.

Wichtige Informationen in den darauf folgenden Anhängen sind unter anderem:

• ASN.113 Notation für T.38 in zwei Varianten (1998 bzw. 2002)

• Verwendung von H.323 für den Verbindungsaufbau (call establishment)

• Beschreibung der optionalen „Forward Error Correction“ (FEC) für UDPTL

• SIP/SDP basierte Prozeduren für den Verbindungsaufbau

• Signalisierung nach H.248.1 Standard

• Verschiedene Ablaufbeispiele sowie Implementationsrichtlinien

Kommunikation zwischen T.38-fähigen Geräten

Als Basis für den Nachrichtenaustausch zwischen beteiligten Einrichtungen kann sowohl TCPals auch UDP verwendet werden. Das T.38-Protokoll wird normalerweise zur Kommunikationzwischen Gateways verwendet. In diesem Falle wird generell UDP benutzt, da das schnelle Aus-liefern der Daten auf der Empfängerseite – ähnlich wie bei VoIP – wichtiger ist als die fehlerfreieÜbertragung des Datenstroms. TCP könnte im Fehlerfalle zu große Verzögerungen verursachen.Der beim Einsatz von UDP mögliche Paketverlust kann durch die in T.38 vorgesehenen Fehler-korrekturverfahren ausgeglichen werden.

Wenn zwei T.38-fähige Endgeräte ohne Einschaltung von Gateways direkt über IP unddamit ohne Zwischenschaltung von Modemverfahren miteinander kommunizieren, ist TCP diebessere Wahl. Es garantiert die fehlerfreie Übermittlung, so dass keine Daten mehrfach (redun-dant) gesendet werden müssen.

IFT Protokoll

Die Kommunikation zwischen T.38-Gegenstellen erfolgt über das Internet-Facsimile-Transfer(IFT) Protokoll, das in Anhang A des T.38-Standards in ASN.1-Form beschrieben ist. Proto-kolleinheiten werden als Internet-Facsimile-Protocol (IFP) Pakete gemäß dieser Spezifikationverpackt14.

13Abstract Syntax Notation One (ASN.1) ist ein OSI-Standard zur formalen Beschreibung von Daten-strukturen in Form einer Grammatik. Diese kann von Computerprogrammen direkt zur Erzeugung vonFunktionen zur Kodierung und Dekodierung genutzt werden. Eine umfangreiche Einführung in ASN.1(und OSI-Standards allgemein) bietet Marshall T. Rose in [20].

14ASN.1 beschreibt die Repräsentation der Daten getrennt von der Syntax. Im Falle von T.38 wird dieBASIC-ALIGNED Version der Packet Encoding Rules (PER) genutzt – nähere Informationen hierzufinden sich in der ITU-T Empfehlung X.691 [21].


Abhängig vom verwendeten Protokoll sind die übertragenen Daten wie folgt strukturiert:

• bei TCP: IP Header, TCP Header, TPKT (Transport Protocol Data Unit Packet) Header,IFP Paket

• bei UDPTL: IP Header, UDP Header, UDPTL Header, IFP Paket + Redundanz/ForwardError Correction (FEC)

• bei RTP: IP Header, UDP Header, RTP Header, IFP Paket + Redundanz/Forward ErrorCorrection (FEC)

Als Beispiel zeigt Abbildung 2.5 die Verpackung eines IFP-Pakets innerhalb eines UDPTL-Pakets. Bei Verwendung von TCP bzw. RTP wird dem IFP-Paket anstelle des UDPTL-Headersein TPKT- bzw. ein RTP-Header vorangestellt.

Abbildung 2.5: UDPTL Paketstruktur – jeder Layer transportiert die Daten der darun-terliegenden Schicht und fügt seinen eigenen Header hinzu (aus [11]).

IFP Paketformat

Jedes Paket beginnt mit einer Angabe des Nachrichtentyps (TYPE). Dieser beschreibt auszufüh-rende Funktionen bzw. Daten, die optional im Paket enthalten sind. Folgende Nachrichtentypensind definiert:

• T30_INDICATOR – dient zur Übermittlung von Ereignissen im Rahmen des Ablaufseiner Faxübertragung; dazu gehören zum Beispiel:

– Beginn eines Tonsignals (CNG oder CED)

– Start des V.21-Vorspanns (Preamble)

– Aktivierung einer bestimmten Modulationsart

– „no signal“ – also Abschalten des Sendeteils

• T30_DATA – transportiert T.30-Protokollblöcke oder Dokumentdaten. Zusätzlich wirddie zu benutzende Modulationsart spezifiziert:


– V.21 Channel 2

– V.27 ter 2400

– V.29 9600

– u.s.w.

Desweiteren können im DATA-Element eines IFP-Pakets unter anderem folgende Datenar-ten bzw. Ereignisse angegeben werden:

• HDLC Data – die im Paket enthaltenen Daten sind Bestandteil eines HDLC-Frames.

• HDLC-FCS-OK – der aktuelle HDLC-Frame soll mit einer korrekten „Prüfsumme“(FCS=Frame Check Sequence) beendet werden.

• HDLC-Sig-End – nach einer HDLC-basierten Übertragung ist kein weiteres Sendesi-gnal mehr vorhanden (HDLC-FCS-OK und HDLC-Sig-End können auch gemeinsam alsHDLC-FCS-OK-Sig-End übermittelt werden).

• T.4-Non-ECM – transportiert Faxdaten ohne Nutzung des Error Correction Mode (ImFalle von ECM werden die einzelnen Blöcke als „HDLC Data“ übermittelt).

• T.4-Non-ECM-Sig-End – signalisiert das Ende der aktuellen Seitenübertragung.

2.3.4 Quality of Service (QoS) Aspekte bei Fax over IP

Ähnlich wie bei VoIP sind auch bei FoIP Quality-of-Service Anforderungen zu berücksichtigen.Im Gegensatz zur Sprachkommunikation sind diese teilweise geringer – insbesondere toleriertdas T.30-Faxprotokoll wesentlich größere Verzögerungen als ein durchschnittlicher Telefonbe-nutzer. Einige FoIP-QoS Aspekte sind in [24] beschrieben, worauf im Folgenden teilweise Bezuggenommen wird.

Zeitverhalten

Ein generelles Problem paketorientierter Übertragung ist das ungenaue Timing von Nachrich-ten, das durch nicht kalkulierbare Verzögerungen im Netzwerk verursacht wird. Das für Faxverwendete T.30-Protokoll ist an manchen Stellen empfindlich für Abweichungen im Zeitverhal-ten. Beim Design eines FoIP-Protokolls muss also darauf geachtet werden, diese Probleme zuvermeiden. Verursacht werden solche Verzögerungen zum einen durch das Verhalten der betei-ligten Netzwerkkomponenten und zum anderen durch die Verarbeitungsdauer der übermitteltenInformationen. Letzteres spielt bei VoIP eine größere Rolle, insbesondere wenn stärker kompri-mierende Kodierungsverfahren genutzt werden.

Jitter

Übertragungsverzögerungen variieren ständig, so dass Pakete mit ungleichmäßigen Abständeneintreffen. Um diese Pakete dennoch kontinuierlich dem Empfänger zu präsentieren, werden


sogenannte „Jitter-Buffer“ benutzt. Dabei wird eine gewisse Verzögerung bewusst in Kauf ge-nommen, um jederzeit über Nutzdaten zu verfügen. Wenn diese Verzögerung zu kurz gewähltwird, kann es passieren, dass trotzdem Lücken auftreten. Zu lange Verzögerung kann das Ge-samtverhalten des Protokolls so weit stören, dass eine erfolgreiche Übertragung gefährdet ist.Die Größe des Jitter-Buffers und damit die aktuell auftretende Verzögerung können auch dy-namisch adaptiert werden.

Ausgleich von Paketverlusten

IP-Pakete können während der Übertragung aus unterschiedlichen Gründen verloren gehen15.Um Paketverluste zu vermeiden, gibt es zwei unterschiedliche Ansätze:

• Redundante Übermittlung von Informationen; dabei enthält ein Paket auch Daten vonbenachbarten Paketen, so dass beim Verlust eines Paketes eine Rekonstruktion der ver-loren gegangenen Daten möglich ist. Dieses Verfahren wird zum Beispiel bei T.38 inVerbindung mit UDP verwendet.

• Nutzung von TCP; dieses Protokoll bringt ein eigenes Fehlerkorrekturverfahren mit sich,allerdings zu Lasten des Echtzeitverhaltens. Es wird deshalb nur verwendet, wenn aufbeiden Seiten IP-fähige Geräte beteiligt sind, die sich nicht an das strenge Timing desT.30-Protokolls halten müssen.

Weitere QoS-Aspekte bei FoIP

Neben den bisher beschrieben QoS-Themen, die in ähnlicher Weise bei VoIP zum Tragen kom-men, gibt es einige faxspezifische Punkte, die dem QoS-Bereich zugeordnet werden können. Vonbesonderer Bedeutung ist vor allem die Frage der Datenflusskontrolle. Faxdaten dürfen nur soschnell gesendet werden, wie sie auf der Empfangsseite verarbeitet werden können, ohne dassirgendwelche Zwischenpuffer überlaufen. Insbesondere betrifft dies die Nutzung von T.38 undFax Pass-Through. Bei Store-and-Forward Verfahren treten solche Probleme nicht auf, da dieÜbermittlung nicht in Echtzeit erfolgt.

Wenn auf beiden Seiten Gateways eingesetzt werden, die zwischen herkömmlichen Faxge-räten vermitteln, sollte dieses Problem zumindest bei der Nutzung von T.38 nicht auftreten,da das sendende Gateway keine andere Chance hat als die Daten in der Geschwindigkeit zuübermitteln, in der sie vom sendenden Faxgerät geliefert werden16.

Komplizierter wird es, wenn es sich beim Absender um ein Internet-aware-Faxdevice (IAF)handelt, das in der Lage ist, die Daten schneller zu liefern, als sie auf der Empfangsseite erwartetwerden. Ein solches Gerät muss also darauf achten, dass es mit der Datenrate sendet, die auchbei der Übermittlung vom entfernten Gateway an das empfangende Faxgerät verwendet wird.Da dieses Timing nur mit begrenzter Genauigkeit einzuhalten ist (z.B. wegen Abweichungenin Taktgeneratoren), sollten die Daten eher minimal schneller gesendet werden als nötig. Es

15Eine Einführung in die Eigenschaften von IP-Protokollen würde den Rahmen dieser Arbeit sprengen.Hierzu existiert jedoch eine große Auswahl an weiterführender Literatur.

16Hierbei wird vorausgesetzt, dass die im Gateway verwendete Abtastrate (meist 8000 Samp-les/Sekunde) hinreichend genau eingehalten wird – eine starre Taktsynchronisierung mit den vom Emp-fangsgateway ausgelieferten Daten ist nicht möglich.


kann schließlich nicht nicht davon ausgegangen werden, dass Gateways in Empfangsrichtungin der Lage sind, beim Pufferunterlauf an den passenden Stellen Fülldaten einzufügen, damitdie Übertragung nicht abreißt. Dazu müsste das Gateway den Inhalt der komprimierten Do-kumentdaten ständig analysieren, um die Grenze zwischen Pixelzeilen zu ermitteln, da nur andieser Stelle zusätzliche Füllbits gesendet werden dürfen. Wenn jedoch die Daten schneller alsbenötigt gesendet werden, entsteht wiederum die Gefahr des Pufferüberlaufs. Diese Problematikist nicht einfach zu lösen, sie birgt immer ein Risiko von Inkompatibilitäten mit bestimmtenGegenstellen. Durch umfangreiche Tests mit möglichst vielen Geräten und Optimierung derStrategie sollte versucht werden, eine größtmögliche Interoperabilität zu erzielen.Zusammengefasst sind folgende Situationen zu betrachten:

• Gateway ↔ Gateway – hier sollte es bei hinreichend genauen Taktgeneratoren kei-ne Timing-Probleme geben. Kleine Abweichungen können durch einen Datenvorlauf imJitterbuffer der Empfangsseite ausgeglichen werden.

• Gateway → IAF – ist problemlos, da das Empfangsgerät ohne Modemstrecke arbeitetund deshalb keine Anforderungen hinsichtlich der Datenrate hat.

• IAF → Gateway – in diesem Falle sollte das IAF die Daten mit einer Rate senden,die minimal über der Übertragungsrate an das empfangende Faxgerät liegt. Falls dasEmpfangsgerät die Daten nicht schnell genug verarbeiten kann, sieht zumindest der Feh-lerkorrekturmodus (ECM) eine Flusskontrolle vor. Der Empfänger kann über die Meldung„Receive not Ready“ (RNR) signalisieren, dass der aktuelle Abschnitt erfolgreich empfan-gen, jedoch noch nicht vollständig verarbeitet (z.B. ausgedruckt) wurde. Das Sendegerätfragt dann solange mit dem RNR-Kommando nach, bis die Empfangsseite signalisiert,dass sie für weitere Daten bereit ist. Ohne diesen nur bei ECM vorhandenen Mechanis-mus gibt es keine Möglichkeit einer Flusskontrolle. In diesem Falle muss das Sendegerätdarauf vertrauen, dass im empfangenden Gateway ein ausreichend großer Pufferspeicherzur Verfügung steht, um die geringfügig höhere Datenrate des Senders verarbeiten zukönnen.

• IAF ↔ IAF – In dieser Konstellation sollte TCP als Transportprotokoll genutzt werden,da dieses über erprobte Mechanismen zur Flusskontrolle verfügt.


Kapitel 3. Auswahl des zu implementierenden Verfahrens 25

Kapitel 3

Auswahl des zu implementierendenVerfahrens

In diesem Kapitel werden zunächst die Anforderungen an die zu implementierende Lösungbeschrieben. Um unter den verschiedenen Technologien für Fax over IP diejenige auszuwählen,die diese Vorgaben am besten erfüllt, werden folgende Fragen betrachtet:

• Welche Techniken unterstützen gängige VoIP-Gateways

• Welche Verfahren nutzen Mitbewerber

• Welche Vor- und Nachteile kennzeichnen die verfügbaren FoIP-Varianten

Anschließend wird eine Methode ausgewählt und festgelegt, in welcher Variante bzw. mitwelchen Optionen sie implementiert werden soll.

3.1 Zielvorgaben des AuftraggebersIm Rahmen dieser Arbeit sollen im Markt eingeführte Unified-Messaging-Controller, die bisherausschließlich über ISDN-Schnittstellen kommunizieren, dafür vorbereitet werden, die Faxkom-munikation auch in IP-basierter Umgebung ohne ISDN-Anschluss abzuwickeln. WesentlicheAnforderungen hierbei sind:

• Kompatibilität zu weit verbreiteten Einrichtungen muss gewährleistet sein.

• Im Vergleich zu Mitbewerbern dürfen keine nennenswerten Einschränkungen im geplantenEinsatzbereich offen bleiben.

• Das auszuwählende Verfahren soll auf internationalen Standards basieren (sofern sichdiese in der Praxis auch durchgesetzt haben).

• Die Ansteuerung der Controller durch die Serverkomponenten darf sich nicht ändern.

• Die zu entwickelnde Software soll sich möglichst gut in die bisherige Architektur derController integrieren und damit unter anderem eine Pflege durch Entwickler, die mit dervorhandenen Lösung vertraut sind, erleichtern.

26 3.2. Fax-Eigenschaften gängiger Gateways

3.2 Fax-Eigenschaften gängiger Gateways

Als Gegenstellen für die IP-Faxkommunikation fungieren normalerweise VoIP-Gateways mitFaxfunktion. Nur in seltenen Fällen trifft man auf IP-fähige Fax-Endgeräte. Für die Auswahldes zu implementierenden Verfahrens ist es also wichtig, die von häufig eingesetzten Gatewaysunterstützten Methoden zu kennen. Zu diesem Zweck wurden Geräte betrachtet, die – in Er-mangelung entsprechender Marktstudien – anhand von Erfahrungswerten des Auftraggebersals wichtig erachtet werden. Soweit vorhanden, wurden die Detaileigenschaften der Gatewaysanhand aktueller Administratorhandbücher ermittelt, ersatzweise wurden Datenblätter zu Ra-te gezogen. Weitere Details (zum Beispiel die in der Signalisierung übermittelte Variante desT.38-Protokolls) wurden bei den für Testzwecke vorhandenen Geräten durch Mitschnitt undanschließende Analyse der IP-Kommunikation ermittelt1.

Fax-Eigenschaften untersuchter GatewaysHersteller/Modell T.37 T.38 Pass-ThroughCisco/div. Router (z.B. 2801) ja ja (Version 1998) jaInnovaphone/ip400, ip800, ip3000 nein ja (Version 1998) neinInalp bzw. Patton/1200, 1400 nein ja (Version 1998) jaMediatrix/2102 nein ja (Version 1998) jaAlcatel/OmniPCX nein ja2 neinAudioCodes/MP-102 nein ja nein3Com/VCX Gateways nein ja jaSiemens/Hipath RG 2500 nein ja nein

Tabelle 3.1: Faxeigenschaften gängiger VoIP-Gateways

Tabelle 3.1 zeigt das Ergebnis dieser Untersuchung. Zu beachten ist, dass alle Verfahren, dieFaxdaten mit G.711-Kodierung (also wie Sprachdaten) übertragen, unter Pass-Through zusam-mengefasst wurden, auch wenn diese Methode von den Herstellern unterschiedlich bezeichnetwird.

3.3 Betrachtung des Mitbewerbs

Die Feststellung, welche Verfahren von Mitbewerbslösungen unterstützt werden, gestaltet sichschwierig, da die meisten Hersteller FoIP erst seit kurzer Zeit anbieten und kaum Details dar-über veröffentlichen. So war bislang nicht herauszufinden, welche FoIP-Varianten von CAEund Topcall unterstützt werden. Ein Großteil der restlichen Mitbewerber nutzt – wie Ferra-ri electronic bisher auch – eine Middleware für die Realisierung von VoIP und FoIP. Dabeihandelt es sich um ein Produkt der Firma TE-SYSTEMS GmbH namens „XCAPI“. Diese Soft-

1Hierfür wurde das Open-Source-Tool „Ethereal“ benutzt, das neben vielen anderen Protokollen auchdie T.38-Kommunikation dekodieren und übersichtlich darstellen kann.

2Derzeit (Mai 2005) noch nicht freigegeben.


ware verhält sich Anwendungen gegenüber wie eine gängige ISDN-Karte3. Unter der Adres-se http://www.xcapi.de/partner/index.php finden sich (Stand 5.5.2005) neben der Ferrarielectronic AG folgende Firmen, die die XCAPI im Rahmen eines Partnerprogramms einsetzen:Cycos AG, Servonic, Speech Design und Tobit Software. Diese bilden zusammen mit den beidenzuvor genannten Firmen die wichtigsten Mitbewerber der Ferrari electronic AG (vgl. hierzu dieDiplomarbeit „Konkurrenzanalyse als Teil einer Marketingkonzeption am Beispiel der Ferrarielectronic“ von Jörg Schmohl [23]).

Die verbreitete Nutzung der XCAPI vereinheitlicht die Eigenschaften der von den aufgeführ-ten Firmen angebotenen Lösungen. Für den Faxbetrieb nutzt die XCAPI das T.38-Protokoll,alternativ kann als separat zu lizensierende Option „Softfax“ verwendet werden. Dabei handeltes sich um eine Variante, die den Fax Pass-Through-Verfahren zuzurechnen ist.

3.4 Beurteilung der möglichen Alternativen

Als letzter Schritt zur Entscheidungsfindung werden im Folgenden Vor- und Nachteile der mög-lichen Alternativen für FoIP betrachtet und gewichtet. Die Bewertungen erfolgen aus der Per-spektive des Auftraggebers, um anschließend eine passende Entscheidung fällen zu können.

T.37 Fax Store-and-Forward

Vorteile Sichere Übertragung auch bei ungünstigen IP-Verbindungen; Absender wird Faxauch los, wenn Empfänger gerade besetzt ist; wenig Probleme mit Firewalls durchNutzung von SMTP

Nachteile Kein echtes „Faxerlebnis“, da die Übergabe und Auslieferung getrennt sind; kei-ne unmittelbare Information über nicht erreichbare Gegenstellen; wird nur vonwenigen Gateways unterstützt

Bewertung Die Bedeutung von T.37 ist in der Praxis sehr gering (vgl. Nölle [18], Seite 176).Obwohl der store-and-forward Betrieb auf Basis erprobter Protokolle einen siche-ren Transport unter nahezu beliebigen Bedingungen verspricht, scheint die Ab-weichung vom normalen Faxablauf die potenziellen Anwender abzuschrecken. DieGewissheit, dass ein positiv quittiertes Fax zeitgleich beim Empfänger vorliegt,ist ein wesentliches Merkmal des Faxdienstes. Der Verzicht auf eine Verhandlungder Betriebsart im Simple Mode schließt zudem unerwünschten Informationsver-lust durch Umkodierung nicht immer aus - auch dies widerspricht der gängigenErwartungshaltung bei der Faxkommunikation.

G.711 Fax Pass-Through

Vorteile Geringerer Aufwand in Gateways; einfachere Integration in VoIP-Konfiguratio-nen

3ISDN-Karten werden in der Regel über die CAPI-Applikationsschnittstelle angesteuert.

http://www.xcapi.de/partner/index.php

28 3.4. Beurteilung der möglichen Alternativen

Nachteile Qualitätsprobleme bei längerer Übertragungsdauer; Umverhandlung des zu be-nutzenden Codecs nach Erkennung von Faxübertragung nötig (wird nicht vonallen Geräten unterstützt)

Bewertung Selbst bei Einhaltung der in Kapitel 2 für den Betrieb von Fax Pass-Throughgenannten Vorgaben können längere Faxdokumente über dieses Verfahren nichtzuverlässig übertragen werden (vgl. Nölle [18] Seite 176). Ein wesentliches Pro-blem ist die fehlende Möglichkeit der Taktsynchronisationen zwischen Telefonie-und IP-Strecke. Während bei reinen Telefonverbindungen durch Taktübermitt-lung bzw. -regenerierung grundsätzlich bitsynchron übertragen wird, geht dieseenge Kopplung beim Übergang in Gateways verloren. Typischerweise ist in die-sem Szenario ein analoges Faxgerät an einem analogen Terminaladapter (ATA)angeschlossen, wo das Signal mit 8.000 Samples pro Sekunde abgetastet und inG.711-Format umgewandelt wird. Diese Abtastung wird über einen lokalen Takt-generator gesteuert, der nicht mit dem ISDN-Takt auf einem später folgendenÜbertragungsabschnitt synchronisiert ist. Im Verlauf einer längeren Faxübertra-gung können diese Takte so weit auseinanderlaufen („slip“), dass dazwischen lie-gende (Jitter-)buffer über- oder unterlaufen. In beiden Fällen gibt es einen zeitli-chen Sprung im Analogsignal – dasselbe passiert auch beim Verlust von Paketen.Bei Sprachübertragung ist dies oft tolerierbar – die für Faxinhalte verwendetenModulationsverfahren sind hingegen sehr empfindlich gegenüber solchen Sprün-gen. In der Regel reißt dabei der Datenfluss beim Empfänger ab und die aktuelleSeite wird negativ quittiert, was normalerweise zum Abbruch der Faxübertragungführt.

T.38 Realtime Fax-over-IP

Vorteile Echtzeitfax bei geringer Bandbreite; weit verbreitet; funktioniert auch bei langenFaxdokumenten

Nachteile Beim verbreiteten UDPTL-Transport gibt es keine Flusskontrolle

Bewertung Das T.38-Protokoll stellt sicher die wichtigste FoIP-Variante dar. Es wird durch-wegs von Gateways unterstützt und auch der Mitbewerb des Auftraggebers setzt(soweit bekannt) auf T.38. Die Echtzeit-Kommunikation zwischen den beteilig-ten Faxgeräten vermittelt den Anwendern das vertraute „Faxerlebnis“ und bietetdie gewohnte Aushandlung der Übertragungsoptionen. Auch längere Dokumentekönnen übermittelt werden und die genutzte Bandbreite erlaubt den Einsatz auchbei schmalbandigen Verbindungen. Lediglich die Steuerung der Sendedatenratekann beim Faxversand von reinen IP-Faxeinrichtungen an Gateways etwas kri-tisch werden, da hier keine feste Taktsynchronisation vorliegt. In diesem Punktmuss eine Implementation sehr sorgfältig konzipiert und mit Gegenstellen erprobtwerden.


3.5 Designentscheidungen

In diesem Abschnitt wird das zu realisierende Verfahren festgelegt und beschrieben, welche derdabei wählbaren Varianten und Optionen implementiert werden sollen.

Auswahl des zu benutzenden Verfahrens

Nach Abwägung der Vor- und Nachteile der verschiedenen Möglichkeiten wurde für Fax-over-IPdas T.38-Protokoll gewählt. Es ist am weitesten verbreitet und verspricht eine bestmöglicheFaxübertragung auch unter nicht optimalen Bedingungen (z.B. limitierte Bandbreite, Paket-verluste). Auch längere Faxdokumente bereiten im Gegensatz zu Fax Pass-Through keine prin-zipbedingten Probleme. Bei letzterem Verfahren kann es durch auseinanderlaufende Takte zusolchen Schwierigkeien kommen. Längerfristig sollte aber die Marktentwicklung im Auge behal-ten werden, um zu entscheiden, ob T.38 ausreicht oder zusätzlich in einem späteren Schritt auchFax Pass-Through realisiert werden muss, damit FoIP auch in nicht T.38-fähiger Infrastruktur– allerdings mit den genannten Einschränkungen – einsetzbar ist.

Für T.37 ist hingegen kein Bedarf abzusehen. Weder der Mitbewerb noch ein Großteilder Gatewayhersteller unterstützt dieses Verfahren. Die Abweichung vom Faxablauf durch dasStore-and-Forward-Prinzip wird nicht als Faxersatz akzeptiert. Wenn die typischen Faxeigen-schaften (Aushandlung von Optionen, Echtzeitübermittlung, unmittelbare Empfangsbestäti-gung) keine wichtige Rolle spielen, können Dokumente problemlos per E-Mail versandt werden.Eine Technik wie T.37, die genau zwischen diesen beiden Varianten liegt, hat es schwer, sichals weitere Alternative zu etablieren.

Als Signalisierungsverfahren wird das Session Initiation Protocol (SIP) benutzt – dieses wirdvom Auftraggeber zur Verfügung gestellt.

Umfang der Implementation

Die im Rahmen dieser Arbeit entstehende T.38-Implementation umfasst die Faxkommunikationmit Gateways als Gegenstellen. Aufbauend darauf kann nach Beendigung der Diplomarbeit ineinem Nachfolgeprojekt der optimierte Austausch mit reinen T.38-Faxeinrichtungen realisiertwerden. Die Priorität hierfür ist allerdings nicht sehr hoch, da solche Geräte bislang sehr geringverbreitet sind4.

Bei den Tests ist vor allem die Senderichtung zu betrachten, bei der der Einfluss durch dieImplementation sehr viel größer ist als beim Faxempfang, da das sendende Gerät den aktivenPart in der entscheidenden Phase B (siehe 2.2.1) darstellt.

Festlegung der Protokolloptionen

Von den verschiedenen in T.38 vorgesehenen Möglichkeiten werden folgende gewählt:

• T.38-Protokoll in der Version von 1998 (Die vollständige ASN.1-Beschreibung findet sichin Anhang B.1). Alle untersuchten Gateways und Gegenstellen halten sich an diese T.38-

4In der Untersuchung an 1000 Empfangsgeräten (siehe A.2) war keines dabei, das die Fähigkeit derdirekten T.38-Unterstützung signalisiert hat.

30 3.5. Designentscheidungen

Variante. Alternativ gibt es die Version von 2002, die als wesentliche Erweiterung die V.34-Modulation mit bis zu 33.600 bps enthält. Dieses Verfahren ist jedoch bei der installiertenFaxbasis nicht weit verbreitet (siehe Untersuchungsergebnisse im Anhang A.2), weshalbder wesentlich höhere Aufwand5 nicht gerechtfertigt ist.

• Für die Verpackung der IFP-Pakete wird der UDP-Transport-Layer (UDPTL) benutzt –dieses Verfahren wird von allen Gateways unterstützt. Im Gegensatz hierzu wird RTP,dessen Einsatzmöglichkeit erst später als Option hinzukam, in der Praxis nicht genutzt6.

• Fehlerkorrektur wird durch Wiederholung der letzten beiden Pakete realisiert, dieses Ver-fahren hat sich bei den Geräten, die überhaupt eine Fehlerkorrektur unterstützen, alsStandard durchgesetzt. Sie sollte durch entsprechende Einstellparameter aktivierbar bzw.deaktivierbar sein.

• Übertragungsraten bis 14.400 bps werden unterstützt (höhere Geschwindigkeiten wärennur mit der T.38 Version von 2002 möglich).

• Als Faxoptionen wird neben ECM (Error Correction Mode) auch die zweidimensionaleKomprimierung (MR, MMR) realisiert, da diese Verfahren weit verbreitet sind (sieheAnhang A.2) und eine deutliche Reduzierung der Übertragungsdauer ermöglichen.

Kompatibilitätsprüfung

Durch ausführliche Tests soll die Kompatibilität der Implementation mit folgenden beim Auf-traggeber vorhandenen Gateways verifiziert werden:

• Cisco Router 2801 mit IOS-Software Version 12.3(11)XL

• Mediatrix 2102 mit Firmware v4.5.7.50 SIP

• XCAPI Software-Gateway (optional)

• Innovaphone ip800 (optional)

Die letzten beiden Gegenstellen (XCAPI bzw. ip800) können nur getestet werden, wenn siein einer Variante mit SIP-Unterstützung rechtzeitig zur Verfügung stehen.

Als Ergebnis der Tests sollte festgestellt werden, ob die Übertragung von Faxdokumenten inähnlicher Geschwindigkeit und Qualität erfolgt wie unter herkömmlichen Bedingungen. Unteranderem muss der Prozentsatz an fehlerhaften Pixelzeilen bei den Testgegenstellen so geringsein, dass die Lesbarkeit nicht beeinträchtigt ist und die Seiten vom Empfänger positiv quittiertwerden. Sollten hierbei Probleme auftreten, ist zu klären, ob diese durch den Prüfling selbstoder durch Mängel an den am Test beteiligten Komponenten verursacht wurden.

5Zusätzlich zu V.34 müsste die Aushandlung der Übertragungsart gemäß V.8-Standard implementiertwerden.

6Dies konnte durch Messungen an verschiedenen gängigen Gateways ermittelt werden.

Kapitel 4. Entwurf und Realisierung 31

Kapitel 4

Entwurf und Realisierung

Dieses Kapitel beginnt mit der Beschreibung des Implementationsumfelds. Zunächst wird dieOfficeMaster Card-Familie kurz vorgestellt, die um Fax over IP erweitert werden soll. Nebendem grundlegenden Aufbau der Hardware wird die Struktur der vorhandenen Software (bzw.Firmware) beschrieben. Anschließend wird die geplante Einbindung von T.38 in diese Umgebungentworfen. Das Realisierungskonzept wird im Überblick beschrieben, auf besondere Problemeund deren Lösung wird dabei ausführlicher eingegangen.

4.1 Umfeld für die T.38-Implementation

Ausgangspunkt für das zu entwickelnde FoIP-Produkt ist ein bereits existierender Controller,dessen Hardware im Folgenden kurz eingeführt wird. Daran schließt sich eine Beschreibung dervorhandenen Software an.

4.1.1 OfficeMaster Card als Hardware Basis

Unter der Bezeichnung „OfficeMaster Card“ stellt die Ferrari electronic AG eine Familie von Uni-fied Messaging Controllern her. Diese werden eingesetzt, um in Verbindung mit entsprechendenServeranwendungen folgende Kommunikationsdienste zu realisieren:

• Faxversand und -empfang

• Festnetz-SMS

• Transport von Sprache für Anwendungen wie Voicemail (elektronischer Anrufbeantwor-ter), Softphones, Anrufverteilung (ACD – Automatic Call Distribution) und interaktiveSprachanwendungen (IVR – Interactive Voice Response)

Diese Controller wurden unter anderem mit dem Ziel einer möglichst großen Unabhängigkeitvon Bauteilelieferanten entwickelt. Alle Modemverfahren sind in Software realisiert und bei derProgrammierung wurde stets darauf geachtet, dass eine Übersetzung des Codes für nahezu

32 4.1. Umfeld für die T.38-Implementation

Abbildung 4.1: OfficeMaster Card mit einer S0-Schnittstelle und 2 Kanälen (aus [25])

beliebige Prozessortypen möglich ist. Dies garantiert eine möglichst lange Lebensdauer1 desentwickelten Produkts.

Tabelle 4.1 zeigt die derzeit existierenden Hardwarevarianten (Stand Mai 2005, weitereGerätetypen sind in Vorbereitung), die ein- und dieselbe Codebasis nutzen.

OfficeMaster Card ProduktvariantenBauart Prozessor ISDN-Interface NutzkanälePCI-Karte IBM PowerPC 405GP 1 S0 2Externe Box IBM PowerPC 405GP 1 S0 2PCI-Karte IBM PowerPC 405GP 4 S0 8Externe Box IBM PowerPC 405GP 4 S0 81 HE 19"-Einschub Intel Pentium IV 1 S2M 301 HE 19"-Einschub Intel Pentium IV 2 S2M 60

Tabelle 4.1: Übersicht über die OfficeMaster Card Gerätetypen

1In der Vergangenheit hat die Ferrari electronic AG mehrfach Produkte neu entwickeln müssen, daverwendete Hardwarekomponenten von den Herstellern abgekündigt wurden. Dies betraf unter anderemdiverse Rockwell-Modems sowie den AM29000-Prozessor.


Die PCI-Kartenversion nutzt als Schnittstelle zum PC einen weitverbreiteten LAN-Controller-Baustein, der von allen gängigen Betriebssystemen direkt unterstützt wird. Eineseparate Entwicklung und Pflege von Kernel-Mode-Drivern für unterschiedliche Plattformen istdeshalb nicht erforderlich. Abbildung 4.1 zeigt die PCI-Variante mit einer ISDN S0-Schnittstelle,über die parallel zwei beliebige Dienste genutzt werden können. In der Boxversion wird dieNetzwerkschnittstelle als 10/100 MBit LAN-Interface nach außen geführt, so dass die Box aufeinfache Weise ins Netzwerk integriert werden kann. In beiden Fällen erfolgt die Ansteuerungüber IP-Protokolle – für die Serversoftware ist es kein Unterschied, ob die Steckkarte oder dieBox angesprochen wird.

Für mehr als acht Kanäle reicht die Rechenleistung des PowerPC nicht aus. In diesemFalle wird eine passive PCI-Karte mit S2M-Schnittstelle(n) in einem Standard-PC im 19 Zoll-Einschubgehäuse verwendet. Die für die Intel-Plattform übersetzte Firmware wird beim Startdes Rechners von einer CDROM geladen – über die Netzwerkschnittstelle wird die Box genausowie die kleineren Varianten angesteuert.

4.1.2 Softwarekomponenten

Als Betriebssystemkern der OfficeMaster Card fungiert ein Linux Kernel in der Version 2.4 –die Umstellung auf 2.6 ist geplant. Das Laden der für die ISDN-Hardware benötigten Treibersowie der Softmodem-Module erfolgt in der Initialisierungsphase. Die verschiedenen Unified-Messaging-Prozesse werden als separate Linux-Programme bei Bedarf gestartet und beendensich am Ende eines Vorgangs. ISDN- und Faxprozesse sind von Vorläufern der OfficeMaster Cardübernommen und angepasst worden. Der bisher verwendete selbstentwickelte Betriebsystemkernwird in diesen Komponenten weiterhin eingesetzt, so dass diese oberhalb von Linux ein weiteres– allerdings sehr einfaches – Betriebssystem (den sogenannten Tasker) enthalten.

Embedded Operating System („Tasker“)

Der Tasker ist ein von der Ferrari electronic AG vor längerer Zeit entwickeltes einfaches Betriebs-system für eingebettete Systeme, das speziell für die Verwendung in Kommunikationsgerätenentworfen wurde. Derartige Umgebungen sind gekennzeichnet durch:

• Unterteilung in Funktionsebenen (Layers)

• Kommunikation zwischen den Layers durch einzelne Nachrichten

• Jeder Layer ist als Zustandsautomat aufgebaut

• Eintreffende Nachrichten sind Ereignisse für den Zustandsautomaten

• Jedes Ereignis wird komplett verarbeitet, dabei kann der Versand von Nachrichten anandere Ebenen sowie eine Zustandsänderung ausgelöst werden

• wegen der kurzen Verarbeitungsdauer eines einzelnen Ereignisses wird kein präemptivesMultitasking benötigt; es genügt, nach der Verarbeitung zum Scheduler zurückzukehren,der den anstehenden Nachrichtenfluss nutzt, um die betroffenen Layers nacheinanderaufzurufen


Der Tasker bietet alle Funktionen, um diesen Anforderungen gerecht zu werden. Dazu ge-hören vor allem Speicherverwaltung, Warteschlangen für Nachrichten, Timerverwaltung sowieTask-Scheduling.

Struktur der OfficeMaster Card Firmware

Den grundlegenden Aufbau einer Unified Messaging Lösung unter Nutzung der OfficeMasterCard zeigt Abbildung 4.2, in der auch die Firmwarestruktur des Controllers ausführlicher darge-stellt ist. Angesteuert wird der Controller durch Komponenten des OfficeMaster Unified Messa-ging Server, der sich in die vorhandene Infrastruktur (meist E-Mail- bzw. Groupware-Systeme)integriert. Die Kontrolle von Sende- und Empfangsvorgängen erfolgt über TCP/IP, wobei einServerprozess mit dem auf dem Controller laufenden Jobcontrol-Prozess kommuniziert. Parallelhierzu werden Nutzdaten – ähnlich wie bei VoIP – über separate Verbindungswege transportiert.

In Abbildung 4.2 ist bereits die geplante FoIP-Implementation angedeutet. Sie nutzt einenseparaten Jobcontrol-Prozess (jcsip), der gleichzeitig die Signalisierung über das Session-Initiation-Protocol (SIP) steuert2.

isdn fax sms

ILID (ISDN Line Interface Driver)und ILIDModem

ISDN Hardware(1D+2B, 4D+8B, 2D+60B)

voice

TCP/IP

user

mod

eke

rnel

mod

e

Groupware-/Mailserver

OfficeMasterUnified Messaging Server

Office Master Card

ISDN Anschluss

Mail-Client

Mail-Client

Mail-ClientLAN

faxt38

IP-Stack

LAN-Interface

FoIP Job Control (jcsip)

Job Control (jc)

Abbildung 4.2: OfficeMaster Softwarestruktur

2Sollten später weitere Signalisierungsverfahren hinzu kommen, empfiehlt sich die Auftrennung vonJobcontrol und Signalisierung, wie dies bei der Nutzung von ISDN bereits der Fall ist.


Gliederung des bei ISDN verwendeten Faxprozesses

Ausgangsbasis für die FoIP-Implementierung ist der bisher im ISDN-Umfeld verwendete Fax-prozess. Er wird nach Aufbau der Verbindung vom Jobcontrol-Prozess gestartet und mit sämt-lichen Parametern versorgt, die für die eigenständige Abwicklung der Faxübertragung benötigtwerden. Für jede aktive Verbindung wird ein solcher Prozess erzeugt, der sich nach erfolgterÜbertragung (oder im Fehlerfalle) selbst beendet.

Fax- prozess

Faxcontrol

T.30 Protokoll

ILAPI (Modem API Layer)

T.4 (Kodierung Dekodierung)

Modem / Line Driver

Messaging Server

Abbildung 4.3: Struktur des Faxprozesses: Faxcontrol steuert den gesamten Vorgang inVerbindung mit dem Unified Messaging Server, darunter übernimmt die T.30-Engine dieAbwicklung des Faxprotokolls und sendet bzw. empfängt Daten über den ILAPI-Layer.T.4 ist für die Kodierung und Dekodierung der Faxinformationen zuständig.

Den Aufbau des Faxprozesses zeigt Abbildung 4.3. Der Prozess ist in verschiedene Ebenengegliedert, die folgende Aufgaben übernehmen:

Faxcontrol In diesem Layer wird der gesamte Faxablauf anhand der übergebenen Parametergesteuert. Letztere beinhalten faxspezifische Optionen (z.B. Auflösung, maxima-le Übertragungsrate, zu benutzende Komprimierungsverfahren), einen Netzwerk-Datenpfad für das Faxdokument sowie Trace-Optionen zur Steuerung von De-bugausgaben in Logdateien. Dieser Programmteil beinhaltet auch die main()-


Funktion, die die übergebenen Parameter interpretiert und in interne Strukturenübersetzt.

T.30 Unterhalb der Faxcontrol-Schicht befindet sich der T.30-Layer, der die Steuerungdes Gruppe-3-Faxprotokolls übernimmt und nach Aushandlung der Eigenschaftenparallel eine T.4-Instanz anlegt.

T.4 Der T.4-Layer3 läuft parallel zur T.30-Schicht und übernimmt für diese die Verar-beitung der Faxdaten. Internes Faxformat für alle OfficeMaster-Produkte ist dasBinary-Fax-Format (BFF), das Dokumente in Seiten unterteilt und innerhalbder Seiten Pixelzeilen als abwechselnde Folge von weißen und schwarzen Lauf-längen darstellt. Dieses Format eignet sich gut für die Umkodierung in beliebigeGrafikformate, insbesondere aber in die bei Fax verwendete MH, MR und MMR-Kodierung, die selbst im Wesentlichen auf Lauflängenkodierung basiert. Nachdemsich Sender und Empfänger auf das zu verwendende Format geeinigt haben, wirddie T.4-Instanz erzeugt und gestartet. Sie übernimmt beim Faxversand die Um-wandlung zwischen BFF und dem festgelegten Faxformat (bzw. umgekehrt imFalle des Faxempfangs).

ILAPI Die T.30-Schicht kommuniziert mit dem ILAPI-(ISDN Line API) Layer, der dieDatenübertragung in den verschiedenen Modemverfahren unabhängig von denzugrunde liegenden Hardwarekomponenten abstrahiert.

4.1.3 Modem Interface Layer (ILAPI)

Die hier beschriebene eingebettete Faxsoftware ist im Laufe der Jahre mit unterschiedlichenModems eingesetzt worden (Yamaha YTM403, diverse Rockwell-Modems sowie aktuell mitSoftmodemtechnologie). Da ein großer Teil der Verarbeitung unabhängig von diesem Unterbauist, wurde ein Layer definiert, der nach oben hin dieselbe Schnittstelle (Application Program-ming Interface – API) bedient und die Anpassung an die jeweilige Umgebung vornimmt. Dieser– ILAPI genannte – Layer existiert getrennt für jede der verschiedenen Technologien bzw.Hardwarekomponenten. Für die Weiterentwicklung zu FoIP bietet es sich an, diese Strukturbeizubehalten und eine weitere ILAPI-Variante (im folgenden T38LAPI genannt) zu entwi-ckeln, die die Umsetzung zum/vom T.38-Protokoll übernimmt. Damit wird sichergestellt, dassein Großteil der Faxsoftware auch bei FoIP weiterbenutzt werden kann.

ILAPI Events und Nachrichten an die T.30-Schicht

Die Steuerung innerhalb der ILAPI erfolgt durch Ereignisse. Dazu gehören:

• Nachrichten vom übergeordneten T.30-Layer, zu erkennen an symbolischen Namen, diemit „LAPI_“ beginnen.

• Interne Nachrichten, die entweder direkt im ILAPI-Layer erzeugt werden oder vom ILID-Driver gemeldet werden. Sie beginnen mit „ILAPI_“. Ein Teil dieser Ereignisse ist hard-wareabhängig und wird nicht in jeder Produktvariante verwendet.

3ITU-T T.4 beschreibt unter anderem die Kodierung von Faxdokumenten – siehe Abschnitt 2.2.2.


Die im ILAPI-Layer bisher (also in der ISDN/Softmodemversion) vorkommenden Nachrich-ten bzw. Ereignisse werden im Anhang B.2 aufgeführt und erläutert. Welche Nachrichten in derImplementation aktuell verwendet werden, ist in Abschnitt 4.3 beschrieben.

4.2 Vorgaben und Programmierkonventionen

Die Ferrari electronic AG hat keine umfangreichen Richtlinien für Kodierungsdetails und Quell-codeformatierung. Die zu entwickelnde Software sollte sich vor allem an den bereits existierendenKomponenten orientieren und dabei folgende Vorgaben einhalten:

Programmiersprache Die Programmierung erfolgt in ANSI-C. Es dürfen keine Prozessor-abhängigkeiten (z.B. big-/little-endianess, Wertebereich von Integer-Datentypen) im Quellcode enthalten sein. Die Software wird für diePowerPC-basierte OfficeMaster Card mit GCC 3.1, für Intel Pentiummit GCC 3.3.1 übersetzt.

ASN.1 Bibliothek Für die ASN.1-Kodierung bzw. Dekodierung wurde eine kommerziellangebotene Programmbibliothek erworben, die bei der Implementie-rung des UDP-Transport-Layer (UDPTL) zu verwenden ist.

Dokumentation Das Quellprogramm muss notwendige Informationen und Erläuterun-gen als Kommentare in englischer Sprache enthalten – selbsterklären-de Codeabschnitte müssen nicht kommentiert werden.

Build-Umgebung Parallel zum vorhandenen ISDN-Faxprozess-Zweig soll für den neu-en T.38-Faxprozess ein separater Zweig eingerichtet werden. Alle ge-meinsam mit dem vorhandenen Programm verwendete Quellmodu-le sind über Links anzusprechen, damit sie nicht doppelt gepflegtwerden müssen. Das neue Programm muss in die existierende make-Umgebung so integriert werden, dass es bei allen make-Aufrufen mitberücksichtigt wird. Sämtliche für die Übersetzung der Software benö-tigten Dateien sind im Quellcode-Verwaltungssystem CVS zu halten.

Testumgebung Die Software soll unter SuSE Linux 9.0 entwickelt und getestet werden– ggfs. unter Nutzung des GNU Debuggers. In regelmäßigen Abstän-den muss eine PowerPC-Version gebaut, in eine OfficeMaster Cardgeflasht und dort getestet werden, um frühzeitig etwaige Plattform-probleme zu erkennen.

Debugausgaben Zur Unterstützung bei der Fehlersuche müssen Debug-Ausgaben vor-gesehen werden. Die hierfür vorhandenen Makros sind zu nutzen, umdie Ausgaben abhängig vom gewünschten Detaillierungsgrad (schwe-re Fehler, wichtige Ereignisse, weitere Details, sämtliche Ausgaben)aktivieren zu können. Die Steuerung des Logging erfolgt über Para-meter, die im Messaging-Server über Konfigurationstools vom An-wender eingestellt werden können. Sie werden dem Faxprozess beimStart übergeben. Beispiel für eine solche Debug-Ausgabe:

38 4.3. Entwurf und Implementierung der T38LAPI

DEBUG_MSG(DBG_B_PHY, 3, "T.38: got signal %d\n", signum);

DBG_B_PHY ist die Bezeichnung des LAPI-Layer, „3“ ist der De-taillierungsgrad. Weitere Parameter werden wie bei printf angege-ben. Alle Informationen landen zentral im Messaging-Server.

4.3 Entwurf und Implementierung der T38LAPI

Die Realisierung der Fax over IP Lösung erfolgt durch Entwicklung einer neuen LAPI – alsodes Programmteils, der die Anpassung an das verwendete Modem vornimmt. T.38 wird dabeiwie eine weitere Modem-Variante betrachtet. Dieser Ansatz erlaubt es, den Unterschied zurvorhandenen ISDN/Softmodem-Version auf einen einzigen Layer zu beschränken; alle anderenProgrammteile bleiben unberührt.

4.3.1 Gliederung der Software

Der T38LAPI-Layer wird in der Quelldatei t38lapi.c realisiert, die folgende Abschnitte undFunktionsblöcke enthält:

Globale DefinitionenHier werden globale Konstanten und Aufzählungstypen (z.B. für die Benennung vonEreignissen) festgelegt. Außerdem wird in diesem Bereich eine globale Datenstrukturdefiniert, die sämtliche zur Laufzeit benötigten Variablen enthält. Ein Zeiger auf diese(ILAPIDATA genannte) Struktur wird bei allen Funktionsaufrufen übergeben – dieserlaubt bei Bedarf eine Erweiterung der Software auf Mehrkanalfähigkeit4, indemfür jeden Kanal eine eigene Instanz dieser Struktur genutzt wird. Zuletzt beinhaltetdieser Abschnitt den Task-Descriptor für die T38LAPI, der für die Initialisierunginnerhalb der Tasker-Umgebung benötigt wird.

UDPTL-SenderoutinenDer nächste Bereich im Quellcode fasst alle für den Versand der UDPTL-Pakete be-nötigten Funktionen zusammen. Die ASN.1-Kodierung und der anschließende Ver-sand des UDP-Pakets erfolgt grundsätzlich über die Funktion SendUDPTL, die wiefolgt definiert ist:

static void SendUDPTL(ILAPIDATA *ld, BOOL isData, int msgType,BYTE *dataBuf, int dataLen, int fieldType);

Die einzelnen Parameter haben folgende Bedeutung:

• ld ist ein Zeiger auf die Struktur der Instanzvariablen

• isData legt fest, ob es sich um einen Datenblock oder um einen T30-Indikatorhandelt (siehe Beschreibung des IFP-Paketformats in 2.3.3)

4Derzeit wird für jede Faxverbindung ein separater Prozess gestartet.


• msgType beschreibt im Falle von Datenblöcken den Datentyp, ansonsten enthältmsgType den T30-Indikator

• dataBuf ist ein Quelldatenzeiger für Pakete, die Informationen transportieren

• dataLen beinhaltet die Anzahl der zu übertragenden Oktette

• fieldType beschreibt die Art der Daten (z.B. das zu verwendende Modulati-onsverfahren) bei Datenpaketen

In der Regel wird die Funktion SendUDPTL nicht direkt, sondern über Hilfsroutinenaufgerufen, zum Beispiel SendV21Preamble, SendTraining oder SendData. Dieseenthalten nur die jeweils erforderlichen Parameter und bedienen sich eines Aufrufsder generischen Funktion SendUDPTL, um die gewünschte Aktion auszuführen. DieVerwendung selbstdokumentierender Funktionsnamen verbessert die Lesbarkeit desQuellcodes.

UDPTL-EmpfangDer Empfang von T.38-UDPTL-Datagrammen erfolgt asynchron in einem Signal-Handler, der zum Initialisierungszeitpunkt eingerichtet wird. Während der Verarbei-tung eines T38LAPI-Events im Rahmen des Taskers ist der Empfang des Signalsgesperrt, so dass grundsätzlich keine sogenannten „Reentrancy“-Probleme durch dasasynchrone Signal auftreten können. Der Signal-Handler für den UDP-Empfang liestund verarbeitet solange Datenblöcke, bis keine weiteren Daten anliegen. Um dieszu ermöglichen, wird ein nicht-blockierender Socket benutzt. Zur Verarbeitung wirddie Funktion HandleUDPTL aufgerufen, die mit Hilfe der ASN.1-Bibliothek das Pa-ket in seine Bestandteile zerlegt und das Ergebnis über einen Zustandsautomatenverarbeitet (siehe Abschnitt 4.3.2).

SendetriggerIm Gegensatz zu gewöhnlichen T.38-Gateways, bei denen die an der Telefon- bzw.ISDN-Schnittstelle anfallenden Faxdaten und Ereignisse sofort weitergegeben wer-den, muss bei der synthetischen Erzeugung dieser Informationen nach jedem Versandeines Blocks abgewartet werden, bis dieses Ereignis auf der Empfangsseite weiterge-geben wurde. Bei Datenblöcken ist anhand der Länge der Daten und des aktuellenModulationsverfahrens zu ermitteln, wie lange diese Wartezeit dauern soll. Ohne sol-che Vorkehrungen würden auf der Empfangsseite nach einiger Zeit Puffer überlaufen(Details zu diesem Thema finden sich in Abschnitt 4.3.3). Nach jedem Sendevorgangwird also ein passend eingestellter Timer gestartet, nach dessen Ablauf die FunktionTriggerTransmission aufgerufen wird. Diese prüft, ob weitere Sendedaten bzw. -ereignisse (z.B. Ende eines HDLC-Frames oder Abschalten des Sendesignals) anliegenund veranlasst deren Versand. Dieselbe Funktion wird auch aufgerufen, wenn neueDaten vom T.30-Layer eintreffen. Diese Daten werden zunächst in die Sendequeuegestellt und anschließend geprüft, ob der Versand bereits aktiv ist oder neu angesto-ßen werden muss. Dieses Anstoßen erfolgt durch Aufruf von TriggerTransmission.

Task-AufrufDer Tasker ruft bei anliegenden Nachrichten den T38LAPI-Layer über die Funk-tionen ILapiTask auf – dies ist (abgesehen vom UDP-Empfang im Signal-Handler)


die einzige Möglichkeit, Funktionen in diesem Layer auszuführen. Die ankommendeNachricht beinhaltet eine Event-ID, anhand derer in die passende Verarbeitungsrou-tine verzweigt wird. Folgende Events können auftreten:

• LAPI_RESET tritt einmalig beim Start des Faxprogramms auf und führt zurInitialisierung der Variablen sowie des UDP-Sockets

• LAPI_SET_MODE startet eine neue Betriebsart (Senden eines Tons, Aktivierungeiner neuen Modulationsart für Sendedaten, Starten des Empfangs).

• LAPI_SEND_DATA übergibt zu sendende Daten

• LAPI_LAST_SEND_DATA übergibt ebenfalls Daten und zeigt zusätzlich an, dassdie aktuelle Sendebetriebsart nach dem Versand beendet werden soll

• ILAPI_TX_REQUEST ist die Benachrichtigung, die durch den Ablauf des obenbeschriebenen Sendeverzögerungstimers ausgelöst wird

HilfsfunktionenDen letzten Abschnitt des Quellprogramms bildet eine Reihe von Hilfsroutinen, dievon den bisher genannten Verarbeitungszweigen genutzt werden. Dazu gehören:

• Funktionen zur Flusskontrolle – diese werden beim Eintreffen neuer Sendeda-ten sowie beim erfolgten Versand von Blöcken aufgerufen, um dem T.30-Layermitzuteilen, ob die jeweiligen Puffer-Schwellen über- oder wieder unterschrittenwurden. Durch Senden von XON- bzw. XOFF-Nachrichten wird der Datenflussaktiviert bzw. deaktiviert. Diese Maßnahme ist erforderlich, um die Anzahl derbenutzten Zwischenpuffer zu limitieren.

• Senderoutinen für Nachrichten an den T.30-Layer; sämtliche Events an diesenLayer werden über SendMsgUp gesendet, wobei für einzelne Nachrichtentypenseparate Funktionen existieren, die sich dieser Senderoutine bedienen.

• Die Funktion AnalyzeRxFrame wird immer dann aufgerufen, wenn innerhalbdes T.30-Protokolls ein Kommando fertig empfangen wurde und nach obengemeldet werden soll. Dies erlaubt ein Mitverfolgen aktueller Ereignisse, umkontextabhängige Entscheidungen treffen zu können. Beispielsweise muss beimStart einer neuen Modulationsart (außer V.21) am Anfang ein Training überT.38 angestoßen werden, wobei beim ersten Auftreten einer bestimmten Mo-dulation ein langes Training erforderlich ist. Bei weiterer Aktivierung dersel-ben Modulationsart sollte hingegen ein kurzes Training verwendet werden. Dader T.30-Layer dazu keine Informationen liefert, muss in gewissem Rahmeneine Verfolgung der Signalisierung vorgenommen werden. Dies geschieht überAnalyzeRxFrame in Verbindung mit empfangenen LAPI_SET_MODE-Ereignissen.

4.3.2 Zustandsautomat für den UDPTL-Empfang

Das bei T.38 verwendete Internet Faxprotokoll (IFP) erlaubt eine flexible Verpackung von In-formationen in Pakete. So kann ein einzelnes UDPTL-Paket mehrere IFP-Pakete enthalten –umgekehrt kann aber auch ein IFP-Paket in mehrere UDPTL-Pakete aufgeteilt werden. Hinge-gen legt die Schnittstelle zum T.30-Layer die Datenübergabe wie folgt fest:


• T.30-Signalisierungsblöcke müssen jeweils einzeln komplett übergeben werden, wobei derletzte Block gesondert zu kennzeichnen ist

• HDLC-Frames im Rahmen des Error Correction Mode (ECM) müssen einzeln übermitteltwerden

• sonstige Faxdaten dürfen in Fragmenten übergeben werden

Da hier eine Umsetzung erfolgen muss, wird ein Zustandsautomat in Verbindung mit einemEmpfangspuffer benötigt. Dieser Automat ist in Abbildung 4.4 dargestellt.

HDLC-DATA RX_V21T4-DATA

RX_INACT

RX_IDLE RX_START

RX_T4

LAPI-RESET

V21-PREAMBLE

SIG-END

VXX-TRAINING T4-SIG-END HDLC-DATA HDLC-FCS-OK

Legende: Zustand:

Zustandsübergang:

Anfangszustand:

Abbildung 4.4: UDPTL-Empfangszustände: LAPI-RESET schaltet den Empfang frei,V21-PREAMBLE bzw. VXX-TRAINING starten die beiden Empfangszweige.

Erläuterung der Abläufe beim Empfang

Der T.30-Layer sendet nach dem Start des Faxprozesses die Nachricht LAPI_RESET andie T38LAPI. Diese wird damit zur Initialisierung aufgefordert, wobei unter anderem auchder Empfang durch Einnehmen des Zustands RX_IDLE aktiviert wird. Die T.38-InformationV21-PREAMBLE bereitet den Empfang einer neuen T.30-Kommandosequenz vor, die aus einemoder mehreren HDLC-Frames besteht. Dadurch wird der Zustand RX_START eingenommen, in


dem ein Kommando-Frame erwartet wird. Mit Eintreffen der ersten Daten wird in den Zu-stand RX_V21 gewechselt, in dem Datenfragmente gesammelt werden. Nach dem Empfang vonHDLC-FCS-OK wird das empfangene Kommando an T.30 übergeben und durch Wechsel in denZustand RX_START der nächste Frame erwartet. Anstatt eines neuen Kommandos kann auchjederzeit SIG-END empfangen werden, wodurch der Empfang deaktiviert wird.

Der Empfang von Faxdaten erfolgt ähnlich wie bei V.21-Kommandoblöcken. In diesem Fallwird der Beginn aber durch die Signalisierung einer Trainingsphase angezeigt, die am Anfangjeglicher Hochgeschwindigkeits-Übertragung erforderlich ist, um das Empfangsmodem an denSender und die Leitungsbedingungen anzupassen.

Im Gegensatz zu den bisherigen in Verbindung mit Modems verwendeten LAPI-Versionenist in der T.38-Variante der Empfang unabhängig vom aktuellen T.30-Zustand jederzeit möglich,da es nicht erforderlich ist, das Modem auf den jeweils erwarteten Empfangsmodus einzustel-len. Empfangene Informationen werden grundsätzlich an T.30 weitergegeben, auch wenn siedort gegebenenfalls nicht erwartet werden. Durch diese Strategie ergibt sich eine Verbesserung,da es zum Beispiel vorkommen kann, dass der Empfänger aufgrund von Problemen abbrichtund dies durch Senden von Disconnect (DCN) anzeigt. Die bisherigen Implementationen be-kommen das nicht mit und senden weiter Faxdaten, in der vorliegenden Lösung wird hingegendas ankommende DCN-Kommando verarbeitet.

Das Zustandsdiagramm in Abbildung 4.4 zeigt die Abläufe der Übersichtlichkeit halber invereinfachter Form. Die tatsächliche Implementation unterscheidet sich in folgenden Punkten:

• Der Empfang von T.4-Daten bei Benutzung des Error Correction Mode (ECM) ist nichtseparat dargestellt. Er erfolgt in Form von HDLC-Frames und damit analog zum Empfangvon Kommandos im V.21-Modus.

• Die Sendeseite kann nach eigener Wahl die Meldungen HDLC-FCS-OK und SIG-END inHDLC-FCS-OK-SIG-END zusammenfassen – in diesem Falle werden die beiden einzeln ein-gezeichneten Übergänge hintereinander ausgeführt.

• Durch HDLC-FCS-BAD oder HDLC-FCS-BAD-SIG-END gemeldete fehlerhafte Frames werdenverworfen. Anschließend erfolgt ein Übergang nach RX_START bzw. RX_IDLE.

4.3.3 Steuerung des Zeitverhaltens

Wie bereits im Abschnitt 2.3.4 ausgeführt, müssen Einrichtungen, die über T.38 – ohne denZwischenweg über analoge Signale – faxen, künstlich Verzögerungen einfügen, um die realeGeschwindigkeit bei der Übertragung zum Faxempfänger einzuhalten. Die Realisierung die-ses Zeitverhaltens ist nicht trivial, da sich beim Versand von kleinen Blöcken bei begrenzterTimerauflösung Rundungsfehler akkumulieren können. Dies kann sowohl zu einer verspätetenAuslieferung benötigter Daten als auch zum Überlauf von Empfangspuffern führen. Außerdemstellt der Beginn einer high-speed-Übertragung durch die nicht exakt vorgegebene Länge desvorangeschalteten Modemtrainings ein zusätzliches Timing-Problem dar.

Bei der Definition des T.38-Protokolls wurde leider versäumt, eine wirksame Flusskontrollevorzusehen, da der Faxversand von internetfähigen Geräten (IAF) an herkömmliche Faxgerä-te nicht im Fokus der Standardisierungsgremien gestanden hat. Im folgenden Abschnitt wirdbeschrieben, wie in der vorliegenden Implementation versucht wird, diese Probleme zu lösen.


Dauer des High-Speed Trainings

Die in der T.38-Version von 1998 vorgesehenen high-speed Modemverfahren (V.27, V.29 undV.17) benötigen zur Anpassung der Empfangsseite unterschiedlich lange, bevor die Übertra-gung beginnen kann. Diese Phase wird „Training“ genannt (nicht zu verwechseln mit demT.30-Training, bei dem eine 1,5 Sekunden dauernde Probeübertragung zur Qualitätsbeurtei-lung erfolgt – siehe Abschnitt 2.2.1).

Nach Start des Trainings muss eine bestimmte Zeit vor dem Versand der ersten Datenabgewartet werden. Wenn diese Zeit zu kurz gewählt wird, können auf der Empfangsseite Pufferüberlaufen, da die Weitergabe der Faxdaten erst nach Ablauf des Trainings beginnen kann. Einezu lange Pause würde dazu führen, dass der Versand begonnen werden müsste, aber noch keineInformationen vorliegen.

Zur Ermittlung der abzuwartenden Zeit wurden Messungen in Verbindung mit dem Cisco-2801-Gateway vorgenommen, um Anhaltspunkte für die Festlegungen zu bekommen. Dabeizeigte sich, dass die gemessenen Werte im Schnitt rund 150 Millisekunden länger waren alsin den jeweiligen Standards beschrieben. Trotzdem funktioniert die Faxübertragung, da zu Be-ginn der Fax-Datenphase das empfangende Gerät auf den ersten End Of Line Code wartet (bzw.beim Error Correction Mode auf das Start-Flag des ersten HDLC-Frames). Alle davor empfan-genen Informationen werden ignoriert. Dies ist aber nur dann unproblematisch, solange dasEmpfangsgateway bis zum Eintreffen der ersten Daten zum Faxgerät definierte Informationensendet, die nicht diesen Bedingungen entsprechen.

Da beim Versand von einem reinen Internet-Faxgerät das Sendetiming künstlich dem rea-len Verhalten auf der modulierenden Empfangsseite angenähert werden muss (dieses Themawird im folgenden Abschnitt weitergehend behandelt) wurde für die Implementation folgendeVorgehensweise gewählt:

• Als Verzögerung wird ein Wert gewählt, der um 200 Millisekunden kürzer ist als die realeDauer

• Bei V.17 short training, das insgesamt nur 142 Millisekunden dauert, wurde die Verzöge-rung mit 20 Millisekunden festgelegt.

• Dies ergibt einen Vorlauf an Faxdaten, der während des gesamten Übertragungsabschnittskonstant gehalten wird, damit es weder zu einem Abreißen der Informationen noch zueinem Pufferüberlauf auf der Empfangsseite kommt.

• Um sicherzustellen, dass mit den gewählten Werten eine sichere Faxfunktion erreicht wird,wurde durch Versuche ermittelt, dass diese innerhalb eines Korridors liegen, in dem dieÜbertragung funktioniert.

• Die bei diesen Tests verwendeten Werte sind in der folgenden Tabelle 4.2 in den SpaltenMinimum bzw. Maximum festgehalten.

• Bei ausführlichen Tests (siehe Kapitel 5) wird ermittelt, ob dieser Ansatz auch mit ver-schiedenen Gegenstellen funktioniert. Im Falle etwaiger Probleme kann experimentell eineeventuell notwendige Anpassung ermittelt werden.


Dauer des Trainings bei verschiedenen ModulationsverfahrenKonfiguration Standard gemessen Minimum Maximum gewähltV.27ter 2400 short 5 67 – – – –V.27ter 2400 long 943 1110 600 900 743V.27ter 4800 short 5 50 – – – –V.27ter 4800 long 708 870 400 700 508V.29 9600/7200 253 385 10 200 53V.17 14400/9600 short 142 315 10 130 20V.17 14400/9600 long 1393 1550 1050 1350 1193

Tabelle 4.2: Timing der Trainingssequenzen (Alle Angaben in Millisekunden)

Tabelle 4.2 enthält folgende Informationen:

• Die Konfiguration beschreibt das betrachtete Modulationsverfahren

• In der Spalte Standard ist der im zuständigen ITU-T Standard genannte Wert für dieDauer der Trainingssequenz angegeben

• gemessen ist der beim Faxversand von einer OfficeMaster Card mit ISDN über das Cisco2801-Gateway ermittelte Zeitabstand zwischen Trainingsbeginn und ersten übertragenenDaten

• Minimum ist die untere Wartezeit, die bei Versuchen noch zu einer funktionierendenKommunikation geführt hat

• Maximum – wie Minimum, nur dass hier ein oberer Wert angegeben ist, bei dem dieÜbetragung in Versuchen problemlos stattfand

• Implementiert gibt den tatsächlich verwendeten Wert an

Zu beachten ist, dass bei einigen Verfahren zwischen kurzem und langem Training unter-schieden wird. Das lange Training wird bei der ersten Verwendung der jeweiligen Modulationbenutzt, bei weiterer Aktivierung der zuletzt genutzten Konfiguration genügt es, die kurze Trai-ningssequenz zu verwenden. Die Konfigurationen V.27ter 2400 short und V.27ter 4800 shortsind im T.38-Standard nicht vorgesehen – bei V.27 wird deshalb grundsätzlich das lange Trai-ning verwendet.

Desweiteren ist es nicht möglich, dem Empfänger mitzuteilen, ob vor dem Training einEcho Protector Tone gesendet werden soll, der mit weiteren 20 Millisekunden zu Buche schlagenwürde. Die Entscheidung, ob dieser Ton zu senden ist, obliegt dem empfangenden Gateway – diesendende Einrichtung hat hierüber keine Kenntnis. Der Echo Protector Tone wird üblicherweisebei V.27- und V.29-Modulation in Wählverbindungen verwendet um sicherzustellen, dass dieEchounterdrückung in der korrekten Richtung aktiviert wird.

5V.27ter short training wird bei T.38 nicht verwendet.


Adaptives Timing beim Versand der Fax-Daten

Das in der OfficeMaster Card in die Prozesse eingebettete Betriebssystem („Tasker“) bietet eineTimerauflösung von 10 Millisekunden. Wegen des zur Fehlerkorrektur erforderlichen Versandsmehrerer IFP-Pakete in einem UDP-Block dürfen diese eine bestimmte Größe nicht überschrei-ten. Gängige Gateways übertragen häufig nur 24 Daten-Oktette in einem Paket. Bei einerÜbertragunsrate von 14400 Bits pro Sekunde benötigt das Empfangsgateway zur Weitergabedieser 192 Bits an das Faxgerät lediglich 13,33 Millisekunden. Es ist leicht einzusehen, dassdie Verzögerung bis zum Versand des nächsten Pakets durch einen Timer im 10 Millisekunden-Raster bei längerer Übertragung zu großen Abweichungen führt. Um die benötigte Genauigkeitdennoch zu erreichen, muss zusätzlich das Langzeitverhalten gemessen werden, um korrigierendeingreifen zu können.

Die Auswirkung dieses Problems zeigt folgende Grafik, in der das Verhalten unter verschie-denen Bedingungen zu sehen ist:

T.38 Sendetiming

0,0

0,2

0,4

0,6

0,8

1,0

1,2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

Datenmenge (Blöcke à 64 Oktette)

Zeitv

erla

uf (S

ekun

den)

Delay aufgerundetDelay adaptiertDelay abgerundetIdealverlauf

Abbildung 4.5: Zeitverhalten beim T.38-Faxversand von einem Internet-Faxgerät

Erläuterungen zu Abbildung 4.5:

Die Grafik zeigt das Verhalten beim T.38-Faxversand mit einer Blockgröße von netto 64Oktette pro UDP-Datagramm bei einer Übertragungsrate von 14400 Bits pro Sekunde. Dieverschiedenen Versuche wurden mit Ethereal aufgezeichnet, anschließend wurden die T.38-Datagramme über ein Anzeige-Filter ausgewählt und die Zeitstempel der übertragenen Blöckeim „Comma Separated Value-“ (CSV-) Format an Excel zur Auswertung übergeben.


Die verschiedenen Kurven in Abbildung 4.5 haben folgende Bedeutung:

• Die türkisfarbene Gerade zeigt den Idealverlauf von 64×814400 Sekunden, also 35, 5 Millise-

kunden pro Block (entspricht 28,125 Blöcken pro Sekunde).

• Bei einer Aufrundung des Zeitabstands auf 40 Millisekunden ergibt sich das Verhalten,das in der dunkelblauen Kurve gezeigt wird. Die Abweichung beträgt rund 13 Prozent.

• Die Auswirkung einer Abrundung auf 30 Millisekunden zeigt die gelbe Kurve. Hier beträgtdie Abweichung ca. -18 Prozent.

• Bei Anwendung des im folgenden beschriebenen adaptiven Korrekturverfahrens entstehtein Verlauf wie in der violetten Kurve gezeigt. Dieser Algorithmus führt zu einer gutenAnnäherung an das Ideal, wobei die absolute Abweichung auch langfristig gering ist – derprozentuale Fehler sinkt dementsprechend mit zunehmender Übertragungsdauer.

Implementation der adaptiven Timing-KorrekturDa der im Tasker verwendete Timer keinen absoluten Zeitbezug bietet, ist es erforderlich,

auf Ressourcen des darunterliegenden Linux-Betriebssystems zurückzugreifen. Hierfür eignetsich besonders die Funktion gettimeofday(), die die absolute Differenz zwischen aktuellemZeitpunkt und dem 1. Januar 1970, 00:00 Uhr in Sekunden (bzw. den Rest in Mikrosekunden)in einer Struktur struct timeval liefert, die wie folgt aufgebaut ist:

struct timeval {time_t tv_sec; /* seconds */suseconds_t tv_usec; /* microseconds */

};

Über diese Funktion kann eine genaue Differenz zwischen zwei Zeitpunkten errechnet wer-den. Da für die benötigten Berechnungen eine Auflösung in Millisekunden ausreicht und dieseZeitangaben komfortabel als Ganzzahlen verabeitet werden können, wird eine Hilfsfunktion zurBerechnung der Zeitdifferenz in Millisekunden zwischen zwei als struct timeval angegebenenAbsolutzeitpunkten verwendet.

Der Algorithmus zur adaptiven Korrektur des Sendetimings läuft wie folgt ab:

• Beim Start des Trainings im Highspeed-Modus wird die timeval-Struktur tx_start_timeauf den aktuellen Zeitpunkt zuzüglich der in Tabelle 4.2 festgelegten Verzögerung desSendestarts gesetzt

• Die beim Senden eines Datenblocks errechnete Zeitdauer wird in einer separaten Variablenaufsummiert, die vor dem Senden des ersten Blocks auf Null gesetzt wird

• Bei Anwendung des Error Correction Mode (ECM) wird die berechnete Zeit um fünfProzent erhöht, um den Overhead des dabei benutzen HDLC-Framings zu berücksichtigen

• Bevor der Verzögerungstimer mit der jeweils errechneten Zeitdauer gestartet wird, er-folgt eine Korrektur dieses Werts um die Differenz zwischen berechneter und tatsächlichvergangener Zeit seit Beginn der Übertragung

Kapitel 5. Tests mit verschiedenen Gegenstellen 47

Kapitel 5

Tests mit verschiedenen Gegenstellen

Die korrekte Arbeitsweise der Implementation wurde durch eine Reihe von Tests mit unter-schiedlichen Gegenstellen verifiziert, wobei sich die Auswahl der untersuchten Kombinationenan verschiedenen Gesichtspunkten orientierte:

• Die Gegenstellen müssen T.38 in Verbindung mit SIP unterstützen, da die vorliegendeImplementation zum Testzeitpunkt keine anderen Signalisierungsprotokolle beherrschte1.

• Bei der Auswahl sollten Geräte bevorzugt werden, die von den Marktführern im VoIP-Bereich stammen.

• An den verwendeten Gateways werden – sofern möglich – Endgeräte betrieben, die zu-sätzliche Diagnoseinformationen liefern können.

Nach den hier genannten Kriterien hat der Auftraggeber verschiedene Geräte angeschafft,wobei die Auswahlmöglichkeiten wegen der Festlegung auf SIP eingeschränkt waren. Alle nam-haften Hersteller (wie z.B. Innovaphone) haben allerdings angekündigt, in naher Zukunft nebenH.323 auch SIP zu unterstützen.

Parallel zu den Tests wurden an den beteiligten Geräten und Schnittstellen Informationenzur späteren Auswertung gesammelt. Sie dienten der Diagnose von auftretenden Problemensowie der Gewinnung verschiedener Messwerte (z.B. Übertragungsdauer) für die vergleichen-de Beurteilung. Folgende Hilfsmittel wurden – in Abhängigkeit vom jeweiligen Testszenario –genutzt:

Traces auf der T.38-fähigen OfficeMaster Card (dem „Probanden“)Standardmäßig lief die Debugausgabe des T.30-Layers und der T38LAPI in Detaillie-rungsstufe 1 mit, dies erlaubt eine übersichtliche Beurteilung des Faxablaufs.

Debug-Aufzeichnungen auf der GegenseiteSofern es sich bei der Gegenstelle ebenfalls um eine OfficeMaster Card handelte, standendort dieselben Debughilfsmittel zur Verfügung. Lediglich in Verbindung mit Gatewaysohne ISDN-Schnittstellen fiel diese Möglichkeit aus, da in diesen Fällen „fremde“ Geräteals Gegenstellen genutzt werden mussten.

1Die beim Test verwendete SIP-Implementation befand sich zudem noch in einem experimentellenStadium.

48

T.38-ProtokollaufzeichnungGrundsätzlich wurden auf der LAN-Seite alle Tests parallel mit Ethereal aufgezeichnetund bei Bedarf analysiert. Neben der Dekodierung vieler Kommunikationsprotokolle (un-ter anderem auch T.38) erlaubt Ethereal auch die Auswertung zeitlicher Relationen an-hand der festgehaltenen „Timestamps“.

ISDN-MonitoringSofern die Gegenstelle über eine ISDN-Schnittstelle angeschlossen war, wurde an die-ser die Kommunikation über einen ISDN-Tester aufgezeichnet und als Stereo-Wavedateiabgespeichert, die die Analogsignale in beiden Richtungen in zeitlichem Zusammenhangfesthält.

Gateway-MonitoringViele Gateways erlauben die Aufzeichnung von Diagnoseinformationen über Terminalver-bindungen oder anhand von Syslog-Meldungen. Diese Möglichkeiten wurden während derUntersuchungen zur zusätzlichen Gewinnung von Detailinformationen genutzt.

Bei den Tests wurde vorrangig der Faxversand betrachtet, da dieser zum einen bei denmeisten Anwendern die Hauptrolle spielt und zum anderen die Implementation als aktiver Teilstärker beeinflusst. Für die Verifizierung der Empfangsfunktion genügte es, pro untersuchterUmgebung einen Empfangsvorgang jeweils mit niedrigster und höchster Übertragungsrate zutesten, während in Senderichtung alle möglichen Geschwindigkeiten und Optionen geprüft wur-den.

Folgende Tests wurden in Senderichtung vorgenommen:

Versand eines TestchartsAls Testdokument wurde die DIN-Testvorlage für Fernkopierer (nach DIN 32742 Teil7) verwendet. Diese enthält verschiedene Bereiche, die dafür geeignet sind, die Qualitätvon Scanner und Drucker zu prüfen (hier allerdings nicht von Bedeutung) sowie etwaigeÜbertragungsfehler leicht zu erkennen.

Testbrief (20 Seiten)Für die Messung der Druckgeschwindigkeit wird seit vielen Jahren ein Dokument ver-wendet, dessen Inhalt in DIN-ISO 10561 genormt wurde. Es handelt sich dabei um eineneinfachen Brief in 10-cpi-Schreibmaschinenschrift (vergleichbar mit Courier 12 pt), der als„Dr. Grauert-Brief“ bekannt ist. Um Lizenzgebühren zu sparen, wurde ein frei verfügba-rer „Dr. Gilbert-Testbrief“ verwendet, der den gleichen Umfang wie das Original hat (zufinden unter http://www.druckerchannel.de/downloads/dr_gilbert.rtf). Zur Mes-sung der Sendegeschwindigkeit wurden jeweils zwanzig Seiten dieses Dokuments in einemVorgang übertragen. Bei diesem Test wird der Einfluss der Seitenquittierung auf die Ge-samtdauer durch die höhere Seitenzahl stärker gewichtet.

ÜbertragungsverfahrenBeide hier beschriebenen Tests wurden mit allen verfügbaren Übertragungsraten (2400bis 14400 bps) sowie – sofern unterstützt – mit und ohne Error Correction Mode (ECM)bzw. mit ein- und zweidimensionaler Komprimierung durchgeführt.

Zur Kontrolle wurden die Tests auch ohne Debugausgaben durchgeführt, um etwaige Ein-flüsse durch die Aktivierung der Traceaufzeichnung ausschließen zu können.

http://www.druckerchannel.de/downloads/dr_gilbert.rtf


5.1 Cisco 2801-Router

Die Firma Cisco Systems spielt seit Jahren eine wichtige Rolle als Hersteller von Netzwerk-Komponenten. Durch Erweiterung der angebotenen Produkte um VoIP-Unterstützung gelanges der Firma, diese Bedeutung auch in der IP-Telefonie zu erreichen. Neben reinen Softwa-relösungen wie dem Cisco Callmanager, der eine Telefonanlage auf IP-Basis darstellt, werdenvor allem intelligente Router mit VoIP-Unterstützung angeboten. Diese erfüllen unter anderemdie Funktion eines Gateways, das Verbindungen zwischen Telefon- und IP-Netz vermittelt unddabei Sprach- und Faxdaten umsetzt und transportiert.

Wegen der geschilderten Marktbedeutung hat die Ferrari electronic AG einen Cisco 2801-Router mit folgenden Baugruppen bzw. Softwarekomponenten für Testzwecke angeschafft:

• Cisco IOS-Betriebssystem Version 12.3 mit VoIP-Unterstützung – dazu gehört auch FaxPass-Through sowie Fax-Relaying über T.37 und T.38

• Callmanager Express als integrierte Software-Telefonanlage

• Ein DSP- (Digital Signal Processor) Modul zur Unterstützung von 30 parallelen VoIPbzw. FoIP-Verbindungen

• Ein ISDN-Primärmultiplex-Interface zur Anbindung an das öffentliche Netz oder eineTK-Anlage mit 30 Nutzkanälen

• Zwei ISDN-Basisanschlüsse, die sowohl zum Anschluss von Endgeräten (=NT-Modus) alsauch zur Verbindung mit Amtsleitungen oder Telefonanlagen verwendet werden können(=TE-Modus)

Testaufbau

LAN ISDN

8818 TK-Anlage

Cisco 2801Router/Gateway

OfficeMaster Cardmit T.38

OfficeMaster Cardmit ISDN

PRI BRI

Abbildung 5.1: Testaufbau mit Cisco 2801 – als Gegenstelle wird eine OfficeMaster Cardverwendet, die umfangreiche Diagnosemöglichkeiten bietet. Dazwischen liegt das interneIP- und ISDN-Netz.

50 5.1. Cisco 2801-Router

Die Konfiguration dieses Gateways erfolgt über das Command-Line Interface (CLI) desCisco-eigenen Betriebssystems IOS (Internetworking Operating System). Hierzu wird eine Ter-minalverbindung mit dem Router über serielle Schnittstellen bzw. über Telnet oder SSH (SecureShell) verwendet2. Das 2801-Gateway ist für den Test einerseits in das vorhandene lokale Netz-werk integriert und andererseits über die S2M-Schnittstelle an die ISDN-TK-Anlage Nixdorf8818 angeschlossen (siehe Abbildung 5.1).

Ergebnisse der Tests mit dem Cisco 2801-Router

Einflussnahme des Gateways auf die T.30-SignalisierungEine Besonderheit der T.38-Implementation in der geschilderten Cisco-Konfiguration wur-de im Zuge der Tests festgestellt: das Gateway unterdrückt bestimmte Fax-Eigenschaftender Gegenstelle, indem es die übermittelten T.30-Signalisierungsblöcke manipuliert.Grundsätzlich sind derartige Eingriffsmöglichkeiten vorgesehen, sie sind aber gemäß derDokumentation durch Einstellparameter ein- und ausschaltbar. Wenn zum Beispiel ausbestimmten Gründen3 die Nutzung des Error Correction Mode ausgeschlossen werden soll,kann dies durch das Kommando fax-relay ecm disable im betroffenen Abschnitt (dial-peer) vorgegeben werden. Ein Test zeigt jedoch, dass – unabhängig davon, ob diese Optiongesetzt ist – nicht nur ECM, sondern sogar jegliche zweidimensionale Faxkomprimierungdurch das Gateway verhindert wird! Die parallele Aufzeichnung des T.30-Protokolls aufbeiden Seiten verdeutlicht dies:

Die gerufene Seite sendet ihre Eigenschaften wie folgt:T30: B27 SEND DIS V17 14400 ECM Fax fine MR/MMR (00 f7 1f 23 01 01 00)

Auf der rufenden Seite kommt dieser Block so an:T30: B01 RCV DIS V17 NOECM Fax fine MH (00 f7 1f 01 01 01 00)

Oktett 4 zeigt, was das gerufene Gerät als Eigenschaften signalisiert hat (23) bzw. wasnach Umsetzung durch das Gateway auf der rufenden Seite angekommen ist (01 – alleAngaben in diesem Trace sind hexadezimal). Die Bits 27 und 32 des Digital IdentificationSignal (DIS) wurden vom Gateway zurückgesetzt (siehe Tabelle A.2). Als Folge diesesFehlverhaltens konnten mit dem Cisco-Router nur Tests ohne Error Correction Modeund mit eindimensionaler Komprimierung durchgeführt werden.

SendegeschwindigkeitDie Messung der Übertragungsdauer ergab beim Versand des Testcharts im Vergleich zurherkömmlichen Faxkommunikation ohne IP-Strecke nahezu identische Werte. Gemessenwurde jeweils vom Beginn der Übertragung des Seiteninhalts bis zum Erhalt der letztenpositiven Quittung. Die restliche Zeit, die benötigt wird zur Aushandlung der Eigen-schaften, Durchführung des Trainings mit anschließender Bestätigung sowie zum Senden

2Der benötigte Lernaufwand, um so ein Gerät einrichten zu können, ist beträchtlich – allein das „CiscoIOS Voice, Video, and Fax Configuration Guide“, das hierfür als Grundlage dient, hat einen Umfangvon knapp 1000 DIN-A4 Seiten, die „Cisco IOS Voice Command Reference“ ist über 2200 Seiten lang.

3Im „Configuration Guide“ wird dies zum Beispiel empfohlen für Netze mit hohem Paketverlust, dadort das ECM-Protokoll zu empfindlich reagiert und deshalb eine Verschlechterung der Faxübertragungherbeiführen könnte.


des abschließenden Disconnect-Befehls, ist unabhängig vom verwendeten Verfahren undbeträgt ca. 11 Sekunden. Bei der Übermittlung desselben Dokuments zwischen ISDN-basierten OfficeMaster Cards unter Nutzung der Modified Modified Read-Komprimierung(die den Error Correction Mode voraussetzt) wurde bei V.17-Modulation mit 14400 bpseine Dauer von 63 Sekunden gemessen. Die durch das Gateway erzwungene eindimensio-nale Komprimierung führt hingegen zu einer Übermittlungszeit von 105 Sekunden – derVerlust durch Verzicht auf optimale Komprimierung ist also nicht unerheblich.

ÜbertragungsqualitätDie Beurteilung der Übertragungsqualität erfolgt auf zweierlei Art:

• bei Nutzung des Error Correction Mode (ECM) ist die Anzahl der zu wiederholendenTeilblöcke ein geeignetes Maß (es kann auch beim Absender ermittelt werden).

• ohne ECM hängt das Diagnoseverfahren vom Empfängertyp ab: wenn es sich um eineOfficeMaster Card handelt, kann durch Aktivierung entsprechender Traceausgabenermittelt werden, wieviele Pixelzeilen korrekt bzw. fehlerhaft empfangen wurden.Fehlerzeilen werden an ungültigen Codes oder Zeilenlängen erkannt – in diesemFall wird nach dem nächsten End Of Line (EOL) Code gesucht und daraufhin neusynchronisiert. Beim Versand an Fremdgeräte kann die Qualitätsbeurteilung nurdurch Kontrolle des ausgedruckten Dokuments erfolgen.

In der hier untersuchten Umgebung wurde die Fehlerzeilenstatistik der auf der Empfangs-seite genutzten OfficeMaster Card ausgewertet. Die Tests ergaben beim Versand mit V.17(14400 bzw. 12000 bps) einen Wert von durchschnittlich 0,5% fehlerhafter Zeilen pro Seite– bei allen anderen Verfahren (V.29 und V.17 ter) wurden alle Testdokumente fehlerfreiempfangen. Dieses Ergebnis ist als sehr gut zu bewerten, da bei einer Faxübertragungohne ECM Werte von bis zu 10 Prozent defekter Zeilen akzeptiert werden (Siehe Anfor-derungen in Kapitel 3).

FaxempfangFür die Beurteilung des Empfangs wurden Testdokumente an den Prüfling versandt. Da-bei traten keine Probleme auf – der Einfluss des Empfängers ist allerdings auch sehrgering. Die Demodulation des Modemsignals erfolgt im Gateway ohne Beteiligung desProbanden. Außerdem gibt es keine nennenswerte Timingprobleme, da der Empfänger dieIP-Blöcke nicht in Echtzeit verarbeiten muss und daher auch Schwankungen der Über-tragungsrate problemlos verkraftet.

Weitere BeobachtungenIn Verbindung mit SIP als Signalisierungsprotokoll tritt am Cisco Gateway folgendesFehlverhalten auf:

Wie im T.38-Standard vorgesehen, wird zunächst eine Sprachverbindung aufgebaut. Wenndas Gateway im Sprachkanal einen Fax-Antwortton erkennt, wird durch ein neues INVITEvon Sprache (über RTP) auf T.38-Fax umverhandelt. Dabei geschieht es regelmäßig, dassnach Ende dieser Verhandlung noch ein RTP-Block gesendet wird, der aber als Zielportbereits den für T.38 ausgehandelten Port adressiert. Da die Protokollidentifikation jedochausschließlich anhand der Portnummer erfolgt, versucht der Empfänger das Datagramm

52 5.2. Mediatrix 2102 mit analogen Faxempfängern

als UDPTL-Paket zu dekodieren. Dies führt in den ASN.1-Funktionen zu einer Reihe vonFehlermeldungen. Ab dem zweiten Paket sind die Inhalte dann korrekt kodiert.

Um dieses Problem zu umgehen, wird in der aktuellen Implementation das erste Bytedes UDP-Paketinhalts ausgewertet. Da dieses das höherwertige Byte der 16 Bit breitenSequenznummer darstellt und letztere nach Ende der Aushandlung mit Null beginnenmuss, werden Blöcke verworfen, in denen dieses Byte ungleich Null ist, sofern der UDPTL-Empfangszähler auf Null steht. RTP-Datagramme beginnen mit einem Byte, bei dem dasoberste Bit gesetzt ist, so dass dieser Workaround zuverlässig funktioniert.

Desweiteren fällt bei der Cisco-T.38-Implementation auf, dass in bestimmten SituationenPakete regelmäßig wiederholt werden. Diese Redundanz scheint eine zusätzliche Maßnah-me gegen etwaige Paketverluste zu sein, auch wenn dies in der T.38-Spezifikation nichtvorgesehen ist. Probleme durch Duplikate entstehen dabei jedoch nicht, da die zusätzli-chen Pakete mit derselben Sequenznummer wie das Original gesendet werden.

5.2 Mediatrix 2102 mit analogen Faxempfängern

Mediatrix (http://www.mediatrix.com) ist eine kanadische Firma, die VoIP-Produkte her-stellt und weltweit vertreibt. Zielmarkt sind Carrier, die passende Gateways für ihre Kundenbenötigen. Ein Teil des Portfolios besteht aus OEM-Komponenten, also Geräten, die nichtvon Mediatrix selber hergestellt werden. Der Hersteller verfolgt die Strategie, den Markt nichtprimär über niedrige Preise, sondern über möglichst hohe Qualität der Produkte zu erobern.Die im folgenden geschilderten Erfahrungen mit 2102-Gateways können dies im Wesentlichenbestätigen.

Das „2102 Residential VoIP Access Device“ gehört zur Kategorie der analogen Terminaladap-ter (ATA). Diese verbinden analoge Telefone, Modems und Faxgeräte mit VoIP-Netzwerken. Esverfügt über zwei Anschlüsse, die bezüglich Leitungsabschluss, Klingelspannung und -frequenz,Signalisierungstöne etc. alle wichtigen Ländervarianten unterstützen. Für den Betrieb an einemgängigen DSL-Anschluss sollte das Gateway zwischen DSL-Modem und Router geschaltet wer-den, um bei Nutzung des SIP-Protokolls Probleme mit Firewalls und Network Address Trans-lation (NAT) zu vermeiden (dieses Thema soll hier nicht weiter ausgeführt werden – detaillier-te Informationen finden sich beispielsweise unter http://www.voip-info.org/wiki-NAT+and+VOIP).

Zur Unterstützung der Faxkommunikation ist das T.38-Protokoll integriert. Da das Gatewayausschließlich über analoge Endgeräteschnittstellen verfügt, konnten als Gegenstellen für denTest nur „fremde“ Faxgeräte verwendet werden – OfficeMaster Cards verfügen nur über ISDN-Anschlüsse.

Zum Einsatz kamen folgende Geräte:

• Ein Laserfaxgerät vom Typ „brother FAX 8070p“

• Ein „AL-1252“ von Sharp

• Ein „Mac mini“ mit integriertem Faxmodem und im MacOS enthaltener Faxsoftware

http://www.mediatrix.com

http://www.voip-info.org/wiki-NAT+and+VOIP

http://www.voip-info.org/wiki-NAT+and+VOIP


Für die Beurteilung der Testergebnisse werden teilweise die oben beschriebenen Messresul-tate am Cisco Gateway zum Vergleich herangezogen, da dieses eine besonders wichtige Rolleim betrachteten Markt spielt. Details werden nur beschrieben, wenn es sich um Abweichungenvom Verhalten am Cisco Probanden handelt.

Ergebnisse der Tests mit dem Mediatrix 2102-Gateway

Einflussnahme des Gateways auf die T.30-SignalisierungDas Mediatrix 2102 lässt im Gegensatz zur getesteten Cisco-Lösung Faxübertragungenmit Error Correction Mode sowie mit zweidimensionaler Kodierung zu. Deshalb wirdin Verbindung mit entsprechenden Gegenstellen eine deutlich schnellere Faxübertragungerreicht. Die Signalisierung privater Eigenschaften durch Non Standard Facilities (NSF)wird durch das Gateway unterbunden, indem der Inhalt des NSF-Kommandos durchNullen ersetzt wird. Damit soll verhindert werden, dass Faxgeräte ein und desselbenHerstellers sich auf private Protokolle oder Modulationsverfahren einigen, die durch dasGateway nicht in T.38-konforme Kommunikation umgesetzt werden können.

SendegeschwindigkeitOhne Error Correction Mode wird dieselbe Übertragungsrate erreicht wie in Verbindungmit dem Cisco-Gateway. Bei Nutzung maximaler Kompression benötigt die Übertragungdes Testcharts um 40 Prozent weniger Zeit. Unter Hinzurechnung des Overheads von 11Sekunden pro Faxvorgang reduziert sich die Verbindungsdauer um ca. 35 Prozent.

ÜbertragungsqualitätDa bei den zur Verfügung stehenden analogen Faxempfängern keine detaillierten Diagno-semöglichkeiten genutzt werden konnten, wurde die Qualität bei Übertragung ohne Feh-lerkorrektur durch Begutachtung des ausgedruckten Empfangsdokuments vorgenommen.Bei Nutzung von V.17 mit 14400 und 12000 bps wurden jeweils einige wenige gestörte Pi-xelzeilen festgestellt, die jedoch die Lesbarkeit des Dokuments nicht beeinträchtigten. MitV.29 bei 9600 und 7200 bps konnten keine Fehler festgestellt werden. Interessanterwei-se traten beim Test mit dem Sharp-Gerät erhebliche Probleme auf, wenn als ModulationV.17 ter verwendet wurde, unabhägig davon, ob mit 4800 oder 2400 bps. Eine erfolgreicheÜbertragung war nur in ca. 10 Prozent aller Fälle möglich. Bei den anderen Probandenwaren zwar auch bei V.27 ter Fehler festzustellen, sie führten jedoch nicht zum Abbruchoder zur negativen Quittierung. Normalerweise ist gerade bei langsameren Geschwindig-keiten eine geringere Fehlerrate zu erwarten. Eine genauere Erforschung dieses Phänomenswar im Rahmen der vorliegenden Arbeit nicht möglich – hierfür wäre der Einsatz einesFax-Protokolltesters erforderlich. Derartige Geräte sind sehr teuer, da sie nur in kleinenStückzahlen verkauft werden.

FaxempfangDer Empfang von Faxdokumenten über das Mediatrix-2102-Gateway funktionierte pro-blemlos.

Weitere BeobachtungenDas Mediatrix 2102 ist das einzige Gerät, das auch ankommende Verbindungen akzeptiert,die über SIP und SDP von vornherein eine Faxkommunikation über T.38 anfordern.

54 5.3. (Noch) nicht untersuchte Umgebungen

Alle anderen Gateways erwarten ausschließlich Sprachverbindungen und erlauben nurinnerhalb dieser eine Umverhandlung nach T.38. Dies ist einigermaßen unverständlich,da zum einen der T.38-Standard beide Varianten vorsieht und zum anderen gerade beiabgehenden Verbindungen von vornherein feststeht, dass ein Fax versandt werden soll.Der Umweg über eine Voiceverbindung ist in diesen Fällen unnötig.

5.3 (Noch) nicht untersuchte Umgebungen

Mit den beiden untersuchten Gateways (Cisco 2801 und Mediatrix 2102) wurden in Verbindungmit unterschiedlichen Faxeinrichtungen umfangreiche Tests vorgenommen, die zeigen konnten,dass die vorliegende Implementation ihre Aufgabe gut erfüllt. Die langjährige Erfahrung derFerrari electronic AG bei der Entwicklung von Faxcontrollern zeigt, dass deren Firmware denendgültigen Reifegrad in der Regel erst erreicht, wenn sie im praktischen Einsatz mit einerVielzahl unterschiedlicher Gegenstellen erprobt und bei Bedarf mit Korrekturen versehen wur-de. Ähnlich verhält es sich offensichtlich mit dem noch relativ neuen T.38-Protokoll – auchhier bedarf es umfangreicher Erfahrungen in Verbindung mit möglichst vielen verschiedenenKommunikationspartnern.

Bevor erste Pilotinstallationen erfolgen können, müssen bei der Ferrari electronic AG Tests inVerbindung mit Gateways vorgenommen werden, auf die man voraussichtlich bei Installationenhäufiger treffen wird. Dazu ist es jedoch erforderlich, dass diese das T.38-Protokoll in Verbindungmit SIP-Signalisierung unterstützen. Tests mit folgenden Gegenstellen sind konkret geplant:

Innovaphone ip800Bisher unterstützt Innovaphone ausschließlich Signalisierung über H.323. Für Testzweckewurde ein ip800-Gateway angeschafft, für das eine Erweiterung um SIP angekündigtwurde. Ein Termin für die Freigabe dieser Version steht noch nicht fest – sobald ersteVersionen verfügbar sind, muss die Interoperabilität der vorliegenden Implementation mitdem ip800-Gateway geprüft werden.

TE-Systems XCAPIFür dieses rein Software-basierte Gateway gibt es bereits eine Betaversion mit SIP-Unterstützung. Diese beherrscht jedoch noch nicht T.38 – erst mit Verfügbarkeit dieserFunktion können Tests durchgeführt werden.

Mediatrix 1402 IP/ISDN-GatewayDieses Gateway liegt bereits in einer SIP-Version vor. Bisher ist es jedoch nicht gelungen,eine funktionierende Faxverbindung aufzubauen, um Tests durchzuführen. Auch Testszwischen Mediatrix 1402 und 2102 ohne Einbeziehung der hier beschriebenen T.38-Lösungbrachten keine funktionierende Faxübertragung zustande. Worin diese Probleme begrün-det sind, muss noch im Detail erforscht werden.

AudioCodes MP-102Die israelische Firma AudioCodes stellt eine Reihe von VoIP-Gateways mit T.38-Unterstützung her. Da diese bisher als einzige für die Nutzung mit Alcatel-Anlagen zerti-fiziert wurden, sollte ein solches Gateway angeschafft und in den Test einbezogen werden.Dies ist für die nähere Zukunft geplant.

Kapitel 6. Zusammenfassung und Ausblick 55

Kapitel 6

Zusammenfassung und Ausblick

Ausgangsbasis

Als Hersteller von Unified Messaging Produkten bietet die Ferrari electronic AG seit über fünf-zehn Jahren Komplettlösungen aus Hard- und Software. Neben Serverkomponenten, die Fax-,SMS- und Voicekommunikation in Messaging-Plattformen integrieren, entwickelt und produ-ziert die Firma auch Controller, die diese Dienste am ISDN-Anschluss realisieren.

Der zunehmende Trend zur IP-Telefonie erfordert die Erweiterung dieser Hardware um IP-basierte Kommunikation. Ein wichtiger Schritt in diese Richtung ist die Implementation vonFax over IP (FoIP), mit der sich die vorliegende Arbeit befasst.

Vorgehensweise

Für die Realisierung von FoIP gibt es eine Reihe von Alternativen, die sich in drei Ausprägungenzusammenfassen lassen:

• Store and Forward

• Fax Pass Through

• Real Time Fax over IP (T.38)

Zunächst musste das zu implementierende Verfahren ausgewählt werden. Dazu wurden dieVor- und Nachteile der verschiedenen Alternativen untersucht und bewertet. Das Store andForward Verfahren weicht stark vom gewohnten „Faxerlebnis“ ab, da es am Ende der Übertra-gung keine Bestätigung für den erfolgreichen Empfang liefern kann. Bei Fax Pass Through gibtes technische Probleme vor allem beim Versand längerer Dokumente, da die Taktgeneratorenauf den verschiedenen Übermittlungsabschnitten nicht synchronisiert sind und dadurch Abbrü-che erfolgen können. T.38 vermeidet solche Probleme, sofern es mit entsprechender Qualitätimplementiert und auf Kompatibilität mit fremden Gegenstellen getestet wurde.

Zusätzlich war zu berücksichtigen, welche Varianten von marktüblichen Gegenstellen (Ga-teways) unterstützt werden und für welche Methoden sich der Mitbewerb entschieden hatte.Die Entscheidung fiel auf T.38, da diese Alternative in der Summe der betrachteten Kriterienführend war.

56

Anschließend wurde untersucht, wie die T.38-Verarbeitung in die vorhandenen Software-komponenten am besten einzufügen ist. Als Ergebnis dieser Analyse wurde beschlossen, denbisher verwendeten Modem-Layer durch einen neuen T.38-Layer zu ersetzen, der den T.38 UDPTransport Layer (UDPTL) implementiert. Dies ergibt eine zweite Variante des Faxprozesses,die sich nach oben hin genauso verhält wie die bisherige und bei der auch die vorhandene T.30-Protokollverarbeitung weiter genutzt wird. Im Rahmen der Implementierung musste eine Reihevon Hürden genommen werden. Zunächst galt es, geeignete Komponenten für Testzwecke auszu-wählen. Um diese in Betrieb zu nehmen, mussten im Selbststudium umfangreiche Handbücherkonsultiert werden. Desweiteren war zu prüfen, in welchem Umfang bzw. mit welchen Optio-nen das T.38-Protokoll implementiert werden sollte. Wenn im Test Probleme auftraten, musstegeklärt werden, ob diese durch das Faxgerät auf der Gegenseite, das dazwischen geschaltete Ga-teway oder durch die eigene Implementation verursacht wurden. Eine Reihe vergleichender Tests– auch ohne Einbeziehung des hier betrachteten Probanden – zeigte, dass die Interoperabilitätvon T.38-fähigen Geräten (noch) keine Selbstverständlichkeit ist.

Ergebnisse der Arbeit

Im Anschluss an die Implementation wurde eine Reihe von Tests durchgeführt, um das Verhaltenin Verbindung mit unterschiedlichen Gegenstellen zu prüfen. Dabei wurden an den verwendetenGateways einige Besonderheiten entdeckt, die in bestimmten Fällen zu Kompatibilitätsproble-men oder sonstigen Einschränkungen im Betrieb führen können. Dies zeigt, dass das T.38-Protokoll noch vergleichsweise jung ist und die Implementationen den benötigten Reifegrad,der sich insbesondere in der Kompatibilität zeigt, noch nicht immer erreicht haben.

Die im Rahmen dieser Arbeit entwickelte Lösung zeigte in allen untersuchten Bereichen(Kompatibilität, Sendegeschwindigkeit, Übertragungsqualität und Empfangsverhalten) gute Er-gebnisse und entspricht damit den in Kapitel 3 vorgegebenen Anforderungen. Eine besondereHerausforderung war die Steuerung des Sendetimings, da im Gegensatz zu Gateways mit an-geschlossenen Faxgeräten keine implizite Vorgabe der Datenrate existiert. Es musste ein Weggefunden werden, die Geschwindigkeit der auf der Empfangsseite in Modemsignale umgewan-delten Daten möglichst exakt einzuhalten.

Ausblick

Die hier beschriebene Lösung soll im Laufe des zweiten Halbjahres 2005 mit weiteren Gegen-stellen getestet werden, sobald diese auch das vom Controller verwendete SIP-Protokoll zurSignalisierung unterstützen. Parallel dazu muss die SIP-Steuerung komplettiert und in die Ge-samtarchitektur der OfficeMaster Lösungen integriert werden. Als nächste Erweiterung soll dieUnterstützung von Sprachkommunikation hinzugefügt werden – erst dann bietet der Controlleralle benötigten Funktionen auch in IP-Umgebungen an. Desweiteren ist zu entscheiden, ob eserforderlich ist, neben SIP auch H.323 als Signalisierungsprotokoll zu unterstützen.

Anhang A. Ergänzende Details zu den Grundlagen 57

Anhang A

Ergänzende Details zu den Grundlagen

Im Anhang werden Diagramme, Tabellen und Abbildungen präsentiert, die zur weiteren Ver-tiefung des Themas dienen.

A.1 Textabschnitte im T.30-Standard 07/2003

1 Scope2 Terms and definitions3 Description of a facsimile call4 Tonal signal functions and formats

Beschreibung von CNG und CED.5 Binary coded signalling procedure

Hier sind sämtliche Steuernachrichten und Prozedurabläufe ausführlich dokumentiert.6 Use of the modulation system defined in ITU-T Rec. V.34

Bis zur maximalen Übertragungsgeschwindigkeit von 14.400 bps sind die Abläufe wiebisher beschrieben, es werden lediglich unterschiedliche Modulationsverfahren (V.27ter,V.29, V.17) in Phase C genutzt. Für höhere Bitraten bis 33.600 bps wird nach V.34 mo-duliert und der gesamte Verlauf ändert sich durch den Einsatz von V.8 in der „Handshake-Phase“.

A Procedure for G3 document facsimile transmission in the general switched telephone net-work incorporating error correctionDer optionale Error Correction Mode (ECM) ist hier beschrieben (siehe obige Beschrei-bung der Phase C). Moderne Faxgeräte enthalten diese Option in der Regel.

B BFT diagnostic messageIn diesem Abschnitt wird die Aushandlung des optionalen binary file transfer (BFT)festgelegt. Damit ist es möglich, beliebige Dateien zwischen zwei Gegenstellen mit denBetriebsmitteln einer Faxeinrichtung zu übertragen. Diese Option ist in den letzten Jah-ren durch Internet-Technologien vollständig verdrängt worden – sie wurde auch vorhernur von wenigen Geräten unterstützt.

C Procedure for Group 3 document facsimile transmission on the Integrated Services DigitalNetwork or on the GSTN using duplex modulation systemsDiese Option definiert eine Faxübertragung nach T.30-Protokoll, jedoch digital im ISDN-

58 A.1. Textabschnitte im T.30-Standard 07/2003

B-Kanal. Damit wird eine Geschwindigkeit von 64 kbps erreicht. Dem Verfasser sind –mit Ausnahme der älteren ferrariFAX-ISDN-Karte – keine Implementationen dieser Be-triebsart bekannt. Sie war, nachdem sich der Misserfolg des für ISDN gedachten Gruppe-4-Standards abzeichnete, als Alternative vorgesehen.

D Optional automatic terminal selection proceduresHier wird die Auswahlmethode der Betriebsart bei Kombigeräten (Fax mit Tele-fon/Anrufbeantworter) beschrieben.

E Procedure for the Group 3 document facsimile transmission of continuous-tone colourimagesFax in Farbe – wie hier beschrieben – ist nach wie vor praktisch ohne Bedeutung.

F Procedures for Group 3 facsimile transmission using the half-duplex modulation systemdefined in ITU-T Rec. V.34

G Procedures for secure Group 3 document facsimile transmission using the HKM and HFXsystemBeschreibt sichere Faxübertragung durch Verschlüsselung mittels Hawthorne Key Mana-gement (HKM) bzw. Hawthorne Facsimile Cipher (HFX).

H Security in facsimile G3 based on the RSA algorithmI Procedure for the Group 3 document facsimile transmission of colour and gray-scale

images using T.43J Procedure for Group 3 document facsimile transmission of Mixed Raster Content (MRC)

imagesDie hier festgelegte gemischte Übertragung von Rastergrafik und Textabschnitten hatsich – wie viele andere Optionen – nicht etablieren können.

K Procedure for the Group 3 document facsimile transmission of continuous-tone colour andgray scale images (sYCC)

I Index of abbreviations used in this RecommendationII List of commands and appropriate responsesIII Alternative procedures used by some terminals which conform to the pre 1996 versions of

this RecommendationIV Signal sequence examplesV Procedure for binary file transmission with protocol examplesVI Mixed Raster Content examplesVII Application rules for use of V.8 with Group 3 facsimileVIII Examples for Internet routing/polling

Vorschläge zur Adressierung von Faxen, die per T.37 store-and-forward über Relaissta-tionen geschleust werden.


A.2 Untersuchung der Verbreitung von Faxoptionen

Zur Festlegung der zu implementierenden Optionen war es erforderlich, einen Überblicküber die Verbreitung von Geräteoptionen zu erhalten. Hierzu wurden zunächst willkür-lich Faxnummern von Firmen aus dem Branchenfernsprechbuch ausgewählt und in einerListe erfasst. Ganz repräsentativ ist diese Auswahl nicht, da sie keine Privatanwenderbeinhaltet. Andererseits nutzen die Kunden der Ferrari electronic AG deren Faxlösun-gen fast ausschließlich für die business-to-business Kommunikation, so dass die gewählteMethode gut geeignet ist.

Für die Ermittlung der Eigenschaften wurde ein Programm geschrieben, das ein imPC integriertes Faxmodem ansteuert, um die Nummern der Reihe nach anzurufen. Dievon den Faxgeräten in der Phase B gemeldeten Blöcke (vergleiche 2.2.1) wurden in einerseparaten Datei festgehalten und anschließend die Verbindung beendet. Um eine einiger-maßen aussagekräftige Menge von eintausend Geräten zu erreichen, mussten insgesamt1273 Nummern angerufen werden. Die anschließende Auswertung ergab folgendes Bild(die Prozentzahlen beziehen sich auf die erreichten Empfänger):

Ergebnis der Messung an 1000 GerätenAnzahl Prozent Beschreibung––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––-809 80% Geräte, die „non standard facilities“ signalisieren977 98% Geräte, die eine Faxkennung senden20 2% DIS 24 Bit

301 30% DIS 32 Bit2 0% DIS 40 Bit

316 32% DIS 48 Bit65 6% DIS 56 Bit5 0% DIS 64 Bit1 0% DIS 72 Bit

287 29% DIS 80 Bit1 0% DIS 88 Bit0 0% DIS 96 Bit0 0% DIS 104 Bit2 0% DIS 112 Bit0 0% DIS 120 Bit0 0% DIS 128 Bit0 0% Internet aware Faxdevice2 0% V.27ter (2400 4800 bps)

218 22% V.29 und V.27ter (2400 bis 9600 bps)777 78% V.17, V.29, V.27ter (2400 bis 14400 bps)222 22% V.8 (für V.34 – bis 33600 bps)999 100% Feinauflösung (ca. 200 dpi)

60 A.3. Kodierung der Faxeigenschaften in DIS/DCS

870 87% Fehlerkorrekturmodus881 88% Modified Read797 80% Modified Modified Read (T.6)182 18% Auflösung 300 dpi65 6% Auflösung 400 dpi8 1% Binary Filetransfer0 0% Document Transfermode0 0% Electronic Data Interchange (EDI)0 0% Basic Transfer Mode (einfacher Filetransfer)0 0% Character Mode0 0% Mixed Mode

155 15% JPEG155 15% Farbe

0 0% HKM (Hawthorne Key Management)0 0% RSA Verschlüsselung0 0% HFX (Hawthorne Facsimile Cipher)

Kommentierung der ErgebnisseFast alle Geräte (98%) senden die – jedoch nicht immer korrekt eingestellte – optio-

nale Faxkennung. Von den Eigenschaften, die nach 1993 eingeführt wurden (siehe [7])werden überwiegend höhere Auflösung, V.34-Übertragung sowie Faxen in Farbe ange-boten. Eigenschaften, die jenseits der 80-Bit Grenze definiert sind, werden fast nichtgenutzt, dazu gehört zum Beispiel die Möglichkeit der verschlüsselten Kommunikation.

Mit 15 Prozent ist der Anteil an Faxmaschinen, die Farbe unterstützen, relativ hoch– allerdings muss diese Möglichkeit vom Benutzer beim Versand aktiviert werden undsie funktioniert nur mit entsprechend ausgestatteten Gegenstellen. Die Farboption isteher ein Abfallprodukt bei den populären Kombigeräten, die Farbscanner und Tinten-strahldrucker mit Kopier- und Faxfunktion vereinen. Viele Nutzer werden wohl gar nichtwissen, dass sie auch in Farbe faxen könnten.

Funktionen wie binary file transfer, EDI und Mixed Mode spielen keine Rolle – siewaren der Versuch, Faxgeräte zu universellen Kommunikationsmaschinen umzudefinie-ren. Angesichts weltweiter Rechnervernetzung auf Basis von Internettechnologien ist hierkein Bedarf zu sehen. Viele Geräte (78%) beherrschen eine Übertragungsrate von 14.400bps, kombiniert mit zweidimensionaler Komprimierung (80 bzw. 88%) werden Faxseiten– je nach Inhalt – meist in deutlich weniger als einer Minute übertragen.

A.3 Kodierung der Faxeigenschaften in DIS/DCS

Auf den folgenden Seiten ist die komplette Tabelle der Geräteeigenschaften und diebitweise Kodierung derselben abgedruckt (Auszug aus [7]).


Table 2/T.30

Bit No. DIS/DTC Note DCS Note

1 Store and forward Internet fax- Simple mode (ITU-T Rec. T.37)

60, 63 Store and forward Internet fax- Simple mode (ITU-T Rec. T.37)

60, 63

2 Reserved 1 Reserved 1

3 Real-time Internet fax (ITU-T Rec. T.38)

61, 63 Real-time Internet fax (ITU-T Rec. T.38)

61, 63

4 3rd Generation Mobile Network 71 3rd Generation Mobile Network 71


6 V.8 capabilities 23 Invalid 24

7 "0" = 256 octets preferred "1" = 64 octets preferred

23, 42 Invalid 24


9 Ready to transmit a facsimile document (polling)

18 Set to "0"

10 Receiver fax operation 19 Receiver fax operation 20

11, 12, 13, 14

Data signalling rate Data signalling rate

0, 0, 0, 0 ITU-T Rec. V.27 ter fall-back mode 2400 bit/s, ITU-T Rec. V.27 ter 33 0, 1, 0, 0 ITU-T Rec. V.27 ter 3 4800 bit/s, ITU-T Rec. V.27 ter

1, 0, 0, 0 ITU-T Rec. V.29 9600 bit/s, ITU-T Rec. V.29

1, 1, 0, 0 ITU-T Recs V.27 ter and V.29 7200 bit/s, ITU-T Rec. V.29

0, 0, 1, 0 Not used Invalid 31 0, 1, 1, 0 Reserved Invalid 31

1, 0, 1, 0 Not used Reserved

1, 1, 1, 0 Invalid 32 Reserved

0, 0, 0, 1 Not used 14 400 bit/s, ITU-T Rec. V.17

0, 1, 0, 1 Reserved 12 000 bit/s, ITU-T Rec. V.17 1, 0, 0, 1 Not used 9600 bit/s, ITU-T Rec. V.17

1, 1, 0, 1 ITU-T Recs V.27 ter, V.29, and V.17

31 7200 bit/s, ITU-T Rec. V.17


0, 1, 1, 1 Reserved Reserved


1, 1, 1, 1 Reserved Reserved

15 R8 × 7.7 lines/mm and/or 200 × 200 pels/25.4 mm

10, 11, 13, 25,

34

R8 × 7.7 lines/mm or 200 × 200 pels/25.4 mm

10, 11, 13, 25,

34

16 Two-dimensional coding capability Two-dimensional coding

17, 18 Recording width capabilities 27 Recording width 27

(0,0) Scan line length 215 mm ± 1% Scan line length 215 mm ± 1%

(0,1) Scan line length 215 mm ± 1% and Scan line length 255 mm ± 1% and

Scan line length 303 mm ± 1%

Tabelle A.1: Kodierung der Faxeigenschaften (Seite 1/6)


Table 2/T.30



(1,0) Scan line length 215 mm ± 1% and Scan line length 255 mm ± 1%


(1,1) Invalid 6 Invalid

19, 20 Recording length capability Recording length

(0,0) A4 (297 mm) 2 A4 (297 mm) 2 (0,1) Unlimited Unlimited

(1,0) A4 (297 mm) and B4 (364 mm) B4 (364 mm)

(1,1) Invalid Invalid

21, 22, 23

Minimum scan line time capability at the receiver

4, 8, 23

Minimum scan line time 8, 24

(0,0,0) 20 ms at 3.85 l/mm: T7.7 = T3.85 20 ms

(0,0,1) 40 ms at 3.85 l/mm: T7.7 = T3.85 40 ms

(0,1,0) 10 ms at 3.85 l/mm: T7.7 = T3.85 10 ms

(1,0,0) 5 ms at 3.85 l/mm: T7.7 = T3.85 5 ms

(0,1,1) 10 ms at 3.85 l/mm: T7.7 = 1/2 T3.85

(1,1,0) 20 ms at 3.85 l/mm: T7.7 = 1/2 T3.85

(1,0,1) 40 ms at 3.85 l/mm: T7.7 = 1/2 T3.85

(1,1,1) 0 ms at 3.85 l/mm: T7.7 = T3.85 0 ms

24 Extend field 5 Extend field 5

25 Reserved 1, 41 Reserved 1, 41

26 Uncompressed mode Uncompressed mode

27 Error correction mode 17 Error correction mode 17

28 Set to "0" Frame size 0 = 256 octets Frame size 1 = 64 octets

7 24



31 T.6 coding capability 9, 17 T.6 coding enabled 9, 17


33 Field not valid capability Field not valid capability

34 Multiple selective polling capability 52 Set to "0"

35 Polled Subaddress 26, 44, 45

Set to "0"

36 T.43 coding 17, 25, 34, 35, 37, 39,

40

T.43 coding 17, 25, 34, 35, 37, 39,

40

37 Plane interleave 25, 46 Plane interleave 25, 46

38 Voice coding with 32 k ADPCM (ITU-T Rec. G.726)

58, 59 Voice coding with 32 k ADPCM (ITU-T Rec. G.726)

17, 58, 59



Table 2/T.30


39 Reserved for the use of extended voice coding

1 Reserved for the use of extended voice coding

1


41 R8 × 15.4 lines/mm 10, 62 R8 × 15.4 lines/mm 10, 62

42 300 × 300 pels/25.4 mm 34, 80 300 × 300 pels/25.4 mm 34

43 R16 × 15.4 lines/mm and/or 400 × 400 pels/25.4 mm

10, 12, 13, 34,

80

R16 × 15.4 lines/mm and/or 400 × 400 pels/25.4 mm

10, 12, 13, 34

44 Inch-based resolution preferred 13, 14 Resolution-type selection "0": metric-based resolution "1": inch-based resolution

13, 14

45 Metric-based resolution preferred 13, 14 Don't care

46 Minimum scan line time capability for higher resolutions "0": T15.4 = T7.7 "1": T15.4 = 1/2 T7.7

15 Don't care

47 Selective polling 26, 44 Set to "0"


49 Subaddressing capability Subaddressing transmission 26

50 Password 26 Sender Identification transmission 26

51 Ready to transmit a data file (polling)

17, 21 Set to "0"


53 Binary File Transfer (BFT) 16, 17, 21

Binary File Transfer (BFT) 16, 17

54 Document Transfer Mode (DTM) 17, 21 Document Transfer Mode (DTM) 17

55 Electronic Data Interchange (EDI) 17, 21 Electronic Data Interchange (EDI) 17


57 Basic Transfer Mode (BTM) 17, 21 Basic Transfer Mode (BTM) 17, 59


59 Ready to transmit a character or mixed mode document (polling)

17, 22 Set to "0"

60 Character mode 17, 22 Character mode 17


62 Mixed mode (Annex E/T.4) 17, 22 Mixed mode (Annex E/T.4) 17, 22



65 Processable mode 26 (ITU-T Rec. T.505)

17, 22 Processable mode 26 (ITU-T Rec. T.505)

17, 22

66 Digital network capability 43 Digital network capability 43

67 (0)

Duplex and half-duplex capabilities Half-duplex operation only

Duplex and half-duplex capabilities



Table 2/T.30


(1) Duplex and half-duplex operation Half-duplex operation only Duplex operation

68 JPEG coding 17, 25, 34, 35, 39, 40

Full colour mode 17, 25, 34, 35, 39, 40

69 Full colour mode 25, 35 Full colour mode 25, 35

70 Set to "0" 36 Preferred Huffman tables 25, 36

71 12 bits/pel component 25, 37 12 bits/pel component 25, 37


73 No subsampling (1:1:1) 25, 38 No subsampling (1:1:1) 25, 38

74 Custom illuminant 25, 39 Custom illuminant 25, 39

75 Custom gamut range 25, 40 Custom gamut range 25, 40

76 North American Letter (215.9 × 279.4 mm) capability

28 North American Letter (215.9 × 279.4 mm)

77 North American Legal (215.9 × 355.6 mm) capability

28 North American Legal (215.9 × 355.6 mm)

78 Single-progression sequential coding (ITU-T Rec. T.85) basic capability

17, 29, 30

Single-progression sequential coding (ITU-T Rec. T.85) basic

17, 29

79 Single-progression sequential coding (ITU-T Rec. T.85) optional L0 capability

17, 29, 30

Single-progression sequential coding (ITU-T Rec. T.85) optional L0

17, 29


81 HKM key management capability HKM key management selected

82 RSA key management capability RSA key management selected 47

83 Override capability 53 Override mode selected 53

84 HFX40 cipher capability HFX40 cipher selected

85 Alternative cipher number 2 capability

56 Alternative cipher number 2 selected

56

86 Alternative cipher number 3 capability

56 Alternative cipher number 3 selected

56

87 HFX40-I hashing capability HFX40-I hashing selected


89 Alternative hashing system number 2 capability

57 Alternative hashing system number 2 selected

57

90 Alternative hashing system number 3 capability

57 Alternative hashing system number 3 selected

57

91 Reserved for future security features

1 Reserved for future security features

1

92 T.44 (Mixed Raster Content) 17, 50, 69

T.44 (Mixed Raster Content) 17, 50, 69

93 T.44 (Mixed Raster Content) 17, 50, T.44 (Mixed Raster Content) 17, 50,



Table 2/T.30


69 69

94 T.44 (Mixed Raster Content) 17, 50, 69

T.44 (Mixed Raster Content) 17, 50, 69

95 Page length maximum strip size for T.44 (Mixed Raster Content)

51 Page length maximum strip size for T.44 (Mixed Raster Content)

51


97 Colour/gray-scale 300 pels/ 25.4 mm × 300 lines/ 25.4 mm or 400 pels/ 25.4 mm × 400 lines/ 25.4 mm resolution

49, 80 Colour/gray-scale 300 pels/25.4 mm × 300 lines/25.4 mm or 400 pels/25.4 mm × 400 lines/25.4 mm resolution

49

98 100 pels/25.4 mm × 100 lines/25.4 mm for colour/gray scale

10, 48 100 pels/25.4 mm × 100 lines/25.4 mm for colour/gray scale

10, 48

99 Simple Phase C BFT Negotiations capability

54, 55 Simple Phase C BFT Negotiations capability

54, 55

100 Extended BFT Negotiations capability

Set to "0"

101 Internet Selective Polling Address (ISP)

26 Set to "0"

102 Internet Routing Address (IRA) 26 Internet Routing Address (IRA) transmission

26



105 600 pels/25.4 mm × 600 lines/25.4 mm

81 600 pels/25.4 mm × 600 lines/25.4 mm

106 1200 pels/25.4 mm × 1200 lines/25.4 mm

81 1200 pels/25.4 mm × 1200 lines/25.4 mm

107 300 pels/25.4 mm × 600 lines/25.4 mm

62 300 pels/25.4 mm × 600 pels/25.4 mm

62

108 400 pels/25.4 mm × 800 lines/25.4 mm

62 400 pels/25.4 mm × 800 lines/25.4 mm

62

109 600 pels/25.4 mm × 1200 lines/25.4 mm

62 600 pels/25.4 mm × 1200 lines/25.4 mm

62

110 Colour/gray scale 600 pels/25.4 mm × 600 lines/25.4 mm resolution

64, 81 Colour/gray scale 600 pels/25.4 mm × 600 lines/25.4 mm resolution

64

111 Colour/gray scale 1200 pels/25.4 mm × 1200 lines/25.4 mm resolution

65, 81 Colour/gray scale 1200 pels/25.4 mm × 1200 lines/25.4 mm resolution

65

112 Field Extend 5 Field Extend 5

113 Double-sided printing capability (alternate mode)

66, 67 Double-sided printing capability (alternate mode)

67

114 Double-sided printing capability 66, 67, Double-sided printing capability 67



Table 2/T.30


(continuous mode) 68 (continuous mode)

115 Black and white mixed raster content profile (MRCbw)

17, 50, 69

Not used set to "0" 17, 50, 69

116 T.45 (run length colour encoding) 17, 78 T.45 (run length colour encoding) 17, 78

117, 118 SharedDataMemory capacity 70 SharedDataMemory required 70

(0,0) Not available Not Used (0,1) Level 1 = 1.0 Mbytes Level 1 = 1.0 Mbytes

(1,0) Level 2 = 2.0 Mbytes Level 2 = 2.0 Mbytes

(1,1)

Level 3 = unlimited (i.e., ≥32 Mbytes)

Level 3 = unlimited (i.e., ≥32 Mbytes)

119 Reserved Reserved

120 Extend field Extend field

121 Flow Control Capability for T.38 communication

72, 73 Flow Control Capability for T.38 communication

72, 73

122 K>4 74 K>4 74

123 Internet aware T.38 mode fax device capability

75 Internet aware fax device operating in T.38 mode

76, 77

124,125,126

T.89 (Application profiles for ITU-T Rec. T.88)

78, 79 T.89 (Application profiles for ITU-T Rec. T.88)

78, 79

(0,0,0) Not used Not used

(0,0,1) Profile 1 Profile 1 (0,1,0) Profile 2 Profile 2

(0,1,1) Profile 3 Profile 3

(1,0,0) Profiles 2 and 3 Invalid

(1,0,1) Reserved Reserved (1,1,0) Reserved Reserved

(1,1,1) Reserved Reserved

127 sYCC-JPEG coding 17, 82 sYCC-JPEG coding 17, 82



A.4 Kodierung/Komprimierung von Faxdokumenten

Zur Komprimierung der Dokumentdaten wird bei Fax Gruppe 3 standardmäßig das inITU-T T.4 [3] beschriebene Modified Huffmann Verfahren verwendet. Im Gegensatz zurnormalen Huffmankodierung wird die Tabelle der Codes nicht dynamisch aufgebaut,sondern ist von vornherein festgelegt. Jedes Codewort beschreibt dabei eine bestimmteLauflänge von schwarzen oder weißen Bildpunkten. Die Tabelle berücksichtigt die Häu-figkeit verschiedener Längen bei typischen Schriftstücken. Eine Ausschnittvergrößerungaus einem Faxdokument soll das Prinzip veranschaulichen:

Abbildung A.1: Beispiel für Faxkomprimierung: Kurze Codewörter für häufig vorkom-mende Lauflängen sorgen für die gewünschte Komprimierung.

Die rot markierte Pixelzeile wird wie folgt kodiert:

Beispiel für Modified Huffman (MH)-KodierungWeiße Pixel Schwarze Pixel Modified Huffmann Code2 0111

4 0111 00111

2 116 1110

2 1110 00111

Tabelle A.7: Faxkodierung eines Zeilenabschnitts

In Tabelle A.7 wird die Kodierung eines Teils einer Pixelzeile dargestellt. Dabei wer-den 27 Pixel in 25 Bits kodiert – die Komprimierung ist also gering. Sie wird aber

68 A.4. Kodierung/Komprimierung von Faxdokumenten

wesentlich besser, wenn wie vorgeschrieben jeweils ganze Pixelzeilen à 1728 Punktenkomprimiert werden, da dabei regelmäßig längere weiße Strecken vorkommen, die beson-ders zur Komprimierung beitragen. So werden weiße Lauflängen bis zu einer Länge von63 Pixel grundsätzlich in maximal 8 Bits kodiert. Lauflängen ab 64 Pixel werden in zweiKodewörter umgesetzt: ein make-up code kodiert Vielfache von 64, der Rest wird – wiebei Lauflängen bis 63 Pixel – in einem terminating code angegeben.

Weiße und schwarze Abschnitte werden alternierend kodiert, wobei jede Zeile miteiner weißen Lauflänge beginnt. Diese Festlegung erlaubt die doppelte Nutzung identi-scher Bitfolgen für unterschiedliche weiße und schwarze Längen, da die Bedeutung ausdem Kontext hervorgeht. Damit kann die unterschiedliche Verteilung der Häufigkeit beiSchwarz und Weiß berücksichtigt werden. Wenn die Zeile mit schwarzen Punkten begin-nen soll, muss zunächst ein weißer Abschnitt der Länge Null angegeben werden.

Faxinhalte sind bei MH (Modified Huffmann) Kodierung wie folgt aufgebaut:

• Die Seite startet mit EOL (end of line = 000000000001)

• Jede Zeile beginnt mit einem weißen Abschnitt, danach folgen abwechselnd schwar-ze und weiße Teile

• Nach 1728 Pixel ist die Zeile zu Ende – an dieser Stelle können optional Füllbits(Nullen) eingefügt werden, um die vom Empfangsgerät signalisierte Minimaldauereiner Zeile einzuhalten1

• Danach folgt EOL sowie die nächste Zeile

• Am Ende der Seite werden sechs aufeinanderfolgende EOL-Codes gesendet. DieseSequenz heißt RTC (return to control), da sie dem Empfänger mitteilt, dass diePhase C (siehe 2.2) beendet ist und in der folgenden Phase B wieder Kommandosim V.21-Modus ausgetauscht werden

Tabelle A.9 enthält die „Terminating Codes“, also die Codes für weiße und schwarzeLauflängen von 0 bis 63. In Tabelle A.8 finden sich „Make-Up Codes“, die bei Lauflängengrößer 63 Pixel benötigt werden. Nach einem solchen Codewort muss in jedem Fall einabschließender Terminating Code folgen.

Neben der bisher beschriebenen Modified Huffman Kodierung können optional zweidi-mensionale Verfahren verwendet werden. Diese berücksichtigen zusätzlich die Ähnlichkeitaufeinanderfolgender Pixelzeilen und kodieren lediglich die Abweichung zur vorigen Zei-le. Bei der Modified Read (MR) Komprimierung muss in regelmäßigen Abständen einenMH-kodierte Zeile gesendet werden, da sich sonst auftretende Fehler bis zum Ende derSeite fortpflanzen würden. Die beste Komprimierung wird mit Modified Modified Read

1Dies ist ein Relikt aus der Anfangszeit der Fax Gruppe 3, in der die Geräte Dokumente währenddes Empfangs kontinuierlich auf Rollenpapier gedruckt haben und nicht ganze Seiten zwischenspeichernkonnten.


T.4 MH Make-Up CodesLänge Weiß Schwarz Länge Weiß Schwarz

64 11011 000000111 128 10010 000011001000192 010111 000011001001 256 0110111 000001011011320 00110110 000000110011 384 00110111 000000110100448 01100100 000000110101 512 01100101 0000001101100576 01101000 0000001101101 640 01100111 0000001001010704 011001100 0000001001011 768 011001101 0000001001100832 011010010 0000001001101 896 011010011 0000001110010960 011010100 0000001110011 1024 011010101 0000001110100

1088 011010110 0000001110101 1152 011010111 00000011101101216 011011000 0000001110111 1280 011011001 00000010100101344 011011010 0000001010011 1408 011011011 00000010101001472 010011000 0000001010101 1536 010011001 00000010110101600 010011010 0000001011011 1664 011000 00000011001001728 010011011 0000001100101

Tabelle A.8: Tabelle der vorbereitenden Make-Up Codes

Abbildung A.2: Zweidimensionale Faxkomprimierung: Definition des Begriffs „changingpicture elements“ (aus [4])

(MMR) erzielt – dort wird grundsätzlich der Error Correction Mode (ECM) vorausge-setzt, der für eine fehlerfreie Übertragung sorgt. Deshalb kann bei MMR die gesamteSeite zweidimensional komprimiert werden, ohne zwischendurch MH-kodierte Referenz-zeilen zu senden. Abbildung A.2 zeigt, welche Fälle von Ähnlichkeiten zur vorherigen

70 A.4. Kodierung/Komprimierung von Faxdokumenten

T.4 MH Terminationg CodesLänge Weiß Schwarz Länge Weiß Schwarz

0 00110101 0000110111 1 000111 0102 0111 11 3 1000 104 1011 011 5 1100 00116 1110 0010 7 1111 000118 10011 000101 9 10100 000100

10 00111 0000100 11 01000 000010112 001000 0000111 13 000011 0000010014 110100 00000111 15 110101 00001100016 101010 0000010111 17 101011 000001100018 0100111 0000001000 19 0001100 000010011120 0001000 00001101000 21 0010111 0000110110022 0000011 00000110111 23 0000011 0000010100024 0101000 00000010111 25 0101011 0000001100026 0010011 000011001010 27 0100100 00001100101128 0011000 000011001100 29 00000010 00001100110130 00000011 000001101000 31 00011010 00000110100132 00011011 000001101010 33 00010010 00000110101134 00010011 000011010010 35 00010100 00001101001136 00010101 000011010100 37 00010110 00001101010138 00010111 000011010110 39 00101000 00001101011140 00101001 000001101100 41 00101010 00000110110142 00101011 000011011010 43 00101100 00001101101144 00101101 000001010100 45 00000100 00000101010146 00000101 000001010110 47 00001010 00000101011148 00001011 000001100100 49 01010010 00000110010150 01010011 000001010010 51 01010100 00000101001152 01010101 000000100100 53 00100100 00000011011154 00100101 000000111000 55 01011000 00000010011156 01011001 000000101000 57 01011010 00000101100058 01011011 000001011001 59 01001010 00000010101160 01001011 000000101100 61 00110010 00000101101062 00110011 000001100110 63 00110100 000001100111

Tabelle A.9: Tabelle der Terminating Codes (Längen bis max. 63 Pixel)

Zeile separat kodiert werden.Tabelle A.9 enthält die terminierenden Codes, mit denen schwarze und weiße Lauf-

längen von 0 bis 63 kodiert werden. Die kürzesten Codewörter (jeweils zwei Bits) wurdenfür schwarze Pixelgruppen der Länge 2 (11) und der Länge 3 (10) vergeben, da diese inSchriftstücken besonders häufig auftreten.


A.5 Modulationsverfahren bei Gruppe-3 Fax

Der Gruppe 3 Faxstandard verwendet eine Reihe unterschiedlicher Modulationsverfahrenzur Steuerung des Ablaufs und zur Übermittlung von Dokumenten. Die wichtigstenVerfahren werden in diesem Abschnitt kurz vorgestellt.

ITU-T V.21 [26]

Dieser Modemstandard, der in seiner ersten Version bereits 1964 festgelegt wurde, er-laubt eine robuste Kommunikation mit 300 Bits pro Sekunde, wobei jedes Bit in einemSchritttakt übertragen wird. In diesem Falle ist also die Baudrate identisch mit der Bi-trate. Zu übertragende Bitströme werden per Frequency Shift Keying (FSK) moduliert,das heißt, dass zwei verschiedene Frequenzen jeweils die beiden logischen Zustände 0 und1 repräsentieren. V.21 unterstützt das gleichzeitige Senden und Empfangen (Duplexbe-trieb), wobei in einer Richtung (Kanal 1) die Mittenfrequenz 1080 Hz beträgt, in deranderen (Kanal 2) 1750 Hz. Der logische Zustand Null wird durch einen um 100 Hzüber dieser Frequenz liegenden Ton dargestellt, die Eins durch eine Frequenz, die um100 Hz darunter liegt.

Beim Faxbetrieb nach Gruppe 3 wird V.21 zum Senden von Kommandos und Ant-worten verwendet. Da die Übertragung halbduplex erfolgt, wird in beiden Richtungennur Kanal 2 benutzt. Die gesendeten Frequenzen sind in diesem Falle 1850 Hz für logischNull bzw. 1650 Hz für logisch Eins.

ITU-T V.27 ter [27]

Dieses Verfahren ist das einzige, das gemäß T.4-Standard [3] von jedem Gruppe 3 Fax-gerät für die Übermittlung von Dokumentinhalten unterstützt werden muss2.

V.27 definiert zwei Geschwindigkeiten (2400 und 4800 Bits pro Sekunde). Bei 4800bps beträgt die Modulationsrate 1600 baud – pro Schritt werden also 3 Bits übertra-gen. Jede dieser sogenannten Tribit-Gruppen wird durch einen Wechsel der Phasenlagekodiert - insgesamt gibt es acht Phasenlagen in Schritten von 45◦. Bei schlechten Ver-bindungen erfolgt die Übertragug mit 2400 bps, die Modulationsrate beträgt dabei 1200baud und mit jedem Schritt werden zwei Bits übertragen. Das ergibt insgesamt vier Bit-kombinationen, die durch Phasenverschiebungen um 0◦, 90◦, 180◦ oder 270◦ signalisiertwerden. Die Trägerfrequenz beträgt in beiden Fällen 1800 Hz.

ITU-T V.29 [28]

Für Gruppe 3 ist V.29 ein wichtiges Verfahren, da es nahezu von allen Faxgeräten welt-weit unterstützt wird und mit 9600 Bits pro Sekunde akzeptable Übertragungsraten von

2Solche Geräte existierten allerdings nur für wenige Jahre, danach wurden fast ausschließlich Fax-maschinen eingesetzt, die mindestens V.29 und damit 9600 bps unterstützen.

72 A.5. Modulationsverfahren bei Gruppe-3 Fax

mehr als einer Seite pro Minute erreicht. Erst in den letzten Jahren (ab Ende der 1990erJahre) wird es zunehmend von V.17 abgelöst, das um 50% schneller arbeitet.

Der V.29 Standard ist charakterisiert durch:

• Fallback Geschwindigkeiten von 7200 und 4800 Bits pro Sekunde (bei Fax nur 7200,da für 4800 bps V.27 ter verwendet wird)

• Duplex- und halbduplex Betriebsart mit kontinuierlichem oder geschaltetem Träger(bei Fax nur halbduplex)

• Kombinierte Amplituden- und Phasenmodulation

• Synchrone Betriebsart

• Nutzung eines automatischen adaptiven Entzerrers (Equalizer), also kontinuierlicheAnpassung an sich verändernde Leitungsbedingungen

Die Trägerfrequenz bei V.29 beträgt 1700 ± 1 Hz. Bei der Übertragung mit 9600 Bitspro Sekunde wird der Datenstrom in Gruppen zu vier Bits (Q1 bis Q4) eingeteilt. Daserste Bit (Q1) steuert in Verbindung mit der absoluten Phasenlage die Amplitude desSendesignals (siehe Tabelle A.10), die restlichen Bits (Q2 bis Q4) bewirken einen Pha-senwechsel relativ zu bisherigen Phasenlage des Trägers. Dieser beträgt ein Vielfachesvon 45◦. Da zur Adaption des Equalizers und zur Taktregenerierung regelmäßige Pha-senwechsel stattfinden sollen, wird das Signal vor der Modulation durch einen Scrambler(„Verwürfler“) geleitet. Dieser verhindert, dass längere gleichförmige Bitzustände auftre-ten (die in typischen Quellsignalen durchaus üblich sind – bei Fax zum Beispiel beimSenden des TCF-Signals, das nur aus Nullen besteht).

Sendeamplitude bei V.29Q1 absolute Phasenlage relative Signalamplitude0 0◦, 90◦, 180◦, 270◦ 31 0◦, 90◦, 180◦, 270◦ 50 45◦, 135◦, 225◦, 315◦

√2

1 45◦, 135◦, 225◦, 315◦ 3×√

2

Tabelle A.10: Ermittlung der Amplitude bei V.29 in Abhängigkeit von Bit Q1 und derabsoluten Phasenlage, die am Anfang des Sendevorgangs etabliert wurde.

Die Anwendung der hier beschriebenen Regeln ergibt eine Verteilung der Signalpunk-te wie in Abbildung A.3 (aus [28]) dargestellt. Die einzelnen Punkte sind so angeordnet,dass sie ungefähr gleich weit voneinander entfernt sind.


Abbildung A.3: Signalkonstellation bei V.29 und 9600 bps (aus [28])

Bei V.29 mit einer Übertragungsrate von 7200 Bits pro Sekunde entfällt die Ampli-tudenmodulation. Für jede Phasenlage, in der jeweils drei Bits kodiert werden, ist dieAmplitude – wie in Abbildung A.4 gezeigt – fest vorgegeben.



ITU-T V.17 [29]

Da Modemverfahren mit zunehmender Übertragungsrate immer komplexer werden, kön-nen sie im Rahmen dieser Arbeit nicht detailliert erläutert werden. Der V.17 Standardsoll deshalb nur anhand seiner wichtigsten Eigenschaften klassifiziert werden:

• Synchrone Übertragung

• Geschwindigkeiten: 7200, 9600, 12000 und 14400 Bits pro Sekunde

• Trägerfrequenz: 1800 ± 1 Hz

• Modulationsrate: 2400 Symbole pro Sekunde

• Modulationsart: Quadratur Amplituden Modulation (QAM)

• Nutzung von Scrambler („Verwürfler“), adaptivem Entzerrer und achtstufigerTrellis-Kodierung zur Verbesserung der Fehlertoleranz

• Zwei verschiedene Trainingssequenzen: langes Training und kurzes Training („re-sync“)

Eine kompakte Beschreibung der Trellis-Kodierung findet sich zum Beispiel unterhttp://www.it-administrator.de/lexikon/trellis-kodierung.html:

„Fehlerkorrekturverfahren, das u.a. in Hochgeschwindigkeitsmodems und bei 1000Ba-seT eingesetzt wird. Ähnlich einem Paritätsbit werden dem zu übertragendem Signal In-formationen über Amplituden- und/oder Phasenlage des Signals hinzugefügt, so daß derEmpfänger eine Plausibilitätsprüfung und Fehlerkorrektur durchführen kann. Außerdemsind die erlaubten Codesequenzen so gewählt, daß die daraus resultierenden Pegelwechselimmer größer sind als bei einer rein zufälligen Auswahl. Durch die geschickte Wahl wirddas Signal/Rausch-Verhältnis der Übertragung verbessert und es wird erreicht, daß imMittel keine Gleichspannung auf der Leitung entsteht.“

Abbildung A.5 zeigt die insgesamt 128 Signalpunkte bei V.17 und 14400 Bits proSekunde.

http://www.it-administrator.de/lexikon/trellis-kodierung.html


0111100 0110010 0011100 1110010 0001100

0111001 0100101 0011001 1000101 0001001

0111011 0110111 1111011 1110111

0111000 0111110 0101000 1111110 1001000

0110001 0101101 0010001 1001101

0110100 0100010 0010100 1100010 0000100

0011011 0100111 1011011 1100111

1111000 0011110 1101000 1011110

1110001 1101101 1010001

1110100 1000010 1010100

0001011 1000111

0110000 0101110 0100000 1101110 1000000

0101011 0010111 1101011 1010111

1111100 0010010 1011100 1010010

1111001 1100101 1011001

1110000 1001110 1100000

1001011 0000111

1001100 1111010 0101100 0111010

0000101 1001001 0010101 0101001 0110101

1110011 1111111 0110011

0001000 1110110 0011000 0110110

0001101 1000001 0011101 0100001

1000100 1101010 0100100 0101010

1010011 1101111 0010011

1010110 1011000 0010110

1011101 1100001

1100100 1001010

0000011

0000000 1100110 0010000 0100110

1100011 1011111 0100011 0011111

1011010 1101100 0011010

1010101 1101001 1110101

1010000 1000110

1000011 0001111

0111111

0111101

0101111

1111101

1001111

2 4 6 8

– 8

4

2

8

6

270° 00000100001010

A

– 6

– 4

– 2

180°– 2– 4– 6– 8

B

C

0000110 0001110

0°

90°

D

0000001

T1701610-92/d02

FIGURE 2/V.17

A 128-point signal structure used with the trellis-coded 14 400 bit/s data signalling rate

Note – The binary numbers denote Q6 , Q5 , Q4 , Q3 , Y2 , Y1 , Y0 . A, B, C and D refer to synchronizing signal elements.n nn n n n n



Anhang B. Implementationsdetails 77

Anhang B

Implementationsdetails

B.1 T.38 (1998) ASN.1-Notation

T38 DEFINITIONS AUTOMATIC TAGS ::=BEGINIFPPacket ::= SEQUENCE{

type-of-msg Type-of-msg,data-field Data-Field OPTIONAL

}Type-of-msg ::= CHOICE{

t30-indicator ENUMERATED{

no-signal,cng,ced,v21-preamble,v27-2400-training,v27-4800-training,v29-7200-training,v29-9600-training,v17-7200-short-training,v17-7200-long-training,v17-9600-short-training,v17-9600-long-training,v17-12000-short-training,v17-12000-long-training,v17-14400-short-training,v17-14400-long-training,

78 B.1. T.38 (1998) ASN.1-Notation

...},data ENUMERATED{

v21,v27-2400,v27-4800,v29-7200,v29-9600,v17-7200,v17-9600,v17-12000,v17-14400,...

}}Data-Field ::= SEQUENCE OF SEQUENCE{

field-type ENUMERATED{

hdlc-data,hdlc-sig-end,hdlc-fcs-OK,hdlc-fcs-BAD,hdlc-fcs-OK-sig-end,hdlc-fcs-BAD-sig-end,t4-non-ecm-data,t4-non-ecm-sig-end

},field-data OCTET STRING (SIZE(1..65535)) OPTIONAL

}UDPTLPacket ::= SEQUENCE{

seq-number INTEGER (0..65535),primary-ifp-packet TYPE-IDENTIFIER.&Type(IFPPacket),error-recovery CHOICE{

secondary-ifp-packets SEQUENCE OF TYPE-IDENTIFIER.&Type(IFPPacket),fec-info SEQUENCE{

fec-npackets INTEGER,fec-data SEQUENCE OF OCTET STRING

}


}}END

B.2 ILAPI Events und Nachrichten

Nachrichten vom T.30-Protokoll-Layer

LAPI_RESETDiese Nachricht wird einmalig beim Start des T.30-Layer an ILAPI gesendet. Darinwird der zu benutzende B-Kanal übergeben, der durch ILAPI anschließend als Devicegeöffnet wird.

LAPI_SET_MODEMit diesem Kommando erfolgen sämtliche Betriebsart-Einstellungen. Dazu gehört dasSenden von Tönen mit angegebener Frequenz und Dauer, das Setzen derModem-Sende- und Empfangsbetriebsarten sowie das Abschalten der Sendeeinheit.

LAPI_ABORTBricht einen laufenden Vorgang ab, löscht alle gepufferten Daten und schaltet dieSendeeinheit aus.

LAPI_SEND_DATADie Daten werden nicht direkt gesendet, sondern in die MAIN_BACKLOG-Queueeingestellt, von wo sie zum passenden Zeitpunkt entnommen und gesendet werden.

LAPI_LAST_SEND_DATAWird wie LAPI_SEND_DATA behandelt; nach dem späteren Senden diesesDatenblocks wird anschließend der Sendemodus beendet.

Nachrichten zum T.30-Protokoll-Layer

LAPI_RESET_OKIst die Bestätigung, dass ein LAPI_RESET fehlerfrei verarbeitet wurde.

LAPI_RECEIVE_DATATransportiert empfangene Daten an den T.30-Layer.

LAPI_XOFFDient ebenso wie LAPI_XON der Flusssteuerung. Wenn beim Zwischenspeichern derSendedaten ein bestimmter Füllstand überschritten wird, teilt diese Nachricht derT.30-Schicht mit, vorläufig keine weiteren Sendedaten zu übergeben.

LAPI_XONMit dieser Nachricht wird T.30 darüber informiert, dass jetzt wieder Sendedatenangenommen werden.

80 B.2. ILAPI Events und Nachrichten

LAPI_END_OF_MODETeilt T.30 mit, dass die aktuelle Betriebsart beendet wurde (z.B. wenn alle Datenversendet wurden).

LAPI_ERRORWird gesendet, wenn eine Nachricht nicht verstanden wurde (sollte höchstens währendder Implementierungsphase auftreten).

LAPI_FRAME_BEGINZeigt an, dass mindestens ein HDLC-Startflag empfangen wurde. T.30 benötigt dieseInformation zum Starten eines Überwachungstimers.

LAPI_CARRIER_LOSTMeldet, dass kein Signalpegel mehr anliegt und beendet den Empfangsbetrieb.

LAPI_DETECT300Wird nicht verwendet.

LAPI_HDLC_RETURNGesendete HDLC-Frames werden mit dieser Nachricht an T.30 übergeben, um beiBedarf für spätere Wiederholungen zur Verfügung zu stehen (speziell im ErrorCorrection Mode).

LAPI_TRANS_RETURNWird nicht verwendet.

LAPI_DETECT_TONEWird ebenfalls nicht verwendet, statt dessen wird bei aktuellem Tonerkennungsmodusdie Nachricht LAPI_END_OF_MODE gemeldet, wenn der gewünschte Ton erkanntwurde.

Interne Events und Nachrichten von ILID

ILAPI_TXUNDERRUNTritt auf, wenn keine Daten zum Senden vorliegen, obwohl die Betriebsart noch aktivist. Sollte nicht auftreten – wenn doch, liegt es meist an Durchsatzproblemen.

ILAPI_TX_REQUESTDieser interne Event wird gemeldet, wenn der Sendepuffer des Modems einen weiterenDatenblock aufnehmen kann. Falls in der BACKLOG_QUEUE Daten vorhanden sind,wird der nächste Block entnommen und in das Sende-Device geschrieben.

ILAPI_TXENDMeldet das korrekte Ende einer Sendebetriebsart, das heißt, dass alle Daten gesendetwurden oder ein Auftrag zum Senden eines Tons fertig ausgeführt wurde.

ILAPI_DETECT_SILENCEIm Empfangskanal liegt kein Signal an (wird nicht weiter verarbeitet).


ILAPI_DETECT_ANY_SIGNALEs liegt ein beliebiges Signal an (wird nicht weiter verarbeitet).

ILAPI_DETECT_CEDIm sogenannten „Hunt-Mode“ wird parallel auf Antwortton (CED) Rufton (CNG) oderV.21-Modemsignale gewartet. Sobald eines dieser Signale erkannt wird, erfolgt dieentsprechende Meldung an die ILAPI.

ILAPI_DETECT_CNG(siehe Beschreibung von ILAPI_DETECT_CED).

ILAPI_DETECT_V21(siehe Beschreibung von ILAPI_DETECT_CED).

ILAPI_RX_TONE_TIMEOUTDer oben beschriebene „Hunt-Mode“ läuft für eine vorgegebene Dauer, ist dieseüberschritten, ohne dass ein gültiges Signal erkannt wurde, wird das EreignisILAPI_RX_TONE_TIMEOUT gemeldet.

ILAPI_RX_OKEin empfangenes Datenpaket wird mit diesem Ereignis vom Modem an ILAPIübergeben.

ILAPI_IND_FLAGStartflag(s) wurden vom Modem erkannt, daraufhin wird LAPI_FRAME_BEGINvon ILAPI an T.30 gemeldet.

ILAPI_IND_CARRIER_LOSTDas Modem empfängt keinen Empfangspegel.

ILAPI_IND_ABORTEin HDLC-Frame wurde während des Empfangs abgebrochen (kein Closing-Flag).

ILAPI_DETECT_V27_2400Die entsprechende Betriebsart wurde vom Modem erkannt. Dasselbe gilt für dieMeldungen ILAPI_DETECT_V27_4800, ILAPI_DETECT_V29_7200,ILAPI_DETECT_V29_9600, ILAPI_DETECT_V17_7200,ILAPI_DETECT_V17_9600, ILAPI_DETECT_V17_12000 undILAPI_DETECT_V17_14400.

ILAPI_RX_WAIT4MODE_TIMEOUTWird nicht verwendet.

ILAPI_RX_TCF_TIMEOUTDer Training Check (TCF) wurde nicht positiv erkannt.

ILAPI_RX_NOSYNCKein HDLC-Flag erkannt, wird nicht weiter verarbeitet, es werden keine Daten nachoben gereicht. Dies gilt auch für die Meldungen ILAPI_RX_FRAME_CRC,ILAPI_RX_FRAME_SHORT, ILAPI_RX_FRAME_OVERRUN,

82 B.2. ILAPI Events und Nachrichten

ILAPI_RX_FRAME_ABORT, ILAPI_RX_FRAME_BREAK,ILAPI_RX_FRAME_CARRIER, ILAPI_IND_BREAK undILAPI_RXOVERRUN.

ILAPI_LAYER1_ACTIVATEDDie ISDN-Schicht 1 wurde aktiviert. Wird hier nicht verarbeitet (diese Nachricht wirdin der ISDN D-Kanal-Steuerung benötigt). Gilt auch für die MeldungenILAPI_LAYER1_DEACTIVATED, ILAPI_FRAMING,ILAPI_FRQSLIP und ILAPI_CODEVIOL.

ILAPI_V21_RX_FLAGS_TIMEOUTWird nicht verwendet.

ILAPI_SEND_FLAGSDieser interne Event startet das Senden von Flags.

LITERATURVERZEICHNIS 83

Literaturverzeichnis

[1] Deutinger, J. (2001), Neue Plattform für Unified Messaging. eManager 2001, H. 2,S. 49-61

[2] ITU-T Recommendation T.30 (07/2003), Procedures for document facsimiletransmission in the general switched telephone network

[3] ITU-T Recommendation T.4 (07/2003), Standardization of Group 3 facsimileterminals for document transmission.

[4] CCITT Recommendation T.6 (1988), Facsimile coding schemes and coding con-trol functions for Group 4 facsimile apparatus.

[5] FTZ 18 TR 53 (01/1994), Anforderungen an Endeinrichtungen der Gruppe 3 zurTeilnahme am Telefaxdienst der Deutschen Bundespost Telekom

[6] CCITT Recommendation T.30 (11/1988), Procedures for document facsimiletransmission in the general switched telephone network



[9] Alan Pugh, European Technical Update (1990), Vortrag gehalten auf der Eurofax’90 Conference in Amsterdam

[10] ITU-T F.185 (06/1998), Internet facsimile: Guidelines for the support of the com-munication of facsimile documents

[11] ITU-T T.38 (04/2004), Procedures for real-time Group 3 facsimile communicationover IP networks

[12] ITU-T T.37 (06/1998), Procedures for the transfer of facsimile data via store-and-forward on the Internet

[13] ITU-T T.37 (09/1999), Procedures for the transfer of facsimile data via store-and-forward on the Internet, Amendment 1: Full Mode

84 LITERATURVERZEICHNIS

[14] ITU-T T.37 (03/2001), Procedures for the transfer of facsimile data via store-and-forward on the Internet, Amendment 2

[15] ITU-T T.37 (11/2002), Procedures for the transfer of facsimile data via store-and-forward on the Internet, Amendment 3

[16] ITU-T H.323 (07/2003), Packet-based multimedia communications systems

[17] Fax Services over IP Overview (2005), http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t11/faxapp/fxappdoc.pdf (erreich-bar am 19.4.2005)

[18] Jochen Nölle (2003), Voice over IP, Grundlagen, Protokolle, Migration. VDE Ver-lag GmbH, ISBN 3-8007-2708-0

[19] James P. Rafferty (02/2004), Addressing The Challenges Of Real-Time Fax OverIP, siehe http://www.tmcnet.com/it/0204/0204F-Brooktrout.htm (erreichbar am18.4.2005)

[20] Marshall T. Rose (1990), The Open Book, A Practical Perspective on OSI

[21] ITU-T X.691 (07/2002), ASN.1 encoding rules: Specification of Packet EncodingRules (PER)

[22] McConnel, Kenneth R. (1999), FAX: facsimile technology and systems, 3rd ed.1999, ISBN 0-89006-944-1

[23] Schmohl, J. (2004), Konkurrenzanalyse als Teil einer Marketingkonzeption amBeispiel der Ferrari electronic; Diplomarbeit an der Fachhochschule Wildau

[24] Texas Instruments (Erscheinungsjahr unbekannt), Voice and Fax over InternetProtocol (V/FoIP), The International Engineering Consortium

[25] Deutinger, J. (2004), Festnetz-SMS als Basis für automatisierten Kurznachrich-tenversand und -empfang; Studienarbeit an der Otto-von-Guericke-UniversitätMagdeburg

[26] ITU-T V.21 (1984), 300 BITS PER SECOND DUPLEX MODEM STANDAR-DIZED FOR USE IN THE GENERAL SWITCHED TELEPHONE NETWORK

[27] ITU-T V.27 ter (1984), 4800/2400 BITS PER SECOND MODEM STANDAR-DIZED FOR USE IN THE GENERAL SWITCHED TELEPHONE NETWORK

[28] ITU-T V.29 (1988), 9600 BITS PER SECOND MODEM STANDARDIZED FORUSE ON POINT-TO-POINT 4-WIRE LEASED TELEPHONE-TYPE CIR-CUITS

[29] ITU-T V.17 (1991), A 2 -WIRE MODEM FOR FACSIMILE APPLICATIONSWITH RATES UP TO 14.400 bit/s

85

Selbstständigkeitserklärung

Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig und nur mit erlaubtenHilfsmitteln angefertigt habe.

Magdeburg, den 17. Juni 2005

Johann Deutinger

86

Documents

Otto-von-Guericke-Universität Magdeburg · Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut für Verteilte Systeme Diplomarbeit Computerfax im VoIP-Netzwerk