Een veel voorkomend probleem bij Hosted VoIP is een slechte audiokwaliteit. Stotteren of wegvallende gesprekken komen met enige regelmaat voor.
Vaak is dit te wijten aan te weinig bandbreedte op locatie wat resulteert in een te drukbezette internetverbinding.
Het RTP verkeer welke zorgt voor de audio bij Hosted telefonie maakt gebruik van het UDP protocol, UDP is een stateless protocol, hierbij wordt niet gecontroleerd of het verkeer aan de andere zijde daadwerkelijk is aangekomen. Wanneer niet alle verkeer aan de andere zijde aankomt of in de verkeerde volgorde dan ervaren wij dit als stotteren en wegvallen van de audio.
Quality of service
Naast het inkopen van meer bandbreedte kunnen we het telefoonverkeer voorrang geven boven het andere verkeer op de internetverbinding. Dit noemen we in internettaal Quality of Service afgekort QoS, een beetje fatsoenlijke router ondersteund deze instel mogelijkheid.
Met de optie QoS zijn we in staat om het verkeer te priorizeren naar het internet toe. Wij gaan in dit blog niet uitvoerig bespreken hoe dit voor een betreffende router te doen. Wij bespreken hier enkel de techniek hoe dit in zijn werk gaat en waar je op moet letten om dit goed te doen.
Helaas zien wij namelijk in de praktijk dat het instellen, om VoIP verkeer te priorizeren, meestal niet goed wordt uitgevoerd.
Als je ons blog hebt gelezen over “One Way Audio” dan heb je al kunnen lezen dat het SIP protocol gebruikt wordt voor de signalering. De standaard poort die hiervoor wordt gebruikt is UDP 5060.
In de praktijk zien we dat de QoS functie wordt ingesteld om alle verkeer te priorizeren met als poort nummer UDP 5060.
Op zich is dit natuurlijk prima om de signalering te priorizeren maar hiermee heb je het stotterende of wegvallende audioprobleem nog niet opgelost.
Als je in staat bent audio overdracht te prioriteren heb je het probleem opgelost
Wat we uiteraard willen priorizeren is het RTP protocol, dit protocol zorgt namelijk voor de audio overdracht. Wanneer wij in staat zijn dit voorrang te verlenen dan hebben we het probleem namelijk opgelost.
Helaas kunnen niet alle routers het RTP verkeer uit zichzelf herkennen, je zal zien dat je meestal de mogelijkheid hebt om QoS in te regelen op basis van:
- IP adres (source / destination)
- Poort nummer
- Classifier DSCP/TOS bit
Iedere router heeft zo zijn eigen specifieke instelmethodes en eigen benamingen m.b.t. de velden en wellicht meer velden dan hierboven genoemd. Hoe je voor je eigen router de QoS instelt zou je moeten opzoeken in de handleiding.
In dit blog gaat het er met name om dat je de audio streams prioriseert en je niet beperk tot het priorizeren van het SIP protocool want hiermee los je het probleem niet op van wegvallende audio en het stotteren of kraken hiervan.
Dus met bovenstaande in het achterhoofd kunnen we een aantal simpele aannames doen om ons audio verkeer te priorizeren.
audio streams priorizeren
Het gaat hierbij om het verkeer te priorizeren naar het internet toe. Het verkeer wat vanaf het internet komt hebben wij geen vat op. Heel simpel gezegd, er zijn wel methodes voor, maar wij kunnen dit niet priorizeren dat zou onze ISP (Internet Service Provider) eigenlijk moeten doen.
We kunnen gaan priorizeren op basis van ip adres, we weten waar onze telefoon(centrale) verbinding mee maakt. We kunnen hiervoor een QoS regel aanmaken in onze router wat al het verkeer naar dat IP adres voorrang geeft.
Maar is dit ook het adres wat ons audio verkeer afhandelt? Heeft de VoIP provider een simpele infrastructuur met 1 enkele server dan is het antwoord ja. Maar in de praktijk blijkt dat Hosted VoIP leveranciers gebruik maken van een heel scala aan servers om al dat VoIP verkeer af te handelen. Dat kan zijn vanwege het aanbod (Load Balancing) of voor redundantie.
In dat geval werkt het niet om dat ene ip adres te priorizeren, dan zou je kennis moeten hebben over de infrastructuur van de provider of dit moeten opvragen.
Heb je de gegevens of is het in jouw situatie duidelijk dat dit 1 ip adres betreft dan is dit de meest simpele oplossing.
Priorizeren op poortnummer
De tweede methode is op basis van poortnummer, hier kiezen vele voor en priorizeren poort 5060 UDP, want dit is bekend. Maar we hebben ook gezien dat hier onze audio helemaal niet door wordt afgehandeld dus dit dekt de lading niet.
RTP verkeer is dynamisch en wordt onderhandeld tijdens het opzetten van het gesprek, wij weten eigenlijk helemaal niet welke poorten hiervoor worden gebruikt. Vaak kunnen we wel een bandbreedte instellen welke poorten er mogen worden gebruikt. Echter een NAT router gaat deze poorten weer translaten en dan zitten we nog met de verkeerde informatie. Wanneer je kiest om alle 65535 UDP poorten te priorizeren dan heb je het ergens vast wel goed. In de hoop dat je in de router een range kunt aangeven anders ben je wel even bezig om ze allemaal toe te voegen.
Daarnaast kost het de router heel veel processor capaciteit om de regels allemaal door te nemen dus dat kan dan ook weer een bottleneck vormen.
DSCP/TOS
De juiste manier hiervoor is om gebruik te maken van DSCP/TOS, dit is een extra veld wat je kunt toevoegen aan de IP header. Hiermee kan de router je verkeer herkennen, het instellen van deze waarde doe je in je IP telefoon. Onze telefoons beschikken over de mogelijkheid om dit frame toe te voegen aan de IP header. In het menu onder “network settings” meestal zet je dit aan en vul je een waarde in, staat meestal al ingesteld.
Vervolgens ga je naar de QoS instellingen van je router en hier vind je de mogelijkheid om IP headers te controleren op bijvoorbeeld de DSCP tag. In het veld vul je de waarde in die je ook in je telefoon hebt ingesteld.
Nu herkent je router deze data en kun je deze in een hogere prioriteit Queue afhandelen, al het overige verkeer zonder die Tag zet je in een lagere Queue.
Hiermee heb je het VoIP verkeer in een keer gepriorizeerd zonder dat je hoeft te weten naar welk ip adres of welke poorten er worden gebruikt.
