Darren Schreiber

No, nothing has reverted. It's only when you edit.

Not sure I understand this one?

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.

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.

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.

Please see if they are coming in now?

I'm checking into this.

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?

Yes, that's not a bug either. It's for OAuth support I believe.

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

Hi guys,      Just a reminder that tonight is the big 4.0 upgrade and we do expect small periods of downtime in each datacenter, sometime between 8pm Eastern and 8am Eastern as we reformat machines and move IPs around to different servers. We'll do our best to avoid disruptions to service and will start with the east coast first, then the west coast, so west coast customers won't feel the impact until later in the maintenance window.       This is, again, our largest upgrade software-wise to date. We've done a lot of prep work for this (A LOT of prep work) but it's possible we've missed things. Please file a support ticket or post here if you find any problems post-upgrade. We have extra staff on-call and in the office to help with things all weekend and on Monday.       We'll be posting status updates on statuspage.io and also sending emails out about the upgrade status as we go.       Thank you for your continued patience and support!

I'll see what we can do about this after the upgrade. That feature only works with PBX Connector as far as I know.

Hi there!       We're trying to avoid disruption best we can in general, but I can't shift the maintenance any further back I'm afraid. We will keep you in mind though and may do the west coast servers last.

Estimated for 6am Pacific Time completion.

Is that seen on Sandbox or production?

Ugh grumble grumble that doesn't belong there. I believe that feature is only for PBX Connector. I don't think that just works on any old number. I'll have to check, engineering may have added an enhancement I'm unaware. So, no, don't use that one. The new one for device/user failover is not exposed yet.

If the phone is registered, the above should work. Thanks Rick for posting that. Please note not all phones support this.

Yes, email in a support ticket if you don't have creds and we'll get you them. This request won't count against your support credits.

Also, as a reminder, if you want to see what's coming out in the next month, check the Sandbox server.

@Karl can you describe to me how the call failover SHOULD work then, under the circumstances you stated your client experiences?

Thanks for this feedback. This is on the back-end only and not available on the Hosted Platform yet because the front-end component is still in design. I've noted the urgency to the team though.

@Karl I don't understand. Wouldn't the correct solution be to correct the internet, or tell the customer that calls fail because of their crappy internet and NOT use the failover feature in such a scenario?

OK, please file a ticket for that feature (or start a separate discussion here on that) for call groups. There is no functionality for that and it requires somehow pre-checking all parties in a ring group, and if they are ALL offline, then sending to an alternate callflow. Currently, there's logic that says: "Retrieve list of devices for user for a bridge string." and the failover function adds an if in there so it's "Retrieve list of devices for user for a bridge string, and if any device is unregistered and failover is checked, return a call forward string instead." That's very different from a ring group, which would need to be modified to somehow check if all users are offline and, if so, then forward somewhere else. That functionality doesn't exist.

I'm proposing a ticket where the existing call-forwarding section in SmartPBX is changed to show: * Forward all calls * Forward calls only if SIP device is unregistered (failover) * Off I don't know if it will be accepted but that is the existing design that's already built so if it's accepted it could go out fairly quickly assuming it gets approved. The rest of the team has to agree with me that it actually works that way, though, and that there's no risk in exposing it. For now you can also set this via the API on the backend.

Hi there,      It is a popular request, I agree. I will see what we can do here.