Polycom VVX firmware v5 – now with BToE!

As foreshadowed in yesterday’s post on the BToE plug-in / device driver, the new Polycom v5 firmware has landed.

You can download the new firmware and documentation from HERE, where you’ll find the software downloads as well as release notes and the updated Admin guide.

New: October 21st: Firmware 5.0.1 released.

What’s New?

There are many new and enhanced features (all documented in the release notes file). Here are a few that jumped out at me:

  • Better Together over Ethernet (BToE). “Connect your computer to your phone and use your computer to control calls on your phone and PC Lync client”. [Note that wording very carefully].
  • Now supports Lync Call Park
  • Downloads the Lync Address Book
  • Will use Lync for its software upgrades (look for the separate “.CAB” file download)
  • The enhanced feature keys Blind Transfer and Voice Mail Transfer now work correctly
  • Multiple E.911 improvements, including LIS & normalisation
  • The phone now successfully answers an incoming call when it is transferred through the Exchange Auto Attendant

It seems that the stability is likely to be improved, with a generous sprinkling of these sorts of messages:

  • The phone’s touch screen responsiveness after a call or after using an application is improved (applies to VVX 500 and VVX 500) [sic]
  • The graphical user interface response on the phone is improved when the phone is used for a long time
  • In a federation call scenario, the phone now transfers the calls successfully between organizations with two-way audio
  • In a Lync environment, the phone now retains the registration when federated contacts (~60) are added and receives 504 server timeout errors from the server
  • The phone now transfers a call successfully when the language is set to German, Japanese, Chinese, Taiwanese, and Korean
  • In a Lync deployment, the phone’s stability is improved for different network environments
  • The phone now retains the configured language even after a reboot
  • The enhanced feature key $Tinvite now works and no longer causes the phone to reboot [where presumably previously a little light lit up black saying “please do not press this button again”?]

Credit Where it’s Due

MUCH of the FTP update process below is directly lifted from Jeff Schertz’ post (HERE), with my own selective tweaks and deviations along the way (many of which are sourced back to my earlier SoundPoint post – and again Jeff’s efforts).

Installation

Try as I might, I couldn’t get the phone to suck its new firmware from Lync. (There *has* to be a process, otherwise it makes no sense to offer the initial v5 firmware as .CAB files). (Jeff Schertz has since indicated that the 5.0 .cab file is only of any use if you have a Beta version of 5 – from *that* you can upgrade into the released version of 5.0 with the .cab file. So for those of us upgrading from earlier releases: here’s the FTP upgrade process).

Having given up on that, I resorted to the tried and true method of downloading from the FTP server. It’s been a while since I’ve tinkered with the SoundPoint family and its stablemates. My last post on that subject was September last year, when I added Aussie tones, daylight saving time and hotline to the config.

Prep

As with my first foray into the family, I’ve decided to use Filezilla as the FTP server. You’ll also still need XML Notepad 2007, and Notepad++ is a must, just because.

You’ll also need the new firmware. v5 for the VVX500 is HERE. Jeff says “It is recommended to always download the ‘split’ package, the ‘combined’ packages can be ignored)”. Cool.

I’m also taking a couple of short-cuts in the below on the assumption that your deployment already has Aries devices running with PIN-based sign-on, so the DHCPUtil batch file has set the required autodiscovery parameters.

Filezilla/FTP Server

I already have Filezilla installed on my “apps” server here, so I’m going to reuse that this time ‘round. If you’re starting this from scratch, make sure you have the server version and not the client!

      1. Unzip the firmware. I’ve opted to place it all under “C:\Polycom\v5.0.0”
      2. Create two extra directories in there for Logs and Calls:
        FTP-folders
      3. I assume you set Filezilla to run automatically, so run up the “Filezilla Server Interface” and connect to the local server (if prompted). If you chose the conservative option during the install, you’ll find it set to Manual in services.msc, so start it now please
      4. Click Edit / Users and create yourself a new user. We’re going to use DHCP so the phone can automatically locate and login to the FTP server, so we need to use the default name that’s hard-coded in the phone: PlcmSpIp
      5. On the General page, use the same name for the password
      6. On the Shared Folder page, click Add and navigate to the firmware folder. Give your account permission to your firmware folder like the below. In this environment the phones need to download firmware (naturally) and config files and also write back their call and log files, which we’re going to neatly tuck into sub-directories, hence the check against “+ Subdirs”:
        Filezilla-Folders
      7. The last time I visited the family we needed to manually push a bunch of parameters to the phones for Lync integration, but that’s no longer required, as any phone running v4.1.0 firmware or later now already has this “Base profile” built in. All we need to do now is create a new config file that enables this “Lync mode”. Save the following text to a file called “Shared.cfg”:
        <?xml version="1.0" encoding="utf-8" standalone="yes"?>
        <!-- Sample Polycom Shared configuration file for UCS -->
        <LYNC>
        <device device.set="1" device.baseProfile.set="1" device.baseProfile="Lync"/>
        </LYNC>
      8. If you now view this file in XML notepad, it should look like this:
        XML-shared.cfg
      9. Now let’s edit the default config file to alert the phone(s) to the presence of the folders & Lync settings. Open “000000000000.cfg” in XML Notepad and add the entries I’ve highlighted in yellow:
        XML-000000.cfg
      10. Save the file and exit XML Notepad. (We’ll come back to it later).

