Quality of Service (QoS) for Lync 2010 and Lync 2013

Microsoft have published a lot of documentation about Quality of Service (QoS) with Lync. There is the Word document Enabling Quality of Service with Microsoft Lync Server 2010, TechNet for QoS on Lync 2010 and TechNet for QoS on Lync 2013. From what I can see there are no QoS specific changes between Lync 2010 and Lync 2013, other than the documentation seems to have been improved – especially for the client QoS section.

As there is so much documentation and no hard recommendations it can seem a bit overwhelming. Elan Shudnow has two comprehensive posts on QoS 1 and 2 but combine these with the Microsoft documentation there is a bit of information overload. The purpose of this post is a simple (relative term) summary of the changes required to enable QoS.

Microsoft Recommended QoS Markings

QoS marking is performed by the endpoints involved in the conversation – Lync clients, Lync Front-End servers, Lync Mediation servers, Lync phones and media gateways. This is done by setting a Differentiated Services Code Point (DSCP) marking on the TCP/IP packets as they are processed by the endpoint. The table below shows the recommended QoS markings for Lync. There are other recommendations for application sharing and file transfer, but the focus of QoS for Lync is to ensure the Audio traffic is prioritised highest, while also prioritising Video and SIP signalling.

Media Type	Classification	Queuing and Dropping	Notes
Audio	EF (DSCP 46)	Priority Queue	Low loss, low latency, low jitter, assured bandwidth (BW)
Video	AF41 (DSCP 34)	BW Queue + DSCP WRED	Pair with WAN Bandwidth Policies on constrained links
SIP Signalling	CS3 (DSCP 24)	BW Queue	Class 4. Low drop priority

Note: The DSCP markings in the following steps should be mapped to what the switches and routers are prioritising if different from the recommendations above.

Step 1 – Decide on the port ranges

In order to mark audio traffic as DSCP 46 and video traffic as DSCP 34, we need to ensure Lync restricts each modality to a specific set of ports that do not overlap. Windows can then set the QoS DSCP markings on traffic based on specific port numbers and potentially from specific programs on those port numbers. Based on the documentation above and Elan’s examples, the table below seems to be a good mix of keeping most settings default and ensuring no overlapping port ranges.

Scenario	Starting port	Ending port
Client audio	20000	20039
Client video	20040	20079
Client application sharing	20080	20119
Server application sharing	40803	49151
Server audio	49152	57500
Server video	57501	65535

Step 2 – Set the Port Ranges (Lync in band settings)

Client Ranges

Set-CsConferencingConfiguration -ClientMediaPortRangeEnabled 1 Set-CsConferencingConfiguration -ClientAudioPort 20000 -ClientAudioPortRange 40 -ClientVideoPort 20040 -ClientVideoPortRange 40 -ClientAppSharingPort 20080 -ClientAppSharingPortRange 40 -ClientFileTransferPort 20120 -ClientFileTransferPortRange 40 -ClientMediaPort 20160 -ClientMediaPortRange 40

Lync Pools

Set-CsConferenceServer -Identity <PoolFQDN> -AppSharingPortStart 40803 -AppSharingPortCount 8348 Set-CsApplicationServer -Identity <PoolFQDN> -AppSharingPortStart 40803 -AppSharingPortCount 8348

Lync Phone

Set-CsUCPhoneConfiguration -identity global -VoiceDiffServTag 46

Step 3 – Group Policy for Clients

A Group Policy should be created to set the following Policy Based QoS settings (applicable to Windows 8, Windows 7 and Vista):

• Voice: DSCP 46 for ‘communicator.exe’ (OCS or Lync 2010) or ‘lync.exe’ (Lync 2013) on source TCP/UDP ports 20000:20039
• Video: DSCP 34 for ‘communicator.exe’ (OCS or Lync 2010) or ‘lync.exe’ (Lync 2013) on source TCP/UDP ports 20040:20079

Step 4 – Group Policy for Servers

A Group Policy should be created to set the following Policy Based QoS settings:

Lync Front-End servers and standalone A/V Conferencing servers

• Voice: DSCP 46 for all applications on source TCP/UDP ports 49152:57500
• Video: DSCP 34 for all applications on source TCP/UDP ports 57501:65535

Lync Mediation servers and SBAs

• Voice: DSCP 46 for all applications on source TCP/UDP ports 49152:57500

In order to confirm the Group Policies have been applied to the servers you can use regedit to viewHKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\QoS\ which should look similar to this:

Step 5 – Local Computer Policy for Edge Servers

Lync Edge Servers are not domain joined so cannot use Group Policy. A Local Security Policy should be created to set the following Policy Based QoS settings by running gpedit.msc:

• Client voice:   DSCP 46 for MediaRelaySvc.exe on destination TCP/UDP ports 20000:20039
• Server voice:  DSCP 46 for MediaRelaySvc.exe on destination TCP/UDP ports 49152:57500
• Client video:  DSCP 34 for MediaRelaySvc.exe on destination TCP/UDP ports 20040:20079
• Server video: DSCP 34 for MediaRelaySvc.exe on destination TCP/UDP ports 57501:65535

Note: The Edge Policy Based QoS is using Destination port numbers, not source like the previous Group Policies

