The ability to both capture and view desktop and telepresence video content in Microsoft Lync 2010 is something that organizations are investing in, testing with, and leveraging more every day.  From simply improving the quality of desktop peer-to-peer video collaboration to allowing interoperability between Lync and existing dedicated high-definition conferencing and telepresence solutions the prominence of life-like, usable video is growing in the personal computer arena.

Hardware Requirements

Before diving into the High Definition video capabilities of Lync the video content itself must be able to even be captured at high resolutions, which requires a specific level of capture devices and processing power.

Cameras

There are no less than 12 different USB devices currently Optimized for Microsoft Lync which support capturing video at a minimum of 720p at 30fps. Some of these devices even support 1080p capturing (the Microsoft LifeCam Studio for example) but the Real-Time Video (RTV) codec is limited to utilizing 720p/30 at most.

Processor Cores

This is the fuzziest area in the topic and is the primary reason for writing this article.  There is a common misconception that a quad-core processor is required on the workstation running the Lync 2010 client in order to handle any high definition resolution media.  This is only partially correct:

• In order to bi-directionally send and receive HD video streams a quad-core processor is required.  But a dual-core equipped workstation can receive video streams sent in 720p HD, although at a reduced frame rate of 15fps.

As it generally requires slightly more processing power to encode video than to decode it Microsoft found in their original testing that a typical dual-core workstation could handle the processing load to decode a 720p inbound stream when limited to sending only a standard-definition VGA stream outbound.

The most likely reasons that this is not very well known are that the large majority of Lync workstations are typically not quad-core today and due to bandwidth concerns many administrators may not have enabled HD resolution in the Lync Server configuration.  So if no endpoints are sending HD then there is no HD video to be received, thus even with a wide deployment of dual-core systems this fact is still obscured.  But with the recent availability of quad-core workstations and third-party video endpoints all capable of sending HD 720p resolution over RTV then this behavior is starting to become more common-place.  Additionally the Lync client’s default behavior is to still send VGA quality video from a quad-core system to a dual-core system, while third-party solutions may instead take advantage of the higher resolution, lower frame rate option.

Now to the informed reader these statements may seem incorrect as Microsoft makes a generic statement about processor support in the official Lync TechNet documentation under Client Hardware Support which simply states: “For video: Dual Core 1.9 GHz processor or higher for VGA, Quad Core 2.0 GHz or higher for high definition.”  So technically this statement is not completely accurate and should instead be defined as “bidirectional send/receive” requirements.

Media Capabilities

To illustrate the proof behind the statements in the previous section a brief look into the the Session Description Protocol (SDP) details of a SIP invitation is all that is needed.  It is important to understand that when Lync negotiates media during call setup it will only advertise its own receive capabilities, it does not ever communicate its send capabilities. Since the remote endpoint is also sending its own unique receive capabilities, then both parties know what the other party is limited to receiving so Lync will not attempt to send a resolution higher than what the remote endpoint can receive.  Another key point to understand as that SDP only negotiates the media setup and it is not until the RTP/SRTP media session is established that Lync will actually tell the remote endpoint what resolution to send.  And because RTV is a flexible codec capable of changing resolutions and bitrates mid-call then the remote party can (and will) ask for different resolutions at any point.  When the Lync video window is resized by the user by popping the video window out or increasing it to full screen then Lync will appropriately ask the remote endpoint to send a higher resolution.

The following table shows the different receive capabilities advertised for RTV under the a=x-caps:121 RTP Payload from a Lync 2010 client tested on three different computers: a single core, a dual-core, and a quad-core.  Each individual capability entry is comprised of a string of identifying values: <Capability ID>:<Frame Width>:<Frame Height>:<Frames Rate >:<Maximum Bit Rate>:1. (The Maximum Bit Rate for each resolution is currently ignored by Lync and is reserved for future use.)

Cores	Capabilities	Description
1	263:640:480:15.0:600000:1; 4359:352:288:15.0:250000:1; 8455:176:144:15.0:180000:1	VGA : 15 fps : 600Kbps CIF  : 15 fps : 250Kbps QCIF : 15fps : 180Kbps
2	263:1280:720:13.0:768000:1; 4359:640:480:30.0:600000:1; 8455:352:288:15.0:250000:1; 12551:176:144:15.0:180000:1	HD720p  : 13fps : 768Kbps VGA : 30fps : 600Kbps CIF  : 15fps : 250Kbps QCIF : 15fps :  180Kbps
4	263:1280:720:30.0:1500000:1; 4359:640:480:30.0:600000:1; 8455:352:288:15.0:250000:1; 12551:176:144:15.0:180000:1	HD720p : 30fps : 1500Kbps VGA  : 30fps : 600Kbps CIF : 15fps : 250Kbps QCIF : 15fps : 180Kbps

