ISDN ist tot, es lebe des Kaisers Telefon!

Den Anstoß zu diesem Beitrag gab mir ein Artikel der bei ZDF Heute erschien. Leider enthält der Artikel einige Ungenauigkeiten, das hätte ich von Peter Welchering so nicht erwartet. So wird unter anderem von ISDN und Internet-Zugang mit 384 kBit/s gesprochen. 384 kBit/s sind mit ISDN nicht realisierbar. Über einen ISDN-Anschluss sind 64 kBit/s möglich, 128 kBit/s bei Kanalbündelung. Es lassen sich z. B. noch Standleitungen realisieren, dort sind dann 2 MBit/s möglich. Vermutlich ist hier aber der Internetzugang mit sog. „DSL light“ gemeint. Die Grundaussagen des Artikels bleibt aber wahr, und es ist nicht das erste mal, dass ich davon höre.

  • Es gibt Regionen in Deutschland, die auch im Jahr 2019, wenn, dann nur über eine bruchstückhafte Versorgung mit Mobilfunk verfügen. Wir reden hier von ganz schnöder Telefonie, von 3G oder gar LTE ganz zu schweigen.
  • „Schnelles“ Internet ist, wenn überhaupt, nur mit der kleinstmöglichen Variante, 384 kBit/s, möglich, dem so genannten „DSL light“. Dabei handelt es sich um Gegenden, die z. B. aufgrund der großen Entfernung zur nächsten „Schaltstelle“ eigentlich nicht per ADSL zu versorgen wären, wo man aber eine Reduktion der Geschwindigkeit (ADSL startete in Deutschland mit 768 kBit/s im Downstream) in Kauf nimmt, um so immerhin einen Internetzugang zu realisieren, der schneller als ISDN ist. Es gibt allerdings auch Regionen in Deutschland, in denen bis heute kein DSL-Anschluss verfügbar ist. Wenn es einen Internetzugang gibt, dann über wackelige Richtfunkstrecken, die oft von privaten Initiativen gebaut worden sind, die oft nur wenige MBit/s liefern und dann noch von einigen Parteien geteilt werden.
  • Falls das alles nicht verfügbar ist, läuft der einzige Zugang zum Internet per ISDN. Per Einwahl. Wie in den 1990ern. Bis jetzt.

Was passiert da aktuell?

Die Telekom will das Kernnetz für ISDN abschalten. Das ist grundsätzlich ein Prozess, der nicht nur die Telekom und nicht nur Deutschland betrifft.
Die Technik (Vermittlungsstellen), die hier auf Provider-Seite im Einsatz ist, ist seitens der Hersteller seit Jahren abgekündigt. Dadurch ist die Ersatzteilversorgung nicht mehr garantiert. Es heißt, ganze Vermittlungsstellen werden schon aufgrund kleinerer Defekte außer Betrieb genommen. Die Telekom hat größtenteils die Produkte Siemens EWSD und Alcatel (früher SEL) S12 im Einsatz. Die Hardware entspricht dabei nicht mehr dem Stand der Technik. Es heißt, auch Stromverbrauch sei ein Thema.

ISDN konnte einst das Versprechen einlösen, unterschiedlichste Kommunikationsnetze in einem, volldigitalen, Netz zu vereinen. Mit dem Aufkommen von (A)DSL jedoch wurde ISDN bereits etwas dieses Sinnes beraubt, denn ISDN, so wie es im Einsatz war, konnte keine hohen Geschwindigkeiten für den Endkunden liefern, wie es ADSL vom Fleck weg ermöglicht hat. Eine Weiterentwicklung war zwar angedacht, kam aber über Pilotversuche nicht hinaus.

Insofern mussten fortan zwei Infrastrukturen parallel betrieben werden. Mit den Jahren wuchsen die Geschwindigkeiten und die Hardware wurde erschwinglich, um Voice over IP in der Masse zu realisieren. Zwar wurden IP-Telefone für den Endverbraucher noch nicht populär, aber die Technik war bereits so erschwinglich, dass sie in Router für den Heimbereich eingebaut werden konnte.
Einer der ersten Router dieser Art, der auch weite Verbreitung erreichte, war die FRITZ!Box Fon (WLAN), die etwa 2004 auf den Markt kam.
Zusätzlich verlor der klassische Telefonanschluss an Bedeutung, dank Internet-Flatrates und Diensten wie Skype wurde auch Telefonie im Sinne von „Audio-Gespräch“ bei beliebigen Entfernungen kostenlos.

Der Bedarf an immer schnelleren Internet-Anschlüssen war nur zu realisieren, indem die Länge des Kupferkabels zwischen Provider und Kunde immer weiter verkürzt wird. Das war irgendwann aus der Vermittlungsstelle heraus nicht mehr möglich. Damit begann der Prozess, dass überall am Straßenrand deutlich größere „graue Kästen“ aufgestellt wurden, bei der Telekom Multifunktionsgehäuse (MFG) genannt. Diese Gehäuse sind per Glasfaser an die Vermittlungsstellen angebunden und enthalten mitunter „VDSL-Modems“ (DSLAM), um die Gegenstelle zum Kunden zu bilden.

Mit diesem Schritt setzte letztlich eine Runderneuerung der aktiven Technik des Telefonnetzes ein. Der Kunde soll nur noch einen (V)DSL-Anschluss bekommen und sich dann die Dienste buchen können, die er benötigt. Neben Telefonie und Internetzugang kam Fernsehempfang dazu und dies wurde bzw. wird noch als „Triple Play“ vermarktet.

Das Telefon: vergessen

Der klassische Telefonanschluss blieb hier jedoch zunächst auf der Strecke. Für (nominell) einen Großteil der Kunden mögen die bis dahin vorgesehenen Dienste ausreichend sein, aber es gibt einige Probleme und generelle Veränderungen, auf die ich eingehen möchte und die oft verschwiegen werden.

Zu allererst: VoIP-Telefonie hat Vorteile gegenüber klassischer Telefonie. Im wesentlichen sehe ich:

  • HD-Audio
    • Lange Zeit war das Telefonnetz mit 3,4 kHz Bandbreite bei der Audioübertragung beschränkt. Dieser Wert stammte aus grauer Vorzeit, in der Kohlemikrofone eingesetzt wurden, die eine größere Bandbreite nicht leisten konnten, hier entstand der typische „Telefonklang“. Im Mobilfunknetz 3G wurde zuerst ein Breitband-Codec populär (AMR-WB), der z. B. als „HD Audio“ bezeichnet wird. Im LTE-Netz werden zunehmend Telefonate auch als VoIP abgewickelt, dort ist diese HD-Telefonie noch stärker verbreitet. IP-Telefone unterstützen HD-Telefonie schon länger, auch mit noch weiteren Codecs.
  • Flexible Zuteilung von Sprachkanälen
    • Bei ISDN sind technisch Sprachkanäle nur in Einheiten von 2 Sprachkanälen (S0) oder 30 Sprachkanälen (PMX) möglich. Mit VoIP sind hier flexiblere Modelle möglich, auch asymmetrisch; viele Anbieter ermöglichen das Zubuchen einzelner Sprachkanäle, oft sogar monatlich zu ändern.
  • Nomadische Nutzung
    • Ein klassischer Telefonanschluss ist auf das Adernpaar beschränkt, auf das er aktuell physisch geschaltet ist. Ist die Leitung gestört, ist der Anschluss nicht nutzbar. Bei VoIP-Anschlüssen wird das Internet als Basisdienst genutzt, damit sich die Gegenstelle des Kunden bei der Gegenstelle des Providers registrieren und für Telefonieverkehr bereit zeigen kann. Dabei spielt es keine Rolle, wo sich die Gegenstelle des Kunden physisch befindet, solange sie Zugang zum Internet hat.
  • Bei VoIP benötigt man keine Telefonanlage mehr, oder die Telefonanlage kann „im Netz“ sein.
  • SIP ist ein offener Standard und setzt auf dem TCP/IP-Stack auf. Das ist deutlich einfacher als die überladene ISDN-Spezifikation.

