Device Review: Jabra GO 6430 OC Wireless Headset

A few weeks ago I started a new job and had to turn in all my UC certified devices to the old employer, which left me needing to pick up some sort of headset for use with Communicator on the road. I took a peek at the Phones and Devices Optimized for Microsoft Office Communicator page and noticed Jabra had a few newly certified devices listed. The Jabra GO 6430 caught my eye mostly because of the  small form factor and sturdy looking design so I decided to give it a shot and placed an order for one.

You can see from the photos below that the device is actually a really nice size.  I’ve had trouble in the past with really small headsets, but I also don’t care for the ones that extend all the way to your mouth. The charging case also doubles nicely as a carrying case, especially for someone who needs to throw a headset in a bag constantly. Unfortunately, the aesthetics are about the only thing Jabra got right. Here are a few photos of the package:







When it arrived I pulled it out, plugged the USB dongle in and tried doing some test calls with Communicator. I placed a call from my mobile to my work number and tried to answer by pressing the multi-function button. It did nothing. Ok, how about outbound? Press the button, and no dial tone. It was as if the button was worthless. Digging a little deeper into the package I found a CD and some documentation (who reads that?) so I popped it in and installed the Jabra Software Suite. After that, I was able to use the multi-function to partially control calls in MOC. For an outbound call I could now get a dial tone by pressing the button, but I still didn’t have much luck with inbound calls. I had some mixed results with the headset either not picking up or it would send the call directly to voicemail, but both were undesirable to say the least.

It only gets worse. Every time I made a settings change within the Jabra suite it seemed take down my entire wireless stack of 802.11 and Bluetooth for a few seconds. At this point I threw in the towel and gave up. Maybe it was my PC, or Windows 7, or some other combination but the bottom line is I shouldn’t have to mess with anything to make these certified devices work flawlessly. I’ve never had issues in the past with any other product, Jabra made or not, but this was unusable. Integrators and especially end-users aren’t going to spend time trying to make these things work – they just expect it to work easily. Giving someone a softphone is already a sensitive subject at times and having a device that flakes out completely ruins any hope of a good user experience. Bottom line: don’t waste your money.

Checking Communicator Endpoint Versions On Your OCS Pools

One of the questions that comes up with OCS deployments that have been around for a while is the question of what clients are connecting to the pool. This can be controlled with client version filters and the auto update feature of R2, but more often than not there are some straggling clients out there. The challenge for those without some sort of configuration management tool is identifying what users have those old clients.

Microsoft has been nice enough to provide a handy tool within the OCS 2007 R2 Management Console that checks what kind of endpoints are connected to your Front-End server. If you open the OCS MMC, click the pool object and then click the database tab you'll see a number of reports you can run. One of the more useful ones is the client version summary. Just press Go next to it and you'll see it return a list of endpoints.

You can see from the results we still have quite a mix, and even someone still using a Communicator 2005 client! This is useful in providing an overall picture of what's been used, but the question I immediately hear next is "Who's using that version?" Unfortunately, there's no easy way to tell in the console. You can run a per-user-report which will tell you the endpoints a particular user is signed in with, but that's going to be a tedious effort to chug through a long list of names trying to find the offenders who haven't updated their clients. You can see below what searching for a single user returns.

In order to answer the question of who's using what we need to run a SQL query against the RTCDyn database. I'll say this is definitely not a recommended/supported task, so be sure you know what you're doing here before you start messing around in SQL Management studio. You have the potential to really hose your OCS installation if you start changing database content. The query we'll run is just a SELECT statement so we shouldn't cause any problems. Still, you've been warned.

Open SQL Management Studio. If you have a standard edition pool you can download and install SQL Management Studio Express for free. Press the New Query button and paste in the following query. Then just press the Execute button. You'll get a list back of SIP URIs along with the endpoint they are currently using.

SELECT CAST([SipHeaderFrom] as varchar) as "SIP URI"
      ,CAST([ClientApp] AS varchar) as "Endpoint"
FROM [rtcdyn].[dbo].[Endpoint]

That will give us a nice long of everything in use and what SIP URI is signed in with that client.

Say we want to filter because we're looking for people with a specific version. In this case, we want to find everyone still using the R1 MOC client so we can add a WHERE clause that searches for strings that match the agent header.

SELECT CAST([SipHeaderFrom] as varchar) as "SIP URI"
      ,CAST([ClientApp] AS varchar) as "Endpoint"
FROM [rtcdyn].[dbo].[Endpoint]
WHERE CAST([ClientApp] as varchar) like '%2.0%'

You could replace that 2.0 with anything else returned in the agent headers such as 3.5, OC, LCC, etc. This only queries the clients that are connected at a specific point in time so you may want to run this from time to time to catch clients that may not have been connected the first time you Hope this helps you identify your clients.

Communicator QoS DSCP Marking on x64 Operating Systems

I never did manage to figure this one out. The registry key HKLM\Software\Microsoft\RTC\Transport\QoSEnabled=1 never seemed to take effect on x64 versions of Vista or Windows 7. Wireshark packet traces would show no tags, but x86 clients worked just fine. Turns out the registry key you need to set for this to work is under the WoW6432Node which makes a ton of sense after seeing it. The DWORD you need to set is this one:


Thanks to Matt McGillen for posting this originally.