Daten über VoIP

Früher gabt es "Zweidraht-Leitungen und Daten wurden mit Modems als "Töne" übertragen. Mit der Verbreitung von ISDN konnten Daten digital im B-Kanal mit 64kbit übertragen werden. Durch den Rückbau der klassischen ISDN-Anschlüsse und analogen Leitungen zugunsten von VoIP-Verbindungen stellt sich die Frage, wie Modems und ISDN-Karten weiter funktionieren können. Denn auch eine Fritz!Box kann durchaus intern einen ISDN-Anschluss bereit stellen. Sicher werden die meisten modernen Programme gleich IP über Internet sprechen. Aber so schnell werden Speziallösungen mit Modems oder ISDN-B-Kanal und D-Kanal nicht entfallen. Im Begriff "VoIP" steckt ja das "Voice over IP" drin und nicht "Aync over IP". Insofern ist die Frage berechtigt, wie durch den Wegfall der klassischen Leitung auch Daten übertragen werden können, wenn die Endgeräte nicht selbst native IP sprechen.

Eine Frage des Codec

Auch wenn wir über VoIP sprechen und viele natürlich damit Telefonate assoziieren, so wissen wir doch spätestens durch Skype, dass auch Video über den gleichen Weg übertragen werden kann. Tatsächlich ist VoIP in der Hinsicht offen, dass zwei Partner sich einfach auf Codecs einigen, die beide verstehen. Diese Auswahl gibt es bei Sprache (RTAudio, Silk, G.711, G.722, G.729 u.a.) aber auch bei Video (H.263, H.264, RTVideo, VC1). Hier mal ein Beispiel einiger Codecs, die aber nicht so "bekannt" sind.

Aber auch G.711 ist durchaus für Daten geeignet und selbst Faxübertragungen sind durch G.711 ziemlich problemlos möglich, solange die Laufzeiten der Pakete nicht zu stark beeinträchtigt wird. Gerade Datenprotokolle die auf ein enges Handshake-Verfahren aufbauen, haben sonst Probleme durch die VoIP-Umsetzung. Diese kostet nämlich "Zeit". Mit einer "Sampling Time" von 20ms verliert eine Information beim Wechsel zwischen TK und VoIP mindestens jeweils 20ms. Kommt dann noch eine Paketlaufzeit dazu, dann kann das ein oder andere Protokoll dies nicht mehr ausgleichen. Sieh sehen hier aber auch Codecs, mit dem Suffix "VBD" , oder auch einen Codec "Transparent" und natürlich T.38

Analoge Modems

Auf analogen Leitungen war die maximale Bandbreite der Frequenzen auf auf 4,8kHz o.ä. beschränkt. Teilweise wurden sogar Tiefpässe eingesetzt, um höhere Frequenzen zu blockieren. Während meines Studiums haben meine Professoren noch gemeint, dass mehr als 4800baud nicht möglich wären und das ist so eigentlich auch immer noch nicht falsch. Aber nirgends steht, dass mit jedem Schritt auch immer nur ein Bit übertragen werden kann. Über Phasenmodulation können mit einem Schritt auch mehr Bits parallel übertragen werden. So wurden aus 300Baud, 2400Baud irgendwann 14.400 und letztendlich 56k. Wobei hier die Geschwindigkeit nicht bidirektional zur Verfügung steht.

Der Anschluss analoger Geräte über entsprechende Gateways ist technisch problemlos möglich und solange es sich dabei um "Sprache" handelt, sind die Beschränkungen der Bandbreite und damit des nutzbaren Frequenzbands nicht störend. Ein Telefonat muss ja nur eine gute Sprachverständlichkeit erreichen aber keinen HiFi-Klang.

Wenn aber nun Computer über Modem mit Tönen letztlich Bits übertragen, dann werden die Daten im Modem erst in analoge Signale gewandelt und im Ziel wieder zurück verwandelt. Kommt auf der Übertragungsstecke nun aber ein VoIP-Stück zum Einsatz, dann muss hier aus den analogen Tönen wieder ein Digitalsignal werden und am anderen Ende der VoIP Strecke wieder analog wiedergegeben werden. Es versteht sich von selbst, dann ein 64kbit Codec vielleicht nicht eine 56000bit-Modemstrecke abbilden kann. Wenn der Codec dann aber noch versucht, die Audioinformation durch "Abschneiden" für Menschen irrelevanter Frequenzanteile zu komprimieren, so dass der VoIP-Codec nur noch 13kbit o.ä. benötigt, dann wird es mit den Daten nicht mehr viel.

Hier ist es wichtig, dass die VoIP-Einheit zum einen erkennt, dass es modulierte Daten sind und dann zwischen den beiden VoIP-Endpunkten auch ein Codec bereit steht, mit dem Daten verlustfrei übertragen werden können. Die meisten Firmen nutzen dazu einfach G.711, der Sprach-Codec, der mit 64bit unkomprimiert das Audiosignal abtastet und überträgt. Damit sind meist 14.400 Baud-Verbindungen möglich, was für kleinere Datenmengen ausreichen sollte.