Dem gegenüber stehen allerdings folgende Punkte:

  • VoIP ist keine zwingende Voraussetzung für HD-Audio
    • Es ist nicht korrekt, dass VoIP für HD-Audio erforderlich ist. Technisch ist das bereits im ISDN möglich, der bei VoIP häufig genutzte Audio-Codec G.722 stammt aus den 1980ern und kann auch im ISDN genutzt werden. Leider gibt es nur praktisch kein Endgerät, dass das unterstützt. Allerdings ist über etliche Jahre bereits ISDN zur Übertragung von hochqualitativen Audiosignalen genutzt worden, nämlich zum Beispiel bei Radiosendern zur Einbindung von Außenstellen auf Veranstaltungen. Ein bekanntes System in diesem Bereich war das Musiktaxi.
  • Die nomadische Nutzung wird seitens der Provider oft aktiv verhindert, insbesondere von den Großen (Vodafone, Telekom).
  • Der de-facto-Standard für VoIP, SIP, liegt im Leistungsumfang deutlich hinter dem, was bei ISDN seit den 1980ern üblich war. Vor allem zeigt sich auch heute, etwa 15 (!) Jahre nach der Verfügbarkeit für die Masse, dass es zu viel Interpretationsspielraum der RFCs gibt, für dasselbe Leistungsmerkmal unterschiedliche (inkompatible) Implementierungen, existieren, usw.:
    • ISDN unterstützt Blockwahl und überlappende Wahl. SIP nur erstere, für überlappende Wahl gibt es nicht-standardisierte Varianten der Signalisierung, die nicht geräteübergreifend funktionieren müssen.
    • Leistungsmerkmale wie Rückruf bei besetzt und Anrufweiterleitung im Amt können nicht durch Endgeräte gesteuert werden, weil es hierfür keine festgelegten Verfahren gibt.
    • Selbst für die Übermittlung von DTMF-Tönen sind aktuell drei verschiedene Verfahren im Einsatz.
  • ISDN bietet eine garantierte maximale Rufaufbauzeit, die danach spezifiziert wurde, wie lange es dauert, den Handapparat vom Telefon zum Ohr zu führen. (Anm.: Hier bin ich aktuell noch auf der Suche nach einer Quelle)
  • Auch bei ISDN sind Fallbacks realisierbar, wenn auch etwas aufwändiger (mit Rufumleitungen / CLIP no screening).
  • ISDN stellt leitungsvermittelte Verbindungen zur Verfügung. Das bedeutet: steht eine Verbindung, ist die Datenrate für die Dauer der Verbindung fest verfügbar, Schwankungen in der Übertragungsgeschwindigkeit treten damit praktisch nicht auf (Jitter). Telefonie ist somit mit einer konstant geringen Verzögerung realisierbar.
  • Bei ISDN kommt die Speisung für den Endpunkt des Netzes (NTBA) mit aus der Vermittlungsstelle, die auch genügt um ein Telefon daran zu betreiben. Man kann bei Stromausfall weiterhin telefonieren. Heute ist der Kunde selbst dafür verantwortlich, es wird seitens der Provider auch aktiv geraten, sich eine USV anzuschaffen.
  • In der Praxis werden VoIP-Netze selten „nackt“ eingesetzt. Speziell größere Installationen sehen sich der Anforderung gegenüber, das z. B. zwischen unterschiedlichen Audiocodecs transkodiert werden muss, oder dass Audioströme ver- bzw. entschlüsselt werden müssen. Dazu kommt das Problem, dass man aus Sicherheitserwägungen nicht möchte, dass SIP-Endgeräte, die schließlich direkt im Firmennetz arbeiten, mit anderen Endpunkten im Internet direkt kommunizieren können. Oft weist die Firmware von VoIP-Telefonen erhebliche Sicherheitsmängel auf, sodass das VoIP-Netz von einer zentralen Instanz gegenüber dem Internet abgeschirmt werden soll, meist als Session Border Controller (SBC) bezeichnet. Somit ist dann doch wieder eine zentrale Instanz notwendig, die alle Telefone koordiniert.
  • ISDN ist ein „richtiger“ Standard, in europäischen (ETSI) und internationalen (ITU-T / CCITT) Normen festgeschrieben, manche Dokumente mögen nicht einmal öffentlich zugänglich sein. Es mag sicher so sein, dass die RFCs fürs TCP, UDP, IP und SIP sich viel leichter lesen und auch deutlich kompakter sind. Aber die Praxis zeigt: RFCs so zu implementieren, dass die eigene Implementierung problemlos mit den Implementierungen aller anderen zusammen arbeitet, ist extrem aufwändig. Oft wird der TCP/IP-Stack als hervorragendes Beispiel für diese einfachen und einfach verständlichen „Standards“ zitiert. Die Realität zeigt jedoch: man nimmt entweder eine „Standard-Implementierung“, die bereits millionenfach im Einsatz ist, oder man muss viel Zeit und Arbeit investieren, um Fehler in der eigenen Implementierung zu beheben oder Ausnahmebehandlungen zu implementieren, um mit den fehlerhaften Implementierungen anderer Endpunkte zusammenarbeiten zu können (siehe https://news.ycombinator.com/item?id=12021195). Ähnlich sieht es bei SIP aus. Es gibt viele Ungenauigkeiten und Wahlmöglichkeiten, sodass die Interoperalität zwischen Systemen verschiedener Hersteller kaum zu gewährleisten ist. Das ging sogar so weit, dass sich das SIP Forum zusammengefunden hat, um ein genauere Regeln festzulegen, wie SIP gesprochen werden soll (SIPConnect).

Die Telekom schreitet voran mit dem Rückbau von ISDN. Aus ihrer Sicht ist das grundsätzlich nachvollziehbar, denn es gilt, veraltete Gerätschaften und eine doppelte Infrastruktur abzuschaffen. Auf Seiten der Kunden sieht es jedoch anders aus. Im Telefonanlagen-Markt waren Amtsanbindungen per ISDN absolut Stand der Technik, und aufgrund der Unzulänglichkeiten von SIP-Anschlüssen, gepaart mit der Tatsache, dass insbesondere die Telekom erst sehr spät eigene Produkte auf den Markt gebracht hat, hatten Kunden wenig Anreize für die Umstellung. Wie der eingangs verlinkte Artikel zeigt, wird mit dem Abschalten von ISDN-Anschlüssen nicht einmal Halt gemacht, wenn keine adäquaten Alternativen zur Verfügung stehen und Kunden sogar Produkte empfohlen, die technisch am Standort nicht realisierbar sind.

Darüber hinaus, ich erwähnte es, wurde ISDN schon immer für mehr als telefonieren genutzt. Das betrifft insbesondere die Kommunikation von Geräten, die zur kritischen Infrastruktur zählen. Pumpstationen, Aufzugnotruf-Anlagen und insbesondere Brandmeldeanlagen mit Feuerwehr-Aufschaltung sind Systeme, die sich seit Jahrzehnten auf etwas verlassen, das dass neue Netz so nicht mehr bietet: Garantien und ein hohes Maß an Dienstgüte.

Für Brandmeldeanlagen genügte in den meisten Fällen, die Alarmaufschaltung der Feuerwehr über einen ISDN-Anschluss zu realisieren, der von Bosch oder Siemens überwacht wurde. Mit der Umstellung auf VoIP gibt es keine vergleichbaren Alternativen und es werden meistens mindestens (!) zwei Kommunikationswege für die Anlage vorgeschrieben.

Das ISDN ist ausgelegt auf eine Verfügbarkeit von 99,99999% im Jahresmittel. Mit der Umstellung auf einen neuen AllIP-Vertrag akzeptiert jeder Telekom-Kunde (egal ob Privat- oder Geschäftskunde!) eine Verfügbarkeit von 97%. Das bedeutet eine Verschlechterung von „Ausfall <1 Min./Jahr“ auf „über 10 Tage/Jahr ist OK“.
Mit anderen Worten: Ein Anschluss kann jedes Jahr 10 Tage am Stück ausfallen, und man darf dann noch nicht einmal von einer Störung sprechen.
Oder, um es so auszudrücken: unser Kommunikationsnetz wurde mit der Modernisierung von der höchsten Klasse von Hochverfügbarkeit zur Nicht-Hochverfügbarkeit deklassiert (vgl. https://de.wikipedia.org/wiki/Hochverfügbarkeit).

Wann immer ich Vorteile von ISDN erwähne, bekomme ich zu hören „ISDN ist alt und überholt, deswegen gehört es abgeschafft.“ Sicherlich enthält der Standard vieles, das heute nicht mehr benötigt wird. Dennoch tut sich SIP bis heute schwer daran, überhaupt den Leistungsumfang zu erreichen, den ISDN schon Jahrzehnte hatte, von „neuen Features“ ganz zu schweigen. Ich könnte mich damit eher abfinden, wenn nun alles an Telefonie grundsätzlich über SIP abgewickelt wird, und alte Zöpfe abgeschnitten werden, und vor allem ein ähnlich hohes Verfügbarkeitsmaß realisiert wird. Stattdessen macht man aber – wie bei der Einführung von ISDN – abermals den Fehler, und setzt als Alternative auf „POTS“, also der schnöden analogen Telefonie von der Jahrhundertwende. Diese bringt meiner Ansicht nach ein paar ganz entscheidende Nachteile mit, von denen besonders die Menschen betroffen sind, die „einfach nur telefonieren“ wollen.

Das Problem mit Oma Finchen

Lange Zeit hieß es, die wenigen Kunden, die ausschließlich telefonieren wollen, bekämen dann eben trotzdem einen DSL-Anschluss und Router. Das Problem mit „Oma Finchen„, also insbesondere älteren Menschen, die wirklich einfach nur telefonieren wollen und absolut nicht in der Lage sind, einen Internetrouter zu konfigurieren oder zu warte, wurde dann aber doch so groß, dass man hier einen alternativen Weg ging.

Die Geräte in den Multifunktionsgehäusen, die aus Glasfaser die VDSL-Anschlüsse machen, heißen MSAN (=Multi Service Access Node). Diese Geräte werden mit Glasfaser versorgt und können unterschiedliche Dienste anbieten, indem man sie mit sog. Linecards bestückt. Neben dem Standardfall, VDSL-Linecards, setzt z. B. die Telekom nun auch POTS-Linecards ein, also Baugruppen, die einen klassischen analogen Telefonanschluss zum Kunden liefern können. Was aber verschwiegen wird: die Hersteller dieser MSANs bieten neben DSL und POTS auch Linecards für ISDN an. Mit anderen Worten: auch nach der Abschaltung des ISDN könnten die Provider über diesen Weg weiterhin, über die moderne Kerninfrastruktur, ISDN zum Endkunden liefern.

Das wäre nicht nur für Geschäftskunden gut, die mit ihrer TK-Anlage einfach nur telefonieren wollen, und deren Verkabelungssituation eine moderne IP-Telefonanlage ggf. überhaupt nicht zulässt oder die mangels entsprechender Internetanbindung (siehe oben) weder VoIP noch Cloud-Telefonie nutzen können.

Auch „Oma Finchen“ könnte hiervon profitieren, denn POTS hat ein paar entscheidende Nachteile gegenüber ISDN:

  • Wir wissen, dass ältere Menschen möglichst lang noch zu Hause wohnen möchten und dies eigentlich auch müssen, da Pflegeheim-Kapazitäten im Hinblick auf die immer älter werdende Bevölkerung dem nicht gewachsen sind. Dabei ist gerade die telefonische Erreichbarkeit sehr wichtig.
  • Seit Jahren sind Systeme wie Hausnotruf etabliert. Sei es der „richtige“ Hausnotruf mit Alarmierung eines Pflegedienstes, mittlerweile gibt es aber auch ähnliche Lösungen, die auf Knopfdruck oder bei Ereignissen wie Umfallen voreingestellte Rufnummern (Verwandte, Nachbarn, etc.) anrufen können.
  • Ältere Menschen können dazu neigen, Telefonhörer nicht richtig aufzulegen, Mobilteile nicht auf die Ladeschale zu stellen, oder, bei Ende des Telefonats den „Auflegen“-Taster nicht zu drücken.

Es gibt diverse Möglichkeiten, die dazu führen, dass der Leitungszustand „abgehoben“ bleibt. Man kann denjenigen nicht anrufen, da bei POTS die Leitung nicht getrennt werden kann. Anders ist das bei ISDN, hier gibt es eine gesicherte Signalisierung: legt der Gesprächspartner auf, weiß auch das eigene Endgerät durch eine Mitteilung der Vermittlungsstelle, dass das Gespräch beendet ist und „legt auf“, ähnlich wie das bei einem Handy der Fall ist. Der Teilnehmer ist also wieder erreichbar. Doch selbst wenn eine Leitung belegt ist, kann der 2. B-Kanal hier Abhilfe schaffen und man kann trotzdem noch anrufen.

Das absurde daran ist: Über ISDN sagt man, es sei veraltet und müsse deswegen abgeschafft werden, den Telefonanschlusstyp aus dem 19. Jahrhundert hält man aber am Leben.
Wie gesagt: die Abschaffung von alter ISDN-Vermittlungstechnik ist kein Grund, dem Kunden nicht weiter ISDN als Anschlusstyp liefern zu können; dann müssten sich die Kunden nicht zahlreiche neue Telefonanlagen oder ISDN-Gateways kaufen/mieten. Ein Schelm, wer Böses dabei denkt…

Praktische Probleme durch Abschaffung des Parallelnetzes

Mit den MSANs gibt es dann jetzt also wieder „alles über ein Netz“. Moderner als das alte soll es sein, und besser. Ich sehe jedoch nur immer wieder die Zahl von 10 Tagen, die mein Anschluss jedes Jahr kaputt sein darf, ohne dass ich einen Grund habe, mich zu beschweren. Und ich sehe Logs diverser Router, die immer mal wieder nachts, teilweise mehrfach, neu synchronisieren. Und man darf an der Stelle nicht vergessen, dass DSL erfordert, dass beide Gegenstellen erst ermitteln müssen, welche Frequenzen auf der Leitung genügend Potential zur Datenübertragung bieten, bevor Datenübertragung möglich ist. Je nach Leitungsqualität kann ein Synchronisationsvorgang Minuten dauern.

In den Jahren, in denen ich mit ISDN-Amtsanschlüssen gearbeitet habe, dauert es nach dem Anschluss in der Regel wenige Sekunden, bis ein Anschluss nutzbar ist. Hier gibt es keine Passwörter, keine „Provisionierung“, kein Webinterface, kein DHCP, kein Firmwareupdate, nichts. Einfach einstecken und sofort erreichbar sein.
Und heute? Tja, blinkt das DSL-Lämpchen am Router, geht nichts mehr, man ist auf das Handy angewiesen, das wie selbstverständlich vorausgesetzt wird, bzw. direkt das Smartphone, damit man die Störungsmeldung über das Onlineportal abwickeln kann.
Doch was, wenn aus Rationalisierungsgründen VoIP/DSL und Mobilfunk dieselbe Infrastruktur nutzen und beides gleichzeitig ausfällt (auch das habe ich schon erlebt)?
Spricht man das Thema Notruf an, heißt es „Wenn der Festnetzanschluss gestört ist, nehmen Sie doch einfach Ihr Handy für den Notruf“. Tja, das muss wohl die Zukunft sein, von der immer alle reden. Und großflächige Ausfälle sind kein Hirngespinst, sondern bereits Realität geworden. Allein im Juli 2019 gab es in Hessen eine großflächige Störung, durch die 110 und 112 über Stunden nicht erreichbar waren.

Fazit

Das war jetzt eine ganze Menge Text, daher möchte ich die Kernaussagen einmal zusammenfassen, wie ich die gegenwärtige Entwicklung sehe bzw. was mich daran stört:

  • ISDN wird abgeschafft, am meisten Vorteile, v.a. Einsparungen, haben jedoch die Provider.
  • ISDN wird als veraltet und überholt abgetan. SIP ist heute noch nicht auf dem Stand, auf dem ISDN schon immer war, und wird es so schnell auch nicht werden.
    • Zeitgleich hält man aber den analogen Telefoniestandard am Leben, der in der Praxis nochmal deutliche Nachteile mit sich bringt
    • Es ist technisch machbar, den ISDN als Anschlusstyp weiterhin anzubieten, das wird aber nicht gemacht.
  • VoIP wird in den Markt gedrückt, aber viele Vorteile, die von VoIP/SIP beworben werden, treffen in der Praxis nicht oder eingeschränkt zu
  • Die Umstellung geschieht mit seinem so hohen Druck, dass die alten Strukturen abgebaut werden, selbst wenn die neue Infrastruktur nicht zur Verfügung steht. Die Leidtragenden sind auch hier wieder die Kunden.
  • Generell gibt es einen enormen Rückschritt in Sachen der Ausfallsicherheit unseres Kommunikationsnetzes, der verschwiegen wird. Es ergeben sich zusätzliche Aufwände und Kosten für Kunden und ungelöste Probleme werden tot geschwiegen („Wenn das Festnetz nicht geht, dann nehmen Sie doch einfach ihr Handy.“)

Telefonanlage mit Asterisk 13 und PJSIP

In diesem Artikel habe ich das große Ganze zu meiner Heiminstallation mit Asterisk 13 und auf Raspberry Pi-Basis erläutert.
Es war nicht ganz leicht, PJSIP zu konfigurieren, da es im Internet kaum Einrichtungsbeispiele für PJSIP-Installationen gibt (zumindest deutlich weniger als für chan_sip), insbesondere gab es nichts, was auf die Spezialitäten für den Telekom AllIP-Anschluss eingeht und über die Verwendung von pjsip_wizard.conf konnte ich in diesem Zusammenhang garnichts finden.
Daher stelle ich in diesem Artikel die Konfiguration meines Asterisk vor und gehe auf ein paar Herausforderungen ein, die sich durch die Umstellung von chan_sip ergeben haben.

Mein Dank geht an Jürgen Büssert und Dr. Martin Rother, die ebenfalls Einblick in die Dokumentation ihrer „Asteriskse“ geben.

Weiterlesen

Heim-Server auf Raspberry Pi mit Asterisk, fhem, LDAP und davical

Vorgeschichte

Als ich vor ein paar Jahren meine jetzige Wohnung bezog, hatte ich eigentlich vor, ISDN als Amtsanschluss zu buchen und mir eine kleine HiPath-Telefonanlage zu installieren.
Es stellte sich heraus, dass ADSL-mäßig in der Wohngegend aber wohl alles ziemlich dicht ist, dafür ist aber VDSL verfügbar. Damit fiel ISDN als Option weg, da mir schnelles und stabiles Internet wichtig ist.

Ich habe dann zunächst zwei DECT-Mobilteile an die bereits vorhandene Fritzbox angemeldet um das Thema „Telefonie“ in Ruhe neu bewerten zu können.
Eine konventionelle Telefonanlage bietet zwar viele Funktionen was Rufverteilung, Berechtigungen, etc. angeht, aber es ist schwierig, die Außenwelt anzubinden, z. B. mit selbst geschriebener Software.
Meist sind dazu zusätzliche (auf Windows basierende) Server und (teure) Lizenzen notwendig, was ich weder aus Kostengründen noch aus Energiegründen für sinnvoll hielt.
Die sonstigen Funktionen werden auch nicht benötigt, denn in der Regel wird eine Telefonnummer genutzt, bei der alle (aktuell vier) Telefone klingeln.

Dazu kommt, dass man bei den HiPath-Anlagen zur Wartung immer die Windows-Software Manager C bzw. Manager E benötigt, selbst, um Telefonbucheinträge zu verwalten. Das ist ungünstig in einem Haushalt, in dem keine Windows-PCs vorhanden sind.

Ein möglichst einfach zu administrierendes Anlagentelefonbuch war mir wichtig. Die HiPath kann zwar LDAP, aber nur als Namensauflösung für eingehende Rufe.

Bei Asterisk, das wusste ich aus vorhergehenden Projekten, kann man sehr einfach diverse Dinge steuern.

Eine konventionelle TK-Anlage schied also aus, auch die Fritzbox erwies sich alsbald als ungenügend für meine Ansprüche. Die Details führe ich hier mal nicht aus, bei Interesse kann ich dazu mal noch einen eigenen Artikel spendieren.
Ich nahm also einen Raspberry Pi (ursprünglich Model B, heute Version 3) und Raspbian als Basis.
Der Raspberry Pi regelt die Telefonie, Zusatzdienste zur Telefonie, Telefonbuch, Kalender und auch Heimautomation.
Wenn jemand an zusätzlichen Details interessiert ist: einfach melden!

Folgende Dienste sind im Einzelnen realisiert:

Asterisk

In der Installation sollen folgende Endgeräte unterstützt werden:

  • SIP-Tischtelefone
  • DECT-Mobilteile
  • Fax (für alle Fälle)
  • POTS

Die Fritzbox wird dazu als Gateway missbraucht: Fax und ein analoges Wandtelefon sind an die a/b-Ports angeschlossen und in der Fritzbox sind „Internet-Rufnummern“ eingerichtet, die sich am lokalen Asterisk registrieren. Die SIP-Tischtelefone (bei mir z. B. Snom 370 und 720) registrieren sich direkt am Asterisk.
Da alle Telefone auf der „einen Seite“ der Wohnung sind, hört man sie schlecht, wenn man sich in einem der anderen Räume aufhält, daher gibts das Siemens Miniset 325 im Flur.
Auch die DECT-Mobilteile sind (zur Zeit noch) an der Fritzbox angemeldet. Ich habe mich für Gigaset SL3 professional entschieden. Diese Geräte bieten einen guten Kompromiss, da sie an verschiedenen HiPath-Telefonanlagen als Systemmobilteil funktionieren, gleichzeitig aber auch an der Fritzbox ein Anlagenmenü bekommen.
Demnächst (Gigaset N510 IP Pro), damit soll das alles besser funktionieren, man hat dann auch nicht die 3 Gedenksekunden als Wahlende-Erkennung.

Mit dem Umstieg auf den Raspberry Pi 3 habe ich das System komplett neu und damit auch auf aktuellsten Versionen aufgesetzt. Bei Asterisk entschied ich mich für die aktuelle LTS-Version, also Version 13. Bei Asterisk ist derzeit die Migration vom aktuellen SIP-Channeldriver chan_sip zu PJSIP im Gange. Ich entschied mich dafür, gleich für die Zukunft gerüstet zu sein und den neuen Stack zu verwenden. Da ich im Internet keine Einrichtungsbeispiele für mein Setup finden konnte, habe ich die Konfiguration meines Asterisk in einem separaten Beitrag dokumentiert.

LDAP

Alle Telefone sollen auf dasselbe, einfach zu administrierende Telefonbuch zugreifen können. Auf dem Raspberry Pi läuft daher ein handelsüblicher OpenLDAP-Server. Für die Administration des Telefonbuchs nutze ich den Teil eines Skripts, das ich im IP-Phone-Forum gefunden habe. Dieses Skript stellt ein Telefonbuch für Cisco-Telefone zur Verfügung und nutzt dafür eine Möglichkeit, das Telefonbuch der Fritzbox als XML zu laden. Das mache ich mir zunutze: ich lade das Telefonbuch per Cronjob runter, konvertiere es per XSLT in LDIF und beschicke damit den LDAP-Server. So haben alle das gleiche Telefonbuch und ich kann es bequem mit dem Webinterface der Fritzbox administrieren.

FHEM

Unsere Waschmaschine steht in einem Gemeinschafts-Waschkeller. Der Strom wird über die einzelnen Haushalte über einen sogenannten Haushaltsumschalter geschaltet, das heißt, es kann immer nur ein Haushalt gleichzeitig waschen. Das führt dazu, dass die Möglichkeit zur Nutzung der Waschmaschine immer nur zeitweise gegeben ist. Dazu kommt, dass die Waschmaschine zwar eine Restzeitanzeige besitzt, die aber eher ein Schätzeisen ist. Was sie besonders gut kann: 7 Minuten als Restzeit anzeigen, die dann über 30 Minuten dauern. Somit besteht großes Interesse, genau dann mitzubekommen, wenn die Waschmaschine fertig ist.
Ich habe hier eine elegante und minimalinvasive Lösung auf der Basis von Homematic-Komponenten und dem freien Heimautomationsserver fhem gefunden.
Dazu wird eine Funksteckdose Homematic 130248 eingesetzt, die eine eingebaute Leistungsmessung hat. Der Regelkreis ist einfach: wird über 50W verbraucht, wird eine Zustandsvariable auf „ON“ gesetzt. Wird länger als 5 Minuten weniger als 5W verbraucht, wird der Zustand auf „OFF“ gesetzt und eine Push-Nachricht aufs Handy geschickt, über das offene Framework „Pushover“.
Ich habe das dann erweitert und lasse auf einem Snom-Telefon ein Bild anzeigen und eine Taste fängt an zu blinken.

Davical

Schließlich entstand auch die Notwendigkeit gemeinsamer Kalender. Diese sollten „cloudlos“ umgesetzt werden. Somit wurde ein einfacher davical-Server installiert. Wann immer ein Gerät im heimischen WLAN eingebucht ist, erfolgt eine Synchronisierung.

Alte Telefonanlagen um moderne Funktionen erweitern

In vorigen Einträgen habe ich ja schon etwas dazu geschrieben, dass ich heute durchaus einen Sinn in der Zweidrahtschnittstelle sehe.
Es mag also sein, dass man noch eine ältere TK-Anlage aus gutem Grund betreibt, sei es, weil eine flächendeckende Versorgung mit Endgeräten (und sogar auch DECT-Kanalelementen) sehr kostengünstig möglich ist.
Dass das Telefonnetz auf VoIP umgestellt wird, ist Realität. In einem vorigen Eintrag habe ich ja bereits auf die Möglichkeit hingewiesen, dass man eine Amtsanbindung erreichen kann, indem man sich ein ISDN-SIP-Gateway mittels Asterisk baut.
Wenn man diesen Weg eingeschlagen hat, hat man die volle Kontrolle nicht nur über ein Asterisk, sondern über die in einem Computer verbauten ISDN-Karten auch einen relativ flexiblen Zugang zur TK-Anlage.
Ich dokumentiere hier einmal, welche Funktionen ich selbst in einer solchen Installation umgesetzt habe. Weiterlesen

Umstellung von ISDN auf VoIP bei konventionellen TK-Anlagen

Die Umstellung des Telefonnetzes von ISDN auf VoIP ist keine Zukunftsmusik mehr, sondern gehört mittlerweile zum Alltag Viele kleinere Provider bieten bereits kein ISDN mehr an, und die Telekom ist seit Längerem dabei, laufende ISDN-Anschlüsse aktiv zu kündigen.
Bei vielen TK-Anlagen-Besitzern kommt daher aktuell die Frage auf, wie man dieser Umstellung begegnet. Ich habe die gängigsten Alternativen aus meiner Sicht mal aufgeschrieben.

Weiterlesen

Upcycling klassicher Telefonanlagen / Renaissance der TDM-Schnittstelle

Bestandsaufnahme

Hier habe ich einen Abriss gegeben über die jüngere Vergangenheit der Telefonanlagen und Telefonie, und warum ich der Ansicht bin, dass das Tischtelefon zu Unrecht in Vergessenheit gerät und mehr leisten könnte als es das in den meisten Fällen heutzutage tut.

Wie sieht die Gegenwart aus? Heute gibt es prinzipiell 3 Arten von TK-Anlagen:
Reine VoIP-TK-Anlagen, meist basierend auf Asterisk, FREESWITCH, ähnlichen OpenSource-Projekten oder auch Eigenentwicklungen. Sie werfen meist Jahrzehnte Entwicklungen im TK-Anlagen-Markt über Bord und hinsichtlich Leistungsmerkmalen endet der Horizont schnell nach absolut grundlegenden Leistungsmerkmalen wie dem Vermitteln von Gesprächen und Konferenzen. Auch die Menüführung bei Endgeräten aktueller VoIP-Anlagen bei Tischgeräten und erst recht in Sachen DECT-Integration kommt bei weitem nicht an das Niveau von Komfort heran, das man vor 20 Jahren bereits mit deutlich weniger Ressourcen erreicht hat.
Weiterlesen

O du schöne Zweidraht-Welt — Resterampe oder Renaissance?

Klappentext

Die Kommunikationswelt befindet sich im Wandel. In wenigen Jahren wird ISDN als Kommunikationsanschluss für Jedermann Geschichte sein, die Umrüstung auf ein IP-basiertes Telefonnetz schreitet voran. Die Omnipräsenz von Smartphones, die steigende Verbreitung von WLAN-Routern mit integrierten Telefoniefunktionen und die Möglichkeit von „Allnet-Flats“ sowie die immer besser werdende Mobilfunkabdeckung stellen die Konzept „Telefonanlage“ „Tischtelefon“ infrage. Doch wird bei diesen Trends nicht etwas übersehen?
Ich bin – kurz gesagt – unzufrieden mit der aktuellen Situation und versuche, mit diesem Artikel darzustellen, woher wir kommen, wo wir stehen und wohin die Entwicklung gehen könnte. In einem zweiten Artikel beschreibe ich, wie man die Situation meiner Ansicht nach verbessern könnte.

Von Vieldraht zu Zweidraht, von Telefon zu Systemtelefon

Mit der Einführung von ISDN und rechnergesteuerten TK-Anlagen wurden diese massentauglich. Wo zu analogen Zeiten Abfrageplätze noch Schuhkarton-große Anschaltgeräte und daumendicke Kabel zur Anbindung an die Anlage brauchten und Telefonanlagen selbst für kleine zweistellige Nebenstellenanzahlen ohne nennenswerte Systemfunktionen mehrere Schränke füllten, gibt es seit Mitte der 1990er Jahre TK-Anlagen, die in der Lage sind, jeden Teilnehmer mit einem Systemtelefon zu versorgen. Modernere Anlagen wie die Bosch Integral 3 bieten wiederum auf Schuhkartongröße eine komplette TK-Anlage.
Durch ISDN und die Einführung der Übertragungsschnittstellen S0 und der zweiadrigen Variante Up0 wurde vor Allem eines Standard: der einpaarige Teilnehmeranschluss. Telefone brauchten keine separate Spannungsversorgung: alles kommt aus der Anlage. Nach Belieben kann der Teilnehmer mit einem Port für ein Systemtelefon, a/b, DECT-Kanalelement oder – dann natürlich mit 2 Paaren – S0 versorgt werden.

Ethernet: Fortschritt durch Komplexität?

Nun, Ethernet und IP-basierende Netze außerhalb der Rechnerkommunikation zu verwenden ist die Zukunft, oder eher schon die Gegenwart. In der Regel werden Neubauten mit strukturierter Verkabelung ausgerüstet, Gebäude untereinander und tlw. sogar Etagen innerhalb desselben Gebäudes mit Glasfaser statt Kupfer verbunden. Die strukturierte Verkabelung klingt sinnvoll und Flexibilität ist das Verkaufsargument Nr. 1, aber wohin führt sie?
Sieht man der Realität ins Auge, sind vor allem bei großen Installationen die wenigsten Telefone diejenigen, die z. B. aufgrund des benötigten Datendurchsatzes einen Ethernetanschluss wirklich benötigen.
Die meisten Telefone haben S/W-Displays, teilweise nicht einmal Vollmatrix-Displays, oder – noch absurder – weder Display noch Funktionstasten.

In Summe wird mehr Kupfer benötigt. Pro Netzwerkport werden 8 Kupferadern verlegt. Bei der sog. TDM-Technik, also dem zweiadrigen Anschluss wie bei Up0, ließen sich mit 8 Adern 4 Up0-Ports realisieren. Siemens mit der Master/Slave-Schaltung bietet sogar die Möglichkeit, an einem Systemtelefon noch ein weiteres zu betreiben. Also 8 Systemtelefone ohne separate Spannungsversorgung an einem Netzwerkkabel.
Bei IP bieten manche IP-Telefone einen integrierten 1-Port-Switch, aber für ein zweites Endgerät wird dann direkt ein PoE-Injektor zur Spannungsversorgung fällig.

PoE-Injektoren und -Switches bringen zusätzliche Komplexität in die Installation, vor allem die Frage nach Notstromfähigkeit wird so komplexer.

IP-Telefone bringen aber auch mehr Komplexität an einer anderen Stelle: Der überwiegende Teil der IP-Telefone basiert auf einem eingebetteten Linux. Meist bieten sie ein Webinterface.

Aber was bedeutet das? In jedem Tischtelefon läuft ein general-purpose-Betriebssystem, bestehend aus etlichen Komponenten und Bibliotheken, basierend auf einem lediglich an die Prozessorarchitektur angepassten Linux-Kernel bishin zum Webserver, mit allen Problemen und (Sicherheits-)Schwachstellen.
Das ist einigermaßen verschmerzbar, wenn die zusätzliche Leistungsfähigkeit auch genutzt wird, zum Beispiel indem das Telefon in der Lage ist, dem Nutzer Daten aus dem Unternehmensnetz oder Internet anzuzeigen, Videostreams von Kameras abzuspielen, etc. Geräte wie das Grandstream GXV3275 nutzen das Potential direkt aus und eignen sich zusätzlich als WLAN-Router und Thinclient.

Doch die Realität zeigt: Anbindung externer Dienste an die VoIP-Telefone von TK-Anlagen sind meist komplex realisiert, es werden oftmals zusätzliche Server benötigt (die also genauso gut in der Lage wären, bspw. Webseiten in ein spezielles Format für Nicht-VoIP-Telefone zu wandeln) und im handelsüblichen Büro gibt es meist 2 Endgeräte dieser Klasse: das der Sekretärin und das vom Chef.

Zweidraht-Telefonie: Sackgasse oder Chance?

Systemtelefone auf Zweidraht-Basis (im Folgenden Up0) wirken mittlerweile wie ein verstoßenes Kind: praktisch kein TK-Anlagen-Hersteller betreibt hier noch Entwicklung. Aus Herstellersicht ist der Schritt leicht erklärt: Up0 ist eine Nische. Die Schnittstellenbausteine, die Entwicklung auf dieser Technologie, die Entwicklung dedizierter Telefon-Endgeräte, diese Felder erfordern spezielles Wissen, sind also teuer. Ethernet-Technologie und Linux-SoCs gibt es wie Sand am Meer und Entwicklung lässt sich billig einkaufen. Ob das System eine Webcam betreibt oder ein Telefon: die grundsätzliche Architektur und die Betriebssystembasis sind idR gleich.
Dabei müsste das garnicht so sein und es geht auch durchaus anders: vxWorks und QNX sind nur zwei Beispiele für sogar echtzeitfähige Betriebssysteme, die speziell auf eingebettete Systeme ausgerichtet sind und bspw. Alcatel hat für eine Serie ihrer IP-Telefone auf vxWorks gesetzt. Der Vorteil ist zum Beispiel eine erheblich kürzere Bootzeit. Aber auch die Kompetenzen werden vielleicht etwas sinnvoller verteilt und jeder macht das, was er gut kann: Der TK-Anlagenhersteller entwickelt und wartet eine Applikation für die Telefonie und überlässt die Wartung eines Betriebssystems jemandem, der Profi in diesem Bereich ist — und sich vor allem auch um die Sicherheit dieses Systems und Bereitstellung von Sicherheitsupdates kümmert.
Wirklich schön ist nämlich nicht, denn wenn der Hersteller spart, muss es der Kunde ausbaden:
Nicht jeder Kunde für eine TK-Anlage ist das Standard-Büro aus der Katalogwelt. Nicht jedes Gebäude verfügt über strukturierte Verkabelung. Und wenn eine Bestandsverkabelung vorhanden ist und bei 99% der Teilnehmer die einzige Anforderung „Telefonieren“ ist, warum dann so viel Komplexität ins Haus holen?
Zumal es mittlerweile so scheint, als sei jedes Linux-basierende Endgerät eine potentielle Gefahr für das Intra- oder Internet: ein Buffer Overflow hier, eine unzureichende Zertifikatsüberprüfung da und schon hat man 100 kleine Agenten auf den Schreibtischen stehen, die nach Belieben Telefonate abhören, mitschneiden können oder auch andere Geräte im Netzwerk angreifen oder aushorchen. Selbst Geräte bei denen man es als unbedarfter Nutzer nicht für möglich hält, wie zum Beispiel Drucker, sind so eine Gefahr.
Das wird durch den Trend „Internet of Things“ wird das gerade nochmal potenziert, und das Grundproblem fasst dieser Tweet schön zusammen.
Bestes Beispiel dafür, welche Gefahr davon ausgeht, ist der DDoS-Angriff auf Dyn im Okt. 2016, der von „Geräten im IoT-Bereich“ ausging. Überhaupt ist mangelnde Sicherheit (meist stammend von schlechter Upgradepolitik) eines der größten (ungelösten) Probleme dieser Geräteklasse.
Und werden Schwachstellen bekannt, hat der Kunde nicht einmal die Möglichkeit, diese zu beheben sondern ist darauf angewiesen, dass der Hersteller reagiert. Der hat aber vielleicht kein Interesse daran, zum Beispiel weil der Kunde seit 2 Jahren kein neues Softwarerelase für seine Anlage gekauft und somit sein „Recht“ auf Firmwareupdates verwirkt hat, oder weil die Endgeräte einfach generell „End of life“ sind. So wird dann ein Gerät, das noch sämtlichen Anforderungen gerecht wird und das man garnicht austauschen möchte, zum Sicherheitsrisiko.
Es ist auch aus ökologischer Sicht unverantwortlich, auf diese Weise den Neukauf von Geräten zu erzwingen, ohne dass der Kunde echten Mehrwert benötigt, aber die aktuellen ein akutes Sicherheitsrisiko darstellen.

Dazu kommt: bei den meisten Herstellern besitzt das Systemtelefon, was die Teilnahme am Systembetrieb angeht, wenig eigene Intelligenz. Displayinhalte, Funktionen der Funktionstasten, alles wird in der Anlage generiert. Über mehrere Generationen ist die Hardware und ihr direkter Funktionsumfang sogar praktisch gleich geblieben. Beispiel Siemens: Optiset E, Optipoint 500-Serie, OpenStage TDM-Serie. Es gibt funktional kaum Innovationen (Display-Hintergrundbeleuchtung, Displaytechnologie, Anzahl und Art der Funktionstasten), über Generationen hinweg. Dafür aber stetige Einsparungen im Produktionsaufwand, auf Kosten der Langlebigkeit der Geräte, wie zum Beispiel die Bevorzugung von bedruckten Gummitastaturen gegenüber Kunststoffeinsätzen wie beim Optiset E.
Wenn es auch leichte Veränderungen gab; „moderne“ Anwendungen werden tendenziell dazu genutzt, IP-Endgeräte zu verkaufen, obwohl z. B. die OpenStage 40-TDM-Geräte mit ihren Vollgrafik-Displays für eine ausgefeilte Interaktion mit dem Nutzer geeignet wären.
Obwohl ISDN grundsätzlich bereits HD-Audio, z. B. mit dem Codec G.722, auch als „7 kHz-Telefonie“ bezeichnet, unterstützt, ist mir keine TK-Anlage bekannt, die das am Systemtelefon unterstützt.
Leider wurde bei der Verbreitung von ISDN versäumt, dies als Alleinstellungsmerkmal prominenter zu platzieren und Telefonie mit 3,1 kHz Bandbreite als „alt“ zu vermarkten.
Ggf. wäre es also möglich, auch hier durch vergleichbar wenig Änderungen an den Geräten eine deutliche Qualitätsverbesserung im Telefonieren herbeizuführen.
Aber letztendlich: das Systemtelefon ist in den meisten Fällen ein Terminal, und so sollte es generell möglich sein, auch funktionalen Mehrwehrt durch ausgefeiltere Software zu ermöglichen.

Telefon: quo vadis?

Die Kommunikationswelt verändert sich. Nicht nur Mobiltelefone sind omnipräsent, sondern Smartphones sind ebenfalls als allgegenwärtig anzusehen, „Jeder“ hat eins und in der Regel auch eine Anbindung an schnelle mobile Datennetze. Das Telefonat verliert jedoch an Bedeutung.
Ein Faktor mag sein, dass gerade bei günstigen Angeboten zwar in irgendeine Form Flatrates für mobiles Internet enthalten sind, Telefonate aber in der Regel Geld kosten – eine Allnet-Flat ist teuer. Zudem fördern soziale Netze die Affinität zum Schreiben kurzer Nachrichten gegenüber von Telefonaten.
Es fühlt sich leichtgewichtiger an, „mal eben“ eine Nachricht zu tippen statt sich Zeit für ein Telefonat zu nehmen.
Für verschiedene Anwendungsfälle mag das stimmen, zum Beispiel für das Übermitteln von Statusinformationen, gerade an eine Gruppe. Viele schätzen als Vorteil, dass es ein „Log“ gibt und man somit immer nachvollziehen kann, was besprochen wurde.

Fakt ist aber: diese Plattformen versagen sämtlichst daran, dies in archivierfähiger Weise zu tun.
Zunächst einmal sind alle „öffentlichen“ Plattformen von privaten Dienstleistern abhängig (Twitter, Slack, Facebook, Snapchat, WhatsApp, etc.). Privates und Geschäftliches ist nicht getrennt und vor Allem bedeutet „Konversation“ in der Regel, dass Nachrichten als quasi-endloser Strom von Nachrichten dargestellt werden und es kaum sinnvolle Suchmöglichkeiten gibt.

Das Schreiben von Textnachrichten fühlt sich leichtgewichtiger an, aber oft löst ein kurzes Gespräch Probleme deutlich effizienter. Meiner Ansicht nach ist es sinnvoller, beide Parteien nehmen sich vielleicht 2 Minuten Zeit, einen Sachverhalt bei voller Aufmerksamkeit zu klären, statt über 10 Minuten immer wieder Nachrichten auszutauschen, und somit bei keiner Sache voll dabei zu sein. Dann doch lieber eine Diskussionskultur pflegen bzw. wieder aufbauen, indem man am Ende eines Telefonats das Ergebnis zusammenfasst, falls es archivierungswürdig ist, oder das Gespräch oder Teile davon direkt von der TK-Anlage archivieren lässt.

Innerhalb von Ansätzen wie „Bring your own device“ gibt es ja auch Bestrebungen, komplett auf hausinterne Telefonie zu verzichten, den Mitarbeitern ggf. Handy-Verträge zu bezahlen und komplett mit Mobiltelefonie zu arbeiten. Ich sehe aber das Telefon eher als Teil der Infrastruktur des Ortes, an dem mich gerade befinde. Warum soll ich z.B. die Intelligenz, Licht und Heizung meines Arbeitsplatzes zu steuern, mit mir herum tragen?
Warum muss ich selbst Telefonnummern von etlichen Mitarbeitern verwalten, wenn diese Informationen zentral vorgehalten werden können, ich statt konkreten Personen „Dienststellungen“ („Das Lager“, „Der Empfang“,…) anrufen kann und diese mit zusätzlichen Metadaten versehen sein können (Empfang anrufen, Fr. Müller aktuell im Urlaub, vertreten durch Hrn. Maier)?
Warum muss ich mein Smartphone aus der Hosentasche holen, am Rechner zum millionsten Mal „Wetter Köln heute“ bei Google eingeben, wenn genau diese Informationen auf einem Gerät präsentiert werden können, das sowieso auf meinem Schreibtisch steht?
Was spricht also dagegen, das Tischtelefon als „Begleiter“ zu erfassen? Welche konkreten Funktionen dieses Gerät erfüllen soll, überlegt man sich ein Mal, und dabei kann es auch bleiben. Diese Funktionen erfüllt es dann immer, es gibt keine „Apps“, die man schließen oder extra öffnen muss. Somit bleiben Smartphone und PC frei von Onlineverläufen, Aktivitäten meiner Chatpartner und Telefonate auf anderen Leitungen.

Die derzeiten Lösungen auf dem „freien Markt“ reichen hier noch längst nicht aus, hier ist noch viel Arbeit für eine durchgängige Interoperabilität zu leisten. Es ist zum Beispiel naheliegend, dass ein Mitarbeiter ein laufendes Gespräch vom Handy aufs Tischtelefon weiterreichen möchte, wenn er von einem Außentermin zurückkommt.

Dear Linux…

Dear Linux,
living with you has become hard.

To start with, I use a current ThinkPad and the latest Ubuntu Linux LTS.
Up to now, the things I have to do occasionally so I can do my daily work:
1) Restart network-manager after wakeup because WiFi looks like it works but it doesn’t
2) Kill unity-panel-service at least every ~1,5 day because it continuously eats system resources (I once catched it claiming 8 gigs of RAM)
3) After issuing a print job, open print queue GUI manually because otherwise the print job isn’t really started

