April 11, 2014 by Jeff Schertz · 1 Comment
After spending a Sunday morning upgrading my PC and rewiring my home office I recently tweeted a photo of the end result and quickly had a number of questions about where I got my standing desk. As I originally got the idea by looking at a few other custom-built standing desks online I decided to document the process in case anyone else wishes to build something similar to what I did..
A few coworkers of mine who had previously converted to a standing desk, primarily Mike Stacy, had me convinced to do the same for my home office as my posture was typically poor and the ergonomics of my desk where really never quite what I wanted. There are numerous articles online touting the health benefits of standing versus sitting all day long. Most importantly I’ve found that it is not that standing is technically better than sitting for the same long periods of time but instead the standing workspace effectively untethers me from the chair and allows me to just move around more, either just pacing while on an audio conference call or leaving the office for a few minutes to take occasional breaks. Any spouts of back pain I’ve had over the last number of years are now completely gone after only a few months of using my new desk.
Moving into a new home last fall seemed like as good an excuse as any to give this a shot, but I needed to a place to start. Some online research pointed me towards a couple of popular options which ran the entire spectrum from nearly free to costing almost a thousand dollars.
The easier, but more expensive route was to opt for a purpose-build standing desk, some of which are motorized for alternating between sitting and standing. These can run from $500 (like the UpLift Desk) to over $1200 (like the Anthro Elevate) and are typically not a very large surface either. As much as I liked the idea of a purpose-built solution this was too high of a cost for a small desk that wouldn’t suit my needs without some compromise. The cheaper, but less ideal route used by many others was to simply take my current desk and raise it up on blocks of some sort. Aesthetically speaking I would not like this and I wanted something more permanent, but my old desk was a glass surfaced ‘L’ shaped workstation that didn’t lend itself well to this approach either.
A third option appeared after a little more research which was to build a custom desk, but at a manageable cost and without the need for a crate of woodworking tools and an apprenticeship in furniture building. A large number of people were putting together various IKEA products from their large catalog to design a custom desk that not only doesn’t cost a lot but is easy to assemble and looks pretty nice. An afternoon spent on the IKEA Hackers website gave me the foundation to get started on the design. I found a number of different D.I.Y. articles written by others detailing the build process on their own desks but I couldn’t find one that met my needs exactly, so I borrowed different ideas from various desks to create a hybrid solution that had everything I wanted.
The end result as shown in the photos cost only about $220 and everything was purchased from my local IKEA store. All of the parts selected were available for shipping if you don’t have a store nearby but I did take one preliminary trip to do some brainstorming and measuring before buying all of the components.
For the basic design I used this desk by Thibaut Colar as a template. The main difference is that instead of gluing two smaller square EXPEDIT bookcases together it was easier to simply purchase a single wider bookcase of basically the same overall dimensions. My desk also has a uniform width (59”) from top to bottom by matching a tabletop with the same dimension as the bookcase and the bookshelf. This allowed for the main table supports to be moved out to the corners for better stability. Other differences are that I omitted the feet for my personal height requirement and I also added a custom monitor stand.
For the monitor stand I found Eric McKiddie’s custom desk to be the best option. His design used separate bookcases turned 90 degrees which was an approach I considered but in the end I wanted the cubes facing forward for stashing some of the many IP phones I have in my office.
The overall design also provides plenty of room to hold equipment, keeping everything off the floor. The eight bookcase cubes are perfect for hiding power adapters, routers, switches, and the associated cabling. The 6” height in the space under the main desktop and above the bookcase is also great for either mounting some cable management products or, as in my case, placing a laptop. The space 8” of vertical space at the rear of the desktop and under the monitor stand is also enough room for my IP phones to fit as well as various other USB devices and even my Surface Pro.
The placement of the desktop was pretty arbitrary as it is not centered as seen from the side view of the diagram above. This was done for two reasons: to allow clearance under the desk so that I would not be kicking it with my feet and to provide fore-aft balance by placing the monitors closer to the center of the base.
The ergonomics are also very good on this design (again for me) in my normal standing position. The dual 22” monitors are located at the optimum eye-level which is roughly 2-3 inches below the top of the screen. The ideal distance is also about arms-length to the monitors so I have mine positioned closer to the front of the top shelf to achieve this. Again if you are taller you can push the monitors back a little bit to adjust the distance.
In terms of comfort a quality anti-fatigue standing mat is highly recommended, especially when first starting out after years of sitting. I opted for the Imprint Cumulus 9 gel mat from Imprint after reading a host of reviews online on various different products. Beware of some of the cheaper gel mats on the market as some do not actually contain a gel material.
The following parts will result in a completed desk height of 39” which is just about perfect for my height (5’6”). If you are taller then you can add some adjustable feet like these to the bottom of the main bookshelf to raise the entire desk up the required amount. I’ve noticed that others have mounted large casters to the bottom of these as well which makes moving the entire desk around very easy, if mobility is a requirement. Be aware that not all of the following wood pieces are available in all of the same colors, so if you want to build one in white or one of the faux wood finishes you may have to go hunting around for alternative items. The Black-Brown finish is one of the most popular and almost every component I looked at included that finish as an option.
|EKBY AMUND||Monitor Shelf
59” x 11"
|EKBY TORE||Shelf Bracket
For back of monitor stand
For front of monitor stand
59” x 29 1/2”
|CAPITA||Bracket, angled (2-pack)
31 1/8” x 58 5/8”
I ended up not using the cable organizer but it would fit well under the main table top if desired. I also have not purchased any of the door or drawer inserts yet but am still planning on getting a couple to hide the networking equipment and to hide some of the wiring out of sight.
|SIGNUM||Cable management, horizontal||Silver||302.002.53||$10|
|EXPEDIT||Shelving insert with door
13” x 13”
|EXPEDIT||Shelving insert with 2 drawers
13” x 13”
12 ½” x 13 ¾” x 12 ½”
As with most IKEA products the assembly was quite simple, I just had to improvise in a few places as the overall desk took shape.
Putting together the EXPEDIT bookshelf was exactly as the directions called for and there was no need to modify this piece. The supplied wall brackets were not used but could be if you wanted to secure the entire desk to the wall once completed. In the end I found my design to be plenty stable and would not tip over unless it was purposely pushed or pulled from one side.
Before drilling any holes I approximated the desk and shelf height to give it a test drive and was happy with the layout.
The next step was to drill holes for the six CAPITA angle brackets which support the main desk. I used the black spacers which came with the legs as guides for drilling holes, starting with a small pilot hole and then drilling out the proper hole. Note that the top of the bookshelf is not solid wood, it is a hollow box design.
This was the trickiest part of the build as the length of the welded bolts in the CAPITA leg is too short to clear the entire 2” width of the top of the bookshelf and also allow a nut to be threaded on the bottom to secure it. In fact the bolts are exactly 2” long so they will end up being flush with the bottom of the drilled hole. At first I was worried about this and looked at other articles and forum posts online where people had modified these brackets to accept longer bolts from a hardware store. To be completely secure you can modify the brackets like others have done to accept longer bolts, like in this build (reference photos 1 and 2).
I tested the stability without actually bolting the bottoms of the brackets down as the bolts are still snug in the hole. Once the LINNMON desktop surface was mounted onto the CAPITA legs I noticed that it was were very solid and there was no way I could pry out any of the legs by applying downward pressure on any one side or corner. I suppose if I lifted the entire table top evenly from all corners then it could separate but that is a unrealistic event. Putting pressure on any corner of half only serves to bind the legs on the opposite wide, so in the table is effectively ‘wedged’ into place once assembled.
I had planned to remove the brackets one at a time in the future to mount longer bolts but after nearly 6 months of use, including leaning on the table often, I do not see this as necessary. I just make sure not to ever lift or move it by grabbing the table top, only by handling the bookshelf base.
The next step was mounting the EKBY AMUND shelf for the monitors which started by clamping the EXBY TORE shelf brackets to the table top. There was no drilling or screws required for this first step.
For increased stability I mounted the feet of the EKBY TORE brackets over the metal flange of the CAPITA brackets instead of screwing the plastic feet directly into the table.
The spacing of the CAPITA legs worked out perfectly to do this on all three shelf brackets. This photo also shows how the space below the table to and above the bookshelf is perfect for placing my Quad Core Lenovo W520 laptop and dock. It’s hidden out of sight and is nearly silent, at least when not under heavy CPU loads.
The front supports of the monitor shelf are also unique in that although the straight CAPITA leg upper mounting brackets are screwed into the bottom of the EKBY AMUND monitor shelf these are just legs so no mounting holes are required in the surface of the LINNMON tabletop. This means that the finished result has zero holes in the table so if needed the configuration or layout can be changed without damaging the table surface.
The upper mounts were evenly spaced and screwed into the bottom of the monitor shelf.
The shelf was then mounted and screwed to the EKBY TORE brackets. The CAPITA legs were spun onto the mounting screw and then adjusted to the proper height to support the shelf at a level pitch.
And voila! Our cat seems less impressed than I with the end-result.
It didn’t take long to start filling up space, but I attempted to keep things at a minimum. A single laptop is docked to both monitors as well as a Polycom Group Series 500 video conferencing system and I can alternate between the separate HDMI inputs when needed. A single PoE switch drives the Polycom phones on the table which are registered to a few different Lync environments.
The fixed Polycom EagleEye Acoustic camera was quickly replaced with an EagleEye III 1080p 12x optical Pan/Tilt/Zoom (PTZ) camera but I didn’t have a good mounting option for it. Using the VESA bracket on the back of the monitor was not ideal as I did not want the camera to be mounted to the desk in any way. Any nudge on the desk from bumping it or typing on the keyboard could be seen on video as the camera would sway or vibrate.
Using a few more IKEA parts (EKBY HEMNES / EKBY VALTER) I mounted a simple bookshelf directly to the wall behind the monitors to hold the camera as well as place it at the optimum eye level for video conferencing. The other side of the shelf was a perfect place to put my Wireless Access Point as it is also out of sight but not obstructed in a way that might degrade the signal reach.
And here is how it looks today. Everything on the desk top is functional while the phones stored in the bookshelf below are not actively connected. I can easily swap them out with the devices on the desk when testing new features, firmware, etc.
Also worth noting is that every device on the desktop is actively used with Microsoft Lync in some fashion, from the natively registered Polycom Group 500 video system and CX & VVX IP phones, to the Plantronics, Jabra, and Logitech USB audio and video devices.
April 4, 2014 by Jeff Schertz · Leave a Comment
The next round of quarterly Lync Users Group meetings has been scheduled and announced for this month. The Lync User Group family has now grown to 15 different locations across the country with the addition of two new regional groups this quarter in Charlotte (N.C.) and in Los Angeles.
For a full schedule of regional events the Lync Users Group Locations page lists all current event locations with links to the associated Meetup.com page for each regional group.
Some additional changes have occurred since last quarter in the form of new roles being filled on the Board of Directors for the non-profit UC User Group which manages all of the Lync UG events. I’ve assumed the role of Director of Content for the group and will be chiefly responsible for selection and creation of the presentation material for each event. Joining me on the board are Britt Baubie of Unify Square who has filled the role of Director of Communications and Chad McGreanor of ExtraTeam who has taken up Director of Onboarding duties. As we continue to add one or two new groups every quarter to the LUG family this newly expanded set of roles has helped us deal with the scale and demand we are seeing in the community.
Presentations will be provided on the following two topics:
Lync Conference 2014 “Top Ten”
- The first session will recap the recent Lync Conference in Las Vegas and cover some of the most important and interesting announcements and details from the event.
Advanced Troubleshooting Tools for Lync
- The second session will cover a host of different troubleshooting tools available for Lync Server from Microsoft, third-parties, and the Lync user community.
Industry Experts will be on-site to deliver these presentations and help answer any questions related to Lync. Food, beverages and additional door prizes will be provided courtesy of the Lync Users Group.
As usual I will be hosting the Chicago event downtown. (Please be aware that this event has been temporarily moved to a Wednesday due to limited availability of the MTC on our normal Thursday night spot.)
|Wednesday, April 23rd
5:30PM – Food and Networking
6:00 PM – Presentation Kickoff
|Chicago UC Users Group||Microsoft Technology Center
200 East Randolph Drive, Suite 200
Chicago, IL 60601
March 31, 2014 by Jeff Schertz · 4 Comments
The original intent of this article was to review the current list of supported audio and video codecs in Lync 2013 and attempt to explain what each one is used for given that the list has grown quite a bit over time. But due to the latest announcements around Lync and Skype integration it seems appropriate to first take a closer look at one of these codecs in particular before diving into the rest. This article has been in the works for a while and in the meantime fellow MVP Johan Delimon has also posted a brief article covering just the audio codecs in Lync 2013.
At the latest Lync Conference Microsoft released more details regarding further integration plans between Lync 2013 and Skype. While most of this new information was focused around direct video compatibility with Lync 2013 clients, there will be some advancements in audio calling as well. Last year Microsoft added support for peer-to-peer audio calls between Lync 2013 clients and newer Skype clients. This “Version 1” capability was actually provided by use of media transcoding gateways in the Skype cloud which would allow both clients to utilize their own , unique pre-existing audio codecs. The signaling gateways in the Skype cloud would then facilitate the connections between the different clients allowing each to negotiate a media connection with the media gateways. So even though the calls are basic peer-to-peer scenarios the media must still traverse the Skype back-end infrastructure regardless. So in the event that a Skype user is calling a Lync user on the same network the media would take the long way around and effectively be hairpinned back into the same network.
For native Lync connectivity the topic of media traversal is well documented and the value of negotiating a direct media connection can be quite obvious. The Lync to Skype scenario is quite different though as this use-case is more about bridging enterprise and consumer solutions in which it can be argued that the two clients would rarely be on the same network. Either way, as depicted in the following simplified diagram, the signaling and media paths are basically the same in that they both must traverse the entire backend infrastructure.
There is tremendous value in terms of performance and scale to providing a direct media path between these different client, and Microsoft is moving in that direction. What will be coming sometime this year is the addition of a separate deployment of services in the Skype cloud referred to as ‘Version 2′ which will be deploy side-by-side with the current v1 capabilities. The biggest difference in the v2 design is that there will no longer be a need for media transcoding gateways, only the signaling gateways which translate the Session Initiation Protocol (SIP) and Session Description Protocol (SDP) messages between the different clients. This will allow for the SDP of both clients to be used to setup a direct media path by using the same ICE, STUN, and TURN protocol implementation that Lync does to facilitate a peer media connection.
Since media transcoding is no longer utilized then the clients obviously must have at least one audio and one video codec in common. For video Microsoft has opted to integrate into Skype the same H.264 SVC codec which was first introduced in Lync 2013. This codec has been added to the latest release of Skype clients and functions at the same levels of compatibility as the Lync 2013 clients. Both ends will support the same list of resolutions, frame rates, and temporal scaling layers.
For the audio portion of the call Microsoft has gone the opposite route and actually selected the SILK codec already in use in Skype. Unbeknownst to most users Microsoft already added native support for this audio codec to the Lync 2013 desktop client with a Cumulative Update in November 2013 (CU4). When performing some troubleshooting shortly after that release the new codec declaration was seen hiding in the SDP of the captured SIP messages. At that time there was no information on exactly why SILK was included but it was an safe guess as to the possible intent. Although this support has been added in the Lync clients the codec is not actually being used yet as the back-end signaling has not been updated, so currently audio calls between Lync and Skype are still using the v1 media transcoding gateways.
When Microsoft launces the ‘v2’ infrastructure when not only will H.264 SVC video calling be available between Lync and Skype clients but the media paths will be optimized and SILK will be the audio codec of choice.
Viewing Session Description Protocol
To see the actual list of supported codecs in the Lync client the SIP INVITE messages of a call attempt can be captured and reviewed in one of a few ways. A SIP trace could be captured at the server or client level, but the easiest approach is to simply review the tracing log file created by the Lync client when logging is enabled. This requires no access to any Lync servers and the file can be pulled directly from the client workstation.
- Open the Options menu on the Lync 2013 client and on the General tab set the Logging In Lync parameter to either Light or Full.
- Sign-out and completely exit the Lync client. Open the user’s Tracing folder in explorer using the path shown below. If a Lync-UccApi-0.UccApilog file already exists then delete it.
Deleting this file will provide a clean file to view in the next steps to make it much easier to find the desired SIP message. IF tracing was just enabled and was not previously used then this file may not yet even exist.
- Restart the Lync client and note that a new Lync-UccApi-0.UccApilog file will be created.
- Place a video call to another Lync client and hang up a few seconds after it is confirmed that the call was succesfully established. This will populate the new trace file with some SIP messages that include both audio and video codec declarations.
- Open the Lync-UccApi-0.UccApilog file in Notepad and search for the string “application/sdp” to locate the first SIP message containing Session Description Protocol information.
The first result should also show the text “ms-proxy-2007fallback” under the Content-Disposition line just below. This message is for backward compatibility with any clients or endpoints still utilizing the older implementation of ICE (v6). This section will be skipped over as the next section includes the same declarations and the formatting of some parameters is easier to read.
- Select search again to find the second instance in the same SIP INVITE message which will not include the fallback string in the Content-Disposition line. This message contains support for the more recent implementation of ICE (v19).
The c=IN line lists the IP address of the sender of this message. The SIP messages captured during call setup can include the list of supported receiving capabilities from both parties, depending on the process used to capture the trace. Checking this line helps identify which of the two clients in the call this SDP information was sent by.
The m=audio line defines the media profile, or RTP Audio Video Profile (RTV/AVP), which lists each supported codec by their unique Payload Type identifiers. The order of the identifiers defines the order of preference from left (e.g. 117=most preferred) to right (e.g. 101=least preferred) . Scenarios where more than one codec may be applicable, like with poor network conditions or lower bit rate policy limitations, can result in the use of a less-preferred codec.
- Skip past the a=candidate lines which are used to declare all the potential host IP addresses to attempt to negotiate media paths. Look for the first occurrence of the a=rtpmap lines as this is where the individual audio codecs are further defined.
Each unique codec is initially defined by an individual a=ftpmap line while some may also include a secondary a=fmtp line to set additional parameters specific to that codec. The order that the codecs are declared in the text (top to bottom) also matches the order they are defined in the media profile (left to right).
The ‘rtpmap’ attribute defines the type of Real Time Protocol (RTP) media payload for a specific codec. The following text uses the wideband RTAudio.codec as an example.
a=rtpmap:<payload type> <encoding name>/<clock rate>
- The Payload Type which is unique to each different codec variant is defined as a numeric value placed immediately after the colon.
- The Encoding Name is the common name of the codec.
- The Clock Rate is the numeric value after the slash which defines the sampling frequency used for each codec. Values of ‘8000’ typically indicate a narrowband codec while ‘16000’ defines a wideband codec.
The list of audio codecs in Lync 2013 is quite extensive and has grown over the many different releases of the Communications Server product. When looking directly at SIP messages between two Lync 2013 clients the initial SIP INVITE from the calling party will include the following lines below the m=audio section of the SDP messages.
The following sections do not outline the audio codecs in any specific order of preference. They are simply organized in similar groups, starting with the more commonly used codecs.
Microsoft’s own proprietary audio codec which can be licensed for use in other third-party clients and devices.
RTAudio, as with a few other supported audio codecs, is provided in both narrowband (8 kHz) and wideband (16 kHz) options. The wideband codec is most commonly used in peer-to-peer Lync calls while the narrowband option can be used for either peer Lync calls or in some outbound calling scenarios. In the event that available network bandwidth is limited then instead of sending G.711 directly to a Mediation server for outbound media sessions destined for the Public Switched Telephony Network (PSTN) the Lync client can utilize RTA instead. Although this will provide better quality at a lower bit rate over a poor network it will require that the Mediation Server perform decoding and re-encoding tasks on the media session into G.711 for the PSTN side. In scenarios with plenty of local bandwidth the Lync client will typically send G.711 to the Mediation Server (freeing the server from transcoding duties) or if Media Bypass is applicable then G.711 is sent directly to a media gateway.
These entries advertise compatibility with the industry standard G.711 audio codec used throughout the PSTN. Support for two different common Pulse Code Modulation (PCM) algorithms are denoted as PCMU for G.711 µ-Law (used exclusively in North America and Japan) and PCMA for G.711 A-Law (commonly used throughout the rest of the world).
These codecs can be used in numerous calling scenarios but are most commonly seen in calls with PSTN callers. The most common scenario is when placing a Lync audio call to the PSTN where there is plenty of available bandwidth on the network between the client and the mediation server. As of an earlier Office Communicator R2 release the as-designed behavior here is for the client to simply encode the audio in G.711 so that the Mediation Server is not taxed with having to perform any transcoding; it will simply send the media on to its next hop. In the event that local bandwidth is limited and the Lync client is aware of this it may instead opt to encode the audio in Real-Time Audio (RTA) so that the transmission over the network is more efficient (e.g. lower bit rate) and then the Mediation Server will need to decode the RTV session and re-encode it into G.711 for delivery on to the PSTN. Another common scenario for G.711 usage is when Media Bypass is enabled and the Lync client must encode the audio in a format that a media gateway or whatever is on the other side of a SIP Trunk can understand, which would generally not be a Lync-only codec like RTA.
The Siren family of patented codecs was originally developed by Polycom. The specific variant supported by Lync is also known as ‘Siren 7’ and has been used only for conferencing scenarios for some time in the Communications Server product family. An immediate benefit of Siren is that it provides wideband audio at a low bit rate (16 kbps) making it ideal for large multiparty calls where many audio streams are sent to the same Front End server.
Developed specifically for Skype to replace the older SVOPC audio codec and was introduced in the 4.x release of Skype clients. It has also been extended into the Internet standard Opus audio codec.
a=fmtp:103 useinbandfec=1; usedtx=0
a=fmtp:104 useinbandfec=1; usedtx=0
This pair of narrowband and wideband codecs will be used for Lync 2013 and Skype audio calling in the near future when media transcoding is removed from the topology. As mentioned earlier SILK supports in-band FEC, denoted by the ‘useinbandfec=1’ parameter, meaning that any additional error correction media packets are sent inside the same media payload stream.
A freely available and widely popular wideband audio codec which Lync will use in a few scenarios.
Unlike other wideband codec the clock rate here is incorrectly identified as only 8,000Hz even though the actual sampling rate is 16,000KHz. Johan’s aforementioned article explains this is due to an error in RFC 1890 and Lync must declare the rate this way to support compatibly with other systems.
This codec is primarily used in Lync conference calls when no other Lync clients are participating in the same call. In the event that a single Lync client joins an audio conference call populated with only PSTN attendees then the mixed audio sent by the Lync AVMCU to the sole Lync client will be in G.722.
In scenarios where other Lync clients have joined the same conference call then the Lync ACMVU will fallback to using Siren for the mixed audio streams sent to each Lync client. Constrained bandwidth or high-latency scenarios can also trigger a fallback to Siren regardless of the client types in attendance. A previous article from Lync MVP Curtis Johnstone covers this specific behavior in more depth.
While RTA is primarily used for wideband audio between Lync clients when negotiating peer to peer Lync calls, when other clients, like Lync Qualified phones, negotiate calls with Lync clients then G.722 may need to be used if RTA is not available on the phone. (RTA compatibility is not a Lync Qualification requirement for IP phones, but it is included in Optimized phones running Lync Phone Edition.)
This codec declaration is a newer capability added with the RTM version of Lync 2013 and is designed to support Lync Room System devices which are equipped with two microphones for stereo dual-channel audio pickup.
Just as with G.722 the clock rate here is also defined as ‘8000’ yet again the actual rate is 16,000Hz. The ‘/2’ after the clock rate indicates that this codec has 2 separate channels,for stereo applications. Lync Room Systems utilize this codec to provide for improved audio pickup in conference rooms.
Another supported option from the same family of royalty-free wideband audio codecs. It is not based on G.722 though, it is actually a variant of the Siren 7 codec.
G.726 is an Adaptive Differential Pulse Code Modulation (ADPCM) codec designed to more effectively compress speech than older PCM-based codecs. The specific variant supported by Lync 2013 is a single narrowband (32 kbps) option which results in a lower bit rate stream of comparable quality to G.711 audio. Some of the Lync-compatible IP desk phones natively support this codec and in theory could negotiate G.726 instead of G.711 in constrained bandwidth scenarios.
Comfort Noise (CN)
Utilizing Comfort Noise provides Lync the ability to leverage either a narrowband or wideband options for adding white noise during periods of silence to prevent users from mistakenly thinking that the call connection might have been lost.
Redundant Audio Payload (RED)
RED is utilized for any out-of-band Forward Error Correction (FEC) audio payload. While Lync clients will leverage this codec for error correction needs in native calls the Skype clients do not support this and will use in-band FEC.
Dual-Tone Multi-Frequency (DTMF)
DTMF signaling is used to support the common telephone events of pushing buttons on the dial pad while in a call.
The unique tone created by each key is represented by a value between 0 and 16 as defined by the additional fmtp attribute. The name describes exactly how these tones work in that each button on a traditional telephone produces two simultaneous tones of different frequencies. Each row and column on a standard phone number pad uses a different frequency tone so that 8 unique tones can be used to support 16 different dual-tone patterns.
The supported 16 standard tones come from 0-9, *, #, and four additional tones used by the AUTOVON military application defined as A, B, C, D. RFC 4733 defines only 16 unique values (0-15) so it is unclear why Lync defines a 17th value (0-16).
|1209 Hz||1336 Hz||1477 Hz||1633 Hz|
For example depressing ‘4’ will produce two tones of 1209 Hz and 770 Hz. This is why many of the tones seem to sound the same as all keys in a row or column will use the same tone for one of the two played. This harmony is difficult for the average person to easily differentiate between but a computer can accurately identify each of the two frequencies in play.
The list of video codecs in Lync 2013 is much shorter than the list of supported audio codes by comparison.
- Return to the same spot in the tracing file as shown at the beginning of the last section and then search for the m=video line found immediately below the audio section.
Just as with audio codecs the m=video line uses the same format to list the order of preference by defaulting to H.264 SVC (122) ahead of RTVideo.(121).
This is the Real-Time Video codec which has been supported from the introduction of video calling in the Communications Server platform.
The ‘/90000’ value is used as the clock rate for all video codecs advertised by Lync. As denoted by the preference order above this codec is listed second and will be used in the event that both sides do not support H.264 SVC.
As covered in various other articles the H.264 SVC implementation in Lync is used by default for all native 2013 calling scenarios as well in certain third-party interoperability scenarios (e.g. Polycom Group Series with at least 4.1.3 firmware).
When communicating with legacy clients (e.g. Lync 2010, Office Communicator) and some third-party video conferencing systems (e.g. Polycom HDX) then RTVideo would still be used.
As explained in previous articles and various presentations the implementation of H.264 SVC in Lync is not the basic H.264 codec but is specialized in Lync This unique implementation is advertised to other clients as X-H264UC and thus must be understood by the other client in the call equally. In the additional fmtp declaration statement the ‘packetization-mode=1’ parameter indicates that UCConfig Mode 1 is the maximum scaling mode supported which is the ability to encode two separate temporal layers: a base layer and an enhancement layer. As previously stated the upcoming implementation of Skype will support the same mode.
Uneven Level Protection FEC
This codec is actually used to allow Lync 2013 clients to setup a second RTP session used specifically for out-of-band forward error correction data, separate from the main video stream.
As the ‘uneven’ part of the name suggests this codec will send portions of redundant data when needed as it is not an complete duplicate of the main media stream.
Just as mentioned earlier in the audio codecs section Skype clients do not support this and will instead simply used in-band FEC with the single SVC media session. This entry did not exist in previous versions of Lync so in legacy video call scenarios the Lync 2010 clients utilizing RTV will also embed FEC data in-band.
March 14, 2014 by Jeff Schertz · 6 Comments
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.
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
- Lync 2013 Client RTV Receive Capabilities
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.
February 13, 2014 by Jeff Schertz · 11 Comments
The official Microsoft Lync Room System Deployment Guide covers in detail the creation of a resource mailbox which will be dedicated to each Lync Room system, yet it also includes a number of optional steps as well as the use of separate cmdlets for each individual parameter.
Lync MVP Adam Jacobs has boiled the account creation process down into a simplified list of command in fewer steps, but even those instructions can be further compressed into less steps by stacking parameters into the same cmdlets and using the Exchange cmdlets to also configure the Active Directory users account in the same process. Another Lync MVP Pat Richard has gone so far as to even create a PowerShell script to automate this process.
The following section in this brief article takes the mandatory configuration and combines it into three simple cmdlets. Some additional optional steps are covered separately in the next session.
The first two steps need to be performed on the Exchange Server Command Shell, which includes the creation of the Active Directory user account, enabling it for authentication, and setting a password on the account. Also added was the ability to define the target Organization Unit so that the account does not go into the default Users container, possibly needing to be moved later.
- Create the new resource mailbox replacing the individual parameter values with the desired information specific to the new account.
New-Mailbox –Name "Chicago Meeting Room" –Alias "chicagolrs" –UserPrincipalName "firstname.lastname@example.org" –sAMAccountName "chicagolrs" –Room -RoomMailboxPassword (ConvertTo-SecureString -String “p@5sw0rD” -AsPlainText -Force) -OrganizationalUnit "ou=Resources,dc=schertz,dc=local" -EnableRoomMailboxAccount $true
- Enable the Auto Accept Agent for the mailbox and control how meetings will be displayed on the LRS screen for the sake of privacy. (Technically the AutomateProcessing parameter is optional, but in most cases the mailbox calendar would not be managed manually by an employee.)
Set-CalendarProcessing -Identity "chicagolrs" -AutomateProcessing AutoAccept -AddOrganizerToSubject $false -RemovePrivateProperty $false
The final step must be performed on the Lync Server Management Shell. These cmdlets will enable the new user account in Lync as well as add the Enterprise Voice capability, if so applicable. The optional Domain Controller parameter was added to insure that the same DC is used for each cmdlet to eliminate the potential of errors in the event that the individual commands were to be executed against different DCs which might not yet have replicated the previous changes.
- Enable the account in Lync as a Meeting Room.
Enable-CsMeetingRoom -Identity "chicagolrs" -SipAddress "sip:email@example.com" -domaincontroller "dc1.schertz.local" -RegistrarPool "lync.schertz.local"
The following steps are not required but may be needed based on the desired configuration.
- Using the Exchange Server Management Shell define a Mail Tip to be displayed in Outlook to assist users in remembering that Lync Meetings should be used with this mailbox for the ideal room experience.
Set-Mailbox -Identity "chicagolrs" -MailTip "This room is equipped with Lync Meeting Room (LRS), please make it a Lync Meeting to take advantage of the enhanced meeting experience from LRS”
- Using the Exchange Server Management Shell define the meeting acceptance response text.
Set-CalendarProcessing -Identity "chicagolrs" –AddAdditionalResponse $TRUE –AdditionalResponse “Enter your desired text here”
- Using the Lync Server Management Shell enable Enterprise Voice and define a Telephone URI for the account..
Set-CsMeetingRoom -Identity "chicagolrs" -domaincontroller "dc1.schertz.local" -EnterpriseVoiceEnabled $true -LineURI "tel:+15551234567;ext=4567"
February 12, 2014 by Jeff Schertz · Leave a Comment
The second annual Microsoft Lync Conference will be taking place in Las Vegas next week, but as it has been sold out for some time if you didn’t already know about it then odds are it is too late to get in now. But for those who already have planned to attend there are a number of sessions which may be of interest to the followers of this blog.
I will be presenting a video-focused session entitled “Video – What in the World are You Doing to My Network” which will be delivered on two separate occasions. The majority of this content is brand-new material created for this session but for any attendees of past Lync Users Group meetings throughout North America a few of slides may look familiar
My first session will be presented (in the Copperleaf 12 meeting room) right after the opening keynote on Tuesday morning, so come on by if you can. I will also be fielding any additional questions immediately after the session, as well as spending time in both the Polycom booth right near the Expo center entrance and Lync Users Group booth in the central Microsoft Pavilion.
There are no less than 17 sessions in the topic of Voice and just a few more than that which include some level of content around the video experience in Lync. For video related sessions the following tables can help you decide which events maybe of the most interest to add to your schedule. Please keep in mind that the dates and times for these events could potentially change and this post will most likely not be updated to reflect any changes if they do happen. Make sure to confirm any events you have selected on the official Sessions page. All sessions are 75 minutes long.
Tuesday, Feb 18th
|Video – What in the World are You Doing to My Network?||Jeff Schertz||11:00 AM||Level 300||NETW305|
|Lync Meetings and Edge? Why does it matter? Why do I need it?||John Weber||2:00 PM||Level 300||MEET303|
|Lync Meetings, everywhere you want them to be||Blaine Carpenter
|2:00 PM||Level 200||MEET200|
|Enterprise Networking with Lync 2013: Network Bandwidth and QoS Requirements||Craig Hill
|2:00 PM||Level 300||NETW307|
|Meetings and Media – the detailed view||Johan Delimon
|3:45 PM||Level 400||MEET400|
|What’s New in Lync Meetings||Nikolay Muravlyannikov||3:45 PM||Level 300||MEET300|
|ICE – Edge Media Connectivity in Lync 2013||Thomas Binder||3:45 PM||Level 400||NETW401|
|Lync Feedback: Voice & Video||Panel||5:30 PM||Feedback||LFBK001|
Wednesday, Feb 19th
|Technical deep-dive into Lync-Skype Video||Carl Olivier
|8:30 AM||Level 400||MEET402|
|Lync Room Systems||Anton Krantz
|1:00 PM||Level 200||MEET201|
|Lync Video – Technical Deep Dive||Danny Cheung
|1:00 PM||Level 400||MEET401|
|Insiders Guide to Lync Meetings – Planning, Deployment & Manageability||Marc Perez||2:45 PM||Level 300||MEET301|
|Lync Meetings and Edge? Why does it matter? Why do I need it?||John Weber||2:45 PM||Level 300||MEET303-R|
|A Mile in My Shoes: Microsoft best practices for the largest meetings using Lync||Mike Jordan||4:30 PM||Level 300||MEET306|
Thursday, Feb 20th
|Lync Video – Technical Deep Dive||Danny Cheung
|Planning for PSTN Conferencing||Doug Lawty
|Video – What in the World are You Doing to My Network?||Jeff Schertz||10:45 AM||Level||NETW305-R|
|Video Conferencing Solutions Interoperable with Lync||Adam Jacobs
|Meetings and Media – the detailed view||Johan Delimon
January 7, 2014 by Jeff Schertz · 8 Comments
The first quarterly Lync Users Group meeting of 2014 has been scheduled and announced for this month. The group has grown to 13 different events across the country stretching from New York to the Pacific Northwest.with the addition of events in Seattle, Portland, and Boise this quarter.
As usual I will be hosting the Chicago event. For details on all other events visit the Lync Users Group homepage.
|Chicago UC Users Group||Microsoft Technology Center
200 East Randolph Drive, Suite 200
Chicago, IL 60601
Presentations will be provided on the following two topics:
Centralized Logging Service
- The first session will be presented by a Lync subject matter expert and will cover the ins and outs of the Centralized Logging Service (CLS) which was introduced in Lync Server 2013.
Lync Room System
- The second session provided by Smart Technologies will dive into the Lync Room Edition solution.
Industry Experts will be on site to deliver these presentations and help answer any questions related to Lync Server.
Food, beverages and additional door prizes will be provided courtesy of the Lync Users Group. The food will be ready at 5:30 so come early if you can to spend time socializing with the group before the presentations begin at 6:00.
One lucky attendee from any of the various Lync User Group events this month will win a trip to Lync Conference 2014 in Las Vegas, courtesy of the Lync Users Group.
*Lync Conference trip entry requires attending an in person event on or prior to January 31st, 2014 and completing a survey. Drawing will be conducted February 1st, 2014 and winner will be contacted immediately. Lync user’s group volunteers, sponsors, employees of sponsors and their immediate families are not eligible to win.
December 24, 2013 by Jeff Schertz · 21 Comments
With the recently announced availability of the CX5100 Unified Conference Station this new device will start making an appearance in Lync environments all over the world. The goal of this article is to review changes and improvements in the completely redesigned CX5100 as well as those found in Lync 2013 servers and clients which were added specifically for this new device family.
For the most part this new model is very similar to the older CX5000 models it replaces, yet there are a few major differences between the previous CX5000 and CX5000HD models and the new CX5100 which are helpful to understand before using the new devices. The additional 5500 model is not yet available but it is nearly identical to the 5100 model so the content of this article applies to both new devices.
As a brief history the original Microsoft RoundTable was rebadged as the Polycom CX5000 and sold for numerous years without any major changes. But back in January 2012 a slightly refreshed model was released as the CX5000HD with one simple change to the unit: the inclusion of higher resolution cameras. While the original device was equipped with cameras capable of standard resolution each at best, these new cameras in the HD model were able to encode video at high resolution (720p). Unfortunately the panoramic video stream provided by the Real-Time Video (RTV) codec in Lync 2010, and still in use in Lync 2013, is limited to a single resolution which meant that the higher resolution could only be provided in the active-speaker window and not in the panoramic view. Due to video resolution limitations in Lync 2010 conference calls even that benefit was not achievable though, so the only time HD video was used in this device was during two-party peer video calls, which is not the traditional use-case for these devices.
As Lync 2013 and the new CX models were designed with each other in mind then these limitations are no applicable and thus the capabilities of the devices have increased quite a bit. Aside from any changes in Lync the new devices have greatly improved audio and video components, providing for a better quality experience across the board.
To recognize these benefits it can be helpful to also understand how each model operates in different Lync Server versions. As different as the physical devices are in terms of capabilities it is vital to understand that the version of the Lync client and server used is just as important.
Lync 2010 clients and the AV Conferencing service utilize RTV for all native video which includes a single, low resolution option for the panoramic stream of 1056×144 at a maximum of 15fps.
Regardless of the device used (CX5000, 5000HD, 5100, 5500) the video will be limited to RTV as supported by the Lync 2010 client. The only available panoramic resolution will be used for all devices, while the active speaker window resolution will depend on the specific scenario.
The active speaker window can be displayed in either 4:3 or 16:9 aspect ratios, depending on the device and call scenario. The 4:3 size will be shown in RTV-based Lync multi-party conference calls which are limited to VGA resolution (640×480) regardless of the device. But when using an HD-capable device (CX5000HD/5100/5500) in a peer-to-peer Lync call the active speaker can be shown in either 4:3 (for CIF and VGA resolution) or 16:9 widescreen (for 720p resolution).
Lync 2013 clients and the AV Conferencing service utilize both SVC and RTV for video sessions which provide multiple resolutions and frame rates for the panoramic video. All resolutions now support a maximum frame rate of 30fps but achieving this frame rate is highly dependent on the codec used and the connected workstation’s capabilities. The Lync 2013 client will intelligently select between the available resolutions and frame rates in scenarios with limited processing power, USB bandwidth, or network bandwidth.
In an almost unnoticeable change the Lync 2013 clients and Web App use a slightly taller 20:3 aspect ratio when displaying the panoramic video window, as opposed the to 22:3 ratio used by older Lync 2010, Office Communicator, and Live Meeting clients.
The inclusion of the new SVC codec introduces three separate resolutions available for the panoramic video.
- The lowest resolution (960×144) is also shared by RTV as implemented in Lync 2013 clients and servers and is sometimes referred to as Pano144p. Older RoundTable and CX5000 models are limited to this single resolution when used with Lync 2013. Lync 2013 clients may drop down to this resolution in the event that processing or bandwidth is limited.
- The next two resolutions, Pano192p (1280×192) and Pano288p (1920×288) are only available in SVC and thus can only be achieved with a newer CX5100/5500 device. The older CX5000/5000HD models are only compatible with RTV and thus are limited to using Pano144p when connected to Lync 2013 clients.
With Lync 2013 when SVC is utilized for either peer-to-peer or conference call scenarios the active speaker window can be displayed in as high as 1080p resolution at 16:9 widescreen. The active-speaker window will always be displayed in widescreen inside the gallery view, unlike the default square view of other Lync clients with standard webcams.
Understand that in most cases achieving 1080p is rare, as the inclusion of the panoramic ribbon on the screen uses up additional real estate such as that the displayed primary video window would not be able to scale above 720p on most monitors. As the industry moves towards ultra high definition displays (like 4K) then these types of high-resolution, high-bandwidth scenarios will become more common but for now most Lync video scenarios are using lower resolutions.
As the focus of this article is on the panoramic video experience a few screenshots are in order to show the obvious improvements in quality. As a screenshot cannot demonstrate anything related to frame rate then image quality is all that can be addressed in a simple side-by-side comparison. A combination of improved optics and video codecs produce the final result.
The first image was captured from a Lync 2010 client participating in a Lync Meeting with an original CX5000 device. The image was captured from an RTV video session at 1056×144 resolution.
The second image was captured from a Lync 2013 client participating in a Lync Meeting connected to a new CX5100. This image was captured during an SVC video session at 1920×288 resolution.
In a side-by-side comparison of the panorama video the image quality from the CX5100 is noticeably better, but when zooming in on the images the difference is night and day.
Understand that in order to leverage the higher quality panoramic video a new CX5100/5500 unit and Lync 2013 are required. Using either a newer camera with Lync 2010 or the older CX5000HD with Lync 2013 will not yield anything other than the lowest resolution option.
At first glance the newly redesigned unit looks just like the other latest generation Polycom video solutions right down to the shape and materials. The configuration is quite similar to the original RoundTable though utilizing as the overall design is still a table-top unit with 5 cameras and a separate ‘under the table’ unit, but as opposed to the older model this unit is more than just a power supply.
The notable changes to the table-top camera unit are that t he keypad and display have been removed from the device (the CX5500 will include a touch-screen control panel) and the traditional Polycom form-factor houses only 3 microphones as opposed to the 6 microphones in the older version.
The cameras have been upgraded to units which are capable of displaying up to 1080p at a maximum of 30fps as mentioned earlier.
The privacy cap is no longer a separate piece and is now fixed to the camera head. It is not motorized but is simply opened and closed by lifting up or pushing the cap down by hand.
The base unit contains the most changes as the majority of the video processing intelligence is now contained in this unit. In order to process the higher quality video it was necessary to add a considerable amount of processing power which in turns creates more heat, so a fan has been added to the box. In most scenarios this box would be located under the conference table and out of sight.
The camera unit includes a number of connection jacks hidden on the bottom, in addition to a handy cable-management plate.
- A pair of microphone jacks for supporting up to 2 external microphones. Newly redesigned extension microphones are available separately and although they look similar to the units used in the Polycom Group Series video conferencing system they are not the same and are not interchangeable.
- A proprietary data cable port which in effect tethers the base unit to the camera unit. This cable carries all communications between the camera and base units.
- .A USB 3.0 port which is used for the high-speed USB connection from the base unit to the camera unit. This cable carries the encoded video from the base back to the USB hub in the camera which then passes that data on to the connected Lync workstation.
The sides of the unit also include a pair of USB ports, as well as a physical security locking hole.
- The square USB-B jack is used for the cable which connects to a Windows Lync workstation. The supplied blue USB 3.0 A-to-B cable is used on this port and when connected to a USB 3.0 device is capable of supporting video at up to 30fps. When any USB 1.1 or 2.0 device or cable is used in the connection then lower frame rates will typically be seen.
- The rectangular USB-A jack can be used for maintenance tasks like upgrading the firmware from a USB flash drive. This process will be covered in a later blog article.
On the the base unit the traditional analog telephone connection has been dropped while the following ports are currently available.
- A functional RJ-45 Ethernet jack. In the CX5100 it can be used to provide firmware updates over the network and the CX5500 also uses this Ethernet connection to leverage the VoIP telephony capability.
- A pair of USB 3.0 ports. The encircled USB port adjacent to the data connector and located inside the white rectangle is used for the other end of the USB tether cable from the camera unit. The other port located outside the white box is used for factory maintenance tasks like firmware updates.
- A proprietary data cable port which connects to the data cable from the camera unit..
- The RCA audio jacks are not currently active and are included for possible future use.
The new units are compatible with a brand new management tool: the CX5100 Control Panel Application for Windows. This tool will be covered in greater detail in a later blog article, but briefly the capabilities it provides are much greater than what was possible with older units. Note that this tool is only compatible with the new CX5100/5500 models and cannot be used with older devices.
The control panel application cab be used to manage a USB-connected device directly or it can be used offline to create device profiles which can then be uploaded to a connected device later on.
The main functions of the control panel are to configure various settings on the device and retrieve diagnostic information for troubleshooting any issues. Available options include Ethernet network settings, software updates, the device password, and time/date settings.
There are also some advanced settings, including one very important one which addresses a limitation of the previous mode: video mute. In earlier models pressing the mute key on the device or muting the microphone using the Lync client would also ‘mute’ the video stream from the device by sending a black box with a mute icon instead of the camera images. There was previously no way to change this behavior, but using the Control Panel the new models can be configured to either mimic this behavior or instead only mute audio and leave the video running. Closing the security cap on the camera would then be the ideal way to mute the video stream separately from the audio stream.
Managing firmware updates is also much improved. Earlier models required the use of separate command line utilities for either the Microsoft Roundtable or Polycom CX5000/5000HD models. This management tool was very limited and often difficult to update the firmware with. It also required manually connecting each device to a PC to perform this method as there was no feasible central management solution. (Yes, there was the Windows Updates Services approach but honestly no one ever actually used that.)
With these new models the firmware can either be updated automatically over the network or manually using a USB flash drive. The first method is configured by selecting an update server location and frequency using the control panel. This will trigger the system to perform automatic updates on a set schedule. Alternatively the manual method is as simple as connecting a USB flash drive to a designated maintenance port and waiting for the system to locate the file on its own.
November 28, 2013 by Jeff Schertz · 10 Comments
In a previous article discussing Lync Mobility an important behavior of the 2013 mobile clients was pointed out which was the fact that 2013 mobile clients are effectively hardcoded to always connect to the external UCWA service in Lync. Since this means internally connected mobile clients will hairpin all signaling traffic through a reverse proxy service, it also means that the same hairpining effect is observed in TURN media relays sessions proxied by the Edge Server.
When dealing with internally connected desktop Lync clients and devices these will always open connections directly to the internal Edge interface in order to utilize the ICE/STUN/TURN capabilities of the Edge Server. So in the event that the Edge server must relay media for an internal to external call scenario then the typical media path is from the internal client to the internal Edge interface, through the Edge Server and out its external interface, and finally on to the external client. Or when two internal clients which are separated by a firewall attempt to establish peer to peer media each of these internal clients will connect to the internal Edge Server interface for relay assistance.
But with Lync 2013 mobile clients this story is different.
First, a recap of what the previous article explained. Any internally connected 2013 mobile clients will leverage the external UCWA URL which in a properly configured environment should cause the client to resolve and connect to a reverse proxy service. The actual data path can vary here depending on the network configuration. The connection could be directed out a corporate firewall to the Internet and back in through a different firewall to the reverse proxy server connecting back into the external web service on the Lync Front End server. Or this traffic could be purposely directed to the internal interface of a reverse proxy server listening for the same traffic as on the external interface, which would shorten the trip distance but still be routed to the external web services. Either way the registration traffic and all connectivity between the 2013 mobile client and the Lync Front End server is hairpinned in some fashion.
How does this behavior impact media traffic then? Simply that all connectivity between internal mobile clients and the Edge server will follow the same logic, meaning that these clients will connect to the external interface of the Edge Server just as if they were external clients. It does not mean that all media is hairpinned though. All Lync clients will still attempt direct connections so in the event of internal peer calls or when joining conference calls on the Lync AVMCU media will still be able to be routed directly as long as that traffic path is not filtered in a way to prevent this from happening. In cases where the Edge Server must step-in to assist in relaying the media then the internal mobile clients will be taking the long way around to the external Edge interface.
Internal Peer Call Scenarios
As depicted in the following diagram an internally connected mobile client will perform Autodiscover locally (1) and then use the supplied external UCWA FDQN to locate the published external web services (2). When attempting to establish media between the internal mobile client and another internal Lync client the media will still flow directly between them (3) if allowed by the network.
In the event that the internal Lync clients are unable to negotiate media directly (1), as happens when an internal firewall is filtering the majority of high ports, then the clients will rely on the Edge Server to tunnel the media for them. The mobile client will connect to and send its media session to the external Edge interface (2) while the standard desktop Lync client will simply connect directly to the internal Edge interface (3).
By comparison if the scenario above was between two desktop Lync clients then the media would be flowing entirely through the internal Edge Server interface and nothing would be hairpinned.
Internal to External Peer Call Scenario
When looking at calls between internal mobile clients and actual external or federated clients the mobile client acts no differently. Clearly directly establishing a media session in these scenarios is not possible so the Edge Server must be utilized in some fashion. If TURN is required for media establishment then the mobile client sends its media to the external Edge interface just as in the previous media relay scenario.
This behavior follows the easy to remember theme that Lync 2013 mobile clients are always treated as external clients regardless of the actual network location they connect from. Internally connected mobile clients will never attempt to connect directly to the internal Edge interface because they are acting as external clients and will use the external Edge FQDN just as an actual external client would.
October 31, 2013 by Jeff Schertz · 17 Comments
In a recent article discussing some of the new Lync features in Polycom UCS 5.0 software the capability of Shared Line Appearance, otherwise referred to as ‘Boss-Delegate’ or ‘Boss/Admin’ was briefly introduced. This article includes a more in-depth look at the feature and its usage.
Throughout the article two phones are used to demonstrate the various new calling features available. A VVX 600 is used to represent the Boss phone, which in the example screenshots is located on the left-hand side. On the right-hand side will be the Delegate phone which is a VVX 500.
Lync Server 2010
Microsoft added the capability for Qualified IP Phones to interface with the delegation features in Lync Server 2010 but much later in the product lifecycle. Thus the server needs to be manually configured first with a one-time change which is applied to the backend RTC database. The Delegation for IP Phones white paper includes the instructions, as do other blog articles like this one from fellow Lync MVP Adam Jacobs.
Lync Server 2013
The required SQL database element is already included in Lync Server 2013 by default, so there are no prerequisite steps .
Before any of these features are made available to the devices the desired Lync user account(s) must be configured as Delegates to another Lync account.
- Sign into a Lync Windows client on a workstation using the boss account and then browse to the Tools > Options menu.
- On the Call Forwarding tab enable the Simultaneously Ring option and then choose My Delegates from the menu.
- The Call Forwarding – Delegates window will automatically appear. Click Add to locate and select the desired Lync contact to delegates administrative duties to. Select the desired ring delay setting and click OK.
- Click OK in the remaining Lync – Options window to save the configuration.
Immediately after selecting OK in the previous window the VVX phones signed in as both the boss and the delegate will report a message to the screen indicating the assignment of delegation.
Additionally the delegate’s phone will automatically add a new tile to the home screen for the boss.
Be aware that there may be two tiles on the home screen for the same contact, which happens when the boss was already added as a favorite to the delegate user’s contact list in Lync. The VVX phone will automatically display both Lync contact in the Favorites group as well as contacts in the People I Manage Calls For group.
These two tiles have different purposes and capabilities. The Delegation contact is used to place calls on behalf of the boss and retrieve calls that the boss has placed on hold, and is always listed first. The Favorites contact works the same as any other favorites have in the past and provides one-touch calling as well as contact card details (via long-press) and is always listed after any delegation contacts.
Now that the boss and delegate users are configured for delegation in Lync then the supported features can used.
Call Status Monitoring
A basic feature of typical shared line appearance scenarios is the ability to see the in-call status of the delegate. For the most part much of this is already available in any Lync client or device by virtue of Presence. When a user is in a call any other Lync user allowed to see the presence status (e.g. not blocked) of that user will see red presence for that contact then they are in a call.
But what is not normally possible is to tell if a call is active or on hold. With the new capabilities provided here the VVX phone indicates this status by providing an additional visual cue: a thin vertical red line on the boss’s delegation contact.
In the following example the boss phone (VVX 600) is on an active call with another Lync contact (e.g. VVX 410) and the display on the delegate phone (VVX 500) indicates this with the red vertical bar.
Another new feature is the ability for the delegate to directly pickup a call that the boss has placed on hold. Typically in Lync a user would need to either transfer the call or send it to the parking lot for retrieval by another user.
- The Boss phone places an active call on hold at which time the Boss contact on the Delegate phone begins to flash the red vertical bar.
- The delegate performs a long-press (press-and-hold for one second) on the flashing boss contact to access the call status screen.
- The delegate presses the Pickup button and the held call is moved to the delegate phone.
- When the boss receives an inbound call the call will also ring simultaneously on any assigned delegate’s phones. The inbound call details will scroll information on the main informational line on both phones describing the caller, if delegation is involved, and who the call is intended for.
- If the boss answers the inbound call the delegate phone will display an alert message informing the delegate that the call was answered by the boss.
- Alternatively if the delegate instead answers the inbound call then the boss phone will display a similar alert message announcing that the call was answered by the delegate.
Calling On Behalf Of
- On the delegate phone press or tap once on the line appearance with the boss delegation contact to bring up the standard dialing menu. Calls placed in this manner will be placed on behalf of the boss.
- Place an outbound call to a Lync contact or number. In the following example the extension of a third VVX phone (1236) was dialed.
- The outbound call is clearly identified on the delegate phone as placed on behalf of the selected boss user.
- When the call rings on the additional VVX phone or Lync client it will also be reported as a call placed by the delegate account on behalf of the boss.