Hallo,
ich würde gerne einen letzten Versuch wagen, mit DSL-Light einigermaßen zuverlässig VoIP nutzen zu können. Hier im Dorf wird in absehbarer Zeit nichts anders verfügbar sein und wenn das mit der Priorisierung nichts wird, dann bleibt nur der Umstieg auf ISDN.
Ich habe für den Zweck für 10 EUR eine Fritz!Box SL beschafft, die mit OpenWRT laufen müsste. Ziel der Aktion: OpenWRT auf die Schachtel und dann ein tc/iptables Script drauf, welches VoIP via HFSC priorisiert. Das ganze vor die Fritz!Box Fon. Direkt auf der Fritz!Box Fon ist mir zu frickelig. Ich will die ganzen Binärbrocken jetzt aus dem Routing raushaben und alles Open Source haben.
Ich habe ein Script, basierend auf dem schonmal hier diskutierten SipShaper, unten angehängt. Wenn ich HFSC richtig verstanden habe, dann teilt mein Script die verfügbaren 64kbit in einmal 4kbit und einmal 60kbit auf. Wenn das zuverlässig geht und ich ggf. noch den Sprachcodec umstelle, dann sollte bei 60kbit schon ein Gespräch in sauberer Qualität gehen.
Die wichtigste Frage: Was passiert, wenn garkein VoIP genutzt wird? Wird dann der "reguläre Traffic" ständig auf 4kbit reduziert?
Sonst irgendwelche Kommentare zum Script?
ich würde gerne einen letzten Versuch wagen, mit DSL-Light einigermaßen zuverlässig VoIP nutzen zu können. Hier im Dorf wird in absehbarer Zeit nichts anders verfügbar sein und wenn das mit der Priorisierung nichts wird, dann bleibt nur der Umstieg auf ISDN.
Ich habe für den Zweck für 10 EUR eine Fritz!Box SL beschafft, die mit OpenWRT laufen müsste. Ziel der Aktion: OpenWRT auf die Schachtel und dann ein tc/iptables Script drauf, welches VoIP via HFSC priorisiert. Das ganze vor die Fritz!Box Fon. Direkt auf der Fritz!Box Fon ist mir zu frickelig. Ich will die ganzen Binärbrocken jetzt aus dem Routing raushaben und alles Open Source haben.
Ich habe ein Script, basierend auf dem schonmal hier diskutierten SipShaper, unten angehängt. Wenn ich HFSC richtig verstanden habe, dann teilt mein Script die verfügbaren 64kbit in einmal 4kbit und einmal 60kbit auf. Wenn das zuverlässig geht und ich ggf. noch den Sprachcodec umstelle, dann sollte bei 60kbit schon ein Gespräch in sauberer Qualität gehen.
Die wichtigste Frage: Was passiert, wenn garkein VoIP genutzt wird? Wird dann der "reguläre Traffic" ständig auf 4kbit reduziert?
Sonst irgendwelche Kommentare zum Script?
Code:
#!/bin/sh
#
# Based on SipShaper v0.01beta Written by Udo Schacht-Wiegand
# http://www.ip-phone-forum.de/showthread.php?t=72590
# Set your outgoing interface and upload rate (in kbit/s) here
DEV=ppp0
RATEUP=64
# Reset everything to a known state (cleared)
tc qdisc del dev $DEV root 2> /dev/null > /dev/null
# Flush and delete tables
iptables -t mangle --delete POSTROUTING -o $DEV -j SIPSHAPER 2> /dev/null > /dev/null
iptables -t mangle --flush SIPSHAPER 2> /dev/null > /dev/null
iptables -t mangle --delete-chain SIPSHAPER 2> /dev/null > /dev/null
# add HFSC root qdisc
tc qdisc add dev $DEV root handle 1: hfsc default 10
# add main rate limit class
tc class add dev $DEV parent 1: classid 1:1 hfsc sc rate ${RATEUP}kbit ul rate ${RATEUP}kbit
# keep it simple: two classes only
tc class add dev $DEV parent 1:1 classid 1:10 hfsc sc umax 1500b dmax 53ms rate 4kbit ul rate ${RATEUP}kbit
tc class add dev $DEV parent 1:1 classid 1:11 hfsc sc umax 1500b dmax 30ms rate 60kbit ul rate ${RATEUP}kbit
# add SIPSHAPER chain to the mangle table in iptables
iptables -t mangle --new-chain SIPSHAPER
iptables -t mangle --insert POSTROUTING -o $DEV -j SIPSHAPER
# Filter for voip packets
tc filter add dev $DEV parent 1: prio 1 protocol ip handle 1 fw flowid 1:11
iptables -t mangle -A SIPSHAPER -p udp --sport 5060 -j MARK --set-mark 1 # SIP High
iptables -t mangle -A SIPSHAPER -p udp --dport 5060 -j MARK --set-mark 1 # SIP High
iptables -t mangle -A SIPSHAPER -p udp --sport 4569 -j MARK --set-mark 1 # IAX High
iptables -t mangle -A SIPSHAPER -p udp --dport 4569 -j MARK --set-mark 1 # ""
iptables -t mangle -A SIPSHAPER -p udp --sport 10000:11000 -j MARK --set-mark 1 # RTP High
iptables -t mangle -A SIPSHAPER -p udp --dport 10000:11000 -j MARK --set-mark 1 # ""
so zu priorisieren das nebenbei wenn auch langsamer noch gesurft werden kann und sich dieses surfen nicht auf die Sprachqualität auswirkt. Intermediate Queueing Device habe ich damals auch ausprobiert, hat mich meinem Ziel jedoch nicht näher gebracht. Ich habe mein Vorhaben nach sehr viel lesen und ausprobieren mit funktioniert bei Resourcenknappheit nicht abgehakt. Da wir jetzt 2009 schreiben und sich bezüglich QoS so einiges getan haben wird will ich dich natürlich von nichts abhalten.