After getting a few weeks to decompress from Lync Conference 2014 in Las Vegas here is some feedback on numerous topics which followers of this blog may find interesting.  Some of the information is related to recent product announcements while other items dive deeper into information uncovered from discussions with members of the Microsoft Lync product team and other conference attendees.  While video conferencing is a great adjunct to personal communications there is still no complete replacement for in-person discussion with resources which typically are not freely available.  The value of an industry-wide conference specific to just the Lync product can be measured in a variety of ways and it is highly recommended to attend future occurrences of this conference if at all possible.

Video Interoperability Server (VIS)

Last year Microsoft first made mention of a native, embedded video interoperability service but details were far and few between on what this might actually be.  This year details were still on the light side, but the intent and functionality are a bit more transparent.

During the latest keynote Microsoft showed a live demonstration of a multiparty conference call with Lync 2013 clients and a single Cisco/Tandberg EX video conferencing system.

Little detail was shared on what was actually shown during the demo, other than the capability was reported as to be “released in our next version of Lync Server”.  As no information was shared regarding the delivery of the next release of the Lync product then one can only guess when VIS will be available to the general public.  And by going off what was shown in the demo it appears that VIS will support not just peer-to-peer calls but also dragging SIP-registered video endpoints into a multiparty conference call on the Lync 2013 AVMCU.  The video codec in use in this demo is unknown but even though the Tandberg EX cannot support Scalable Video Coding (SVC) there is a compatibility option in H.264 SVC as implemented in Lync Server 2013 in terms of using basic Advanced Video Coding (AVC) media payloads.  The VIS signaling gateway service embedded in the next Lync version is most likely handling this complexity.  These concepts were first discussed in this previous blog article.

Fellow Lync MVP Adam Jacobs has covered the topic of VIS in a new blog article which discusses the service in more detail as well as relating it to existing third-party solutions already compatible with Lync 2013.

Skype Video

During the keynote Microsoft also demonstrated a capability which was first announced last year in San Diego at Lync Conference 2103: the ability to support peer-to-peer video calling between Lync 2013 and Skype clients.  In the demonstration a video call was placed to a Skype contact in the Lync contact list and similar video behavior one would expect from another Lync client was seen.  The call started off in the small embedded window in low resolution and when maximized to full screen a higher resolution of a widescreen aspect ratio was renegotiated, as shown below.

Currently Microsoft has been supporting peer-to-peer audio calls for time with Lync 2013 clients, but these media sessions are not peer-to-peer.  The audio is actually being transcoded on the backend by a gateway as currently two different audio codecs are in use between the different clients.  This current ‘v1’ infrastructure will be maintained for some time for backward compatibility, but the upcoming ‘v2’ topology will facilitate direct media connections between Lync and Skype clients for both audio and video session, leverage ICE, STUN, and TURN protocols for media establishment assistance.

The video codec at in the demo image above here was definitely H.264 SVC as the most recent releases of Skype clients have already introduced native support for that video codec just as it was implemented in Lync 2013. This means that when the v2 back-end Skype infrastructure is made available to the public then media will be negotiated directly between them. There will be no need for any intermediary servers or gateways to transcode media.

The Lync 2013 clients have already received native support for both narrowband and wideband SILK audio codecs in a previous cumulative update, which will be used for direct audio streams as well.

In short Microsoft has put the latest video codec from Lync (H.264 SVC) into Skype and the latest audio codec from Skype (SILK) into Lync.to facilitate the media codec compatibility required to support peer-to-peer media sessions..

Lync Room Systems

Microsoft originally announced the Lync Room System (LRS) solution at last year’s conference and a few partners demonstrated early pre-release systems at the event in San Diego.  Fast-forward a year later and there are now three established product offerings which come in a variety of display sizes, quantities, and camera configurations.

Polycom has joined the arena with Crestron and SMART (LifeSize no longer offers an LRS product) with a handful of additional bundling options in terms of multiple monitor and camera choices.