Moreover, I am forced to run a beta-kernel, because, using the official kernel, standby after undocking suddenly got broken. And, since day one of using this system, there is the issue of laggy audio output which needs some seconds until audio is played and permanently blocks the whole application having sound output for several seconds.
As a side note: whilst running Windows 7 on the same machine, none of this issues is present.

Apart from that, I constantly face minor and major issues concerning the applications themselves, also interfering my daily work. For example when working on publications, I am forced to use up to four different tools, because a graphic tool doing sophisticated vector drawings, diagrams and graphs at one go simply doesn’t exist. Additional overhead is caused because there is no proper interoperability between those. And, still, every GUI framework seems to come up with its own philosphy how certain keystrokes and GUI elements should work, apart from the fact that there is still no really gobal clipboard.
The issues I have using this tools are well-known, documented and exist at least since I began using Linux for my daily work again several years ago. All of these applications didn’t make visible progress since then. What is more astonishing: some of them feel like there hasn’t been much change since my first contact with Linux roughly 17 years ago.

I know what some of you might think now. Please, don’t come up with „It’s obvious that you have such problems with distro X, you should use distro Y instead! Everything is better there!“
During the last years, I tried a number of different distributions, all promoted as „The one and only distribution to bring back stability, reliability and everything else you love!“. I tried a number of these distributions hoping that it would do its job better. But all of them fell short on their promise. Plus, the more atypical the distribution, the bigger the problem to find someone who can actually help to solve problems with it.

