Administrators Darren Schreiber Posted December 5, 2016 Administrators Report Posted December 5, 2016 Hi everyone, As noted, we expected some issues today with the 4.0 upgrade. I wanted to keep a public list in the hopes of avoiding duplicate submissions for issues we already know about, and also to keep you all informed. I'll update the top part of this post as the day progresses. Here are the issues we are currently seeing and working on:* FIXED: International calls fail - DNS issue causing failure to route to our international carriers (US calling and E911 are via IP so they were OK)* FIXED: Customers who ONLY allow G729 codec are having codec negotiation issues.* FIXED: Webhooks were not firing in some zones.* FIXED: Conference entry tones are missing when parties join the conference* FIXED: Email to fax not working.* FIXED: Numbers should now be properly appearing in all accounts. If your account was somehow missed, please drop support an email and we'll fix you up.* FIXED: We have received multiple reports of voicemails not being received and have determined that an issue with recording and storing the messages impacted a percentage of voicemails left. Voicemails are now being stored properly.* FIXED: DISA Caller ID not respected for calling outbound (rare feature usage scenario)* FIXED: BLFs for parking slots are not working reliably (though in testing)* FIXED: Voicemails that weren't stored properly after the initial 4.0 upgrade have been recovered. They have been placed back into customers mailboxes as "new" messages. This should also trigger the MWI indicator on customer's phones and are available in the voicemail manager application. The messages will lack a valid Caller ID. Unfortunately customers who are missing the Caller ID on a message will need to pair up the voicemail's date/time with CDRs to identify (or guesstimate) the Caller's information.* FIXED: Duplicate voicemail to email messages are being generated on some older accounts (one branded and one un-branded). This is being fixed.* FIXED: Click-to-call changed slightly in how it functions, updates via UPDATE package to show dialed number on the screen. One customer had customizations that relied on Caller ID being the field where this data was delivered. We will be making a change to attempt to appease this client.* FIXED: Many requests came in previously to show the local IP of the phone in the debug tool, not the public IP. This was to help partners figure out exactly which phone at a client's site was attached. We made this change, but now people want the public IP as well (which makes sense). We are working to add both so you can use both.* FIXED: MWI not illuminating if a user has multiple voicemail boxes. Only the first voicemail box count is being checked. The old strategy used to be that you'd be sent the total voicemails in ALL mailboxes. We are reverting to the old behavior.This concludes the rollout of 4.0 and all major known bugfixes we have learned of.Last Update: December 10th, 2016 @ 1:30pm PST
FASTDEVICE Posted December 5, 2016 Report Posted December 5, 2016 @Darren, are you aware that "auth_token" is returning a much longer string than usual?
Administrators Darren Schreiber Posted December 5, 2016 Author Administrators Report Posted December 5, 2016 Yes, that's not a bug either. It's for OAuth support I believe.
esoare Posted December 5, 2016 Report Posted December 5, 2016 Under IRONIC. Have an account that some phone registrations show the Internal IP and others show the external IP address. Will stand by on this one. as a side note: Thanks for posting the Known Issues!
FASTDEVICE Posted December 5, 2016 Report Posted December 5, 2016 Webhooks are not working. This is a high severity issue for my clients as they depend on our Harmony CRM integration app that is triggered by a Webhook.
Administrators Darren Schreiber Posted December 5, 2016 Author Administrators Report Posted December 5, 2016 Not sure on this report. I just checked the logs and webhooks are firing. Got any more details? Did you check the GUI to make sure they're not marked disabled?
FASTDEVICE Posted December 5, 2016 Report Posted December 5, 2016 Yes, the hooks are enabled and my test hook "channel_answer" is set to be received at http://requestb.in/14hja8g1
Administrators Darren Schreiber Posted December 6, 2016 Author Administrators Report Posted December 6, 2016 I'm checking into this.
Administrators Darren Schreiber Posted December 6, 2016 Author Administrators Report Posted December 6, 2016 Please see if they are coming in now?
FASTDEVICE Posted December 6, 2016 Report Posted December 6, 2016 Yes, they are working now. Thank you. And, as usual, I get two for every one. Someone should look into if duplicate hooks are a bug.
Administrators Darren Schreiber Posted December 6, 2016 Author Administrators Report Posted December 6, 2016 They are not a bug. They are by design, but nobody likes it. It ensures the message gets through always in case there's an ecallmgr issue (there are two ecallmgr's, hence two notices).However we have heard this complaint enough that we are changing the way we do it soon, which should de-dupe them.But it's not a bug.
FASTDEVICE Posted December 6, 2016 Report Posted December 6, 2016 Webhooks, list of attempts log is not working.
Guest Posted December 6, 2016 Report Posted December 6, 2016 UI is not Deleting Numbers. When in Spare Numbers in SmartPBX, select number to delete and select Delete, does not delete the number and no error thrown.
FASTDEVICE Posted December 6, 2016 Report Posted December 6, 2016 This appears to be a side effect of the url length. Long urls break reporting.
FASTDEVICE Posted December 7, 2016 Report Posted December 7, 2016 @Darren, please have a developer review "clicktocall." I am certain that it's issuing the account's callerID for <contact_number> when it should be the other way around. Also, please have them review the entire "clicktocall" process as there is something else going wrong that my developers can't pinpoint. Prior to the upgrade "clicktocall" has worked for us flawlessly for two years and we haven't made any code changes on our part, but now our CRM integration app is broken.
Administrators Darren Schreiber Posted December 7, 2016 Author Administrators Report Posted December 7, 2016 I can request this, but it'd be helpful if you posted the full URL and responses you get when using it. There are a bunch of different scenarios you can do with Click-to-call, if I don't know which one you're doing, we're just guessing.
FASTDEVICE Posted December 7, 2016 Report Posted December 7, 2016 Big Thanks for jumping on this issue. Sent my developer's update via email. My clients have been without CRM integration for 2 days and they are starting to get restless.
Administrators Darren Schreiber Posted December 7, 2016 Author Administrators Report Posted December 7, 2016 Wrote back to your developer. Seems the issue is simply that the Caller ID is swapped on loopback calls initiated from Click-to-Call. I assume this will be a simple fix but need to talk to the developers tomorrow about it.
Administrators Darren Schreiber Posted December 7, 2016 Author Administrators Report Posted December 7, 2016 Not sure I understand this one?
FASTDEVICE Posted December 7, 2016 Report Posted December 7, 2016 Under the Webhooks app, for each active webhook there is an option to "show list of attempts." This in turn generates a filtered report of attempts. If you configured a webhook with a long url the report headers are misaligned and the report won't generate.
Recommended Posts