Übungsaufgaben zu VoIP, Latenz und Quality of Service

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „VoIP, Latenz und Quality of
Service“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/voip-qos
- https://oer-informatik.de/uebertragungsdauer-bandbreite
- https://oer-informatik.de/vlan
- Stilbeispiel: https://oer-informatik.de/voip-qos-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- VoIP
- Cloud-Telefonanlage
- SIP
- Codec
- Bandbreite
- STUN
- Quality of Service
- Latenz
- Jitter
- Videokonferenz

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

Funktion 3 kann mit Begründung auch dem Markieren zugeordnet werden. (3 Punkte; je zwei richtige Zuordnungen 1 Punkt)

Eine Warteschlange mit strikter Priorität wird immer vollständig geleert, bevor eine andere an die Reihe kommt. Sprachverkehr hat eine kleine, gleichmäßige Datenrate und lässt den anderen Warteschlangen genug Zeit. Landet dort dagegen umfangreicher Verkehr (z. B. ein Backup), kommen die Warteschlangen 0–6 kaum noch zum Zug, und der übrige Verkehr stockt („Verhungern“). (2 Punkte)

Geg.: r_{Codec} = 64\,\mathrm{kbit/s}, Paketabstand 20\,\mathrm{ms}, Header 58\,\mathrm{Byte}, Reserve 2\,\mathrm{Mbit/s}

Ges.: Datenrate je Gespräch und Richtung r, Anzahl Gespräche n

Pakete je Sekunde: \frac{1\,\mathrm{s}}{20\,\mathrm{ms}} = 50; Sprachdaten je Paket: \frac{64.000\,\mathrm{bit/s}}{50} = 1.280\,\mathrm{bit} = 160\,\mathrm{Byte} (1 Punkt)

r = (160 + 58)\,\mathrm{Byte} \cdot 8\,\tfrac{\mathrm{bit}}{\mathrm{Byte}} \cdot 50\,\tfrac{1}{\mathrm{s}} = 87.200\,\mathrm{bit/s} = 87{,}2\,\mathrm{kbit/s}

(1 Punkt)

n = \frac{2.000\,\mathrm{kbit/s}}{87{,}2\,\mathrm{kbit/s}} \approx 22{,}9 \Rightarrow \underline{\underline{22\ \text{Gespräche}}}

(1 Punkt, abgerundet)

Die Spitze von 12 Gesprächen braucht 12 \cdot 87{,}2\,\mathrm{kbit/s} \approx 1{,}05\,\mathrm{Mbit/s} und ist mit Luft für weiteres Wachstum abgedeckt. (1 Punkt)

• account.1.expires → 600: Mit 60.000 s erneuert das Telefon seine Anmeldung nur etwa alle 16,7 Stunden. Startet die Anlage neu oder ändert sich die Adresse des Telefons, bleibt die Theke unter Umständen stundenlang unerreichbar.
• rtp.port_min / rtp.port_max → 11000 / 11999: Das Telefon erwartet Sprachpakete auf Ports, die die ACL zwischen den VLANs verwirft. Gespräche kommen zustande, sind aber stumm (oder nur in eine Richtung hörbar).
• network.vlan.voice_id → 42: Das Telefon versieht seine Frames mit der falschen VLAN-ID. Der Switch lässt sie am Port nicht zu oder ordnet sie einem fremden Netz zu; das Telefon erhält keine passende Adresse und kann sich nicht anmelden.
• network.qos.dscp_rtp → 46: Ohne Markierung gelten die Sprachpakete beim Routing zwischen den VLANs und am Internetrouter als normaler Verkehr. Bei hoher Last werden sie nicht bevorzugt, es kommt zu Aussetzern.

Je Abweichung 1 Punkt für den richtigen Wert und 1 Punkt für die Folge.

