Wie konfiguriert man QoS mit Asterisk und Sipgate?

[wrrdlbrrmpft]

Hallo,

ich habe Asterisk auf meinem DSL-Router laufen und möchte nun mit QoS Folgendes realisieren:
Wenn jemand über VoIP telefoniert, soll der restliche Upstream so viel wie nötig gedrosselt werden.
Es gibt hier doch bestimmt jemanden, der genau sowas realisiert hat oder mir zumindest an Hand eines einfachen Beispiels erklären kann, wie man so etwas aufbaut.

Mit http://www.voip-info.org/wiki-QoS+Linux komme ich jedenfalls nicht zum Ziel.

Mein erster Versuch sieht so aus:

#!/bin/sh

/usr/sbin/tc qdisc add dev ppp0 root handle 1:0 htb default 12
# Hauptklasse
/usr/sbin/tc class add dev ppp0 parent 1:0 classid 1:1 htb rate 125kbit ceil 125kbit
# Klasse für ACK
/usr/sbin/tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 10kbit ceil 125kbit prio 0
# Klasse für VoIP (Für Test erst mal auf 1kbit gedrosselt)
/usr/sbin/tc class add dev ppp0 parent 1:1 classid 1:11 htb rate 1kbit ceil 1kbit prio 1
# Klasse für Rest
/usr/sbin/tc class add dev ppp0 parent 1:1 classid 1:12 htb rate 5kbit ceil 125kbit prio 2

/sbin/iptables -A POSTROUTING -t mangle -o ppp0 -p tcp -m length --length :64 -j MARK --set-mark 10
/sbin/iptables -A POSTROUTING -t mangle -o ppp0 -p udp --dport 5004:5007 -j MARK --set-mark 11

/usr/sbin/tc filter add dev ppp0 parent 1:0 prio 0 protocol ip handle 10 fw flowid 1:10
/usr/sbin/tc filter add dev ppp0 parent 1:0 prio 0 protocol ip handle 11 fw flowid 1:11

So funktioniert es aber nicht. Die VoIP-Pakete landen in der Rest-Klasse mit classid 1:12. Wenn ich die Doku bei Sipgate richtig interpretiere, sollte doch der Port-Bereich 5004:5007 für die Sprachdaten verwendet werden. Stimmt das? Wo könnte sonst noch der Fehler sein?

Viele Grüße!
Benno

 

[otaku42]

Der Bereich, der von Asterisk fuer die Sprachdaten (bei SIP also die RTP-Pakete) verwendet wird, ist in der rtp.conf festgelegt. Wenn die Datei nicht vorhanden ist, werden meines Wissens die Ports 5000 bis 31000 verwendet.

 

[wrrdlbrrmpft]

Danke für den Hinweis. Es lag tatsächlich an den Ports. In rtp.conf ist 10000:20000 eingetragen. Damit funktioniert es offenbar.

Vielen Dank!
Benno

 

[wrrdlbrrmpft]

Achso, falls es noch jemanden interessieren sollte. Mein Skript sieht jetzt für den Anfang so aus:

#!/bin/sh

/usr/sbin/tc qdisc add dev ppp0 root handle 1:0 htb default 12
# Hauptklasse
/usr/sbin/tc class add dev ppp0 parent 1:0 classid 1:1 htb rate 125kbit ceil 125kbit
# Klasse für ACK
/usr/sbin/tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 10kbit ceil 125kbit prio 0
# Klasse für VoIP
/usr/sbin/tc class add dev ppp0 parent 1:1 classid 1:11 htb rate 110kbit ceil 125kbit prio 1
# Klasse für Rest
/usr/sbin/tc class add dev ppp0 parent 1:1 classid 1:12 htb rate 5kbit ceil 125kbit prio 2

/sbin/iptables -A POSTROUTING -t mangle -o ppp0 -p tcp -m length --length :64 -j MARK --set-mark 10
/sbin/iptables -A POSTROUTING -t mangle -o ppp0 -p udp --dport 10000:20000 -j MARK --set-mark 11

/usr/sbin/tc filter add dev ppp0 parent 1:0 prio 0 protocol ip handle 10 fw flowid 1:10
/usr/sbin/tc filter add dev ppp0 parent 1:0 prio 0 protocol ip handle 11 fw flowid 1:11

Die VoIP-Pakete sollten sich damit mindestens 110kBit/s an Bandbreite "greifen" können. Verbesserungsvorschläge sind mir jederzeit willkommen.

