Forum Discussion

Iron Contributor

Sep 07, 2017

Solved

QoS for SfB when using Cloud PBX and PSTN Calling

Hi not sure if anyone can assist as I am new to QoS and wondered if there were any proper guides when using the Cloud based SfB along with PSTN Calling. (e.g. No SfB Server on site) I found this...

Deployment & Operations

PSTN Calling

Nick Elniff
Sep 11, 2017
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!

Nick Elniff

Microsoft

Sep 11, 2017

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!

Peter Longley
Iron Contributor
Sep 12, 2017
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>
- Peter Longley
  Iron Contributor
  Sep 18, 2017
  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.
  - Freddy Mulder
    Copper Contributor
    Dec 04, 2017
    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.
Trent
Iron Contributor
Sep 12, 2017
Without trying hijack this thread - I also have the same issue.

Setting 'Control DSCP Marking requests from applications and services' to Allowed didn't make any difference.