• STUN mit Portweiterleitung: Das Softphone erfährt die öffentliche Adresse des heimischen Routers und gibt sie im SDP an; bei manchen Heimroutern (z. B. mit wechselnden Ports je Ziel) klappt das trotzdem nicht. Die Telefonanlage ist direkt aus dem Internet erreichbar, ein beliebtes Ziel für Passwortangriffe und Gebührenbetrug. Wenig Aufwand, aber das höchste Risiko. (1,5 Punkte)
• Session Border Controller: Er ist für diesen Fall gebaut: Er setzt Adressen in SIP und SDP um, leitet RTP weiter, verschlüsselt und filtert Angriffe; die Anlage bleibt intern. Zuverlässig und sicher, aber zusätzliches Gerät, Lizenzen und Einrichtung. (1,5 Punkte)
• VPN: Im Tunnel hat das Notebook eine interne Adresse, zwischen Softphone und Anlage gibt es kein NAT; STUN bleibt aus. Sicher und ohne neue Technik, sofern das VPN schon existiert. Nachteile: Telefonie geht nur bei aktivem VPN, der Tunnel erhöht Overhead und Latenz. (1,5 Punkte)

Empfehlung (1,5 Punkte, andere begründete Entscheidungen werden anerkannt): Für eine einzelne Person mit vorhandenem VPN ist Variante 3 die einfachste sichere Lösung. Arbeiten künftig viele Beschäftigte mobil, lohnt sich der SBC. Variante 1 scheidet wegen des Risikos aus.

Geg.: Kosten laut Tabelle, 24 Nebenstellen, 60 Monate, Verfügbarkeit Anschluss 99,5 %, Plattform 99,95 %

Ges.: Kosten über fünf Jahre K_{tk\text{-}sen} und K_{Cloud}, Ausfallzeit je Jahr t_{Ausfall}

K_{tk\text{-}sen} = 2.400\,€ + 100\,€ \cdot 60 = \underline{8.400\,€} \qquad K_{Cloud} = 400\,€ + 24 \cdot 7{,}90\,€ \cdot 60 = \underline{11.776\,€}

Der Weiterbetrieb ist über fünf Jahre rund 3.400 € günstiger. (3 Punkte)

Bei der Cloud-Lösung müssen Anschluss und Plattform gleichzeitig verfügbar sein:

V = 0{,}995 \cdot 0{,}9995 \approx 0{,}99450 \qquad t_{Ausfall} = (1 - V) \cdot 8.760\,\mathrm{h} \approx \underline{48\,\mathrm{h}\ \text{je Jahr}}

(2 Punkte; wer nur den Anschluss betrachtet, kommt auf 43,8 h, 1 Punkt)

Empfehlung (2 Punkte, andere begründete Entscheidungen werden anerkannt): Der Weiterbetrieb ist günstiger, und die Theke bleibt bei einem Internetausfall intern erreichbar. Das Homeoffice-Argument lässt sich auch mit der vorhandenen Anlage lösen (VPN oder SBC, siehe Teilaufgabe d). Deshalb sollte tk-sen weiterbetrieben werden. Für die Cloud spräche, wenn ein Großteil der Beschäftigten dauerhaft verteilt arbeitet oder niemand die Anlage betreuen kann.

(3 Punkte: 2 Punkte für die vier Summen, 1 Punkt für die Anteile)

Ableitung (2 Punkte): Innerhalb von fünf Minuten sinkt der Upload auf weniger als ein Fünfzigstel. Fast die gesamte Einsparung stammt aus dem Video, das in Stufen kleiner und ruckeliger wird und schließlich wegfällt; die Tonrate bleibt bis 10:07 gleich und sinkt danach nur um 8 kbit/s. Die Software regelt also adaptiv über den großen Videostrom und hält den kleinen Tonstrom stabil, sodass die Besprechung hörbar bleibt.

Richtwerte: Latenz je Richtung bis 150 ms gut, bis 400 ms noch akzeptabel; Jitter unter 30 ms; Paketverlust unter 1 %.

• Büro und Homeoffice abends: alle drei Werte klar im guten Bereich. (1 Punkt)
• Homeoffice mit Backup: Die Latenz ist mit 310 ms nur noch eingeschränkt akzeptabel, Jitter (62 ms) und Paketverlust (3,8 %) sind störend. (1 Punkt)

