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.


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


VGA : 15 fps : 600Kbps
CIF  : 15 fps : 250Kbps
QCIF : 15fps : 180Kbps


HD720p  : 13fps : 768Kbps
VGA : 30fps : 600Kbps
CIF  : 15fps : 250Kbps
QCIF : 15fps :  180Kbps


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.


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.

o=- 0 0 IN IP4
c=IN IP4
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 at which placed a video call to the Lync user on another computer at  The User-Agent line indicated the client type and version on the caller’s workstation.

From: <>;tag=5514ed4091;epid=e3da4b03d8
To: <>
Call-ID: cb2839fee0aa41c19103e7e48095cb83


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


o=- 0 0 IN IP4

  • 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: <>;tag=5514ed4091;epid=e3da4b03d8
To: <>
Call-ID: cb2839fee0aa41c19103e7e48095cb83


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


o=- 0 0 IN IP4

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.

image    image

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.

By Jeff Schertz

Site Administrator

41 thoughts on “HD Video in Lync”
  1. Another great post from Jeff 🙂
    The Lync/OCS Resource Kit is a good source but you show with real life examples.
    This is real usefull when you try to explain do customers how and why quality is affected by hardware choices.

  2. Wow, what a great post! Thank you Jeff!
    I have enabled HD in our enterprise deployment, but we cannot get HD quality. I have done testing using 2 machines with i7 (quad core) processors and MS LifeCam Studio webcams.
    Looking at our Lync client logs, I get this:
    m=video 32328 RTP/SAVP 121 34
    a=x-caps:121 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
    a=x-caps:34 262:352:288:15.0:250000:1;4358:176:144:15.0:180000:1
    I have no idea why our bitrate is stuck at 768Kbs… any help would be highly appreciated!

    1. What endpoints are in that call? Both Lync, or Lync and a third-party endpoint? Although the x-caps offer for that endpoint shows HD receive as a capability something else is limiting the other party to sending only VGA. Maybe a defined CAC policy?

    2. The reason why your 720p call is limited to 768kbit is, that your so-called "HD" Lifecam cinema in reality cannot do HD as you would expect. If you have the box of your webcam, you can see the marketing term: "up to 30 FPS". The experienced geek immediately recognizes the trick: framerate DEPENDS on the actual conditions, so 30FPS is not always reachable. Look closely the x-caps, you will definitely see: 1280×720 13 FPS(!) was used. Why? Because these cheap HD webcams are "soft-webcams" (similar to the "soft-modems" used in the late 90s). All the coding of the video pixels is done in software by the CPU. That means uncompressed raw pixels must travel through the USB2 bus from the webcam to the CPU. And that is the point where your USB2 bus theoritical max. bandwidth (480 Mbit/sec) will become the bottleneck in this story. Soft-webcams cannot pump 720@30FPS through USB2, only real hardware webcams can.

      1. True, although the x-caps designation you see in SDP is the endpoint's advertised receive capabilities which are related to the core count and not the capabilities of the encoding camera. Hence the value of a dedicated HD hardware platform encoding and sending true 30fps video into a desktop which can then decode and display that, even if it cannot reciprocate at the same frame rate (or even resolution). The 13fps shown in a native Lync-to-Lync call is reflective of the dual-core limitation placed into the Lync client, where as quad-core systems will advertise 30fps even if the USB camera isn't up to the task of actually pulling it off on it's own.

  3. Your blog was a very interesting read and very informative. I spent the day working with a customer on testing peer-to-peer HD video between a Polycom CX7000 and some 4 core and 2 core PC's. We could consistently get 720p from the CX7000 to the 4 core PC's based on the VQReportEvent data. However, we could only get VGA to the 2 core PC's based on the VQReportEvent data.

    The "x-caps" data for the 4 core PC was as expected:
    a=x-caps:121 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

    As well as for the 2 core PC:
    a=x-caps:121 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

    What is really interesting is that the the video from the CX7000 displayed on either of the PC clients was always in 16:9 aspect ratio (without borders) no matter the size of the video display window (full screen, integrated in the IM windows or in pop-out mode expanded in size). I ensured that at the end of the video call the VQReportEvent would have the highest resolution used by leaving the PC client in full screen mode for the video and closing the call from the CX7000. The 4 core PC always received 720p 16:9 aspect ration, while the 2 core PC's always received VGA 16:9 aspect ratio.

    Have you been able to get a 2 core PC to receive 720p video as reported in the VQReportEvent at the close of the call? I haven't been able to get any of the customers 2 core PC's to do so.

    1. Greg, do you have (or have you ever had ) CAC enabled? Also note that native Lync to Lync calls (including the CX7000) can sometimes be displayed in a 16:9 window yet still be a VGA call, the clients will crop the video window to fit. I'm not sure how or why Lync does this, but in calls to an HDX or RMX this will never happen as the display window aspect ratio should strictly adhere to the source resolution (4:3 or 16:9).

  4. hi Jeff
    Really Impressive and clear post , i have read this one many times and got enough benefits
    for now i am trying to test HD or even VGA call between Lync Clients.i could not achieve this for a configuration of one lync client on 4 core PC and other i7 PC.but Video Quality was not good.looking at both lync loggs i saw X-caps like this:
    a=x-caps:121 263:1280:720:30.0:1500000:1
    i even tried to have Video p2p call with HDX 6000 with Software version but when i called and checked call information on HDX i saw only CIF,ofcourse i don't have RTV License on HDX and just wanted to see 4CIF but not happened.lastly i checked our monitoring reports and inside User activity when i checked p2p video call,Video Stream (Caller -> Callee) and Video Stream (Callee -> Caller) was h263 … ! what does this means ?
    i cannot even get VGA Quality
    by the way Global media Configuration set to hd720p15m too

    1. If the RTV license is not included on the HDX then calls with Lync are limited to using H.263 which is a completely different video codec. Although the H.263 standard supports various low and standard resolutions the implementation of H.263 in the Windows Lync client oly supports CIF resolution, hence the H.263/CIF quality that you are seeing. The only way to utilize other resolutions is to use RTV, which requires an Options Key in the HDX. Also the video quality issues you are seeing in the PC to PC calls might be related to the optics, some make sure you are using Lync Optimized devices and not just the built-in cameras on laptops for example.

      1. thanks for Clarification of H263 Codec. i didn't see this kind of codec definition in any documentation or just missed comments on this one.tomorrow i will receive Life-cam Pro 3000 HD and i hope to receive HD resolution on one side of PC2PC call.
        i ll post result here asap.

        1. Any High-Definition resolution (or even standard resolution) will only be available if RTV is utilized by both endpoints, so if H.263 is the only compatible codec in a specific call then CIF resolution is the best you will see regardless of the optics or hardware used.

  5. Hi Jeff,

    Just found this post – great info.

    I am currently configuring my Cisco router QoS to support Lync, and I need to know which RTP Payload Types to match on for audio and video in Lync.

    I want to match these payload types using this command on Cisco routers for that I can give them the proper QoS treatment:

    'match protocol rtp payload-type <pt-type>'

    From your post, I should match on PT=121 for video – I that correct?

    But for audio, which value should I match on for RTA ??? Is it 97? Or other??

    Thanks very much for your help in advance.


  6. I'm curious, how do you even get video into Lync from a professional source (like a broadcast camera)
    I will be using HDMI as my source for audio and video.

    1. Good question, I've not seen this done directly. Using standards-based video conferencing equipment you can bridge a Lync call with a system capable of accepting a professional camera input source.

        1. The Polycom Group Series endpoints have HDMI inputs and are supported for native Lync 2010 interoperability today.

  7. […] In Office Communications Server 2005 and Lync Server 2010 the usage of high definition video was straightforward.  The Real-Time Video (RTV) codec used primarily throughout those client and server versions provides for only a single HD resolution at 720p and was utilized in very specific scenarios, as documented in this previous article. […]

    1. Cisco/Tandberg systems do not support RTV unless you've added the additional Advanced Media Gateway (AMG). Without that extra box to transcode RTV to H.264/AVC then you'll only be able to negotiate video to Lync 2010 clients at CIF using the H.263 codec. Lync 2013 clients no longer support the older H.263 codec so video is not possible today without using the AMG.

  8. We have HDX 8000 with software version 3.1.2. We have RTV licence keys installed Its registered with Lync 2013. I can joinLync Hosted meeting But the problem is that video send/recieved is CIF.

    Anyone help on this ?

    1. Video should be at a maximum of VGA in that scenario. Firstly, are you positive that it's actually CIF? The only way to know for sure is to check the Monitoring Reports; it could be reported incorrectly on the HDX statistics page. Secondly RTV in t he Lync AVMCU is a least common denominator experience so if any other endpoint joins the meeting and is unable to send higher than CIF video than all participants will be brought down to that lower resolution. Also, it's possible that CAC or some other bandwidth limitations are limiting the bit rate to CIF quality video in RTV.

      1. I have a 2 Polycom RealPresence 500 with an RTV license and it is also registered with the lync server. I have checked CAC and bandwidth policy and it's set to Global policy (which hasn't been changed)

        I am also getting the same issue as Samir where it uses CIF when initiating a Lync Client call to the Polycom kit. Polycom to Polycom call uses 720p. Would I be right in saying that 720p is possible in a Lync to Lync client call? but, Lync client to third party kit will always default to VGA?? Sounds to me like a Polycom firmware update Jeff??


        1. When utilizing RTV the VGA limitation only comes into play for calls hosted on the Lync AVMCU. Calls to the Polycom MCU are in essence peer-to-peer Lync calls and all RTV resolutions are available. You should open a support ticket if the video is only reaching CIF in either direction. That being said I would expect VGA in those scenarios as RTV 720p is difficult to achieve in Lync due to the processing requirements (quad-core). The RMX also defaults to sending VGA at 30fps versus HD at 15fps (opting for motion or sharpness) but you can control this behavior. Search the Administrators Guide for 'MAX_RTV_RESOLUTION' for more details.

  9. I was wondering if limiting the Video for Video Conferencing also changes it for desktop sharing? We have many Mac users in our environment with retina displays and when they share, it is almost always a desktop share. If we could reduce the resolution that is broadcast from these laptops using the same commands, it would solve my issues greatly!

    Thank you

    Eric Drabert

  10. Excellent summary. Should be required reading for all enterprise sys admin and mobile video conference techs.

    Do you have any insights on the impact of the next generation of digital video object architecture CODECs on secure mobile platforms.

    This architecture has significantly better and broader capabilies than the legacy h263/264 – p8/p9 simple bit pump analog CODECs.

    Thx for sharing the excellent analysis!

  11. Hello Jeff,

    Great Article as always… We have Lync 2013 Infrastructure with many users with Lync 2013 clients with Skype Ui and also configured IWB (Interactive White Boards Skype UI engine) from RICOH. When a Video Meeting initiated by IWB and Skype UI user is joined the aspect ratio keeps changing from 4:3 to 16:9 based on movements of a person in Conference room.

    Similarly when Skype UI generates a meeting and Lync user joins same behavior sometimes 4:3 or 16:9 depending on the movement of the person.
    Also after checking the UCCAPI logs of skype UI client- found 1280:70 as client capabilities. But seems to be getting no where.
    Your Inputs would be highl;y appreciated !!!

  12. Hello Jeff!

    Thank you for this incredible post full of information…

    I am late, ahah, but do you know this problem?:

    We have a Polycom infrastructure (RMX DMA…) and a Lync Server.

    But when the Skype client dial into a Dma’s VMR, the quality isn’t good.

    But that s ok between polycom to polycom or Skype to Skype.

    I am going to check the Line Rate in RMX. But I would like to know if you know this problem and if you know how to solve it?

    Thank you by advance even if you don’t have the answer 😀


    1. Hi Johan – did you ever resolve this issue? We have something similar in that we see a lot of video frames freezing on the cascade link – Skype to Polycom on the RMX. Thanks

Leave a Reply

Your email address will not be published. Required fields are marked *