It appears that our upgrade last night from 8.0.1.3 has bro9ken the ability of users in their extension GUI (web portal) to change call forwarding. THey get a "Server error -1" and after you OK that it appears to be changed, but isn't .
I know this by the following.
users calling in complaining about, I went in to troublehshoot and verify.
I also used a test ext which had no forwarding enabled in the GUI, and I couldn't configure a forwarding number.
I need a workaround asap, there is no where I've seen in the admin gui to change or configure forwarding numbers, and I don't want to give out the connect app to all in order to change forwarding, if in fact that even works, will I will check now.
Is there somewhere in the asterisk configs to manually configure forwarding?
Also, another problem, and I
Also, another problem, and I should add that the tenants are currently using all capital letters in the tenant name.
When using the thirdlane connect app it will switch to "use the app" and work properly, but won't switch back properly. When switched back to "use the extension" the incoming calls go directly to VM until you reboot the phone. I even tired to "sign out" of the app after it was supposedly switched back.
In the admin GUI the The app changes the setting in the "phone tab" to from Webrtc back with SIP, but the phone doesn't answer and goes directly to VM.
Also, I've seen where there is supposed to be a setting somewhere where you "Allow the thirdlane Connect to change the webrtc setting" I could not find any such setting, could this be the issue?
Interestinly I have just
Interestinly I have just heard of other users who's extensions wouldn't ring, they were sending callers directly to VM and wouldn't ring unless the phone is rebooted. Yealink phones, in case that matters.
This may be related to one of my symptoms above where when I reverted back to using the extension from the Connect APP config
Here is some words from my
Here is some words from my sysadmin. First his original words on the upgrade:
I had a minor issue when upgrading the main Thirdlane pbxmw-mt package... it
installed fine and then ran a post-install script which upgraded some Perl
modules outside the OS package system. It timed out trying to update one of
the packages (Lexical::SealRequireHints whatever that is) and failed the
upgrade ... then I ran the command to continue an aborted upgrade, but it
didn't run the post-install script again... so just to be safe I re-installed
the Thirdlane package and it upgraded the remaining Perl modules and did
whtever else it wanted to do after that.
These Perl modules (there are a lot of them) are apparently why the upgrade
often takes several minutes to complete as they are downloading custom
packages from Thirdlane's servers without printing anything.
Anyway everything seems to be running fine, a couple new things are there,
including a TURN daemon.
Then After having the issues described above today, he had this to say when we were discussing downgrading if we have to the perl error had to do with attempts to confgure forwarding in the GUI at the extension level:
If they designed it to downgrade it would be easy, just install the old
package over the new one. Otherwise I'd have to check the DB structure
before/after and see if anything needs to be rolled back manually.
Unless I see some docs I don't know. Google didn't turn up much specific but I
see a few comments here and there of people that downgraded. I don't see
anything on the server related to "database migrations" or similar terms.
Those logs are the POST requests from the browser (i.e. just the requests that
would change something on the server). So you see them log in, try a couple
times, log out and log in again, try again, etc.
The web app is Java but the JSONService endpoint in the logs is a Perl script,
which may be related to the Perl upgrade issues I had, and the Perl error in
the logs.
That random Perl error was:
Mon Mar 6 10:03:53 2017 (1488812633.410653) 8.0.2.1 [DEBUG]:
(/usr/lib64/perl5/XSLoader.pm:94) Eval error: Can't locate object method
"tid" via package "threads" at /usr/lib64/perl5/XSLoader.pm line 94.
Backtrace shows a lot of calls to SSL module. Doesn't really tell me anything,
just noting it.
Let me know your thoughts guys, I'm concerned and downgrading may be necessary if we have issues with phones not ringing, and the GUI problem with configuring forwarding needs to be fixed.
Same issue here as far as not
Same issue here as far as not being able to edit call forward / follow me from admin/user portal - on version 8.0.2.1
Yes, unfortunately there is a
Yes, unfortunately there is a problem with call forwarding and screening in the user portal - we are working on it and will release an update ASAP
Same here, I've been
Same here, I've been experiencing this issue. I have a new customer I just setup and they cannot forward calls for the conference they're headed out of town for. Not happy campers. Any timeline on the fix?
Any idea what time the
Any idea what time the release will happen? I am set to port my customers numbers at 9am PST, just want to know if I need to have a workaround or not.
Any update on this? I am
Any update on this? I am still experiencing the problem and I haven't seen a new release yet.
Thanks,
Robby
I was not able to check this
I was not able to check this earlier - but I believe we updated both the ISO and repos at about the time I expected. Please try the usual:
yum clean all
yum update
The release came out and
The release came out and resolved all the problems we were experiencing. It did come out significantly later than expected though.
Sorry, we tried to do it ASAP
Sorry, we tried to do it ASAP, I guess it happened a bit later than I thought. Also - while the update solved the problems you were experiencing, we found some other issues that will require another release. Please stay tuned.
Hello Doug,
The issue is known. Please update to 8.0.2.1.