The Polycom CX8000 can be purchased unbundled from the displays which are then individually selected from an a la carte menu of qualified touch-panels from Samsung and Perceptive Pixel.  Any size monitors can be selected alone or in pairs.  For the best in-room user experience it is always recommended to utilize dual displays when wall space allows as this provides more screen real estate to use when dealing with multiple modalities.  Dedicating separate screens to content and video or using both screen to display the entire video Gallery view (as shown in the photo above) are what the system was designed to do.

• Single or Dual 55” Perceptive Pixel display
• Single or Dual 65” Samsung Displays
• Single or Dual 82” Perceptive Pixel Displays

Also new is the availability of a center-or-room camera experience in the LRS by bundling the CX5100 ‘RoundTable’ camera which replaces the standard front-of-room USB camera typically mounted above the displays.  This solution provides an improved video experience for far-end participants in both round-table discussions and when an in-room attendee is presenting and/or annotation on one of the main touch-screens and addressing the room attendees.

• Standard “Front of Room” Camera
• Enhanced “Center of Room” CX5100 Panorama Camera

Hidden Real-Time Video Resolutions

In a previous article about HD Video in Lync 2013 the discovery that Lync 2013 had added additional resolutions to RTV was first discussed.  The list of video resolutions supported by the 2013 client for RTV can be seen when reviewing the Session Description Protocol (SDP) portion of SIP INVITE messages during call setup. The m=video portion of the SDP data exposes the different formats the clients are capable of receiving, declaring the capabilities of RTV on the a=x-caps:121 line. The format of each resolution is covered in the previous article in detail, but what is applicable here are the second and third parameters of each entry which lists the width and height in pixels of each resolution. When comparing the lists of supported resolutions between what Lync 2013 clients and 2010 clients declares there are multiple new resolutions in RTV on the Lync 2013 client.

• Lync 2010 Client RTV Receive Capabilities

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

• Lync 2013 Client RTV Receive Capabilities

a=x-caps:121

263:1920:1080:30.0:2000000:1;
4359:1280:720:30.0:1500000:1;
8455:640:480:30.0:600000:1;
12551:640:360:30.0:600000:1;
16647:352:288:15.0:250000:1;
20743:424:240:15.0:250000:1;
24839:176:144:15.0:180000:1

What is interesting is how these new resolutions are not actually used in the current implementation of Lync.

These three new entries include one each for low, standard, and high resolutions all in a widescreen (16:9) aspect ratio.  As only the Lync 2013 clients support these new resolutions then when performing a Lync 2013 to 2010 peer-to-peer video call they are not available because the 2010 client can neither send nor receive these new resolutions. The Lync 2010 client would simply report that it can only accept the original few resolutions and thus the Lync 2013 client will never send video to it using any of the new resolutions. An encoding client cannot send media in a format that the decoding client does not declare as an option.

When Lync 2013 clients participate in peer video calls H.264 SVC will always be used.. So although they both would support receiving those additional RTV resolutions the RTV codec itself would never be utilized.  The same holds true for multiparty conference calls. Although the Lync 2013 AVMCU may support these same RTV resolutions any Lync 2010 or older RTV clients still do not support them. And, just as before, any Lync 2013 clients negotiating video with the Lync 2013 AVMCU will always utilize H.264 SVC.

So what in the heck are these new RTV resolutions included in Lync 2013 for, and why even add them when there appears to be no possible scenario in which they could be used? The answer actually lies within a recently removed configuration parameter in Lync Server 2013 which provided the capability to completely disable H.264 SVC on the Lync 2013 AVMCU for conferences. In the initial RTM version of Lync Server 2013 there was a parameter in the Set-CsMediaConfiguration cmdlet called DisableH264SVC which could be used to disable SVC on the Lync 2013 AVMCU. A restart of the service would be required to trigger the change, but afterward all Lync 2013 clients joining conference calls would utilize only RTV for video.

The obvious indicator to this change would be the loss of Smart Framing as cropping of the video stream was simply centered in the image and would not follow the user’s face. The media quality reports in the Monitoring server would also list the codec as ‘x-rtvc1‘. In these scenarios then the Lync 2013 clients would in theory be able to utilize the additional resolutions when negotiating media with the AVMCU.  As this capability was removed in a recent cumulative update then it is no longer possible to create a scenario in which any of these additional resolutions can be utilized by forcing the use of RTV.