I just “inherited” an operational FreePBX install that a small business is using for their phone system. I fixed most of the obvious strangeness (forced to dial “9” for an outside line, 10-digit dialing for some of the calling area, etc.) but there is one thing that has me baffled, and a search through the available literature isn’t getting me where I need to be.
Note that the intermittent nature of this problem is what seems to vex me. Suggestions greatly appreciated.
Polycom 501 and 650 phones. All of the phones work the same way and do the same things.
IVR problems:
Whenever one of the folks using the phones connects to a remote IVR, the system works flawlessly - until the keypad goes dead. No DTMF, nothing. There doesn’t seem to be a pattern to it - the next time they connect to the same IVR, it may work all the way through, or fail again - it appears random.
Voicemail problems:
Whenever one of them has more than three voicemails, they get the same effect when trying to delete or bypass the third e-mail.
In both cases, the only solution they’ve found is to hang up the phone.
My initial guesses are DTMF mode and something in the dialplan getting in the way. I thought about the inband DTMF setting, but that appears to cause a complete failure of one or the other (vice the intermittent failure they have now). If I change the inband DTMF setting, my research implies that either external IVRs will stop working altogether, or that the CSRs will be unable to retrieve their e-mail.
At this point, though, these are really the only issues the system has, so “install a new version” or other similarly draconian solutions aren’t really viable.
The phones are all loaded with firmware version 3.2.2, so I’m thinking we’re looking at a firmware error on the phone. We confirmed that the phones going dead is actually limited to the 650s - the 3xx phones don’t seem to exhibit this behavior after all.
I talked to the customer, and she wants to bite the bullet and switch all the phones over to use EM. I convinced her that it would be in her best interest to do it so that her “computer guy” (I’m using that term very loosely here) would be able to get onto the server and update the phone configurations.
Thanks for the help on this. Once again, you guys are life-savers.
I installed it, thinking it would make the management of the phones something the customer’s “computer guy” could then handle on his own.
The phones are all configured to use FTP (vice TFTP) and the config files are held in a /home/polycom/phoneXXX directory. Each phone has it’s own sub-directory and each of the files seems to have been “finely crafted” by the previous “techie guy.”
I don’t want to spend all day over there resetting the phones so that they do the smart thing (this, after all, was what TFTP was invented for), but having to manage each and every phone seems like a financial non-starter. It’s going to be about $500 worth of time to reconfigure each phone to get all of their parameters from endpoint manager, and the customer isn’t going to be willing to pay that. Even after that, I’m going to have to set up the phones IN the Endpoint Manager, including the dial-planning and other features that need to be set up.
If you have a suggestion (I can make the argument) that using the EM and a particular set of setting will be the way to solve this problem, I’ll do it.
I have 100’s of Polycom’s out in the field and have never seen this problem.
The “going dead” part is very interesting as the keypress audio is a local phone generated item.
When the phone is in this state do the keypresses register on the Polycom screen?
The next troubleshooting step (assuming you are using RFC2833) is to set RTP debug to the peer when this is going on and see if you see the DTMF events in the RTP stream.
One thing to keep in mind, what Polycom phones are we talking about? Polycom has had some “bum” BOOTROM and firmware releases. You may have one of the problem sets.
Also, FTP is not a bad way to go on the Polycom’s. They default to this out of the box. FTP is more robust than TFTP, especially over VPN’s that may have fragmentation issues. The trick is the phones have a default FTP user and PWD. You need to create this user on the provisioning box and them set that users home directory to the /tftpboot that is used by endpoint manager. Now you can “out of box” a Polycom phone without having to local set it up. If you can run lldp on your Ethernet switch you don’t even have to manually set the VLAN. DHCP option 66 is boot server protocol agnostic.
A finely tuned provisioning system is one key to a professional telephony deployment.
One of my judging criteria of a tech’s work is provisioning and dial plans. If either are wrong it brings all work into question. If someone is actually trying to configure phones for customers using the web interface in the phone itself that is a non-starter for me, it indicates complete incompetence of the tech. I applaud your efforts for wanting to take the time to do this right. It pays off in customer satisfaction in the long run.
Just call me “Mr. Process” Documenting process is the key to pushing Open Source Telephony deeper into the enterprise.
Thanks for letting me use your thread to jump on my soap box.
The “going dead” is just that. Keypresses don’t generate anything to DTMF (to the handset, to the speaker, nothing). I did some quick math, and it looks like it drops off at the 11th or 12th digit. That’s why I was thinking it was something in the Polycom’s dial plan.
On Monday (assuming all things being equal) I’ll pop over and see what’s going on. I don’t have the access to the system for week-end work yet (still trying me out, although the system works A LOT better now then when I picked it up).
As far as provisioning goes, the last guy dropped the phones into the offices and set up the minimum using the web interface and then forced the customer to basically “just deal with it” when it came to things like dialing 9 for an outside line, etc. I spent the first two days on the project just trying to figure out where all the pieces went.
I don’t normally use Polycoms - I’ve always either used Rhino RCB24 cards and real phones, or Cisco. I do enough of either of these Polycom models to get to the point where this kind of weird stuff doesn’t just punt me off my game.
“Process Engineer” was my job title before I retired from the Air Force, so I’m happy to let you up on your soapbox.
Cynjut - I need you to elaborate on the “going dead” part additionally as I am not sure you caught what I was trying to ask.
“Are the kepresses reflected on the Polycom screen when it goes dead”
If I am reading your post correctly the answer to that question is no, the key presses are not reflected on the screen. If I am correct then I do believe this is a BOOTROM/Firmware issue. When you can get onsite we need to look at that data.
If you are truly going to extricate the customer from this situation you need to spend some quality time with the Polycom Administrators guide for the SIP release and see what the phones can do. They have thousands of configuration options. Configured properly they support full line state functionality (the line keys reflect in use, ring and hold on BLF/DSS keys), one touch park, one touch pickup, transfer to voicemail, remapped softkeys etc.
The dial plan is not in effect one the digits are mapped, this is not a dial plan issue.
I’ll check on Monday (the soonest I can get in and check the system). I knew what you were asking, but I didn’t have an answer for you then, or now. I wasn’t paying a lot of attention to the screen when it went dead.
If the keys are not showing up on the display, I’ll double-check the firmware versions and see what they are. A Bootrom/Firmware error wouldn’t surprise me at all.
I started through the Administrator’s Guide once. The fact that there are thousands of configuration options is expectedly daunting and not really a great comfort to me. With thousands of options, it is going to take forever to find out which one config choice is not correct.
As far as the functionality of the unit itself, I am officially impressed with the capabilities of the phone. Several of the units have sidecars, and they work pretty much exactly the way everyone expects them to. On the other hand, the units also seem prone to touchiness - all of those options make the unit flexible, but it also makes it far more complicated than I would expect it needs to be.
I may yet become a fan, but for right now, I’d just like to get one of them working right all the way around.
Well, remember these are designed for system integrators. Not techs and end users. The good news is all the common options go in sip.cfg so once you flesh out a working config you can use it as a template for new installations. I probably have over 100 hours of time invested over the last 4 years in Polycom config writing.
As Andrew’s provisioning manager continues to evolve it will take much of the hard work out of provisioning.
The only manufacturer that has stepped up to the plate and addresses the provisioning issue with open XML scripts is Aastra. They are plug and play.
As far as the sidecars I bet you a steak dinner they are not programmed right. The lights should flash green when ringing, flash red when extension on hold and solid red when in use. Also when flashing green (ringing) you should be able to press the key and pickup the ringing extension.
Actually these issues you state that are happening to your phones are when you are using configurations from firmware 3.3.1+ but you don’t have firmware 3.3.1+ installed on your phones.
Easiest way to fix this issue is to just click “install firmware” inside endpoint manager. Then it will be all good to go
I’m not opposed to using EM - that was why I installed it in the first place.
The problem is that I can’t take the system down for the afternoon and reconfigure all of the phones. Right now, like I said, the configs are all hand crafted for each of the stations. It was done according to a setup guide that the last guy found and used, back when 1.6 first came out.
I’m going to try to get the customer to let me tear down the existing network and (hopefully) rebuild it back to where it should be. It will probably be most of an evening to get everything down to the point where I can use EM to make my life there SO much easier.
On the sidecars: you’re right - they don’t work the way you describe. Anyone with a sidecar has to use the “standard” Asterisk keypresses to pick up a ringing phone. Other than that, it all appears to work the way you described.