Polycom call park retrieve issues since 5.9.x

[DarrenW]

Just a heads up to share this tip which had me and some others scratching their heads. Since Polycom firmwares 5.9.x and later the retrieval of parked calls was failing.

There is another thread here on what looks to be same issue.

Polycom - Valet Park Retrieval quit working with EPM Update

Ok - I am trying to use Sangoma Connect and it told me I had to update EPM to have Connect work correctly - I was on 15.0.24.something (didn’t write it down) and it made me upgrade to 15.0.39.49 - Now Valet-parking quit working - You can park the call when you press the spot BLF-XFER button (automata) but when you try and retrieve it, it acts like you are trying to dial out - WHY???

There is a new setting introduced in these new firmwares that appears to affect call retrieval.
attendant.behaviors.automata.pickupOnBusy, when this is set to it’s default value =“1” parked call retrieval fails. Setting this to “0” reverts to the 5.8.x and older behaviour and allows single key parking and retrieval again.

Hope this helps someone else.

[GSnover]

Genius! Thanks - No one at Polycom seems to know about this - Finally! We can use current firmware again!

Awesome!

[GSnover]

Ok - I just tested, and it works perfectly!

In case anyone needs to implement this fix, you need to add it to the basefiles in Endpoint Manager. Here is what it looks like when it’s done:

  <attendant.behaviors.automata
   attendant.behaviors.automata.pickupOnBusy="0"
   >
  </attendant.behaviors.automata>

So you have to add a Section under attendant.behaviors called automata. Once you have added that, you can add the value above. It goes in features.

Thanks Darren!

[sorvani (Jared Busch)]

This phrase is a question @lgaetz . Whenever new firmware implements a new thing like this, how can we get it implemented into Endpoint manager? While I cannot see the code for EPM, it sure does not ever act like it knows to only use certain things with certain firmware.

Do we just put in a feature request or commercial bug report and then your team adds it and we just hope it don’t break a phone with older firmware?

[lgaetz (Lorne Gaetz)]

As all Polys are uncertified devices, you can just open a ticket requesting the basefile default change and the firmware version be added to EPM.

[GSnover]

I was going to ask this exact question - the endpoint manager for Polycom’s at this point is way out of alignment with a working config for the phones - I have just been manually doing it each time, but it’s tedious (and error prone).

I will put in a ticket this morning for the basefile change and the updated firmware - there is no reason that we should be running the old firmware when (with one tweak) the current firmware works like a dream!

[sorvani (Jared Busch)]

@lgaetz

As all Polys are uncertified devices

That was not the point of the question. Nice evasion.

[lgaetz (Lorne Gaetz)]

@sorvani

That was not the point of the question.

A more complete answer is that, yes, there is a mechanism in EPM that can be used when there is a change in provisioning between firmware versions. It’s a bit cumbersome, and we haven’t used it in a long while now, but essentially there is a Legacy/Current toggle in the EPM template and the admin must be sure to match the toggle setting correctly for the firmware version they’re using. It’s intended for major changes to provisioning file format and is probably not something we would set up for a non-certified device.