VOIP über VPN

Auch wenn du im NCP Client die VPN Frames priorisierst besagt das noch nichts wenn diese MA mobil unterwegs sind. Der lokale Router (was auch immer das ist) der ihren VPN Traffic dann ins Internet bringt muss zwangsweise dann ein DSCP Honoring machen, sprich also überhaupt die ToS Bits lesen können und je nach lokaler QoS Policy entscheiden was er damit bzw. dem spezifischen ToS Wert macht (es gibt derer 64). Alle billigen Consumer Router, teathering Smartphones und auch sonstige Router/Firewalls ignorieren das wenn dort keine solche Policy definiert ist. Es wird dann also vermutlich egal sein was du da einstellst weil in den meisten Fällen einer mobilen Infrastruktur diese Settings eh ignoriert werden. Und wie bereits gesagt...spätestens am Internet Port dieses Routers ist dann so oder so Schluss mit jeglichem QoS weil der Provider das gleich abschneidet.
Nur das du das auf dem Radar hast bei deinen Überlegungen !

Das ist dann eine Herausforderung und ein Problem des Task Schedulers im Client selber. Hat dann aber eher weniger was mit dem Netzwerk an sich zu tun.
Da muss der Client Rechner dann wissen und entscheiden was er von welcher Applikation bevorzugen soll zudem muss er im Congestion Fall wissen ob Voice Daten übertragen werden oder nicht um die Bandbreite zu reservieren. Und dann ist ein sehr entscheidender Faktor ob der NCP VPN Client im Split Tunneling oder im Redirect Mode rennt. Beim Redirect wird das doppelt schwierig weil ja der gesamte Datentraffic des Clients dann in den Tunnel wandert und nicht nur Firmen relevanter Traffic wie beim Split Tunneling.
Das erfordert recht tiefe Eingriffe in den Task Scheduler des jeweiligen Betriebssystemes und es ist per se fraglich ob der NCP Client sowas allein leisten kann als externe Software die niemals so tief im System verankert ist wie der bordeigene VPN Client. Z.B. ein Grund mehr um bordeigene VPN Clients zu bevorzugen.