About Me

My photo
This is a blog for John Weber. One of my joys in life is helping others get ahead in life. Content here will be focused on that from this date forward. John was a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). I used to write a variety of articles (https://tsoorad.blogspot.com) on technical issues with a smattering of other interests. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. The opinions expressed on this blog are mine and mine alone.


AudioCodes BToE Preview

I was offered the opportunity to take a look at the upcoming release of the AudioCodes Better Together over Ethernet beta.  Comments here are related to that beta, acknowledging that this is a beta, and I was asked to run it through the ropes (as I see them) and comment.

What is BToE?

BToE is part of the AudioCodes One Voice – a comprehensive offering of tools and devices that enhance the Lync Server environment with gateways, devices, and management to provide (a single neck to choke) an end-to-end set of solutions.  Simply, BToE allows the desktop Lync client to connect to the AudioCodes desk telephone (400HD series) without a USB tether.  There are some phones on the market that do a full USB tether (Lync Phone Edition) – but not everyone wants to spend that type of money for all of their users – one of the key points for Lync is reduced cost.  BToE allows the user to connect the phone to their desktop and essentially make the phone an extension of the Lync client enabling concepts such as click-to-dial and controlling the phone login from the client.

The provided documentation explains BToE thusly:

  • Lets users pair their AudioCodes IP phone with their Microsoft Lync client on their PC or laptop,
    over Ethernet, and from their PC or laptop control phone operations such as answer incoming
    calls, make outgoing calls (click-to-dial), hold and resume calls, and initiate/join an online meeting
    or Lync conference using their Lync client.
  • Allows mirroring of each call on both the AudioCodes IP phone and the PC, so that calls can be
    controlled from either the IP phone or the PC, adding substantial value to AudioCodes unified

Diving in

AudioCodes provided me with application drivers, pre-release firmware and application documentation, and firmware updates for the 420HD, 430HD, and 440HD phones.  I used a 420HD which I happen to have handy right on my desk.  I tested with my corporate account, not using a VPN.  The phone needed  the firmware update, the computer needed the application install, and my brain needs more operation cells – the two I have are already full.  Hey, and this time, proving that even *I* can learn, I actually read the documentation prior to pushing buttons.  Go me!

The firmware upgrade (on a 420HD) was seamless.  Setup an FTP server (I use FileZilla) (you probably already have this in some flavor, or a TFTP if you are running more than a few AudioCodes phones – or anyone else’s Lync phones), setup the DHCP option 160, and away it goes. At phone boot time, the phone reads the DHCP Option 160 data, connects, and upgrades itself, reboots itself, and then it is ready. This took about 2 minutes. Nice.


As a side note, I did not have this setup completely in my lab, which requires a different domain name; I set this up in my operational environment so I could test against a fully live corporate account.

With the phone sitting there waiting for login, I then installed the AudioCodes BToE application. I initially tried to install on a Windows 8.1 – I even tried compatibility mode on the msi.  Nope.  This caused me to open a virtual machine for the remainder of this test. The install was flawless, but only on Windows 7. Oopseyo!.   What about Windows 8.x?  I will assume that this will be addressed prior to actual release – I am not back-revving my core laptop just for this.

Once the application is installed, the documentation walks you through getting the pair code from the phone – according to a briefing given by devs at AudioCodes, this pair code is essentially the phone’s IP address.  Once entered into the application, the code does not go away (nice), but be aware if the phone ever changes IP, that code won’t work anymore.  Also not clear in the documentation was the need for the Lync 2013 client to be logged in first before pairing the phone – or at least that was my experience.  I could be just looking at the process wrong also; but maybe something to be alert to?

(beta) Findings

I would like to see the app minimize to the system tray instead of the task bar, but that could just be me.


For a non-domain joined machine, the BToE application which logs you into the phone did not pick up the need for a separate domain name (in my case my SIP address is different from my UPN).  However, I was able to add it in the dialogue box, at which point the phone just worked.  Login was quick and painless at that point.  Disconnecting the AudioCodes BToE application did not cause the phone to log out.  So you could use this little app to make the phone login much easier as the dial pad data entry can be a real pain.  And remote/external users cannot use PIN auth login like an internal user which forces them to do the dial pad routine, so this app could be right handy in those situations.


Logging out of the PC Lync client left the phone logged in and fully functional.  Nice.  Disconnecting the application from the phone left the phone logged in also.  Nice.

Not so nice, after observing that the Lync client needs to be logged in before pairing the device is that I closed everything, disconnected from the phone, and then rebooted my test Win7 VM.  On restart, the AudioCodes BToE app was already connected to the phone – BEFORE Lync logged in.  This might be because on my test VM I don’t have Lync starting with Windows.  Maybe the app could have a few lines of code added to detect Lync status prior to connected to the phone automatically?

According to the documentation, video calls will not work when BToE paired.  I sure hope this is resolved soon; I am a confirmed video call user – especially when working with customers.  OTOH, click to call works perfectly; start the call using the desktop client, complete the call using the phone device.  SWEET!  The desktop client shows the video device is there; you can use the appropriate Lync buttons to start a video call, the call actually hooks up as expected, but….no audio.

Disappointed smile

All other claimed features worked as advertised.  Click-to-call, transfers, holds, etc.  I really liked be able to click in the PC Lync client to start the call and have my phone functional for the actual call. So nice for us speaker phone talkers.

As an enhancement, and I have no idea how this would work, but if the phone is BToE paired to a full desktop, it would be really cool if the phone’s “personal” directory picked up the clients contact list.

How did it go?

Overall, this beta is impressive in that it delivered (with some minimal hassles) what amounts to a USB phone tether.  Video calls aside, my testing showed that my phone now becomes a fully-enabled Lync device.

One highlight is the ability for the BToE concept to get around the login terror for the remote/external user. This item alone make the AudioCodes BToE worth consideration for those users forced to login to the phone using the traditional phone keypad which requires dexterity, close attention to detail, and brain cells that are not already at capacity.

I could use the BToE right now, even as it exists in this beta.  I saw no stability issues, the app handled the phone as expected, and with the proviso that the app installs on Windows 8.x, I see a net gain for the administration side as well as the user side of the Lync experience.



Lync 2013 Disable Video

So, the customer, for various reasons, wanted to disable video but leave audio enabled.  Usually, the request is to disable audio AND video.

Disabling the audio AND video is pretty straightforward:

set-csuser john.weber –audiovideodisabled $true

But we wanted the audio to be enabled, with just the video turned off.  And we did not want to go mucking around with users disabling cameras, or setting a GPO to turn things off at the driver level, or some other esoteric solution.  What we wanted was to not allow video but allow all other modalities.  And we wanted to be able to undo this solution when the time came to turn video back on.

It would seem that using a Conferencing Policy would be a good choice, but the options offered up by the Lync Control Panel merely control what is available for the conference, not what the individual user can and cannot do P2P or in conference.  Here is what the Lync Control Panel offers:


Handy, but setting this to “Enable IP Audio” did not stop the user from starting a video call in a P2P scenario.




Indicates whether or not computer audio is allowed in the meeting. The default value is True.

This setting applies to the user who organizes the conference: if set to False, no conference created by a user affected by this policy will allow IP audio. However, the user can take part in other conferences where IP audio is allowed.




Indicates whether or not computer video is allowed in the meeting. The default value is True.

This setting applies to the user who organizes the conference: if set to False, no conference created by a user affected by this policy will allow IP video. However, the user can take part in other conferences where IP video is allowed.

But, to Lync, everything is pretty much a conference of one sort or another, so maybe Conferencing Policy can still help us?  Looking down the list of options for a Conferencing Policy we see this little gem:




If True, users will be able to take part in peer-to-peer video conferencing sessions. The default value is False.

This setting is enforced at the per-user level. That means that one user in a peer-to-peer communication session might be allowed to use video while the other user is not.

Now we be cooking with gas!  Be aware though, setting this at the conference policy level DISABLES the camera options in Lync for the users that have been granted the particular policy in question.  As in the video button in the client is gone.  Not just greyed out; gone.

This approach met our needs, but you need to examine the possible impacts to your users – this totally disables video.  With this set to $False, the affected users cannot use video at all, in any modality – even if the Conference Policy is set to “Enable IP audio/video” this attribute disables the local camera and any video.  The user will still get the audio portion of the conference, but no video at all.


test 02 Feb

this is a test it’s only a test this should be a picture