Unsere Arbeit richtet sich somit in erster Linie an Verbindungen, deren physikalische Bandbreite zwischen 9,6 (einfache Modemverbindung) und 64 kbit/s (ein ISDN-B-Kanal) liegt. Die Überlegungen behalten auch bei höheren Bandbreiten ihre Richtigkeit.
Üblicherweise besteht der Anspruch, Konferenzen mit einer Qualität zu übertragen, die wenigstens der einer Telefonverbindung entspricht. Im INTERNET werden deshalb solche Konferenzen meistens als µ-law komprimierter PCM [itu9303:G.711] Datenstrom übertragen. Die Abtastrate beträgt hierbei 8 kHz, mit einer Auflösung von 13 Bits, die durch die µ-law Kompression auf 8 Bits komprimiert werden. Dies entspricht einem Datenvolumen B von
B | = | 8000 * 8 |
| = | 64 |
Zu dieser Datenmenge kommen noch diverse Header und Trailer der benutzten Protokolle im INTERNET hinzu. Dies sind:
Weiterhin werden meistens 320 Samples der PCM-Daten in einem RTP Paket versendet, was 20 ms Audio-Daten entspricht. Rechnet man die Protokoll-Header nun noch zu den eigentlichen Audio-Daten hinzu, ergibt sich die benötigte Bandbreite B zu:
B | = | (320 + 12 + 8 + 20) / 40 |
| = | 9000 | |
| = | 72 |
Vergleicht man diese benötigte Bandbreite mit der zur Verfügung stehenden, so fällt sehr schnell auf, daß eine Modemverbindung oder ein einzelner ISDN-B-Kanal hierfür nicht ausreicht. Die Folge wären massive Verluste von Paketen:
L64 | = | (72 - 64 ) / 72 |
| = | 11% | |
| L28,8 | = | (72 - 28,8 ) / 72 |
| = | 60% |
Derartig hohe Verlustzahlen sind unakzeptabel, zumal noch ein weiterer Overhead durch die verwendetet Übertragungstechnik selber dazu kommt. Die zu erwartenden Verlustzahlen erhöhen sich somit noch einmal. Desweiteren kommt zu dem reinen Datenstrom durch RTP noch die durch RTCP (Realtime Transport Control Protocol) erzeugte Datenmenge, die abhängig von der Anzahl der Teilnehmer an der Konferenz ist. Unabhängig davon kann es bei einer Konferenz durchaus passieren, daß zeitweise mehr als ein Sender aktiv ist (z.B. im Falle einer Unterbrechung eines Sprechers).
Der erste Punkt hat den Vorteil, daß direkt beim Sender, also an der Stelle, an der die Daten generiert werden, die Konvertierung ansetzt. Jedoch kann es auf der anderen Seite nicht vernünftig sein, daß aufgrund eines Einzelnen oder weniger die Qualität für alle anderen Teilnehmer der Konferenz abnimmt. Der zweite Ansatz scheint daher der vernünftigere zu sein, da hier nur diejenigen, die über eine schlechte Anbindung zum INTERNET haben mit der schlechteren Qualität auskommen müssen. Nachteilig ist jedoch, daß ein derartiges Komprimierungsverfahren dann für jeden slow-speed-link erneut durchgeführt werden muß.
Nehmen wir nun an, daß dieser Mixer das Format nach GSM [etsi:GSM] wandelt. Somit entstehen für 320 Bytes PCM µ-law Daten 66 Bytes GSM kodierte Daten. Betrachtet man nun die Menge an Bytes, die für die verschiedenen Protokoll-Header benötigt werden (20 + 8 + 12 = 40 Bytes), so fällt auf, daß das fast genau so viele sind, wie an Nutzdaten zu übertragen sind.
Es stellt sich somit die Frage, ob es nicht möglich ist, diesen Overhead drastisch zu vermindern. Einen ähnlichen Ansatz gibt es bereits für Komprimierung der IP/TCP Header [rfc1144]. In diesem Bericht wurden die einzelnen Felder der beiden Protokoll-Header während einer Verbindung untersucht. Dabei stellte sich heraus, daß sich ein großer Teil der Felder über die Lebensdauer der Verbindung nicht ändern. Die restlichen Felder ändern sich zwar, jedoch immer in der gleichen Art und Weise. So wird beispielsweise die Sequenznummer in einem IP-Protokoll-Kopf meistens um eins erhöht. Es ist somit möglich, anstelle der Protokollköpfe nur Änderungen zu übertragen. Da die Änderungen in vielen Fällen vorhergesagt werden können, müssen noch nicht einmal die Änderungen, sondern nur Abweichungen von den Vorhersagen übermittelt werden.
Zusammenfassend ergab sich, daß anstelle der IP/TCP-Protokollköpfe mit (20 + 20) Bytes im Durchschnitt nur 2 Bytes übertragen werden mußten! Es galt somit zu untersuchen, inwieweit etwas ähnliches auch bei der Kombination IP/UDP/RTP möglich ist.
Glücklicherweise wurde uns diese Arbeit bereits durch Stephen Casner und Van Jacobson (der auch die IP/TCP Komprimierung entwickelte) abgenommen. Sie verfaßten bereits einen Internet Draft, in dem exakt dieses Problem beschrieben und eine Lösung gefunden wurde [Casner9611:Compressing]. Das dort entwickelte Verfahren war in der Lage, den Overhead von 40 Bytes (20 + 8 + 12) auf ebenfalls nur 2 Bytes im Durchschnitt zu komprimieren.