Can't answer calls on VVX500 w/expansion module

[Anonymous]

’ve got a weird situation on a site with a handful of Polycom VVX500 phones (5.8.0), two of which have sidecars (x100 & x101). A ring group is set up in FreePBX 13/Asterisk 13.10 to ring all phones, but one of the sidecar phones (x101) can’t pick up the incoming call. Lifting the handset or pressing the speakerphone button just gives a dial tone as if the extension were idle. If that extension is called direct, it works as expected - it’s only an issue when the call comes in through the ring group.

And here’s the kicker, when the order of the extensions in the ring group is changed, and x101 is put at the top of the list, above x100, the extension can answer calls, but now x101 can’t.

All of the extensions are monitored on the sidecars, and I’m thinking it has something to do with the way the calls coming into the other extensions are showing up on the display “before” the call to the extension in question. I haven’t yet found anything in the provisioning file that might affect it.

Can someone point me in the right direction? Yes, Steffen, I've searched the FAQ and the forums. 😉 Maybe my search-fu stinks, but I'm coming up with zilch. It's probably something simple, but I'm at a loss.

Thanks!

[SteffenBaierUK]

Hello @PCS-Brad,

welcome back to the Polycom Community.

Both the community's Must Read First and the community's FAQ reference the basic minimum information a new or follow up post should contain.

This ensures the questions having to be asked are limited and any new or follow up post contains the right amount of details to ensure any voluntary participant within the community does not spend additional time chasing basic information.

As a reminder the basic information asked for:

• Provide the exact Software Version of your Phone
• Provide the Phone Model
• Provide the Call Platform (aka openSIP,Skype for Business Online, Skype for Business on Premise, Lync)
• Additional Polycom Infrastructure (RPRM,PDMS or BToE)
• If applicable provide a backup of the phone in question

UC Software 4.0.0 or later via the Web Interface Utilities > Phone Backup & Restore > Phone Backup > Phone Backup

• If possible provide a Log and either attach them or use the Code Tag.Consult the Troubleshooting Section found within the FAQ if applicable
• If possible provide the MAC Address or Serial of the device
• Provide details if the issue is a day 1 issue or only happened after an upgrade or any other relevant details

Whilst providing some of these details may not directly impact any possible answer the community can provide, it does enable Polycom to have an overview of the current software used. In addition other details allow us to check logs or look up a potential support partners if an issue needs to come into support. It also enables us to verify the entitlement for using features.

Please ensure you always check the FAQ's and/or utilize the community search before posting any new topics or follow up post’s.

Jan 19, 2012 Question: How to troubleshoot Polycom VoIP related Issues?

Resolution: Please check => here <=

and

May 12, 2016 Question:Are there any limitations on Hunt Group's or BLF / Busy Lamp Field?

Resolution: Please check => here <= 

and

Nov 4, 2011 Question: How can I setup a Busy Lamp Field / BLF with an Digium Asterisk SIP Server?

Resolution: Please check => here <=

Additional questions:

• What type of BLF are you using?
  attendant.uri or attendant.resourceList
  
  
• Are you using any form of flexible line key?
• Day 1 issue or recently started?

Most likely we would need some logs but for myself this is outside the scope of this community.

I assume you know the drill to get this into Engineering

Please ensure to provide some feedback if this reply has helped you so other users can profit from your experience.

Best Regards

Steffen Baier

Polycom Global Services

[Anonymous]

Hi Steffen,

I've been unable to re-address this issue until today.

After setting up a couple of test extensions offsite, I was able to duplicate the issue, and more importantly, apparently solve the issue.

To answer your questions:

The phone is running 5.8.1.7278. Upgrading to 5.8.2.4732 made no difference.

We are using attendant.resourceList BLFs

We are using flexible line keys

I should note that the mis-behavior only happened when the other extensions in the ring group were monitored on the VVX500.

The apparent issue was the attendant.resourceList.X.type was set to "normal". When this was changed to "automata" for all the monitored extensions, the expected behavior asserted itself.

I understand that the normal/automata type determines what a BLF line key does during an active call (place active call on hold before dialing selected BLF phone vs. transferring the active call to the resource), but I don't see anything in the Admin Guide that indicates why the behavior I was seeing would occur. Can you explain this?

Is this what the attendant.behaviors.display.spontaneousCallAppearances.normal/.automata affect? If so, both .normal and .automata were set to 0 on the attendant consoles where we had the issue.

My problem is fixed. Now I'm just trying to understand WHY this fixed my problem, and to understand more about these mystical and mysterious devices. Y'know, sometimes my wife is easier to understand than my Polycom phones. 😉