istike2
Goto Top

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)


dsl

dsl_voip


dsl_internet

dsl_default

dsl_ack



Und hier für LAN:

lan

lan_voip

lan_qlink

lan_internet

lan_ack

So sieht es im Queues aus:

queues


So wurde die Traffic zu dem VoIP-Fritzbox priorisiert:

floating_rules

Vielen Dank.

I.

Content-Key: 316358

Url: https://administrator.de/contentid/316358

Ausgedruckt am: 29.03.2024 um 14:03 Uhr

Mitglied: aqui
aqui 28.09.2016 um 09:49:15 Uhr
Goto Top
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.