Summed up over the last years, I invested an absurd amount of businessdays to

  • clean install my system
  • fix issues to get my hardware work in the first place
  • fix issues that came up after package updates or distribution upgrade
  • search for help to all of the above
  • .

Nowadays, the diverse community platforms are full of problems and suggestions, but unfortunately, an immense ammount is on a level of esotheric methods or „solutions“ like „I did a clean install and my issue is gone now.“. These are things for which Linux users used to laugh at Windows users for years.

Don’t get me wrong, I like computers, I like to use them and I also like hacking and fiddling with configuration files to reach a certain goal. As a hobby or to realize sophisticated server functionalities. But concerning my system for daily work, I need a reliable system with flawless support for the internal hardware as well as periphery, and the ability that I can update the system to get new features and bug / security fixes without having to fear that functionality breaks. Again, this is what Windows users have been laughed at by Linux users for years.

Concerning my concrete issues in the introduction, after failing to unearth workable information out of the depths of community platforms, I lastly went the official way by filing bugs.
Most of them are open since months now, most of them did not gain any serious attention yet apart from complaining that I did something wrong when writing the bug report or not providing the right / enough information. In every case I provided this information, but none of the bugs has been solved yet or treated in a way that it helped me to fix the issues.

And sadly, even if I would succeed in all of this, there is still a big problem given by the abscence of productivity applications apart from web, mail, office and graphics.

