I apologize. The equivalent options for that on GXV324 and GXP2170 are Validate Certificate Chain and Validate Hostname in Certificate respectively.
21 days since this post, are you close to a firmware release? Several of my clients are eagerly awaiting this firmware update to resolve the freezing issue.
I apologize for the delay. However, some problems were discovered during Q&A for the build with the fix, and more time is needed for testing. Unfortunately, I cannot provide the ETA for it at this time.
Firmware 22.214.171.124 not recording queue when making incoming calls…
Pls fix it.
My issue turned out being with my switch config. I reconfigured adding an ip helper-address pointing to the DHCP (my firewall) and also used both options 66 and 43, now all seems well. Only issue was that I had to offset the time zone by 1 hour on the NTP as the time kept being an hour behind.
you could kindly let others who read the forum understand, what exactly did you do to solve?
Hi, was just editing to give some more detail.
Okay, thank you, then just tune it in.
I just finished deploying 2 additional servers to try my best to transparently integrate directory users into the system. Since I’d be dealing with 3 servers a lot of crazy-complicated routing and overkill security on the endpoints and network because there’s no authentication to speak of in order to achieve this. It’s blindly trusted peering all over.
Also, as a result I had to remap all extensions and make extensions aliases so the old numbers are reachable while they transition into the new ones that match user and number correctly in Active Directory.
I read big headlines about the new firmware supporting new, possibly-unheard-before, exotic characters so I decided to give it a go, it was that or deciphering how on earth that XML phonebook works to which there is no documentation. Same as what are the email and storage sections for in the Zero Config section, BTW, if it’s for the users, it shouldn’t be batch-configured, if it’s for the admin shouldn’t the system the data from the system itself?–Oh well.
Anyway, so I’m configuring the LDAP phonebook and I went straight to where the problem has always been, the username. It asks for the full DN, which if filled correctly, it will include spaces, a character not accepted in the box. I’ve used the DN in other servers, and it’s always accepted with spaces. Not here.
I didn’t have my hopes up so I wasn’t expecting anything, therefore no biggie. Then I remember, LDAP uses a similar address scheme to HTTP, so what if I URL-encode it? I looked it up and my the first hits I got were straight from Oracle with tons of examples. Now, I had my hopes up and:
Are you kidding me? You found the time to add another piece of bloat, some CRM thing–I read on the release notes, but not to have directory support?
Well…Active Directory, my LDAP backend accepts credentials formatted in at least 5 different ways, like sAMAccountName:
userPrincipalName and sAMAccountName@NetBIOSDomainName:
What about the mysterious new characters that are now accepted?:
The offending character is a . (period) by the way.
Lastly, I didn’t need to as the CA is already imported system-wide, but I was being thorough:
How do you expect for users to use all this? Extension numbers for everyone with yet more credentials to lose on Post-Its? And why must the certificate use a special extension? Or any extension at all. Isn’t this running Linux in the background?
Do you have some high ranking in-house executive/engineer whose job is to make everyone’s life convoluted and pointless? He/she should get a raise. Top notch.
Are you following any set of standards, RFCs, anything? Microsoft breaks a lot of things for many nefarious reasons, sure. But when it comes to AD there’s not much else. Freshly installed RHEL/Fedora systems bind in seconds to AD, without having to add certs, Red Hat is behind FreeIPA, which is about the best Linux-equivalent for the LDAPpy AD-like thing. Why must the UCM care how credentials are sent as the supplicant? That’s for AD, OpenLDAP or what-have-you to interpret. Plus, for over 20 years servers have been accepting requests with spaces on them, they just escape them, URL-encode them or pull some trick from somewhere. This isn’t even binding, just trying to get a phonebook.
“X Client CA Cert” is extremely ambiguous by the way. It sounds like a subordinate CA. If it’s not an authority-meant certificate, that uppercase A should be nowhere near. Asking for a key right below sort of confirm it’s not a root CA but also makes room to believe maybe it’s a subordinate instead.
I installed this firmware last night and now am locked out again. I do have a backup, so I can factory reset if needed, but I definitely don’t want to do that and be locked out again when it comes up with my other settings. Is there a fix for this?
depends on what the problem is, the new firmware does not create that problem
Well, it definitely did.
I updated from 126.96.36.199 to 188.8.131.52 and lost access, I was using the default password from my UCM6202 which is printed on the back and I can no longer use it to log in.
Is there another way than factory resetting?
EDIT: I’m able to log in through SSH yet not through web
Refresh browser cache (CTRL+F5 usually do job).
You looking in OLD login which prevent you from log.
Seems like cache has nothing to do with it, I had to factory reset and start from scratch.
You skipped a lot of version (which are needed for keeping settings).
Usually FR is needed after you skip version as structure is not correctly inside UCM.
I apologize for what I am about to write, but I just finished watching the third season of Designated Survivor, so I’m a little pumped up.
@grandstream, what is wrong with you (as a company)? You have hundreds, if not thousands of people on this forum willing and able (and proven) to be beta testers for you and your software. You roll out firmware releases with no warning, no method, no schedule, and no input from the public on what new features should be added, what features should be updated, and what features should be removed. Your “fixes” tend to be “breaks” and you constantly change p-codes so that configuration files from firmware version X are no longer valid on firmware version Y.
Don’t get me started on the inconsistencies of p-codes in the first place. But I’ve started, so I’ll continue. They’re completely lacking in any real ability to provide computer-generated configuration files. Look at Cisco. Look at Polycom. These are your competitors. They use XML-based files that are not simply “p-codes in XML format.” They are actual XML with configuration names that mean something and can survive being used on different model phones without changing anything. It’s time to get rid of p-codes.
Back to firmware.
Why does a version get released that changes basic functionality and then, when brought to your attention, gets the response, “some problems were discovered during Q&A for the build with the fix, and more time is needed for testing.” WHY WASN’T THE TESTING DONE BEFORE THE THING WAS RELEASED IN THE FIRST PLACE? That’s what beta testing is for. That’s what QA is for. Testing in production is for 1990s “dot com bubble companies.” You should be above that. Beyond that.
Until you start wearing big-boy pants and behaving like big-boy companies, Grandstream devices will always be seen as second-rate behind Cisco, Polycom, Avaya, and even the once “last of the pack” Yealink and newcomers like Sangoma and Digium.
PLEASE get your act together and actually create a release methodology that doesn’t include doing beta testing in production with real customers. And I say this as someone who has beta tested dozens of Grandstream devices and runs a company that sells hundreds of Grandstream devices. If we don’t feel comfortable in our product selection choice, we will change to a provider we are comfortable with.
I just upgrade and now LDAP is not working
I had the same problem (I also reported it with a ticket), LDAP with 184.108.40.206 did not work, then I went to 220.127.116.11 and resumed to work LDAP.
At that point I put back 18.104.22.168 and it continued to work.
It seems obvious to me that 22.214.171.124 has problems with LDAP as I am not the only one who has encountered this problem.
Probably the anomaly comes out only by updating ucm to 126.96.36.199 and not by factory reset.