Vodia PBX

Next version will automatically check if files are missing and attempt to download them when missing.

We will add a page size selector, including the "all" option.

Just made another 61.1 Win64 "L&G" version

Actually I believe support wanted to guide you to 61.0....

We have made 61.1 builds for CentOS64 and Debian64 ("Latest and Greatest" builds, not a release) that includes this. Maybe we can also get a Win64 build done in the next few days.

This is simply because the audio files are missing. We are aware about it and are working on getting those files shipped with the next release.

We have also added something in the TrueCNAM code itself, because we know it wants the code in the E164 format and there is no point to have everyone jump through hoops to get this working. But so far it is only on the latest and greatest (61.1 builds).

Hmm I think the easiest solution would be to add another option to the history info so what we can say how long the history has to be to be included in the request.

You have to hit it exactly on the triangle. The "click" event was on the icon, not the button. We'll fix that in the next version.

Many people hang up after hearing the beep tone. So yes technically they left a voicemail, but it would be very annoying if the PBX sends the message out with just the "click" in it. The duration is actually not hard coded, it is in a domain setting called "mb_min_dur" so you can adjust that if you think it cuts off too early.

Internally the PBX stores phone numbers in a global format whenever possible - then when sending the call to a trunk it can be easily presented in the right format. Even in the same country different trunk providers cannot make up their mind on how to present numbers, and likely this will never happen. But for converting user input into canonical numbers the PBX needs to know how to read them, thus the country code. Anyway next version will make a proposal when you create a new domain, and this should make this problem a lot smaller.

You need to enable redirection in the trunk that you are using.

Well if you set it after everything was already up, it is indeed a problem that it breaks things in many places. Some vendors just hardcode it to "1" (which makes it difficult to sell it outside of the US and Canada) and other hardcode it to ROW (which makes it hard to sell it in US and Canada). When creating a domain the PBX prompts already for the country code, to make the point clear that this is an important setting. We probably need to make this easier in the initial setup, e.g. propose a reasonable default that the admin can override when needed.

Looks like there is a problem with the interpretation of the caller-ID. If you are in the US or Canada, make sure to set the country code in the domain to "1" this helps the PBX to better understand the numbers.

Try Googling for Microsoft OCS and pbxnsip. It is a very complicated topic, and unless you have a lot of time, IMHO it is much easier to leave the voicemail just on the PBX and send it by email instead.

What are you trying to achieve? Do you want to leave voicemail there?

Looks like this is really because of the missing domain context. Unfortunately this seems to be broken in 61.0. We will fix that ASAP. Not sure how much work this would be for you, but you could instead just use the "native" CSTA interface to send the MakeCall command.

We'll add that to the latest version.

This was necessary so that we can offer the mailbox BLF button - which is just a shortcut for this code extension.

Yes. It is called "Enable SPAM rejection" when you edit the domain properties.

Do you make this post to the right HTTP Host? In 61.0 the PBX cannot use the username @ domain it only uses the username. If you send it to the right domain it should work again. For example curl http://your-domain/... your-domain should be a domain on your system.

Video is a technically challenging topic, and its practical use for VoIP phones is limited compared to what is happening on the smart phones and in the web browser today. VoIP phones are far away from what WebEx, zoom, logmein, whatsapp, telegram, and so on deliver today. Video does serve as "fireworks" when presenting a new PBX to a prospect CEO, but as far as we can tell is has no day to day impact for those who have to work with it every day (it does not help generating revenues or saving money). Because of this this was not a top priority. It is okay that it works in principle after a friendly audio introduction, but that's all. No white boarding, no chat, no emojis, no screen sharing.

No the thing is that there are two WAV files needed here: When the services flag gets "active" (whatever that is) and when it gets inactive. That is why the files are provided with the service flag. The paging account is just used for delivering those files.

If you see scheduled playback in the service flag web interface, then it is in the software. You need to upload your WAV though the "Upload Audio" menu in the domain (or on system level). After the upload you can actually verify right on the upload page that the WAV file works by pressing the "play" button.

Well but we have to do things in a way that works properly. If we mark the message as read at the beginning of the readout, there are still other people in the team that have already pressed the button and will (unless they pay attention to the message light on their phone) hear the message as well. Therefore I don't think we should code that as a proper solution. Maybe what you need is that only one person can listen to the message - the first one who listens does not only mark it as read, it actually moves the whole message into the listeners mailbox.