I once had to cut some video material. So I went through the repositories and some PPAs out there to get a video editing tool. I tried three different ones, all being advertised as compatible with my system and being a top-notch thingie.
None of them succeeded in cutting the video correctly, one even did not start.
I ended up tinker with ffmpeg and cut the video blindly, hoping that the time data discovered using a second tool lead to the needed result. Is this the way things should be in 2016?

Providing a product also means that it needs servicing, maybe over a long period of time. For example, „Getting Things Done“ is my favourite methode of – well – getting things done.
This method became popular in ~2006, which means that most applications supporting this method also came up at that time.

Today, the only at least somehow working GTD tool for the Linux desktop is Getting Things GNOME. Sadly, it has some essential backdraws since it is still in some early stage of development (the version number states 0.3.1), but, even worse, it crashes now and then, letting an unpredictable amount of modifications to my data vanish. In fact, the last maintenance release was in 2013. But at least it works most of the time. All other tools I found during many search sessions weren’t even updated since the initial GTD hype, leaving them in an incompatible state since they aren’t hardly maintenanced to be up-to-date to newer Linux distribution versions, but still found in repositories. This lets me think that software repositories have a big amount of members who only exist on paper.

The thing is: I for sure understand that much of what is made possible in the Linux world is made by people in their freetime. But at close of day, I need to get my work done, and to succeed in this I am perfectly fine with spending money for a commercial product with the promise of maintenance over a long period of time – if only there were such products.