Ciao!
Benno

 

[zorg]

noch einfacher gehts mit

iptables -t mangle -A $CHAIN -m owner --cmd-owner asterisk -j MARK --set-mark $X

das matched einfach alle pakete, die der prozess asterisk erzeugt, vorausgesetzt, er laeuft auf dem router.

was in meiner erfahrung auch prima hilft ist das reduzieren der MSS fuer ausgehende TCP-verbindungen. damit sinkt die worst-case wartezeit fuer hoeher priorisierte pakete betraechtlich.

ein max-mtu/mss paket von ~1500byte braucht bei 256kbit upstream immerhin fast 50ms bis es ueber die leitung geht. da hilft auch das umsortieren vor der queue durch QoS nicht viel.

deswegen verringere ich die MSS bei mir auf dem router/asterisk server auf magere 112. dadurch hab ich auch mit gleichzeitig laufendem edonkey und bittorrent keine probleme zu telefonieren.

nachteil ist natuerlich der groessere overhead bei saemtlichen ausgehenden tcp-verbindungen....

vielleicht hilft das ja jemandem...

ciao

martin

 

[wrrdlbrrmpft]

Und wie macht man das mit der MSS? Reicht es, wenn man in /etc/ppp/options einen Eintrag der Form "mtu 120" einfügt?

Ciao!
Benno

 

[zorg]

-p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 112

hab ich bei mir....

martin

 

[wrrdlbrrmpft]

Danke, ich werds ausprobieren!

Benno

 

[Blackvel]

Hmm, VOIP unter der ACK Klasse mit andere Priorität + rate 1kbit ?
Ist nicht wirklich optimal.

Besser VOIP als 1:10 anlegen und rate auf Codec z.B 80kbit anlegen.

In die ACK Klasse gehen meist auch Pakete wie eMule etc.

 

[wrrdlbrrmpft]

Die 1kbit hatte ich ja nur als Test um festzustellen, ob die VoIP-Pakete auch wirklich in der richtigen Klasse landen. Ich habe versucht eure Vorschläge zu berücksichtigen. Mein Test-Skript sieht nun so aus:

#!/bin/sh

/usr/sbin/tc qdisc add dev ppp0 root handle 1:0 htb default 12
# Hauptklasse
/usr/sbin/tc class add dev ppp0 parent 1:0 classid 1:1 htb rate 125kbit ceil 125kbit
# Klasse für VoIP
/usr/sbin/tc class add dev ppp0 parent 1:1 classid 1:11 htb rate 110kbit ceil 125kbit prio 0
# Klasse für ACK
/usr/sbin/tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 10kbit ceil 125kbit prio 1
# Klasse für Rest
/usr/sbin/tc class add dev ppp0 parent 1:1 classid 1:12 htb rate 5kbit ceil 125kbit prio 2

/sbin/iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 112
/sbin/iptables -A POSTROUTING -t mangle -m owner --cmd-owner asterisk -j MARK --set-mark 11
/sbin/iptables -A POSTROUTING -t mangle -o ppp0 -p tcp -m length --length :64 -j MARK --set-mark 10

/usr/sbin/tc filter add dev ppp0 parent 1:0 prio 0 protocol ip handle 11 fw flowid 1:11
/usr/sbin/tc filter add dev ppp0 parent 1:0 prio 0 protocol ip handle 10 fw flowid 1:10

Damit funktioniert das Telefonieren bei sonstigem Upload schon mal besser als ohne Skript.

@Blackvel: Kannst du mir konkret sagen, wo ich sinnvollerweise was ändern sollte?

Ich will möglichst optimale Sprachqualität. Der restliche Datentransfer darf während eines Telefonats ruhig über die Leitung kriechen.

Ciao!
Benno

 

[Blackvel]

Konkreter:

125kbit Bandbreite ? Falls Nur 128kbit, auf 102 setzen (Latentz, Queueing-Problem ADSL-Modem).
Ich würde keine 110kbit fix resevieren, besser 80kbit.
Ich will es eigentlich nicht jetzt so gross erklären, warum jetzt genau
Für 1 User ist das halt in dem Falle die bessere Konfig. Lieber für Normal bzw. Higher-Traffic (z.B Web) mehr Bandbreite reservieren.

Sobald man ceil benutzt, gibt's bandwidth borrowing von Top-Level class 1:0, wird BW also zwischen Child-Queues aufgeteilt.

#!/bin/sh 