Wirkungskette (4 Punkte):

1. Der DSL-Anschluss hat nur 10 Mbit/s im Upload. Backup (rund 8 Mbit/s) und Konferenz (rund 1,8 Mbit/s) brauchen zusammen mehr, als nach Abzug von Overhead und weiterem Verkehr verfügbar ist.
2. Der Router kann nicht schneller senden, als die Leitung erlaubt; die überzähligen Pakete warten in seinem Sendepuffer. Die Pakete der Konferenz stehen dort hinter vielen Backup-Paketen an: Die Latenz steigt.
3. Die Füllung des Puffers schwankt mit dem Backup-Verkehr, also warten die Pakete unterschiedlich lange: Jitter.
4. Ist der Puffer voll, verwirft der Router neue Pakete: Paketverlust. Kommen Pakete zu spät für den Jitter-Puffer des Empfängers, zählen sie ebenfalls als verloren.

Geg.: r_{Leitung} = 10\,\mathrm{Mbit/s}, Nutzung 90 %, Konferenz 1{,}8\,\mathrm{Mbit/s} + 0{,}04\,\mathrm{Mbit/s}, Overhead 20 %, Reserve 1\,\mathrm{Mbit/s}, Backup 40\,\mathrm{GB}

Ges.: höchste Datenrate für das Backup r_{Backup}, Dauer des Backups t_{neu} und t_{alt}

r_{Konferenz} = (1{,}8 + 0{,}04)\,\mathrm{Mbit/s} \cdot 1{,}2 = 2{,}208\,\mathrm{Mbit/s}

r_{Backup} = 0{,}9 \cdot 10\,\mathrm{Mbit/s} - 2{,}208\,\mathrm{Mbit/s} - 1\,\mathrm{Mbit/s} = \underline{\underline{5{,}792\,\mathrm{Mbit/s}}}

(2 Punkte)

t_{neu} = \frac{40 \cdot 10^9 \cdot 8\,\mathrm{bit}}{5{,}792 \cdot 10^6\,\mathrm{bit/s}} \approx 55.249\,\mathrm{s} \approx 15{,}3\,\mathrm{h} \qquad t_{alt} = \frac{320 \cdot 10^9\,\mathrm{bit}}{8 \cdot 10^6\,\mathrm{bit/s}} = 40.000\,\mathrm{s} \approx 11{,}1\,\mathrm{h}

(2 Punkte)

Beurteilung (1 Punkt): Die feste Begrenzung schützt die Besprechung, verlängert das Backup aber um gut vier Stunden, auch dann, wenn gerade keine Besprechung läuft. Besser ist, das Backup in die Nacht zu legen oder die Begrenzung nur zu den Arbeitszeiten gelten zu lassen, ggf. zusammen mit QoS am Router.

1. Wirksam. Der Engpass ist der Upload des eigenen Anschlusses, und genau dort steuert der Router, wer zuerst senden darf. Formt er knapp unter der Leitungsrate, staut sich der Verkehr in seiner eigenen Warteschlange statt im Modem; Konferenzpakete überholen dort die Backup-Pakete. Latenz, Jitter und Verlust der Konferenz sinken, das Backup wird nur etwas langsamer. Zusätzliche Bandbreite entsteht dabei nicht. (2 Punkte)
2. Allein wirkungslos. Eine DSCP-Markierung ist nur ein Kennzeichen; sie nützt nur, wenn ein Gerät am Engpass sie auswertet. Der Engpass liegt im eigenen Router, und der behandelt die Pakete ohne QoS-Regel trotzdem gleich. Im Netz des Anbieters und im Internet werden fremde Markierungen meist ignoriert oder zurückgesetzt. In Verbindung mit Maßnahme 1 kann die Markierung dem Router die Erkennung erleichtern. (2 Punkte)
3. Wirkungslos. Gestört wird das Senden von Bild und Ton, also der Upload, und der bleibt bei 10 Mbit/s. Mehr Download ändert an der Warteschlange im Upload nichts. (2 Punkte)