The Edge Local Computer Policy should look similar to this:

Step 6 – Set Voice Gateways to mark correct DSCP values

This is dependent on the gateway vendor, but ensure the gateway is setting the same DSCP markings for audio defined above.

Finished

Assuming traffic prioritisation has been set on all routers / switches in the media path, that should be all that is required. For more information on how to confirm the DSCP markings are being applied, see the blog by Jeff Schertz on QoS.

No incoming call notification with Lync or OCS

with Windows 7, some time you can't get the incoming call notification, you just see the Lync icon on the taskbar is flashing, and can't answer the call, here is the quick solution:

change the Theme to windows basic, Easy?

cisco router adsl setting

First we will need to build the VPDN group so we will be able to add our dialer after we configure the Ethernet interface we will use for the WAN connection.

router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
router(config)#vpdn enable
router(config)#vpdn-group 1
router(config-vpdn)#request-dialin
router(config-vpdn)#protocol pppoe
router(config-vpdn)#exit

Now we configure one Ethernet interface for use as our WAN interface.

router(config)#interface Ethernet1
router(config-if)#description ADSL WAN Interface
router(config-if)#no ip address
router(config-if)#no ip redirects
router(config-if)#no ip unreachables
router(config-if)#no ip proxy-arp
router(config-if)#no ip mroute-cache
router(config-if)#pppoe enable
router(config-if)#no cdp enable
router(config-if)#exit

Now to add your Dialer interface:

router(config)#interface Dialer1
router(config-if)#description ADSL WAN Dialer
router(config-if)#ip address negotiated
router(config-if)#no ip unreachables
router(config-if)#ip nat outside
router(config-if)#encapsulation ppp
router(config-if)#no ip mroute-cache
router(config-if)#dialer pool 1
router(config-if)#dialer-group 1
router(config-if)#no cdp enable

At this point you will need to find out what type of authentication your ISP requires. When you run into problems with this (ISP says one thing, it's actually something else...), you are suggested to turn on the debug ppp packet option to view low level packet output. Generally you will need to either use CHAP or PAP authentication. In some cases ISP requires both type of authentication. Following is how to set both up.

router(config-if)#ppp authentication chap pap callin
router(config-if)#ppp chap hostname ispusername

You want to make sure that username is whatever your ISP requires. Some ISP like the full e-mail address and some just need the username. You may receive a letter or email regarding this info. Consult your ISP if you are unsure. Following is the setup.

router(config-if)#ppp chap password isppassword
router(config-if)#ppp pap sent-username ispusername password isppassword

As you can see, with PAP as opposed to chap you input your username and password all at once in one command.

In some routers running newer IOS image, you may need to enter the password as it is (clear text) or encrypted. When you need to enter them as clear text, then you need to type in 0 (zero) then the password to indicate the password you are about to enter is in clear-text format. Similarly, you need to type in 7 (seven) followed by the password to indicate the password you are about to enter is in encrypted format.

You may notice that the Dialer1 interface is part of dialer group 1. This dialer group controls the Layer-3 protocol traffic that go over the Layer-2 PPP encapsulation. For this dialer group control, you need to specify which Layer-3 protocols the Dialer1 interface is allowed to pass through over the Layer-2 PPP. In this case, you want to pass IP protocols. Following is the setup.

router(config-if)#exit
router(config)#dialer-list 1 protocol ip permit

Another problem you may experience with many providers making constant changes to their network is with packet fragmentation from PCs with MTU Maximum Segment Size (MTU MSS) set too high. The MTU on the dialer interface should be 1492 as PPPoE adds an 8 byte encapsulation header. The key is setting ip tcp adjust-mss 1440 on the inside ethernet interface. You will find many different suggestions and recommendations out there. Some will say 1492 or 1460 MTU size instead of 1440. Some will even say 1452. 1452 MSS is pretty much the standard for DSL with a PPPoE transport. Normal MSS is 1500 bytes. But you have to account for the 40 byte IP header and the 8 byte PPPoe header. That gets you to 1452.

Following is from the mouth of Cisco, "If you have ADSL running PPPoE and run into problems resolving DNS, adjust your MTU on your ethernet interface using the command ip tcp adjust-mss 1452. This is because PPPoE requires more bits in the header packet than any other type of circuit."

The last bit of optimization is a little more subtle and is a debatable topic. As the PPPoE traffic is carried over ATM cells, it has to be chopped up before it can be transmitted. ATM cells are 53 bytes long and have a 5 byte header. So a total of 48 bytes of payload. If you were to take 1452 bytes of data and split it up across 48 byte payloads. You would come up with 30.25 cells. The .25 is a 12 byte remainder that would have to be sent in a separate ATM cell. ATM cells are always 53 bytes. So the payload would have to be stuffed with an additional 36 bytes of null data for that last chunk. So to be completely optimized you would set the MSS to 1440 to eliminate those wasted 36 bytes.

Adjusting MTU size may be news to you, but the minute you do it all network-related problems might be fixed. With this in mind, note that MTU size should not be too big in order to avoid general connectivity issue. Similarly MTU size should not be too small in order to avoid ineffective traffic flow. Feel free to experiment to set MTU size to either 1452 or 1440 to see which size brings you the most suitable result.