Can't answer calls on VVX500 w/expansion module

Occasional Advisor

Can't answer calls on VVX500 w/expansion module

’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!

Message 1 of 3
2 REPLIES
Polycom Employee & Community Manager

Re: Can't answer calls on VVX500 w/expansion module

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

Please be aware:

The purpose of these forums is to allow community members collaborate and help each other.
Questions posted here do not follow Polycom’s SLA guidelines.
If you require assistance from Polycom technical support, please open a
web service request or call us .

The above is necessary in order to track issue internally within Polycom.

You are welcome to post more questions or configuration or logs for other community members to look at but if your issue requires a fix via Polycom you must go via the official support structure.

Please ensure you always check the VoIP , Video Endpoint , Skype for Business , PSTN or RPM FAQ's

Please remember, if you see a post that helped you , and it answers your question, please mark it as an "Accept as Solution".

This forum reply or post is based upon my personal experience and does not reflect the opinion or view of my employer.
Polycom employee participation within this community is not mandatory and any post or FAQ article provided by myself is done either during my working hours or outside working hours, in my private time, and may be answered on weekends, bank holidays or personal holidays.
Message 2 of 3
Occasional Advisor

Re: Can't answer calls on VVX500 w/expansion module

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. ;)

Message 3 of 3