Forum Discussion
QoS for SfB when using Cloud PBX and PSTN Calling
Hey Peter,
(Author of those articles checking in)
I am curious as to what is causing the traffic not to be marked. Are you able to test on a machine that is not domain joined? (Should be able to export those Registry Keys and import them on the test machine)
*EDIT* - I think I found the issue.
- Go to the GPO Editor and navigate to 'Computer Configuration>Windows Settings'
- Right-click 'Policy-Based QoS' > choose 'Advanced QoS Settings ...'
- Go to the 'DSCP Marking Override' tab
- Check 'Control DSCP Marking requests from applications and services'
- Select "Allowed'
I can't update the Perficient blog post since I am no longer employed there.
But I will try to figure out the PowerShell GPO cmd to create this entry
Hopefully this works for you!
That worked for me it seems!!!
At least for Audio, now to test the others. Thanks Nick
***EDIT***
Now tested all others (except file transfer and looks to be working fine now)
The Skype tracing log file still shows this though which is strange!
<qosEnabled>false</qosEnabled>
<enableInCallQoS>false</enableInCallQoS>
One more thing if any of you can assist, as per my last post it appears that the GPOs are now working as expected.
Our network switches have QoS options and are set as default to trust dot1p there is the option to change it to trust ip-dscp am I correct in assuming now I have set the QoS at GPO level I need to change the switches to the trust ip-dscp also to ensure the switches manage the priorities?
These are the other settings which I am not sure if I should be changing also.
Thanks for all your assistance so far.
Hi Peter, I think you will know the answer by now but to finish this topic, Yes in the GPO you configured QoS at OSI layer 3 using DSCP.
So if you configure an access layer switch for this client, you also need to configure it at Layer 3 (DSCP) to trust, because there is no marking at Layer 2 (802.1p) present in the packet on the ingress. In the access layer switch you can, if you want to, map DCSP to COS to switch the packet through your distribution and core layer network. And at the end (egress port on the access switch) you can map COS back to DSCP. If your whole network is configured to support QoS with DSCP, there is no need to recoloring QoS marked packets.
Not exactly a reply to/for the post above,
Just share things I have observed so far on Applying QoS on SFB servers and ClientsThe port range is controlled by the server and the client gets these settings via in-band provisioning. Without the GPO (both server and clients) will not tag the traffic with the desired DSCP markings.
You could take a look at the Skype Validator QoS Calculator and see what settings might have been missed: https://skypevalidator.com/_tools_qos.aspx
Skype Validator - Used to assist in the validation and documentation of Skype for Business/Lync Server.
Nice tool though, to generate the commands that can be run straightaway in the environment,However end configuration exists in the environment already,
I needed to know the reason why is it required to deploy the GPO when the command set-csconferencingconfiguration is run in the environment already,
and when the client is still not able to download / apply the client side port range, I have confirmed the GPO and corresponding Reg keys do existsHowever I have the uccapilog it show qosenabled is still set to false what does that means ?
Whereas I have clearly and successfully ran the commands to set the port ranges for servers and clients
Which is also the part of process know as in-band provisioningDo I have run the set-csconferencingconfiguration again or do I have to apply the server gpo also ?
