Hallo, um eine möglichst störungsfreie VoIP-Kommunikation zu ermöglichen, habe ich an mein Device ppp0 (1 Mbit SDSL) einen Traffic-Shaper gehängt. Dieser verwendet (erstmal) zwei Klassen: eine für SIP und RTP (markiert durch iptables), die andere für den Rest.
Weil mir mal jemand gesagt hat, das sei besser für VoIP, habe ich eine HFSC-qdisc verwendet. Frage 1: Ist das sinnvoll? Wo genau liegen die Unterschiede zu HTB (ich finde über HFSC relativ wenig im Netz)? Wäre dort an »oberster Stelle« vielleicht auch eine PRIO-Klasse angebracht; schließlich soll ja eigentlich der gesamte VoIP-Traffic durch? Diese qdisc wirkt sich ja nur auf den ausgehenden Datenverkehr aus. Um eingehende Übertragungen etwas zu zügeln, gibt es ja eine ingress-qdisc, die beispielsweise ab einer bestimmten Rate beginnt, (schon angekommene) Pakete zu verwerfen, um die Gegenstelle zu langsamerer Übertragung zu bewegen und somit die Queue des ISP leer zu halten. Frage 2: Funktioniert das auch denn auch mit eingehenden UDP-Strömen? Es findet nämlich ziemlich viel Kommunikation über ein UDP-OpenVPN statt, die u. U. die RTP-Pakete stört. Angenommen, ich richte also eine solche ingress-qdisc ein, dann möchte ich ja eigentlich nur Nicht-VoIP-Pakete verwerfen, und zwar genauer gesagt immer nur soviel, daß genug Luft für RTP bleibt. Und gleich den sonstigen Download auf 180 kbit zu beschränken, nur weil es bei Lastspitzen *theoretisch* mal vorkommen kann, daß 800 kbit für eingehenden VoIP-Verkehr benötigt werden, wäre auch irgendwie Quatsch. Meine Idee: Ein Skript, das regelmäßig (oder noch besser von asterisk getriggert) die Downloadrate für Nicht-VoIP-Verkehr abhängig von der gerade genutzten VoIP-Uploadrate (die sich ja einfach aus dem Durchfluß durch die VoIP-qdisc ermitteln läßt) hoch- und runterregelt. Drum Frage 3: Geht das? Gibt's das vielleicht schon? Wie geht's richtig/besser? Mit lieben Grüßen Daniel