DHCP

In my earlier posts I manually pointed the phone to the FTP server. This time I’m aiming to automate this process as much as possible, using DHCP to point them to the FTP server.

      1. Launch the DHCP MMC.
      2. Expand the tree and right-click Set Predefined Options as shown below:
        DHCP-SetPredefOptions
      3. Now click Add and create a new option type:
        NewPredefinedOptionType
        This value needs to be of Data type String. Here I’ve shown the Code as 160, which is the default for phones delivered with SIP firmware. (The name and description don’t need to be exactly what is used here)
      4. Click OK twice to return to the DHCP MMC.
      5. Now right-click on your chosen section (either Scope Options or Server Options) and click Configure Options:
        DHCP-ServerOptions
      6. Scroll to what’s probably the bottom of the list, select the UCS Boot Server option we created above & enter an ftp string to reach your ftp server:
        DHCP-ServerOptions2
        The string value needs to be in the format “ftp://<FQDN>”
      7. Now REPEAT steps 2-6, using a new name and specifying Code 161 in Step 3. Newer phones arriving with the Lync firmware already on them now look for Option 161, so it’s better to cater for both possibilities by having both present in your DHCP config.
      8. Ensure that DHCP options 2 and 42 are set correctly. The phones will need to find an NTP server (option 42), and the offset from GMT/UTC (option 2) gives us the right time zone. I assume this is a working installation so I’m expecting you already have those active.

Showtime!

Let’s give it a whirl and see what happens. If your phone hasn’t been reconfigured away from the default settings, a reboot should be all we need to get it to suck all the new firmware. If it doesn’t (and Filezilla’s log doesn’t report failed attempts at contact from the phone) it’s best to restore it to factory settings: Settings / Advanced / 456 / Admin Settings / Reset to Defaults & then options 1, 2, 3 & 5 in that order.

For me to kick this off, all I needed to do was login to the phone and tell it to reboot. The rest just happened:

IMG_1583 IMG_1587 IMG_1588
IMG_1589 IMG_1590 IMG_1591
IMG_1592 IMG_1593 IMG_1594
IMG_1595 IMG_1596 IMG_1597
IMG_1598 IMG_1599 IMG_1601
IMG_1603 IMG_1604 IMG_1605
IMG_1606 IMG_1607 IMG_1608

 

And we’re up. We have a phone – but it’s not logged-in yet.

Click More: IMG_1609 Click PIN Auth: IMG_1611 Give it some credentials and click Sign in: IMG_1613
 IMG_1614 It thinks about it for a sec:IMG_1615 … and then it’s me:IMG_1616
IMG_1617

And here’s my home screen, with my top three contacts visible:

IMG_1618

To prove a point, let’s double-check. Select Home / Settings / Status / Platform / Application / Main:

IMG_1619

Now what???

BToE is the must-have feature in this version, so having previously installed the device driver on the PC, let’s tie the two together. (I blogged the fairly vanilla install process here).

Press Home & then Settings:IMG_1622 3 Features:IMG_1623 5 BTOE:IMG_1624
1 BTOE (Disabled):IMG_1625 We’re disabled by default, so click Enabled and then Back:IMG_1626  IMG_1627
Now click Pairing Status:IMG_1628  IMG_1629 IMG_1630
Whoops. OK, let’s run the plugin on the PC and try that again…IMG_1633 IMG_1634 Yay! Note that we have the BTOE option on the menu now:IMG_1636

 

