I have a FreePBX 15.0.37.9 server and a FreePBX 17.0.19.13 server. I am migrating users from the 15 to the 17, but oddly, the first time I tried to connect some grandstream phones to it, they register OK, receive calls OK, but making any outbound calls just gets 401 Unauthorized. I did a packet capture on the phone itself and the pcap isn’t super helpful. According to the PBX there was never an attempt to connect.
To make things more interesting, at the site with the Grandstream GXP 2160s that don’t connect, there is a Cisco SPA504G which I also set up with EPM and that one worked fine. It’s just the grandstreams that don’t work. I also have HT802s at other locations that I connected to this new FPBX17 server and they work fine, but I connected an HT814 and it was also unable to dial out. This HT814 is connected to the FPBX15 server no problem.
I’m at a loss. Any ideas? (I have suggested replacing with all Yealink)
First thing I would try is downloading and installing GS Wave on an Android cell phone (this is Grandstream’s free softphone app for Android) and trying it out. It works fine with Asterisk you don’t need a Grandstream PBX for it.
I have a Grandstream GXP 1450 in my test phone pile and I pulled it out and plugged it in, intending to try configuring it with FreePBX 17. (It’s been years since I played with it) I kid you not, the phone sat there with a blank screen for 3 minutes with power applied before suddenly booting. (I DON’T think the build quality of these phones is very good) I don’t know if it was bad electrolytic caps in the phone or what. It COULD be the auto-upgrade firmware feature of the phone, I turned that off after logging into the phone.
Anyway, I did provision it on my FreePBX 17 system and made and recieved calls on it just fine with a Cisco softphone, here’s a pic
Note that the phone does not show the password in the webinterface once you submit it. This is firmware 1.0.8.9 on the phone.
I don’t know what you got invested in these phone but the Polycom VVX series phones is dirt cheap on Ebay and extremely compatible with very high quality build quality.
Incidentally, I don’t use EPM, I manually provision. In the case of these GXP phones, what I would do is take one of them, delete out all the provisioning in EPM for it, then factory reset the phone, access the webinterface (default password admin) then manually provision the phone and then download the config file as config.txt then renaming it cfgMACADDRESS of the phone and sticking it on the tftp server. Make sure the phone is working - then make a backup copy of the confg file, and then run EPM and have EPM generate a config file for the phone - and then compare the two. I’m betting that EPM on FreePBX 17 as botched up the config file for the phone. Possibly, the programmers who wrote EPM were using different firmware loads for the phones when they write EPM than you are running on your phones.
Yes, one of my users has VVX410s he got free from a law firm that closed and switched from Cisco SPA504G to those. I had quite a time getting them on the latest firmware but I figured it out and posted a howto.
I have a Grandstream GXP1760W that also works fine, and the HT802 works fine, but the HT814 did not works fine, and it’s a mystery. I like your diffing the confs idea. I don’t have any spare GXP2160s on hand but we’re swapping some out for Yealink SIP-T46U next week so I will test then and report back. I did see one website say it’s the extra headers, but that doesn’t make any sense.
That is either because Custom SIP Settings only exists in that older firmware that the one website is showing or because it’s on a special custom firmware possibly released for Gradstream-PBX-bound phones. It does not exist as a menu item in the 1.0.8.9 firmware on my phone.
I just logged into a phone and those options are there, so your phone is not a great test phone for this case. It would be interesting to have a HCL for FPBX and the EPM but that is a community project for which I do not have the ability.
Your first post does not indicate an authentication problem. The 401 is merely a challenge for auth. The subsequent INVITE presumably had an Authorization header and Asterisk proceeded with the call. I’m guessing that the 183 was playing an error such as “your call cannot be completed as dialed”, probably because the phone formatted the number incorrectly or calling restrictions for ext. 505 were incorrectly set. After the 8-second message, a 503 was sent. However, something else was also wrong (codecs, local network settings), so you heard silence during that interval.
Please turn on pjsip logger, paste the Asterisk log for a failing call at pastebin.com and post the link here.
And did you turn them off like the other website recommended?
“custom SIP headers” sounds like a politically correct term for “proprietary Grandstream SIP modifications” Grandstream does sell PBXes and one problem with the SIP protocol is that a lot of extra features are NOT defined in it, so if a manufacturer wants to add on extra features to telephones it sort of encourages them to make additions to the protocol that may make it work in a non-standard way.
A lot of the problem here is that I pulled a Bill O’Reilly, F it, we’ll test in prod. Once some devices become available for testing I will try the suggested things.
Thanks for all the advice. I will report back later in the week.
All of those P- headers are RFC compliant headers that numerous SIP networks can use and do use. The x-switch-info header is also used by many vendors from Polycom, Grandstream and even Cisco. It actually can be used by any SIP network. There are also other X- headers though I’m not sure if those are considered deprecated theses days or not. As well other vendors offer the ability to send a MAC header from their devices.
None of these headers are proprietary to a single vendor. Asterisk could very well handle using those headers if desired by the admin/person writing the dialplan and configurations for an Asterisk deployment.
Here are my updates. I installed several Yealink SIP-T46U today, no issues at this site. Tested a grandstream on the FPBX17 server again to see if it was maybe an intermittent issue, no, fails with 7, 10, and 11 digit dialing, which all worked on the Yealink. So I took a GXP2160 home and just re-provisioned it to the FPBX17 server… no problems.
So, what would cause Yealink and Cisco to work, Grandstream to not work, but on another network the grandstream works fine? Keeping in mind that the Grandstream worked fine on FPBX15 still on PJSIP. What other tests should I perform, I’m going to go to a site where it doesn’t work and sit and try to debug this issue.
Yes, I saw. However, your premise has changed. Previously, you were trying to figure out how to fix it. Now, you are trying to figure out how to break it! (more accurately, how the non-working PBX has broken it)
You can generate wireguard traces from a PBX that works with this phone. So now, generate one from a broken PBX with this phone and compare it to see what’s different.
