Latest distro, everything registers but Polycoms

Yesterday a customer’s older FreePBX box died due to a bad hard drive. I replaced the drive and rebuilt the box up with the lastest 64 distro (STABLE – 10.13.66).

They have mostly Polycom Soundpoint IP 501’s which I can’t get to register to save my life. My Bria soft-phone register fine to the same accounts. The 5 newer Grandstream phones register fine with no issues.

I thought maybe the Polycom’s were having a hard time with the new pjsip so I changed on of the extensions (actually deleted and re-created) to chan sip.

I couldn’t really see any errors from the extension while it was pjsip and I am not familiar with how to get the console to show those for pjsip, it just happens with chan sip.

Anyhow, I changed the one Polycom over to chan sip, changed the port on the Polycom to match the port chan sip runs on. I then started getting mis-matched username errors in the Asterisk CLI. The username and password are correct, I checked and double checked many times. It complains and says something like "Have <100> digest has <'T>.

Totally confused and head well beaten against the wall after a few hours of messing with this, searching google, this forum and others.

Since Chan SIP didn’t seem to make any difference I put the extension back on pjsip but now I don’t see any registration errors in the CLI like I do with CHAN SIP. I do know that the extension is still not registering though.

I will try to keep my personal opinions and all the times I have nightmares with Polycom’s to myself but, all I am sayin’ is that the Grandstreams and soft phones just needed a freakin’ password update to match the new password in FreePBX and they are all working. Polycom’s hours later, still dead in the water with no logical explanation.

Thanks for any help, I am ready to go home for the night once I get these Polycoms working.

OK, I found the very handy “pjsip set logger on” command. With this I was able to see the packets.

If you look in the packet below you can see that the Polycom just isn’t sending a username, that’s what it looks like to me anyhow. Thoughts?

It of course sends an “Unauthorized” back.

<— Received SIP request (789 bytes) from UDP: —>
Via: SIP/2.0/UDP;branch=z9hG4bKb3d9e8c39D56FD7C
From: “8004” sip:[email protected];tag=D9FF270A-2415B851
To: sip:[email protected]
Call-ID: [email protected]
User-Agent: PolycomSoundPointIP-SPIP_501-UA/
ÐÌÌÌorization: Digest username=“¸
”, realm=“asterisk”, nonce=“1468113625/d88efe092a95e82323582b95a06247a0”, qop=auth, cnonce=“2NOdNc0KjreqFze”, nc=00000001, opaque=“6d750f0b23e1fad7”, uri=“sip:”, response=“7a790f1338671a1c8256df01bfc8a4b6”, algorithm=MD5
Max-Forwards: 70
Expires: 600
Content-Length: 0

For what it’s worth… Based on my past experience with tons of Polycom’s that do really odd things when you try to provision them using the phone’s web interface. I think what’s happening is that when I set the new password on the phone in the web interface, it’s getting harfed up and not really being applied to the sip account under line 1. This is causing the password to be sent to Asterisk as garbage.

I have gone through the pain staking process today of learning how to provision Polycom’s via tftp and learning their file formats and procedures. OK, I have a lot to learn still but, I have successfully loaded firmware and a config from a tftp server. So, I am not at my customer site to test right now but, I am hoping when I can get back there and re-config a phone via tftp, it will set the password correct on the phone and everything will work.

Have to see… I will update post when I know more.

Turns out, I was basically correct. Nothing wrong with FreePBX at all. The Polycom phones where basically doing what I have seen in the past with the web interface screwing things up.

I am to the point where I just don’t want to use the web interface on these phone ever, at all. They have on more than one occasion proven to be VERY wacky. Ultimately, I had to set the username/password on line 1 on the web interface on the phone and let the phone reboot (that doesn’t fix it), then set the username and password on the phone itself with the keypad, then reboot. After the second reboot, the phones register and work fine.

The odd thing is, just setting the SIP username/password on the phone itself and rebooting doesn’t do the trick and doing it only on the web interface doesn’t do the trick, I have to do both for it to work.

WOW! Seriously, I fixed like 8 phones using this same method, if I went off the technic even a little, it wouldn’t register.

Go figure… Once again, the biggest thing I have learned here is that I will continue to work with Polycom phones only when forced and the option to replace them is not available.

Ah, my arch nemesis once again attempts to ruin someone else’s life. :smile:

1 Like

Have you tried using End Point Manager to provision the Polycom handsets. I recently installed about 30 Polycom phones (not the same model but the VVX310) using EMP and they worked fine. However I think I agree with you generally that Polycom phones can be a nightmare!

Yes, I have tried the free end point manager but it was riddled with errors and problems. It’s flat out broke and I am sure there is no motivation for the devs to fix the free version since there is now a paid version. Can’t justify to customer in terms of purchasing the end point manager, they just don’t have enough need for it at their size.

The devs don’t work on the OSS parts of the system. If you want the OSS EPM fixed, you need to pitch in. This is a community supported system, especially this part.

Yes, I am well aware. I was only pointing out that there wouldn’t be much motivation for anyone at Sangoma to fix the open source version when they sell a commercial version of the end point manager and I can’t say I blame them. I have never used either other than trying to use it to fix the problem I originally posted in this thread.

When/if I have a reasonable need for an end point manager in FreePBX, I will just build the commercial version into the cost of the system and pass it on to the customer. After all, the less time I spend messaging with phones manually, the cheaper it is for them in the long run.