To the casual Microsoft administrator the QCIF capability may look awfully foreign, as nowhere in the Lync documentation is this term ever discussed.  Throughout the standard TechNet documentation the only resolutions described for RTV are CIF (Common Intermediate Format), VGA (Video Graphics Array), and HD (High Definition).  But CIF resolution in the documentation is actually two different resolutions, CIF and QCIF, categorized as one.  QCIF means “Quarter CIF” and is exactly that, the overall resolution is one-quarter of CIF resolution.  To do the math CIF is 352 x 288 = 101,376 pixels while QCIF is 176 x 144 = 25,344 pixels, which is exactly 1/4 the total overall resolution.  For more mathematical fun further compute that VGA is 307,200 pixels and HD is 921,600 pixels.  Thus increasing the resolution from CIF up to VGA offers three times the amount of pixels, and bumping VGA to HD is yet another triple-jump in pixel depth.

Enabling HD Resolution

Regardless of whatever hardware capabilities exist in the Lync environment, out-of-the-box HD video sessions cannot be established without first increasing the default global media configuration setting above VGA resolution.  This setting overrides all capability checks, local setting, client policies, conferencing policies, and bandwidth management settings.

• From the Lync Server Management Shell use the Get-CsMediaConfiguration cmdlet to identity the current value of the MaxVideoRateAllowed parameter in the Global media policy.

The potential values are either CIF250K, VGA600K (the default setting in Lync), or Hd720p15M.

• To increase the default value to allow for any HD video sessions in Lync use the Set-CsMediaConfiguration cmdlet as shown below.

Set-CsMediaConfiguration –Identity Global -MaxVideoRateAllowed Hd720p15M

• Publishing the configuration change to the Lync Topology will commit the new setting but typically these global media parameters can take a long time before the new behavior takes affect, so a restart of the Front End Server or its Lync services will prompt an immediate change.

Enable-CsTopology

Be aware that increasing this value still does not provide for HD video during any Lync AVMCU-hosted conferencing sessions as HD video is only possible in Lync during Peer-to-Peer calls. The Lync AVMCU is limited to voice-switched VGA resolution only and has no high definition video capabilities by-design. Third-party conferencing bridges are able to provide HD video resolution because calls to these integrated systems are essentially a peer-to-peer call as the signaling is not handled by the Lync MCU and the calls are not a traditional Lync conference.

Verifying Client Capabilities

As discussed earlier the SDP details of the SIP traffic can be viewed to see what a specific client is advertising as its receive capabilities.  There are a couple way to capture this SIP traffic during a call negotiation: either from the Front End server that the Lync client is currently registered to by using the Lync Logging Tool, or by directly looking at the UCCAPI logs on the Lync workstation.

• To enable the client-side trace logs check the Turn on logging in Lync setting in the Lync General Options page.

• Restart the Lync client and then place a video call to another Lync endpoint, allowing video to be established in both directions.
• Stop the call and then and then browse to the %userprofile%Tracing folder on the Lync client’s workstation.

• Open the Communicator-uccapi-0.uccapilog file in Notepad and search for the string “x-caps” and the first match should be the the local Lync client’s advertised video capabilities.

m=video 12450 RTP/AVP 121 34

a=x-caps:121 263:1280:720:13.0:1500000:1; 4359:640:480:30.0:600000:1; 8455:352:288:15.0:250000:1; 12551:176:144:15.0:180000:1

a=x-caps:34 262:352:288:15.0:250000:1;4358:176:144:15.0:180000:1

The first line in the selection above starts with m=video and is the beginning of the section of SDP which describes the client’s inbound video capabilities, potential candidate IP address (local and proxy), encryption capabilities, etc.  (Scrolling up a number of lines in the log file should show the earlier m=audio header which lists all of the different audio capabilities.)

The second line is the video capabilities statement for the RTV codec, as designated by the media ID of 121.  The highlighted text is proof that the dual-core workstation can receive 720p as it is advertising that very capability to the remote party.

