We are continuing to investigate the usage of polycom vvx endpoints with fusion (under duress, not by choice). We very commonly use shared mailbox buttons, parking orbit buttons, and call flows as buttons whose status is indicated by their green/red status or just 'lit vs unlit'.
Everything works as expected on Yealink phones: if someone's in a parking orbit/lot/space then we see that button 'lit', and you can transfer to/from it successfully with the push of a button. Also, shared mailboxes lit when there are unheard VMs, etc., and call flows light up when their status is 'false'.
So far with a VVX 450, parking and a mailbox button work as expected and their lights work/stay working for extended periods.
However, with call flows, the VVX 450 is losing the 'status' of the call flow button after a period of time. (several hours) Meaning that basically overnight, when you return to the phone, the call flow light will be off, but in reality the call flow status will still be set to 'false' in the system. (reminder: the light is ON if the call flow status is 'false', meaning it's sending the call to the alternate destination in the call flow.) If you toggle a call flow true/then false (from the phone), then the light does what it should (lights up).
One other observation is that if the call flow status is changed from within the GUI, neither the polycom or the yealinks update properly. I thought that was strictly just a polycom issue, but latest tests prove otherwise, so this is less of a polycom concern, and probably needs a bug entered...
I'm curious if anyone has any thoughts on what might be behind this, or how to cure? I've tried looking over what VVX documentation I can find to determine if they have some sort of info subscription refresh interval. Or perhaps the module/lua script which creates the status/info needs some love for polycoms?
Any info/assistance/wayfinding/experience here would be greatly appreciated.
Everything works as expected on Yealink phones: if someone's in a parking orbit/lot/space then we see that button 'lit', and you can transfer to/from it successfully with the push of a button. Also, shared mailboxes lit when there are unheard VMs, etc., and call flows light up when their status is 'false'.
So far with a VVX 450, parking and a mailbox button work as expected and their lights work/stay working for extended periods.
However, with call flows, the VVX 450 is losing the 'status' of the call flow button after a period of time. (several hours) Meaning that basically overnight, when you return to the phone, the call flow light will be off, but in reality the call flow status will still be set to 'false' in the system. (reminder: the light is ON if the call flow status is 'false', meaning it's sending the call to the alternate destination in the call flow.) If you toggle a call flow true/then false (from the phone), then the light does what it should (lights up).
One other observation is that if the call flow status is changed from within the GUI, neither the polycom or the yealinks update properly. I thought that was strictly just a polycom issue, but latest tests prove otherwise, so this is less of a polycom concern, and probably needs a bug entered...
I'm curious if anyone has any thoughts on what might be behind this, or how to cure? I've tried looking over what VVX documentation I can find to determine if they have some sort of info subscription refresh interval. Or perhaps the module/lua script which creates the status/info needs some love for polycoms?
Any info/assistance/wayfinding/experience here would be greatly appreciated.