Otto-von-Guericke-Universität Magdeburg · QoS Quality of Service Read Relative Element Address...

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

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.

Kapitel 4. Entwurf und Realisierung 33

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 de

Otto-von-Guericke-Universität Magdeburg · QoS Quality of Service Read Relative Element Address...

Documents

Transcript of Otto-von-Guericke-Universität Magdeburg · QoS Quality of Service Read Relative Element Address...