This document has been created to assist customers in solving network related Video Quality issues, regardless of the video codec/system manufacturer. We will present options for each of the elements involved; this will include a review of the physical, logical, network, and application level elements associated with a multi-site Video Conferencing deployment.

Please note that this document assumes that you have some form of MPLS, VPLS, and/or Point-to-Point Wide Area Network transport in place for connecting your locations.

The first step in isolating video & audio quality is a physical inspection of the cabling plant that connects the conferencing system together (i.e. Codec, Flat Screens, and Audio Systems), on occasion, bad crimps and/or faulty connectors will seemingly impair a video quality session as it relates to the haptic elements associated with both Audio and Video quality.

The second step is to review the network connectivity that links the Video Unit in the LAN/WAN infrastructure; this includes checking the in-room Ethernet cabling, room jacks, IDF patch points, as well as the device’s physical interface settings. As was mentioned above, you want to ensure that there’s no faulty wiring or connector points. Moreover, the network interfaces of different switches & codec manufacturers react differently when they’re set to auto/auto and rely on MIDI or MIDIX for determining speed and duplex settings. As such, you should avoid any form of auto-negotiation on the network interfaces between the Codec and the switch it connects to. Assigning a 100/Full setting to both respective interfaces will ensure a constant high-quality configuration regardless of whether the Codec reboots or spanning tree changes/resets on the switch.

Logical Connectivity Assessments

Once you’ve completed the physical network configuration inspection, the next step is to configure your logical paths within the LAN network so that video is isolated from other types of LAN traffic. Although it is not widely documented, mostly due to the large back-plane and heavy forwarding capacity of high-end LAN switches, it is highly suggested that you separate your Video, Voice, and Data Traffic into individual broadcast domains using VLANs. The reason for this is that quite often, Video and Video RTP Streams use the same UDP ports that other devices may use, such as replication engines, SharePoint, accelerators, load-balancers, etc…. When you isolate traffic into a broadcast domain using a VLAN, where the VLAN is trunked between multiple switches, you are assured that traffic will be isolated to that specific service/traffic from a forwarding perspective between the different devices that are residing on this specific virtual network. Moreover, multicast, spanning tree, as well as rapid spanning tree works faster when individual interfaces are isolated to a specific broadcast domain/virtual network; essentially giving you the extended capability to modify the setting of these elements on the interfaces that are associated to this specific virtual network without affecting your other networks within the LAN core.

Also, there is an additional advantage to isolating traffic to a VLAN. If your virtual networks traverse a switch core that is responsible for switching/forwarding an exceptional amount of UDP traffic (i.e. 10Gbps or more) within the spanning tree/forwarding core, you can further isolate your virtual network by associating priority and/or quality to the VLANs directly (802.1q/p). This provides you with several advantages.

• You can ensure that all traffic traversing your segmented Video network has a higher priority over other types of traffic (this will ensure low jitter and constant packet delivery)

• You can create forwarding classes on the VLANs within your switches to set priority on the allocation of the available buffer space to ensure that Video traffic is prioritized within the backplane on forwarding (this is absolutely critical if you’re using a video bridge to run multi-site/multi-room connections and/or if you’re streaming live content from video servers).

• You can also create VLAN inference to ensure that all traffic gaining access to the VLAN is assigned a Class of Service value on ingress and egress (this is a great feature to use if you have mobile video stations that do not have a locked configuration) – more on this point shortly.

In additional to these physical and logical configuration best practices, there are several network based configurations that should be associate to your video network. We will discuss the top three in the next section.

To continue from the previous section, once you’ve confirmed the physical connectivity of your Video System, as well as configured & confirmed the logical isolation of your video traffic, the next step is to ensure that you have quality associated with the individual traffic streams (Video, Audio, and Signaling). As we mentioned previously, you can use VLAN inference to associate Class of Service to the IP Headers of the individual streams that are traversing your Virtual Video Network. The reason you want to have Class of Service associate to individual streams is twofold:

1. You never want to have to worry about what will happen to your video traffic as it relates to using both switched and/or routed interface within your LAN core(s).
2. You want to ensure that video traffic is associate to the proper forwarding queues when that traffic is routed through the interfaces that are connecting both the LAN & WAN links.

As such, it is best practice to assign class of service directly on the individual units. For example, on most Polycom devices you can set Quality of Service by going to the Administration Menu of your Polycom via Setup\LAN Settings\IP Settings\QoS Settings section. This may vary from model to model, but Class of Service should be listed under the IP settings menu.

By default , most network documentation suggests using the following ToS/DCSP setting for each of the three elements of a video call:

Traffic Type	ToS Value	IP Precedence Value	DSCP Value
Signaling	3	3 or 011XXX	AF31
Video	4	4 or 100XXX	AF41
Audio	5	5 or 101XXX	EF46