Moreover, I have the impression that the platform itself is abandoned by the industry slowly but surely. It is actually getting harder and harder to take part in business conference calls. Two wide-spread tools, Adobe Connect and Skype, lack fundamental support under Linux. To share my screen and benefit from all functionality of Adobe Connect, the „Adobe Connect Add-In“ is needed. There is no Linux version of it. Period.
The last really native version of Skype is heavily outdated and can’t be used for virtually anything except I want to communicate with other Linux users using the same version. For a more current version, the is the new „Skype for Linux“ which isn’t a native application anymore but just a wrapper for the web application. Apart from chats and audio calls there doesn’t seem to work much by now, altough there have been a big number of updates since first release. Oh, and it loves to crash, too.
And, to add one more: Citrix GoToMeeting doesn’t support Linux at all.
So, I have actually no possibility to take part in conference calls and share my screen using a tool which is available for Windows, macOS and Linux and I’m already forced to use an other OS here.

At this point, I am beyond the question of using open source software because it is for example better in terms of privacy or ideology. What I see is: I just want to use my computer as a tool to get my daily work done. And I see that the best I can actually get is a system that hinders me every single day, productive tools lacking innovation and the mere absence of commercial products to compensate lack of open source developers where it is necessary to pay a company for developing an maintaining a product for a specific use case. I tried to take part in the open source process and help the people by describing my problem and offer my help to further investigate and test stuff. But my offer of help wasn’t answered many times, leaving me in a desperate situation.