Analoge Fax

Die Übertragung von Faxen ist "Zeitkritisch", d.h. das Timing ist hier auf Latenzen empfindlich und wenn es einfach zulange braucht, bis der Empfänger dem Sender die Daten quittiert hat, dann scheitert die Übertragung. Nützlich ist es hier, möglichst früh aus den Tönen quasi ein Computerfax zu machen.

ISDN D-Kanal Daten

Der ISDN-D-Kanal ist offiziell ein "Signalisierungskanal", über den die Verbindungen der B-Kanäle gesteuert werden. Es ist technisch aber eine permanente Datenverbindung mit 16kbit, die zwischen Endgerät und Vermittlungsstelle permanent besteht und nicht ausgelastet ist. Schön früh wurden daher über den D-Kanal weitere Informationen übertragen. Es soll sogar schon Programme gegeben haben, die über den D-Kanal Daten ausgetauscht haben. Recht schnell haben die Vermittlungsstellen dann diesem Treiben ein Ende gesetzt. Es mag noch Speziallösungen geben aber ich kenne keinen Anwendungsfall, bei dem D-Kanal Daten über VoIP weiter vermittelt werden, abgesehen von dem üblichen Rufaufbau und Abbau-Meldungen.

ISDN B-Kanal Daten - CLEARMODE

Interessanter ist da schon die Frage nach Daten über den D-Kanal. Über das Dienstmerkmal "ISDN 64k data" konnten schon früh Computer eine echte 64kbit Verbindung aufbauen, z.B. Dialup-Router (Novell MPR) , Modems als ISDN-Adapter (z.B. Elsa TLPro).

Bislang hatte ich noch nicht den Bedarf, dass ich eine Datenübertragung per ISDN auf einen VoIP-Kanal umsetzen musste. Im Zeichen von Internet of Things dürften immer mehr Dienste direkt IP sprechen oder auch die M2M-Kommunikation per Mobilfunktechnik hat in vielen Geräten mittlerweile Einzug gehalten. Es gibt aber tatsächlich eine RFC für die Übertragung von 64kbit transparenten Daten

  • RFC4040 RTP Payload Format for a 64 kbit/s Transparent Call

Die Daten müssen dazu mit 8000bit/Sek abgetastet werden und werden vergleichbar zu unkomprimierter Sprache der Codecs PCMA und PMCU übertragen. Allerdings gibt es hier z.B. kein Comfort-Noise oder Silence Detection.

Hier ein Auszug eines Audiocodes Mediant 1000 SYSLOG. Hier finden Sie mitten drin den Text "CLEARMODE"

13:45:11.138 : 10.160.81.22 : NOTICE  : [S=59968611] [SID:727184939] SIP/2.0 200 OK  
Via: SIP/2.0/TCP 10.160.165.26:50791;branch=z9hG4bKaa7d652  
From: ;tag=ff34e34247;epid=4C9F4A327B
To: ;tag=1c1527500817
Call-ID: 9b218ca49c6a47dd834ede5d829dd3ea
CSeq: 3159 OPTIONS
Contact: 
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,REFER,INFO,PRACK,UPDATE
Server: Mediant 1000/v.6.60A.027.014
Content-Type: application/sdp
Content-Length: 793
v=0
o=MxSIP 0 0 IN IP4 0.0.0.0
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 5555 RTP/AVP 8 18 4 96 98
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:4 G723/8000
a=rtpmap:96 CLEARMODE/8000
a=rtpmap:98 telephone-event/8000
a=silenceSupp:off - - - -
a=fmtp:18 annexb=no
a=fmtp:4 annexa=no
a=fmtp:98 0-15,32-36,49
m=audio 5555 RTP/SAVP 8 18 4 96 98
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:4 G723/8000
a=rtpmap:96 CLEARMODE/8000
a=rtpmap:98 telephone-event/8000
a=silenceSupp:off - - - -
a=fmtp:18 annexb=no
a=fmtp:4 annexa=no
a=fmtp:98 0-15,32-36,49
m=image 0 udptl t38
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxFillBitRemoval:1
a=T38FaxMaxBuffer:72

VoIP Native Daten

Nur der Vollständigkeit halber können über VoIP natürlich auch richtig Daten übertragen werden, z.B. Dateitransfer bei Lync, Videos mit Konferenzen et, die schon immer digital vorliegen. Hierbei kommen dann natürlich ebenfalls entsprechenden Protokolle und Codecs zum Einsatz. Es gibt aber keine Konvertierung der Daten zwischen einer Telefonleitung und VoIP. Daher betrachten wir dies hier nicht weiter

Weitere Links