/usr/sbin/tc qdisc add dev ppp0 root handle 1:0 htb default 12 
# Hauptklasse 
/usr/sbin/tc class add dev ppp0 parent 1:0 classid 1:1 htb rate 125kbit ceil 125kbit 
# Klasse für VoIP 
/usr/sbin/tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 80bit ceil 125kbit prio 0 
# Klasse für ACK 
/usr/sbin/tc class add dev ppp0 parent 1:1 classid 1:11 htb rate 2kbit ceil 125kbit prio 1 
# Klasse für Standard
/usr/sbin/tc class add dev ppp0 parent 1:1 classid 1:12 htb rate 42kbit ceil 125kbit prio 2 
# Klasse für Low-Priority (P2P, FTP, SMTP, etc.)
/usr/sbin/tc class add dev ppp0 parent 1:1 classid 1:13 htb rate 1kbit ceil 125kbit prio 3

/sbin/iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 112 
/sbin/iptables -A POSTROUTING -t mangle -m owner --cmd-owner asterisk -j MARK --set-mark 10
/sbin/iptables -A POSTROUTING -t mangle -o ppp0 -p tcp -m length --length :64 -j MARK --set-mark 11 

/usr/sbin/tc filter add dev ppp0 parent 1:0 prio 0 protocol ip handle 11 fw flowid 1:11 
/usr/sbin/tc filter add dev ppp0 parent 1:0 prio 0 protocol ip handle 10 fw flowid 1:10

Was ich noch vermisse ist eine tc filter rule, die ACK Packete erkennt und dann ins die ACK-Queue 1:11 steckt. Such mal bei google nach wshaper, Du wirst schon fündig

Was mir noch einfällt, ich arbeite derzeit zwar mehr mit Port-Matching, aber habe ich z.B bei eMule festgestellt, dass manche Port-Rules z.B 5004-5007 bzw. 10000-20000 auch hier für Destination Port zutreffen und damit in der VOIP Queue 1:10 landen, wenn man hier nichts dagegen unternimmt.
Aber auch hier lehn ich mich jetzt nicht zu weit aus dem Fenster und lass Dich mal machen

Gruß und viel Erfolg!

Blackvel

 

[wrrdlbrrmpft]

Was mir noch einfällt, ich arbeite derzeit zwar mehr mit Port-Matching, aber habe ich z.B bei eMule festgestellt, dass manche Port-Rules z.B 5004-5007 bzw. 10000-20000 auch hier für Destination Port zutreffen und damit in der VOIP Queue 1:10 landen, wenn man hier nichts dagegen unternimmt.

Das sollte dank zorgs Hilfe doch schon gelöst sein. Hast du hier was überlesen, oder versteh ich noch weniger von der Materie, als ich dachte? Werde deine Änderungen auf jeden Fall mal testen.

Erstmal vielen Dank!
Benno

 

[Blackvel]

Etwas überlesen, einfach etwas mehr skeptisch

Wenn VOIP als 2. Queue ist, dann hättest ein grosses Problem jedenfalls.

Am Besten Du testet es mal aus.

 

[Ryven]

Ich würde zusätzlich auf Kernel 2.6 mit den Echtzeitpatchen umsteigen, Damit kannst du die Druchlaufzeit im router nochmal etwas verbessern.
Was viel bringt wenn mans schaft das routingverhalten von Storage and forward auf Put-throw umstellen kann, Ist aber auch ein Kriterium wieviel defekte Packete im Intranet produziert werden.

 

[Fux]

Blöde Frage: Was ist eigentlich mit großen Downloads ? Beeinträchtigen die nicht auch die VoIP-Übertragung, wenn man z.B. von einem gut angebundenen FTP-Server etwas saugt und gleichzeitig telefoniert ?

 

[otaku42]

Das kommt letzlich auf die verfuegbare Bandbreite der eigenen Anbindung an. Aber prinzipiell: ja, das kann Probleme geben. Deswegen fluchen die Leute, die P2P und VoIP parallel und ohne QoS benutzen wollen, ja auch oft ueber die Aussetzer und "bescheidene Sprachqualitaet"

 

[bassmaster187]

@Blackvel:
kannst du mal dein script posten?

 

[lirv]

/sbin/iptables -A POSTROUTING -t mangle -m owner --cmd-owner asterisk -j MARK --set-mark 11

Funktioniert dieser Code auch noch im aktuellen Kernel? Seit der Version 2.6.14 hab ich Probleme damit... gibt es eine Alternative?