As it is, I think I won’t change anything in my setup. I have a system that somehow works for me, there is a bunch of issues but I somehow can work around them. I think I won’t give the n+1-th distribution a try, eventually determining that all of the above issues may be gone then but some others are appear instead.

Dear Linux, living with you has become hard.

Für Blaulichtverbot auf Autobahnen

Heute war es wieder einmal soweit. Auf meinem morgendlichen Weg zur Uni staute es sich auf der Autobahn. Es ging nur im Schneckentempo voran. Irgendwie hatte ich im Gefühl, was der Grund dafür sein mag – und ich sollte leider nicht enttäuscht werden: nach ca. 1 km Autobahnschleichen konnte ich auf der anderen Fahrbahnseite einen Kleintransporter, einen PKW und dahinter ein Polizeifahrzeug auf dem Standstreifen stehen sehen. Erlaubterweise war am Polizeifahrzeug das Blaulicht angeschaltet – möglicherweise auch deswegen, weil die beiden Fahrzeuge aus dem fahrenden Verkehr angehalten worden sind.
Ich hatte viel Zeit, mir das „Spektakel“ anzuschauen und mir meine Gedanken dazu zu machen, denn immerhin ging es ja auch weiterhin im Schneckentempo voran – und zwar exakt bis zu dem Punkt, an dem ich diese Fahrzeuge passiert hatte – dann floss der Verkehr wieder ganz normal weiter. Abgesehen natürlich von der Gegen-Fahrtrichtung, hier konnte man dann noch den kilometerlangen Stau sehen.
Leute, mal ganz ehrlich: wie #!@Z/|##! muss man eigentlich sein, dass ein Fahrzeug mit Blaulicht auf der Gegenfahrbahn ausreicht, um seine eigene Geschwindigkeit drastisch zu verringern, damit sich und Andere zu gefährden und den Vehrkehrsfluss zu behindern, nur um glotzen zu können?