The last line is an additional video capability statement defining the native Lync client support for H.263. Notice that the only resolutions advertised here are 352×288 CIF and 176×144 QCIF.  This is the reason that any video calls between Lync clients and third-party video endpoints which do not support RTV will look low-quality, as this is the only other codec supported by the Lync client .

Since the log file will capture SIP messages received as well as sent, then the remote endpoint’s capabilities can be located as well.  Scan back up from the searched x-caps line and look for the first SDP statements listed just above the m=audio statement.

v=0
o=- 0 0 IN IP4 172.26.240.120
s=session
c=IN IP4 172.26.240.120
b=CT:99980
t=0 0
m=audio 1030 RTP/AVP 114 9 112 111 0 8 116 115 4 97 13 118 101

The o= line identifiers the Originator by its IP address.  This is the IP address of the computer which sent this message and the c= Connection line will typically also show the same address.  This is the best way to identify exactly what host sent this specific SIP message, as looking at the From field in the beginning of the SIP messages is not a good idea.

The way that the SIP messages are addressed in Lync is that all messages in a given conversation will be addressed From the SIP URI of the caller To the SIP URI of the called party.  So even SIP responses sent by the remote endpoint will still show the calling Lync user’s SIP URI in the From: field.  This can make it difficult to identify the direction of individual messages.

• To illustrate this, the following text shows the header from a SIP INVITE message sent by a Lync client logged in as jeff@mslync.net at 192.168.1.105 which placed a video call to the Lync user testuser1@mslync.net on another computer at 192.168.103.137.  The User-Agent line indicated the client type and version on the caller’s workstation.

From: <sip:jeff@mslync.net>;tag=5514ed4091;epid=e3da4b03d8
To: <sip:testuser1@mslync.net>
Call-ID: cb2839fee0aa41c19103e7e48095cb83
CSeq: 1 INVITE

<snip>

User-Agent: UCCAPI/4.0.7577.314 OC/4.0.7577.314 (Microsoft Lync 2010)

<snip>

o=- 0 0 IN IP4 192.168.1.105

• Yet in the SIP message received back from the endpoint the From and To lines are identical.  But the remote computer’s IP address and the true sender of this message can be identified in the Originator line.  The User-Agent line in the header also indicates a different client version (CU2 versus CU3), further proving the source of the message is not the local client.

From: <sip:jeff@mslync.net>;tag=5514ed4091;epid=e3da4b03d8
To: <sip:testuser1@mslync.net>
Call-ID: cb2839fee0aa41c19103e7e48095cb83
CSeq: 1 INVITE

<snip>

User-Agent: UCCAPI/4.0.7577.280 OC/4.0.7577.280 (Microsoft Lync 2010)

<snip>

o=- 0 0 IN IP4 192.168.1.137

And just because the eye can be deceiving the following screenshots (click either to view larger size) compare the different aspect ratios used between VGA and HD resolutions.  In the left image the first Lync client is displaying an inbound HD video stream, as evident by the measured 16:9 aspect ratio.  In the right image the other Lync client is receiving only VGA as the screen size (using the identical overlaid ruler images) is measured at 16:12, which simplified is 4:3.

The camera preview window also gives a hint to the resolution which is being sent as the different SD and HD aspect ratios can easily be identified when compared side-by-side.

RTV Bitrates and Resolutions

When placing video calls to a Lync-integrated Polycom RealPresence Platform the maximum bit rate for video calls can be controlled be modifying the Line Rate setting in the RMX virtual meeting room’s Conference Profile.

In the following graph the labeled bars indicate the documented bandwidth range for each resolution contained within RTV, yet the darker colored-matched bars across the bottom show which resolution was negotiated when calling from an HD capable Lync client into a virtual meeting room set to each of the recorded Line Rates.

Some interesting behavior was discovered when running these tests, as illustrated by the graph:

• Even though CIF is rated to go as low as 50kbps it required at least 96Kbps to even establish media during the test calls and even then only QCIF was negotiated.
• There exists a very small window were CIF video would be negotiated as calls limited to ~128K would only establish QCIF, while as soon as ~256K was available then VGA would be established.

• VGA calls were established for Line Rates higher than 600K (the documented maximum bitrate) but lower than the 800K required to step-up to HD.  (This does not mean that VGA was using more than 600Kbps in the stream as the Line Rate is simply a maximum allowed.)

• HD 720p was spot-on the documented range as it was not until the maximum rate was raised above 800kbps would 720p be negotiated.