1
PFSense: trotz QoS-Klasse keine vollständige Priorisierung der VOIP-Traffic
Hallo,
Ich habe auf PfSense 2.3 drei QoC Klassen eingerichtet, die laut "Queues" tatsächlich greifen. Wenn ich telefonieren erhöht sich die Menge an Traffic in der Klasse VoIP.
Es kommt dabei aber bei überbuchten Leitung zu gedroppten Paketen und in 50% der Fälle zu abgewiesenen VoIP Anrufe.
Ich wollte die Klasse VoIP so einstellen, dass 250Kbits für zwei gleichzeitige Gespräche auf jeden Fall zur Verfügung stehen.
Ich habe schon alles mögliche ausprobiert und die sinnvollsten Forentipps übernommen. "States" wurden bei den Änderung stets zurückgesetzt.
Ich finde einfach keinen Grund warum es nicht funktionieren sollte.
Hat jemand einen Vorschlag?
(stehe offensichtlich auf der Leitung.)
Die Geschwindigkeiten der DSL-Line laut SFR-Modem:
Max: Upstream rate = 953 Kbps, Downstream rate = 8988 Kbps
Anbei sind die Einstellungen für DSL (WAN1)
Und hier für LAN:
So sieht es im Queues aus:
So wurde die Traffic zu dem VoIP-Fritzbox priorisiert:
Vielen Dank.
I.
Ich habe auf PfSense 2.3 drei QoC Klassen eingerichtet, die laut "Queues" tatsächlich greifen. Wenn ich telefonieren erhöht sich die Menge an Traffic in der Klasse VoIP.
Es kommt dabei aber bei überbuchten Leitung zu gedroppten Paketen und in 50% der Fälle zu abgewiesenen VoIP Anrufe.
Ich wollte die Klasse VoIP so einstellen, dass 250Kbits für zwei gleichzeitige Gespräche auf jeden Fall zur Verfügung stehen.
Ich habe schon alles mögliche ausprobiert und die sinnvollsten Forentipps übernommen. "States" wurden bei den Änderung stets zurückgesetzt.
Ich finde einfach keinen Grund warum es nicht funktionieren sollte.
Hat jemand einen Vorschlag?
(stehe offensichtlich auf der Leitung.)
Die Geschwindigkeiten der DSL-Line laut SFR-Modem:
Max: Upstream rate = 953 Kbps, Downstream rate = 8988 Kbps
Anbei sind die Einstellungen für DSL (WAN1)
Und hier für LAN:
So sieht es im Queues aus:
So wurde die Traffic zu dem VoIP-Fritzbox priorisiert:
Vielen Dank.
I.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 316358
Url: https://administrator.de/forum/pfsense-trotz-qos-klasse-keine-vollstaendige-priorisierung-der-voip-traffic-316358.html
Ausgedruckt am: 21.04.2025 um 11:04 Uhr
1 Kommentar
Nutzt du als Voice Provider auch den Provider der dein Internet bedient oder einen externen ?
Grund der Frage ist die weitere Priorisierung im Providernetz.
Alle lokale Priorisierung nützt dir nichts wenn du in Richtung Provider gehst und der Voice Dienstleister ist ein anderer Anbieter als der Internet Provider, denn der ignoriert schlicht und einfach ab Übergabepunkt die Priorisierung bzw. QoS Einstellung.
Anders sieht das natürlich aus wenn der Internet Dienstleister auch der Voice Dienstleister ist. Dan besteht der Engpass am WAN Port natürlich nicht und man sollte sich fragen woher dann die Aussetzer kommen.
Die von dir geschilderte Tatsache das auch Calls abgewisen werden ist bedenklich, denn das ist SIP. Das SIP Protokoll nutzt üblicherweise TCP als Transportprotokoll, hat also quasi einen eingebaute Sicherung im Transport.
Das solche Pakete verloren gehen ist schon schwerwiegend, denn die Endgeräte sollten über die TCP Sicherungsschicht dafür sorgen das das nicht passiert bzw. soviel Retransmissions kommen bis die Session etabliert ist. Auch auf hoch belasteten Links.
Das würde im Umkehrschluss bedeuten das dort erhebliche Ausfälle in der Leitungsverfügbarkeit sind die den Sessiontimer in den Timeout zwingen. Sowas liegt im deutlichen 2stelligen Sekundenbereich.
Eigentlich fast unmöglich es sei denn auf deiner Leitung wird permanent Video gesehen oder sowas und die Leitung dauerhaft überbucht.
Grund der Frage ist die weitere Priorisierung im Providernetz.
Alle lokale Priorisierung nützt dir nichts wenn du in Richtung Provider gehst und der Voice Dienstleister ist ein anderer Anbieter als der Internet Provider, denn der ignoriert schlicht und einfach ab Übergabepunkt die Priorisierung bzw. QoS Einstellung.
Anders sieht das natürlich aus wenn der Internet Dienstleister auch der Voice Dienstleister ist. Dan besteht der Engpass am WAN Port natürlich nicht und man sollte sich fragen woher dann die Aussetzer kommen.
Die von dir geschilderte Tatsache das auch Calls abgewisen werden ist bedenklich, denn das ist SIP. Das SIP Protokoll nutzt üblicherweise TCP als Transportprotokoll, hat also quasi einen eingebaute Sicherung im Transport.
Das solche Pakete verloren gehen ist schon schwerwiegend, denn die Endgeräte sollten über die TCP Sicherungsschicht dafür sorgen das das nicht passiert bzw. soviel Retransmissions kommen bis die Session etabliert ist. Auch auf hoch belasteten Links.
Das würde im Umkehrschluss bedeuten das dort erhebliche Ausfälle in der Leitungsverfügbarkeit sind die den Sessiontimer in den Timeout zwingen. Sowas liegt im deutlichen 2stelligen Sekundenbereich.
Eigentlich fast unmöglich es sei denn auf deiner Leitung wird permanent Video gesehen oder sowas und die Leitung dauerhaft überbucht.
