Vodia PBX

You could use the code *80 for that. However that might not be the right thing because it set the redirect all to the specified value. It is usually used for "snow days" when there is nobody in the office. The other idea would be to program the IVR node. There is a action "set" that can set any parameter "night", e.g. action:set?name=night&value={input}&account=70 (see https://doc.vodia.com/ivrnodes) - however the account parameter was not available until version 64.1 (available for CentOS64 and Debian64 as of now).

Oh ok - yes # is kind of special. The problem with the auto attendant is that the choices in the auto attendant (press 1 for sales) may overlap with extension numbers (101). In that case the # means that the auto attendant would not wait for a timeout.

Ehh ja that makes sense we fixed that please update one more time to 64.1...

That is indeed weird. We are also on the latest 64.1 but we don't have that problem. I would look at the "inspector" (JavaScript debugger) if there is any warning. Maybe Umläute that somehow screws things up (though this should of course not happen). You should see requests that go to the PBX trying to fetch the user settings, and they should contain valid JSON responses.

64.1 is just a development build - please be careful with it. What could have happened is that the webpages are not 100 % in sync with that version. We actually made another 64.1 Win64 build today (Feb 11). Also if you have changes to the page it could cause problems like these.

Well that is a pretty old version - of course we would recommend to use the latest release. If you do have to install the version, I would install the latest and then just downgrade using wget and replacing the pbxctrl files with the downloaded ones. You might have to edit the /etc/init.d/pbx file and remove the command line argument --respawn because 5.3.2 did not have that option yet.

I would make sure that DTMF works - e.g. call the mailbox and see if it does anything. If it does the next question would be - where does it happen?

Agreed. We are trying to leverage the API that Google and also others are providing for telling us who exactly logged in. For example when you are on Android you are already logged in through your Android account - why not just use that. That is a lot easier than implementing authentication fully internally.

Its a complex topic - one the one hand some customers want the latest and most productive features and we want to deliver them quickly. On the other hand many customers mostly want a 24/7 service with no surprises. We don't require customers to update. That's in many cases best for everyone, even if there are known bugs customers can work around them. Some actually love to be on the latest and greatest. We try to set the expectations right that those versions are daily builds. This helps us a lot getting those versions tested much faster than this would be possible with automated tests. For example the topic with the agent login/logout was and still is tricky because we made some major changes underneath that we need for getting reporting up to speed. We have made more changes that brings the old login/logout experience back, however it is not in a release yet. It is in 64.1 but that is a daily build. We do entertain a few branches that someone became "LTS" versions - 57.3 is the only that is probably the most popular. With the newer versions we usually try to port the "good" bug fixes back into the branch. We did this e.g. with 64.0.1/2/3/4, 63.0.1/2/3/4/5 although I would not really call this LTS. I am not sure what branch would be a candidate for LTS like the 57.3 branch, especially because of all the new features coming up for the apps. Maybe 63.0 could be a candidate.

We added a new DLL to the build in 64. Windows might not like it. The workaround is to stop the service, start CMD as administrator, go into the PBX working directory (cd ...) and then start the PBX manually (e.g. .\pbxctrl.exe --no-daemon). Then there might be a pop-up where you need to approve the DLL. After that you should be able to start the service from the service manager.

In version 64 agents can be logged in or logged out. This was a change to the previous versions where the ACD kept that information - now the information is in the extension. We have refined that already in the next build so that agents can also be logged in and out of specific ACD again, still storing the information in the extension and not in the ACD.

You can only charge for inbound or outbound. If you want to charge for both, just make two lines - one with "i" and another one with "o"

We will solve the problem by adding two settings for including the password and including the QR code. Then the system administrator can make the decision wether to include it or not.

So is this about the busy light (BLF) or the message waiting (MWI)? Are you watching your own mailbox (MWI) or somebody else mailbox (BLF)?

Well looking at the list of SIP trunk providers for voice termination there is a lot of work to do for sure. I guess we have to put this on the to do list!

The install-centos.sh script installs the script in /etc/init.d which is needed to control the PBX as background process/daemon. Before copying the working directory over, just install the PBX on the operating system and then copy everything from the working directory except the pbxctrl (or pbxctrl.exe and opusldll in Windows) and pbxctrl.dat over to the new server. Then you can restart the service with /etc/init.d/pbx restart.

Yes the 1xx would wait for more digits (10-digit US dialing). Can you check what was sent to the phone as dial plan?

That might be a problem with the dial plan on the devices. Maybe in the domain settings there was the dial plan for 2-digit extensions set?

Es gibt das Datenblatt (https://vodia.com/fileadmin/Data/Documents/IO_data_sheet_de.pdf) mit ein paar allgemeinen Angaben. Das Gerät basiert auf der Intel-Platform GRX550 die auch bei der neuesten Gerneration eines in Deutschland populären Routers zum Einsatz kommt. Ja für die Fiber-Schnittstelle braucht man noch ein SFP Modul was nochmal ca. 20 € kostet. Damit ist es z.B. möglich auch einen zweiten SDL-Anschluß zu betreiben, aber natürlich auch Glasfaser. Grundsätzlich basiert das Design auf OpenWRT - man kann damit recht flexibel WAN Netzwerk-Adapter betreiben. Die Hardware Platform ist "giga" d.h. bei der Bandbreite gibt es genügend Kapazitäten. DSL beinhaltet auch alle möglichen älteren Standards. Wir haben da keine Software geschrieben sondern nur die Platform verwendet. Das Web-Interface bietet die notwendigen Parameter an, für die Deutsche Telekom haben wir ein spezielles DropDown eingebaut. DSL ist aber im Vergleich zu Ethernet oder Glasfaser ein "Fummel" Thema aufgrund der langen Historie und der Menge an verschiedenen DSLAM die bei den Betreibern zum Einsatz kommen. DSL sollte in den meisten Fällen funktionieren; wenn es nicht klappt muß man halt ein externes Modem verwenden. Die Firewall ist vor allem ein NAT-Router. Es gibt ein paar Funktionen für NAT, Port Forward oder MAC-Address-Registrierung. Da ist die Vodia IO aber nicht zu vergleichen mit z.B. SonicWall oder Fortinet (da DNS jetzt aber zunehmend über TLS läuft und sowieso alles verschlüsselt wird m.E. die Firewall wie wir sie heute kennen sowieso bald Geschichte). Wir haben aber die Kontrolle über alle Parameter. Wenn es etwas interessantes einzubauen gibt können wir das machen.

It really depends on the device. On mobile phones and soft phones fortunately nobody yet had the idea that the app has to start dialing without pressing the enter button. What you enter is what you dial. The PBX will look at the country code and then convert the number into the +-format. On desktop phones there is still that desire that the phone will start dialing by itself. This is similar to the desire to press a 9 to start making a phone call. IMHO this is very confusing and there is no more need for that on practically all VoIP phones. Asking users to dial 9911 instead of 911 is now illegal in many environments. The easiest on VoIP phones it to tell users that they can dial the number just like they dial the number on their cell phones. Usually 99.99 % of the users get it immediately and will never look back. For analog devices like old FAX machines and legacy phones there is still the problem to determine when the number is complete. The easiest is to use a timeout which is okay in many cases because there is no human operating those devices any more or ask them to terminate their number with # instead of the enter button. Rotary dialers are not used any more. Yay!

Looks like this is a TLS problem. We did have a problem some versions ago when the email server (especially Microsoft servers) were requesting a client certificate - the PBX would actually send it however the server would not like it. We fixed it also on the 64.0 branch. I would turn on TLS logging to see what is happening.

Maybe this topic is drifting a little. Maybe the Pi build is not up to date for the showing of the QR codes in a single page. Sending a QR code out will be in the next version (65). Regarding the email example - many users have only email in their smart phone. How are they supposed to use the email?

We don't have plans right now but it does sound interesting.

/9 is unfortunate - we have only /8 and /16 which would mean that you would have to add 128 /16 blocks. Alternatively you could white list the /8 block, which would white list more addresses that you would actually need. If you want to do this in JavaScript, here is the code: for (var i = 128; i < 256; i++) fetch("/rest/system/access", {"body":"{\"ip\":\"166." + i + ".0.0\",\"netmask\":\"16\",\"type\":\"true\",\"comment\":\"Whatever\"}","method":"POST"});

We have the QR code ready - however still struggling to understand how you would that email in a smart phone unless you have a mirror for taking the photo. A link to the play store with the credentials in it might make more sense - we are investigating this as well.