Waarom QoS voor VoIP?
QoS (Quality of Service) gaat over voorrang geven aan spraak op het moment dat er ergens in het netwerk wachtrijen ontstaan. Dat moment hoeft niet vaak voor te komen, maar als het gebeurt (drukke Wi-Fi, volle uplink, back-ups/updates, piekbelasting), dan is het precies het verschil tussen “gesprek blijft netjes” en “robotstem / haperingen”.
Binnen je netwerk is QoS goed toe te passen, maar het is van belang dat QoS in het hele netwerkpad wordt doorgetrokken. Van de clients (hardphones, softphones, WebRTC) via eventuele access points (in geval van Wi-Fi), switches naar de firewall/router (WAN-edge).
Bij veel internetproviders is QoS in de praktijk “best effort”. Dat betekent dat verkeer niet (of niet consistent) wordt geprioritiseerd op basis van QoS-markeringen. Toch is het nuttig om QoS toe te passen in uw eigen netwerk, omdat ook in uw netwerk op knelpunten piekbelasting kan ontstaan. Vaak is dat niet zichtbaar in netwerkmonitoring, omdat die pieken heel kort kunnen zijn en het middelingsmechanisme van netwerkmonitoring daar meestal geen rekening mee houdt.
Hoe werkt QoS en wat kun je inrichten
QoS in het kort
QoS is het classificeren van verkeer (wat is het?) en het prioriteren ervan (wie mag als het druk is als eerste door?).
Daarbij komen twee kernbegrippen terug:
- Marking: verkeer labelen (bijv. DSCP).
- Queueing/Prioritization: die labels gebruiken om wachtrijen slim te behandelen.
Waarom QoS end-to-end moet
QoS werkt alleen goed als:
- de juiste stromen herkenbaar zijn (marking), en
- de netwerkcomponenten die marking ook daadwerkelijk respecteren (queues).
Als één schakel het niet doet, verdwijnt het effect. In praktijk moet je daarom denken aan:
- Endpoints (hardphone/softphone) – marking aan de bron.
- Switching (access/distribution/core) – trust/remark + queues op uplinks.
- Wi-Fi (indien gebruikt) – voice queueing (WMM) en capaciteit.
- WAN-edge (router/firewall/edge) – hier ontstaat vaak de echte wachtrij, dus hier moet prioriteit werken.
SIP en RTP: twee protocollen, twee prioriteiten
- SIP (signaling)
Regelt registratie, call setup en call control (ring/answer/transfer/bye). Bandbreedte is beperkt, maar het is functioneel belangrijk: als SIP slecht gaat, merk je dat in vertraagde opbouw, registratieproblemen, of mislukte transfers. - RTP (media)
Dit is de audiostream zelf. Continu en real-time. Als RTP last heeft van jitter of packet loss, hoor je dat direct als haperingen, stiltes of robotstem.
Met deze kennis is het logisch om te zorgen dat:
- RTP de hoogste prioriteit krijgt
- SIP een hoge prioriteit krijgt, maar lager dan RTP
Aanbevolen QoS-profiel (eenvoudig en gangbaar)
Wij adviseren een klein aantal klassen. Meer klassen maken een ontwerp zelden beter en vaak minder beheersbaar.
Advies DSCP-markering:
- RTP / Voice (media): DSCP 46 (EF)
- SIP / Signaling: DSCP 26 (AF31)
Overig verkeer (data) hoeft niet expliciet geclassificeerd te worden en blijft:
- default / best-effort (meestal DSCP 0)
Dat betekent niet dat data “langzaam” wordt, maar wel dat spraak voorrang kan krijgen op momenten dat er congestie ontstaat.
Praktische randvoorwaarde:
Als RTP in een priority queue geplaatst wordt, is het verstandig die queue te begrenzen (rate/percentage), zodat verkeerd gemarkeerd verkeer niet onbedoeld alles kan verdringen. Deze waarden liggen natuurlijk aan het te verwachten VoIP verkeer en hapklare waardes hebben we hier niet voor.
Kwaliteitsparameters (waar je op stuurt)
QoS is een middel; het doel is voorspelbare kwaliteit. De belangrijkste parameters:
- Latency (vertraging)
Richtlijn spraak: bij voorkeur ruim onder ~150 ms one-way. - Jitter (variatie in vertraging)
Richtlijn: bij voorkeur < 20–30 ms. - Packet loss (verlies)
Richtlijn: < 1% (liefst lager).
In de praktijk zien we dat vooral congestie en buffering (wachtrijen op Wi-Fi of WAN uplink) de oorzaak zijn van slechte spraakkwaliteit. QoS is er om juist dat effect te beperken.
Dus doorvoer van QoS hangt af van
- Marking aan de bron (toestel/softphone): RTP EF, SIP AF31.
Onze device provisioning profielen voorzien hierin voor zowel hardphones (Yealink, Polycom) als softphones (Webex).
Dit laatste met een kanttekening: op Windows wordt DSCP-markering doorgaans afgedwongen via Policy-based QoS (lokaal of via domein-GPO) of via PowerShell. Microsoft Learn
(Als referentie: Microsoft Teams beschrijft hetzelfde principe van Policy-based QoS op Windows clients.) Microsoft Learn
(Voor Webex specifiek: Cisco beschrijft GPO-gebaseerde DSCP-markering voor Webex App op Windows.) Webex Help Center - Marking behouden binnen het LAN (switching): trust/remark en queues op uplinks.
- Wi-Fi correct behandelen (als er via Wi-Fi gebeld wordt): voice-prioriteit en voldoende capaciteit.
- WAN-edge prioriteit: zorg dat voice niet achteraan in de rij komt op de uplink
Hoe test je de werking van QoS
- Start een gesprek en genereer vervolgens bewust veel netwerkverkeer (bijv. zware upload).
- Als QoS goed staat, blijft het gesprek stabiel en hoor je geen haperingen.
- In de netwerkcomponenten is zichtbaar dat voice-queues gebruikt worden (counters/queues).