However, these suggested settings do not always meld well with how your Wide Area Network service provider recognizes traffic for QoS enforcement of specific traffic types. As such, it may be less complex (and work just as well) to simply mark all three streams with the same Class of Service forwarding value that your WAN provider expects to see for you to achieve specific service level for a given type of traffic. This will ensure configuration continuity throughout the network over that specific provider.

There are also situations (typically due to network inheritance, multiple providers, and/or management simplicity) where you may choose not to set Class of Service directly on the Video Units. In these situations, we typically recommend the following configurations (again, these suggestions are based on the assumption that you’ve already isolated your Video Traffic into a segmented Virtual Network within the LAN):

• Infer the Class of Service assigned to the IP headers from the VLANs themselves (this will ensure that all traffic is marked while traversing the LAN core, even if it’s traversing intermediary/campus routing points). When you do this, you must make sure that any interface associate to this virtual network has a QoS trust policy associated to it. If you do not have a campus network, but you’re still routing from core to edge, then refer to the next option.

• Associate Quality of Service (not class of service) on the Video VLANs so that traffic arrives at core & edge routing points “un-marked”, but with forwarding priority. On those intermediate routing interfaces, create a Policy/Class Map, and then associate that Policy to these interfaces for outbound traffic using the “service-policy output” command. Be sure to select a single CoS value (i.e. ToS 4 or AF41) for all traffic…this will allow you to create simple remark policies on your edge WAN routers if necessary to accommodate multiple service providers.

• If the VLAN does not have an intermediate routing point for getting traffic to your edge network devices (i.e. the VLAN/Subnet gateway resides on the edge router(s)), then you assign the policy map on that particular LAN/Gateway interface. The different between doing it at intermediate point versus at the actual edge is the way the Policy/Class Map is assigned. In the previous example, we would assign it on “output” as traffic left the core destined to your routed edge. In this example, since the edge device is the actual LAN gateway of the virtual Video network, you will use the “service-policy input” command so that traffic is marked as it enters the edge router from the LAN. In this example, if only one service provider is connected to that edge router…you would mark traffic to match that service provider’s specific QoS policies; if two providers exist…then you would again assign a single CoS value for that traffic, and then place remark policies (assigned as “service-policy output” commands) on the interfaces connecting to the two service providers.

There are a variety of ways to assign class of service on Layer 3 Switches and Edge Routers. We’ve provided an example of how to assign class of service to the interfaces connected to a couple of service providers from a single router:

Sample Class of Service Configuration

!

class-map match-all video

match access-group name video

!

policy-map Provider A-Video

class video

set dscp af31

!

policy-map Provider B -Video

class video

set ip precedence 4

!

ip access-list extended video

permit ip 10.1.1.0 0.0.0.255 any

!

interface Serial0/0

description Connection to Verizon

ip address 172.16.0.1 255.255.255.252

service-policy output Provider A-Video

!

Interface Serial1/0

description Connection to Masergy

ip address 172.16.1.1 255.255.255.252

service-policy output Provider B-Video

!

Again, this configuration would change slightly if this device was an intermediate interface or the gateway for the LAN network. For example, you would use the following mapping if it was a single service provider connecting to a single gateway router:

!

interface GigabitEthernet0/0

encapsulation 802.1 VLAN102

no ip address

speed 1000

!

interface VLAN102

ip address 10.1.1.1 255.255.255.0

service-policy input Provider A-Video

!

This configuration marks traffic as it leave the VLAN and enters the edge router. With traffic being already marked, the router simply has to forward traffic out to the service provider (pending no additional policies are required on the interface for shaping to the service providers policing queue(s)).

To summarize, once you’ve confirmed physical connectivity, configured and confirmed logical network isolation and separation, and have the appropriate Class of Service markings at your QoS forwarding points…your video transport network should be rock solid!!! However, this does nothing to prevent human error in the actual use of the video systems. As such, here are some key pointers and best practices you should assess and implement to ensure Quality of User Experience (QoE) every time you have a video conference.

• Lock the users out!!! Once you have physically setup the system, whenever possible, be sure that the only equipment and wiring exposed is Camera, Screens, and Ethernet Patch Cable, respectively. The less stuff being touched will ensure performance over the long run.
• Lock the users out!!! Make sure you have administrative passwords associated with each video unit so that no one but the assigned team can access the configuration elements.
• Lock the user out!!! Ensure that each individual video system and/or management gateway has a list of the callable end points. Moreover, you should define and hard set specific Audio and Video codec types for each destination point (i.e 384K H.264 to Dallas, 768K H.323 to London, etc…). This will prevent users from selecting either too large or too small of codec, and thus getting bad performance and/or quality.
• Lock the users out!!! If possible, lock down the volume and mute control settings on the remote…making it accessible via the microphones only (this will prevent user error), and awkward situation of a user trying to figure out why he can hear them, but not the other way around.
• Lock the users out!!! If possible, lock down the TV’s remote and video input options, making volume & power the only accessible items. This will prevent situations where users getting audio but no Video.