The PC confirms we’re paired:

BTOE-paired

So does Lync:

BTOE-PrimaryDevice

Here’s me testing the process, killing two birds by seeing what Mum’s up to.

Of interest is that the Lync client is now showing the call in “participant view” – something you’re more used to seeing when you’re in a meeting. I’m a fan of consistency, and this might grate with some users & upset some sysadmins. Change to a headset or back to the CX300 and a call to the same destination is rendered differently:

BToE

CX300

TestCall-mum TestCall-mum2

 

Thankfully, whilst it might LOOK like it’s a conference call, it’s not:

PS C:\> Get-CsWindowsService

Status   Name            ActivityLevel
------   ----            -------------
Running  W3SVC
Running  MASTER
Running  REPLICA
Running  RTCCLSAGT
Running  RTCSRV          Incoming Requests per Second=0,Messages in Server=0,Incoming Messages Held=0
Running  RTCCAA          Concurrent Calls=0
Running  RTCCAS          Concurrent Conferences=0
Running  RTCRGS          Current Active Calls=0
Running  RTCPDPAUTH
Running  RTCPDPCORE      Active Client Connections=0,Active Edge Connections=0
Running  RTCCPS          Total Parked Calls=0
Running  RTCATS          Current Active Calls=0
Running  RTCIMMCU        Active Conferences=0,Connected Users=0
Running  RTCDATAMCU      Active Conferences=0
Running  RTCAVMCU        Number of Conferences=0,Number of Users=0
Running  RTCASMCU        Active Conferences=0,Connected Users=0
Running  RTCMEDSRV       Current Outbound Calls=1,Current Inbound Calls=0,Current Outbound Priority Calls=0,Current Inbound Prio...
Running  FTA
Running  RTCXMPPTGW
Running  RTCCHAT

 

And here’s the now-discarded CX300, which announces my betrayal of it with “Active on another device”:

IMG_1651

Call Park

I thought I’d see what the Call Park process looks like. It works well:

1 IMG_1638-edit 2 IMG_1639-edit
3 IMG_1640-edit 4 IMG_1641-edit

Customising it for Oz

Out of the box the phone defaults to US tones and cadences, but as I’ve blogged before, that’s not so hard to fix.

We need to revisit the FTP server. Paste the following text into a new file we’ll call “customisations.cfg”:

