Vodia PBX

We have made builds for 5.2.4d for the mini1 (AKA snom mini) and the mini3 (AKA Beaglebone on Debian); the mini2 (AKA BeagleBone on Angstrom) might still be missing.

I would also perform a general sanity check of the server, e.g. check if the disk is full (df) and check if there is any process consuming the CPU (top).

Why don't you run the PBX on different ports, e.g. 81 and 444? You can edit the pbx.xml file, for example.

What phones are you using?

try logging in with 499@imaginefilm and the password (do you still have a domain with the name "localhost"). I assume that the PBX cannot identify the domain. Even though it is a mini, the system is multi-tenant, in principle.

Wenn möglich würde ich für solche Sachen lieber die Automatische Vermittlung verwenden. Da muss man sich nicht mit extended-regular-expression herumschlagen. Das Feld heisst in Deutsch "Muster die mit der DTMF-Eingabe verglichen werden". Das Ende der Ansage ist sozusagen ein Tastendruck "E"...

snom has released a new DECT product that supports handover properly. I think you should take a look at that. The PBX has nothing to do with that, it is handled by the DECT base station.

Roaming is not handover. You will loose the call when moving from one cell to another. Apart from that, from the PBX perspective, you need to make sure that the base stations are all configured to register the right account with the PBX.

Although we were not able to integrate them into the automatic provisioning yet them I believe this is will be a successful project: The DECT part is much better than the previous model and the handover is a killer feature for a large installation. On the SIP side, the requirements are relatively low, because cordless phones don't have buttons. Hopefully we will get our test device soon and then we can add the PnP.

Sorry the problem is related to the operating system. If you upgrade your OS it will work with no problems. We did not do this just for fun. The point is the development platform which we have upgraded (Visual Studio). It wasn't our idea, but a upgrade of the tool chain results in backward compatibility issues. I am not sure if Microsoft broke the backward compatibility on purpose to make more money on selling OS upgrades or if there are actual technical reasons for this (new features only available on new OS versions). We could move back to the old development tool chain; however then we have eventually outdated software that is generating sub optimal code. That would put those clients at disadvantage that are using the latest OS. That all said, I believe it is a reasonable to recommend to the 64-bit versions for all modern installations and use the old tool chain for the 32 bit version for an enhanced backward compatibility. Also the number of clients using the older versions of Windows is really going down. From a customer focus point of view, we need to focus on the majority of clients who are using newer OS versions.

When the user presses the button first, the PBX will start searching for all matches that contain that first character. So it is not unusual that the PBX comes with a lot of seemingly unrelated matches. As the user keeps refining the search, the PBX should then come up with more useful results, and eventually the entry the user was looking for. The LDAP part was rewritten in version 5 to make better searches possible and also to enhance the LDAP compatibility, especially when you perform searches that are not the default in the snom phones.

Why don't you just use the cell phone twinning feature?

Sorry for that we don't have a build yet. ETA is two weeks.

The installer just takes care about registering the service and copy the files. So what you could do is install the 64-bit version and then manually copy the 32-bit executable over (32 bit will also work on 64 bit OS, but not the other way around). The links are in http://vodia.com/downloads/pbx/version-5.2.4c.xml you can just copy and paste them.

We don't have that launched yet. Depending on your OS, the 5.2.4c might already have it for you.

Unfortunately the different Windows versions come with different libraries, which have a couple of backward compatibility issues, especially with XP (which is server 2003) and before (Windows Millenium, WIndows 95, WIndows 3.1 and so on). Our strategy is now that the 64-bit build uses pretty much the latest stuff, which is Windows 7 and higher. The 32-bit builds use a much older tool chain which should work even on XP. Bottom line is to use the 32-bit version if you have compatibility issues. It would not take you as far as the 64-bit edition in terms of CDR and number of phones you can connect on TCP/TLS; but most installations that use older OS versions don't use that much resources (does not justify the OS upgrade).

It is debatable what is the best/right behavior in this situation. On the one hand the owner of the trunk wants to know what calls were going through the trunk. On the other hand, the way the trunk it working is that the call gets delegated into a domain. What kind of CDR are you actually using (there are so many these days, see http://www.vodia.com/documentation/cdr)? The call recordings (audio) should be definitively in the right domain, no matter if they came from a local or a global trunk.

There is a debian64 build for 5.2.4c if you want to try that one.

100 Hz would be a problem, but 100 MHz should be okay at least for a few calls. Also if the CPU is really too slow the CPU would just "drown", but not delay the media.

Two seconds are huge. This sounds like the media takes a ridiculous path over some satellite link and back. Try to turn on PCAP on the PBX extension and/or trunk, this will help you figuring out where the PBX sends the RTP packets.

As for the snom firmware, we are talking about 8.8 or 8.9. So this was more like a theoretical answer. From a practical point of view, the snom phones are limited to one account at this time. But did you check the "generated" folder? There you see what has been sent to the phones, including the passwords.

Did you try to log in using the web browser?

The background for this is that most installations don't want their users screw up the phone. Only the administrator should have access to the phone. Newer firmware versions have two account, one for the user and another one for the administrator that can solve the problem. If you don't remember the password (or it has been automatically been generated during the setup), you can look it up in the generated folder for that domain and extension. Could be simply a hardware failure. The device should not be clicking all the time. If other extensions work correctly then I would really suspect that there is a problem with the ATA hardware.

For dialog-based phones like the GS we support only the BLF and speed mode. Your best shot for a park button would be using the BLF mode for the park orbit and if that does not work, use the speed dial with a star code.

You mean like in https://www.docker.com/ ? As far as I can see it, this platform is built for non-realtime requirements (mostly, HTTP-based services). My worry with servers that are drifting in the cloud is that when the drift happens and you are in a call, you'll have a pretty bad experience.