Auswertung (2 Punkte): Der Anruf wird mit G.729 aufgebaut, obwohl die Gegenseite auch G.711 a-law (PCMA) angeboten hat, weil der Adapter G.729 bevorzugt; dazu ist die Sprachpausenerkennung (VAD) aktiv. Drei Sekunden später erkennt der Adapter den Antwortton eines Faxgeräts (CED) und bittet per re-INVITE darum, die Medien auf T.38 umzustellen. Die Cloud-Telefonanlage lehnt mit 488 Not Acceptable Here ab, sie akzeptiert diese Medienbeschreibung nicht. Der Adapter bleibt deshalb beim Audiostrom.

Zusammenhang (2 Punkte): Ohne T.38 werden die Faxsignale als Ton durch den Codec G.729 geschickt. G.729 überträgt keine Abtastwerte, sondern Kennwerte eines Stimm-Modells; die Faxmodulation lebt aber von exakter Phase und Amplitude und lässt sich so nicht nachbilden. Die VAD wertet gleichförmige Abschnitte als Stille und überträgt sie nicht. Das empfangende Faxgerät kann die Antworten der Gegenstelle deshalb nicht dekodieren, und das T.30-Protokoll beendet die Verbindung.

Änderungen (zwei davon, je 1 Punkt):

• T.38 bei der Cloud-Telefonanlage freischalten lassen oder zu einem Anbieter mit T.38 wechseln.
• Am Faxanschluss des Adapters nur G.711 a-law (PCMA) zulassen und VAD abschalten.
• Das Faxgerät durch einen Fax-zu-E-Mail-Dienst ersetzen, der die Verträge als PDF zustellt.

Ausbreitung hin und zurück: 2 \cdot 300\,\mathrm{km} \cdot 5\,\tfrac{\mathrm{µs}}{\mathrm{km}} = 3.000\,\mathrm{µs} = 3\,\mathrm{ms}. Bei einer Umlaufzeit von rund 27,2 ms sind das nur etwa 11 %; rund 24 ms entstehen anders. (2 Punkte)

Der größte Teil entsteht zwischen Station 4 und 5 am Übergang in das Netz des Cloud-Anbieters (rund 16 ms), der zweitgrößte im Zugangsnetz des Kabelanschlusses (1 → 2). (2 Punkte)

Geg.: n = 480 Anfragen, RTT = 27\,\mathrm{ms}, je Antwort 3\,\mathrm{KiB}, r_1 = 1\,\mathrm{Gbit/s}, r_2 = 10\,\mathrm{Gbit/s}

Ges.: Wartezeit t_{Warten}, Übertragungsdauer t_1 und t_2, Ladezeit mit Sammelabrufen t

t_{Warten} = 480 \cdot 27\,\mathrm{ms} = \underline{12{,}96\,\mathrm{s}}

(1 Punkt)

D = 480 \cdot 3 \cdot 1.024 \cdot 8\,\mathrm{bit} = 11.796.480\,\mathrm{bit}

t_1 = \frac{11.796.480\,\mathrm{bit}}{10^9\,\mathrm{bit/s}} \approx \underline{0{,}0118\,\mathrm{s}} \qquad t_2 = \frac{11.796.480\,\mathrm{bit}}{10^{10}\,\mathrm{bit/s}} \approx \underline{0{,}0012\,\mathrm{s}}

(2 Punkte)

Gesamt heute ≈ 12,97 s, mit schnellerem Anschluss ≈ 12,96 s: Ersparnis rund 0,01 s, also unter 0,1 %. (1 Punkt)

Mit Sammelabrufen zu je 100 Meldungen: \lceil 480 / 100 \rceil = 5 Anfragen.

t = 5 \cdot 27\,\mathrm{ms} + 0{,}0118\,\mathrm{s} \approx \underline{\underline{0{,}147\,\mathrm{s}}}

(1 Punkt)

Bewertung (1 Punkt): Die Aussage ist falsch. Die Ladezeit besteht zu über 99 % aus Wartezeit; nur weniger Anfragen bringen eine spürbare Verbesserung (Faktor rund 88), ein schnellerer Anschluss praktisch keine.