Vor einigen Monaten, als wir nach einem geeigneten Thema für diese Diplomarbeit suchten, kam uns die Internet-Telefonie in den Sinn. Wir überlegten in wie es möglich ist, gewöhnliche Telefongespräche über eine ISDN-Verbindung von einem angeschlossenen Rechner aus führen zu können.
Wir versuchten zwar durch dissassemblieren zweier beiliegender Testprogramme (zum Verschicken und zum Empfangen einer Audiodatei) einen Weg zu finden dennoch mit der Karte arbeiten zu können. So fanden wir heraus, daß diese Programme mit der Software über eine named-pipe kommunizierten, und waren auch in der Lage einen Anruf zu initiieren. Jedoch fehlten Informationen über die Art und Weise von Signalisierungen.
Wir fragten natürlich auch bei SUN direkt nach und erhielten die Antwort, daß diese Software ausschließlich für den Einsatz von PPP konzipiert worden war. Die Testprogramme seinen nur aus historischen Gründen mitgeliefert worden. Von der direkten Benutzung der named-pipe riet man uns auch ab, da diese Schnittstelle sich von Version zu Version ändern könnte.
Dennoch verwiesen uns die Leute von SUN auf ein Produkt, mit dem es möglich sein sollte die ISDN Karte für unsere Zwecke nutzen zu können. Dieses Produkt (SunXTL 1.2) wurde dann auch bestellt und installiert.
Wie in der Abbildung zu erkennen ist, stellt diese Architektur eine verteilte Telefonie Umgebung zur Verfügung. So weit so gut, als wir jedoch nach dem MPI[ Das MPI (Media Provider Interface) verbindet einen Typ eines physikalischen Gerätes (wie einer ISDN Karte) mit den XTL Teleservices. Es wandelt somit die internen Funktionen der XTL in Aktionen auf dem Gerät um (z.B. Initiieren eines Telefonanrufs), und erzeugt für eingehende Ereignisse (z.B. ein eingehender Anruf) in die internen Nachrichten. Ohne diesen MPI ist es somit nicht möglich, die unterliegende Hardware zu benutzen.] für die ISDN Karte suchten, stellte sich heraus daß dieses nicht zum Lieferumfang gehört. Auf Nachfragen hieß es dann, daß wir einen derartigen MPI von einem Fremdhersteller beziehen könnten. Die Software stellte auch kein sonstige Möglichkeit zur Verfügung, die ISDN Karte zu verwenden.
Nach dieser wiederum ernüchternden Erkenntnis fragten wir in der GMD nach, ob dort schon irgendwo eine Implementierung existiert. Dort verhielt man sich eher zurückhaltend der XTL Architektur gegenüber und riet uns, noch einige Zeit zu warten. Man war dort selber dabei eine ISDN Karte für eine SUN zu entwickeln, die dann auch besser liefe und unterstützt werden sollte.
Nach der Kontaktaufnahme erhielten wir auch gleich Zugang zu den Quellen, und konnten diese auch benutzen. Es existierten zwei Testprogramme, mit denen es möglich war eine Datei über das ISDN zu versenden.
Ein wenig enttäuschend waren jedoch,
Hinzu kam, daß das Semester dort gerade zu Ende war, und mit einer Weiterentwicklung erst in einigen Monaten zu rechnen sei.
Das SunShine Projekt war die einzige Referenz, die wir in Hinblick auf Unterstützung zur Programmierung der ISDN-Karte gefunden haben. Aus diesem Grunde entschlossen wir uns zu einer Zusammenarbeit. Ein Teil der Entwicklung wurde dort weiter von Bengt Olof Shalin betrieben, der andere Teil von uns.
Zum Verständnis der weiteren Ausführung ist nur ein Überblick über die einzelnen Schichten im ISDN nötig.
Die physikalische Schicht (physical layer) ist beim ISDN durch die ITU Empfehlung I.430 [itu9303:I.430] für einen Basisanschluß[ Es werden drei Arten von Anschlüssen unterschieden, der Basisanschluß, der Primärmultiplexeranschluß und das Breitband-ISDN. Diese unterscheiden sich im wesentlichen nur in der Übertragungsrate und den physikalischen Eigenschaften. Für die weitere Betrachtung beschränken wir uns hier auf den Basisanschluß.] spezifiziert. Die ISDN Karte ist die Instanz, die eine Schnittstelle zu dieser physikalischen Schicht herstellt. Da diese bereits vorhanden ist, beschäftigen wir uns hier nicht weiter damit.
Die zweite Schicht (Link Layer) ermöglicht den Datenaustausch mittels des Physical Layers. Sie erfüllt dabei Aufgaben wie die Adressierung von Absender und Empfänger und ermöglicht einen fehlerfreien Datenaustausch durch Fehlererkennungs- und Fehlerkorrekturmaßnahmen. Sie ermöglicht auch das Mulitplexen mehrerer Zugangspunkte. Diese Schicht ist durch Q.920 [itu9303:Q.920] (gleich I.440 [itu9303:I.440]) und Q.921 [itu9303:Q.921] (entspricht I.441 [itu9303:I.441]) spezifiziert.
Die dritte Schicht (Network Layer) ermöglicht die Kommunikation zwischen zwei oder mehreren Teilnehmern. Beim ISDN entspricht dies beispielsweise einer Möglichkeit, daß zwei Teilnehmer über ISDN miteinander telefonieren können. Diese Schicht ist spezifiziert durch Q.930 [itu9303:Q.930] (I.450 [itu9303:I.450]) und Q.931 [itu9303:Q.931] (I.451 [itu9303:I.451]).
Die anderen Schichten sind für unsere Arbeit nicht weiter von Bedeutung und werden daher nicht weiter betrachtet.
In dem SunShine Projekt wurden diese beiden Schichten implementiert, so das es mit dieser Software möglich war, auf das "normale" ISDN zuzugreifen und es zu nutzen. Wir zuvor schon erwähnt gab es jedoch eine Menge Fehler in der Implementierung. Weiterhin war diese auch nicht für einen echten Einsatz geplant, sondern diente nur als Versuchsobjekt. Hinzu kam noch, daß die Implementierung kein Programmierinterface zur Verfügung stellte.
Es wurde daher beschlossen, einen Teil neu zu entwickeln. Glücklicherweise waren die Implementierungen der beiden Schichten von einander völlig getrennt. Die Implementierung der Schicht 2, genauer des Q.921 LAP-D Protokolls, wurde als eine eigene Streams-Extention für den SUN Kernel implementiert. Die Implementierung des Q.931 Protokolls hingegen wurde zur Applikation dazugelinkt.
Nach einigen Überlegungen entschlossen wir uns für eine Implementierung des Q.931 Moduls. Zusätzlich sollte eine Programmierschnittstelle zur Verfügung gestellt werden. Beng Olof Shalin entschied sich währenddessen, das Q.921 Modul völlig zu überarbeiten.
Jede nach Q.931 eingehende Nachricht besitzt den gleichen Aufbau (siehe Abbildung [q931-msg]). Nachdem die Nachricht anhand des Protocol Discriminator Feldes als Q.931 Nachricht identifiziert wurde, wird die Call Reference Value (CRF) decodiert, sowie der Message Type (MT). Die dann optional folgende Liste mit weiteren Information Elements (IE) wird dann Stück für Stück dekodiert und in einer internen Struktur abgelegt. So wie in Q.931 beschrieben werden unbekannte IEs ignoriert, sie erzeugen keinen Fehler.
Dieses Modul ist auch für das Verschicken einer vollständig aufbereiteten Nachricht an das DLPI Modul zuständig.
Alle Funktionen, die für die Behandlung eines speziellen Message Type nötig sind, wurden in einem eigenen Source-Files zusammengefaßt. Derzeit werden die folgenden Q.931 Message Types behandelt (vergleiche auch Q.931 [itu9303:Q.931], Abschnitt 3.1):
Es fehlen somit nach Q.931 die folgenden Typen:
Für die Benutzung der Implementierung reichte dies in der Vergangenheit aus, die fehlenden Nachrichten wurden auch nie empfangen. Um eine Q.931 konforme Implementierung zu haben, müßten diese dennoch behandelt werden.
Für jede eingehende und ausgehende Nachricht wird die Q.931 Finite State Machine des entsprechenden Kontextes abgearbeitet. Zusätzliche werden die (alle) ebenfalls in Q.931 definierten Timer entsprechend den SDL [itu9303:Z.100] Diagrammen behandelt. Realisiert wird dies mit Hilfe des Scheduler Moduls.
Wenn eingehende (zum Teil auch ausgehende) Nachrichten eine Indikation zur Applikation erfordern, wird in den einzelnen Funktionen noch eine IsdnLib Indication generiert und die zuvor registrierte Callback Funktion der Applikation aufgerufen.
Aus diesem Grunde und aus dem Grunde der Übersichtlichkeit, haben diese Kodierung und Dekodierung der IEs in eine eigenen Modul ausgelagert. Für jedes IE existieren zwei Funktionen, die jeweils in einem Source-File implementiert wurden. Die eine Funktion Realisiert die Kodierung, die andere die Dekodierung. Zu Debugging Zwecken haben die meisten IEs noch eine weitere Funktion zur Verfügung, eine mit der der Inhalt formatiert ausgegeben werden kann.
In der jetzigen Implementierung werden folgende IEs unterstützt (in alphabetischer Reihenfolge):
Die markierten IEs sind noch nicht vollständig implementiert.
Das Modul mit der Q.931 Finite State Machine benutzt diesen beispielsweise für die Realisierung der Timer.
Die IsdnLib basiert maßgeblich auf den anderen zuvor beschriebenen Modulen, so auch das Scheduler Modul. Bei der Entwicklung der IsdnLib wurde jedoch auch daran gedacht, diese später einmal in tcl/tk[ tcl/tk ist eine Scriptsprache, die von John K. Ousterhout entwickelt wurde.] einbinden zu können. Zu diesem Zweck muß es möglich sein, die Schedulling Routinen des tcl benutzen zu können. Die Implementierung wurde daher so realisiert, daß nur einige "Hüllfunktionen" geschrieben werden müssen, die den Namen der Funktionen des Scheduler Moduls besitzen, und die entsprechenden Funktionen der tcl Implementierung aufrufen. Dies wurde bisher jedoch noch nie getestet!
Zu Beginn des Projektes überlegten wir, was das einfachste Interface für eine ISDN Unterstützung sein könnte. Wir überlegten uns hierzu die folgenden Varianten:
Besonders schwierig war es jedoch, die asynchrone Signalisierung realisieren zu können. Im ISDN können zu jeder Zeit Nachrichten für existierende oder noch aufzubauende Verbindungen eintreffen. Um diese den einzelnen Verbindungen zuordnen zu können, müßte etwas ähnliches verwendet werden, wie die Call Reference Value der Q.931 Nachrichten. Wir würden dann ein neues Protokoll benötigen, in dem wiederum verschieden Nachrichtenformate definiert werden müßten.
Er stellte sich somit heraus, daß wir wiederum eine neues Protokoll definieren müßten, das ähnlich Komplex wäre wie das Q.931 Protokoll selber, womit wir dann im Grunde überhaupt nichts gewonnen hätten.
Bei der Betrachtung der Spezifikation fiel jedoch schnell auf, daß dieser ebenfalls recht komplex zu sein scheint. Zumal das Problem auftrat, daß diese Implementierung dann wiederum eine STREAMS Kernel Extension realisiert werden müßte. Da wir einen derartigen Aufwand scheuten, und da die Benutzung von CAPI auch recht kompliziert erschien, verwarfen wir auch diese Idee.
Ein kleinen Nachteil gab es bei dieser Variante jedoch auch. Da die Library als Teil des Prozesses läuft, würde ein Blockieren des Programms auch die ISDN-Schnittstelle beeinflussen. Eingehende Q.931-Nachrichten würden dann zeitlich nicht mehr Q.931 Konform behandelt werden können.
Wir entschieden uns dennoch für diese letzte Variante, und nannten die entstandene Library IsdnLib.
Die einzelnen Funktionen der IsdnLib sind im Anhang [manIsdnLib] in der Form von Manualpages beschrieben. Die Implementierung der IsdnLib ist in Anhang [srcIsdnLib].