Jump to content

Vodia PBX

Administrators
  • Posts

    11,069
  • Joined

  • Last visited

Everything posted by Vodia PBX

  1. Once a message has been sent to the recipient, there is no practical way of deleting it any more, especially on SMS. We all know the embarrassing "this message has been recalled by the sender" email that does not work. What does make sense is to hide the message, so that it does not clutter up the space. For internal messages, we can also think about editing the message, and there we can also show that the message has been edited by the sender to the recipient. It's not even sure if we need a policy for that; IMHO this makes sense in any case and this should work with regulations that do not allow deletion or alteration of content.
  2. Generally, transcoding from one codec to another never improves the quality (unless you use some artificial intelligence magic). In other words, if your SIP trunk does only use G.711 there is no point using anything like OPUS. That being said, G.711 is bad when it comes to packet loss. Especially on mobile devices it makes sense to use OPUS even though the quality without packet loss might be slightly lower than with G.711 because in situations where the packet loss is high, users will hear a huge difference. In any case, I would recommend to stay from old codecs like G.722 or G.726 and even iLBC. In a nutshell its G.711 or OPUS today.
  3. Vodia PBX

    69.1

    We'll have to spend some quality time with outbound calls as well. We have more or less quietly added a page for managing outbound numbers for outbound campaigns, but we need to work more on it e.g. a default wrap-up-code and statistics.
  4. Yealink now runs the cloud provisioning server in different regions (e.g. GPDR so that the data is physically stored in the EU). In preparation for that, the PBX needs a new setting for the server URL. There was a problem that the PBX would not find the right trunk when there are multiple trunks associated with the same IP.
  5. Oh actually that's true, it should be called code >= 500 || code == 408. Why should it not failover on 6xx codes?
  6. Yea we actually need a policy for that (also for the other apps). For example in public environments, this would be a problem because you are not allowed to delete anything.
  7. Vodia PBX

    69.1

    There is an option for that in the queue settings, did you see that (Show post-call survey)? In the future we might add more stuff there, so we kept it under the term post-call survey.
  8. Vodia PBX

    69.1

    You might have to retrovision the phones one more time. Fun fact is that while practically all of today's VoIP phones support SNI in TLS for HTTP, they don't do that by default for SIP and LDAP believe it or not. Some support enabling it, and for some we need to provision them in the way so that they will see the system management DNS address and not the tenant address as a dirty workaround.
  9. Vodia PBX

    69.1

    In the FAX calls that we did for testing it was always the caller that hung up. But it seems that that is not always the case and we need to disconnect after the FAX has been received to be on the safe side. We will do another FAX round soon anyway, the ECM for "analog" is still missing and this would further enhance the reliability obviously.
  10. Vodia PBX

    69.1

    Looks like you have turned on the translations in a previous version. In order to see the texts, you need to remove (or rename) the dict.json. The wrap up codes or categories are there for the agents to categorize calls, so that later analytics can better understand what the calls were about. For example, categories could be "winter tires", "summer tires", "repair", "accounting" and so on. The codes are reporting in the nightly emails and you can also download the call records in the queue management in the user front end — obviously need to have the permission to manage at least one queue for that.
  11. Hmm actually not sure. There were some changes with the identification with the trunk, and that could have to do with Teams. I guess we'll find out! But I know that the net mask was causing a lot of erratic problems with Teams trunks that were set up versions ago when the associated IP addresses were a much smaller range. It was really just the label. The settings internally were not affected so that you don't have to change anything, it will just show on the front end the other way around and hopefully now makes sense.
  12. We have made a 68.0.34 build with a couple of fixes that can be seen in the release notes. Nothing really spectacular, but a few annoyances that came up in the past few weeks. One of the major points is an improved Teams behavior, especially if you are using IPv6 for Teams please make sure that the associated addresses are up to date with the SIP trunk template.
  13. Well maybe we should just split the V68 Windows app from the V69 Windows app. Then we can just freeze the 68 app pretty much and don't have to deal with this when we add stuff to the V69 app.
  14. Just changing the service flag would be relatively was (that's what the iOS app does). Monitoring with live updates is another story.
  15. What if you call the seconds stage directly? Does it work then? I would say we are talking about 4 redirections, and that should not be a problem. I would look into the logs, there should be a clue why the voicemail does not work...
  16. Well we have added stuff that at least removes accounts when they are deleted and renames them when their primary name changes. But its "hairy", there are a lot of references!
  17. You can change the global settings in the reg_settings.htm page without the need to restart, including the variable that limits the number of redirections (if that's the problem).
  18. Not ATM. In the mobile apps, users can change service flags.
  19. You can change the values in pbx.xml conveniently through the reg_settings.htm page. There is an edit button in the header where you can select the setting that you want to set, no restart required.
  20. It's actually different from what we have in 69, and in 68 it's labeled the wrong way (at least inconsistent with all the other places). We'll fix this in the next 68 build.
  21. Did you try the "local override" (at least that is how it's called in Safari) in the browser? It's a very convenient way to change anything in your web page and it's great for tinkering with such things. E.g. if you are not happy with the numbers in your online banking account, try this method — does not require any changes on the backend and might impress people looking at it!
  22. There were still some unrelated changes for 69.1.4, but we'll turn the switch today to make the 69.1.4 the version that will be shown on the upgrade page including ignoring the closing of the notification.
  23. Well the reject is triggered when the Notification gets closed, see https://developer.mozilla.org/en-US/docs/Web/API/Notification/close_event. It seems it's not clear if this is because of a user interaction or because of the browser after a timeout closes the window. Looks like Electron has a different way of handling this than most of the browsers. Anyway, IMHO it is not worth the trouble. As a short-term measure let's just ignore that event (69.1.4). Then as the next step to clean this up, IMHO clicking on the notification should just bring the tab to the front and then the user can decide in the tab what to do — accept the call, reject the call, divert, and so on. Yes this will mean two clicks for the user, but because the browser notification essentially has only one action item available today, well that is what we have to work with. We are working on the next Windows store version that will handle notifications through the Windows API where multiple choices are possible and fit into the Windows user experience better than the browser does today. That will be. the ultimate answer to this annoying issue.
  24. In the "redirection" area or in the "condition/parameter" area?!
×
×
  • Create New...