<?xml version="1.0" encoding="utf-8"?>
<customisations>
<tone>
<tone.chord>
<tone.chord.callProg>
<tone.chord.callProg.busyTone>
<tone.chord.callProg.busyTone.freq tone.chord.callProg.busyTone.freq.1="425" tone.chord.callProg.busyTone.freq.2="425" />
<tone.chord.callProg.busyTone.level tone.chord.callProg.busyTone.level.1="-20" tone.chord.callProg.busyTone.level.2="-20" />
<tone.chord.callProg.busyTone.onDur tone.chord.callProg.busyTone.onDur="0" />
<tone.chord.callProg.busyTone.offDur tone.chord.callProg.busyTone.offDur="0" />
<tone.chord.callProg.busyTone.repeat tone.chord.callProg.busyTone.repeat="1" />
</tone.chord.callProg.busyTone>
<tone.chord.callProg.reorder>
<tone.chord.callProg.reorder.freq tone.chord.callProg.reorder.freq.1="425" tone.chord.callProg.reorder.freq.2="425" />
<tone.chord.callProg.reorder.level tone.chord.callProg.reorder.level.1="-20" tone.chord.callProg.reorder.level.2="-20" />
<tone.chord.callProg.reorder.onDur tone.chord.callProg.reorder.onDur="0" />
<tone.chord.callProg.reorder.offDur tone.chord.callProg.reorder.offDur="0" />
<tone.chord.callProg.reorder.repeat tone.chord.callProg.reorder.repeat="1" />
</tone.chord.callProg.reorder>
<tone.chord.callProg.dialTone>
<tone.chord.callProg.dialTone.freq tone.chord.callProg.dialTone.freq.1="400" tone.chord.callProg.dialTone.freq.2="425" />
<tone.chord.callProg.dialTone.level tone.chord.callProg.dialTone.level.1="-12" tone.chord.callProg.dialTone.level.2="-12" />
</tone.chord.callProg.dialTone>
<tone.chord.callProg.ringback>
<tone.chord.callProg.ringback.freq tone.chord.callProg.ringback.freq.1="450" tone.chord.callProg.ringback.freq.2="400" />
<tone.chord.callProg.ringback.level tone.chord.callProg.ringback.level.1="-20" tone.chord.callProg.ringback.level.2="-20" />
<tone.chord.callProg.ringback.onDur tone.chord.callProg.ringback.onDur="0" />
<tone.chord.callProg.ringback.offDur tone.chord.callProg.ringback.offDur="0" />
<tone.chord.callProg.ringback.repeat tone.chord.callProg.ringback.repeat="1" />
</tone.chord.callProg.ringback>
</tone.chord.callProg>
</tone.chord>
</tone>
<se>
<se.pat>
<se.pat.callProg>
<se.pat.callProg.ringback>
<se.pat.callProg.ringback.inst se.pat.callProg.ringback.inst.1.type="silence" se.pat.callProg.ringback.inst.1.value="200" se.pat.callProg.ringback.inst.2.param="400" se.pat.callProg.ringback.inst.2.type="chord" se.pat.callProg.ringback.inst.2.value="ringback" se.pat.callProg.ringback.inst.3.type="silence" se.pat.callProg.ringback.inst.3.value="200" se.pat.callProg.ringback.inst.4.param="400" se.pat.callProg.ringback.inst.4.type="chord" se.pat.callProg.ringback.inst.4.value="ringback" se.pat.callProg.ringback.inst.5.type="silence" se.pat.callProg.ringback.inst.5.value="1800" se.pat.callProg.ringback.inst.6.type="branch" se.pat.callProg.ringback.inst.6.value="-4" />
</se.pat.callProg.ringback>
<se.pat.callProg.busyTone>
<se.pat.callProg.busyTone.inst se.pat.callProg.busyTone.inst.1.type="silence" se.pat.callProg.busyTone.inst.1.value="375" se.pat.callProg.busyTone.inst.2.param="375" se.pat.callProg.busyTone.inst.2.type="chord" se.pat.callProg.busyTone.inst.2.value="busyTone" se.pat.callProg.busyTone.inst.3.type="branch" se.pat.callProg.busyTone.inst.3.value="-2" />
</se.pat.callProg.busyTone>
<se.pat.callProg.reorder>
<se.pat.callProg.reorder.inst se.pat.callProg.reorder.inst.1.type="silence" se.pat.callProg.reorder.inst.1.value="375" se.pat.callProg.reorder.inst.2.param="375" se.pat.callProg.reorder.inst.2.type="chord" se.pat.callProg.reorder.inst.2.value="reorder" se.pat.callProg.reorder.inst.3.type="branch" se.pat.callProg.reorder.inst.3.value="-2" />
</se.pat.callProg.reorder>
</se.pat.callProg>
</se.pat>
</se>
</customisations>

Now add a reference to this file in the “000<blah>.cfg” file we edited in Step 9 earlier:

XML-000000 customisations.cfg

Don’t overlook the comma between “shared.cfg” & “customisations.cfg”.

Now just reboot the phone and all should be fine – although I found I needed to go though the increasingly tedious pairing process on the phone to re-establish BToE.

Summary

Despite the initial road-bump of not being able to load the firmware through Lync, we got there eventually.

I like the look and feel of the VVX500. With this update it’s just become my primary phone here in the greiginsydney home office, and I look forward to putting it through its paces. There is no shortage of options detailed in the Admin guide, and as I shop through those in the coming weeks I’ll update the “customisations” file with my preferred tweaks and share those…

The requirement for the user’s PC to be directly tethered to the phone is a minor annoyance, and it’s sure to upset those running in a VDI environment. Polycom has indicated a goal in the next update to extend the reach of BToE to a client running on other networks, and when they can pull that off there’ll be no stopping them!

I don’t know if the need to re-pair is something I’ve not yet found in the Admin guide, but that’s the only other thing that’s failed to impress me thus far.

 

As always, special thanks to Rocky for the photos.

Revision History

24th September 2018: update the XML Notepad link to the Github version.
22nd May 2015: Updated to add the new entry for Code 161 in the DHCP section.
8th Sept 2013: This is the initial post

 

G.

Leave a Reply

Your email address will not be published.

... and please just confirm for me that you're not a bot first: Time limit is exhausted. Please reload the CAPTCHA.

This site uses Akismet to reduce spam. Learn how your comment data is processed.