Vodia PBX

Wir haben gerade 5.1.3 freigeschaltet. Dort würde ich mal den Loglevel auf 9 stellen und einen Anruf starten. Dann sollte man sehen können wo das Problem ist.

We have made builds for all supported operating systems (Windows 32/64, Debian 32/64, CentOS 32/64, FreeBSD 64, Apple MacOS Intel/PowerPC, snom ONE mini) for the 5.1.3 release. The release notes can be found on http://wiki.snomone.com/index.php?title=Release_5.1 there are many fixes, we consider this release a major milestone regarding stability and features. Before you upgrade we recommend as usual to make a backup of the old installation. Also consider resetting your webpage changes or at least review them (webpages directory, html directory) as many things have been changes in the web interface. This version introduces a new firmware for snom phones. If you automatically provision snom phones, the phones will load a new firmware on the next reboot. Polycom phones that are running version 4 or higher will start using TLS and SRTP for phone calls after the next provisioning cycle.

Automatic de-licensing is technically difficult. It would be easy to make a backup of the PBX, de-license it and then restore the backup. We have a manual way of deactivating the license. For this you need to contact us. This is probably what you need to do.

Könnte sein dass das bei 5.1.2w gerade kaputt war. Bei 5.1.2d sollte es aber geklappt haben. Falls es dort Probleme gibt, sollte man die aber schnell über das LOG sehen können.

I think so... actually the last word has not been spoken on this subject. There are thoughts to sell WebRTC extension licenses similar to call licenses, but it has not materialized yet. As for now I suggest that you just use the 30-day trial.

The PCAP link on admin mode is superfluous now; we have forgotten to take it out. 5.1.3 will not have that link any more. The only way to get the PCAP is (right now) to get file system access and download the files in the pcap directory. Even for the embedded systems like snom ONE mini that is still okay, as they support SSH access.

Make sure that you have the password policy set to medium or strong. Users tend to choose trivial passwords, for example extension numbers, 1234 or password. Then a scanner can easily find a password and get going. If you have the password policy set, the web interface will highlight those extensions that need to change their passwords. Usually that is already enough so nobody can hack the system. On the trunk side, take the warning serious to put in an outbound proxy, or even better explicitly specify where the traffic is coming from. Unfortunately the ENUM specification must allow it that INVITE can come from anywhere to the PBX. Especially when the trunk is able to route calls out of the PBX again, that is very important. The message that the registration has changed is actually misleading. If I remember correct, it was changed at some point. The PBX must keep an internal object for the REGISTER request, and if the next request comes in fast enough, it reports that the address has changed for that address.But it does not mean that there is an active registration or that resource is allowed to place a call. If the scanner has not guessed the password right, it cannot place a call.

The license itself is for one server. The license reset is in preparation for a server crash. In such an event you don't have to wait until someone gets available (holiday, vacation, office-hours and so on) and use the portal instead. If your second server crashes, yes then you would have to purchase another license. Again, because the portal is 24/7 at least you don't have any extra downtime because you have to wait for someone. A workaround that is okay with us is to run the PBX in a virtual machine. If you run the VM exclusively on a physical host, there is no risk of resource conflicts; you get the same call quality as if you run it on a physical machine. The virtualization layer gives you the possibility to make snapshots, so that in the case of a hardware crash you can resume the PBX operations on another physical host. We also offer an option with an IP-based license. Those licenses have a time limitation and report back every day to our license server, so we can be pretty sure that they are not run on multiple servers at the same time. In such cases we don't care on what server the software is running. Many hosted PBX providers are using this to offer the PBX service on the virtual or physical hardware that they prefer.

You mean ad-hoc recording? Yes, those recordings are only available in the web interface.

It'll be tough. You definitively need a firmware that uses SIP, as far as I remember there were versions that were only using Skinny. The pnp.xml file contains entries for the 7961 and 7960 phones. There is some documentation leftover from the old pbxnsip wiki at http://kiwi.pbxnsip.com/index.php/Cisco that might be useful for you. IMHO you may save a few bucks on the hardware, but it will take you a long to to get this done, and the feature set will be basic. At the end of the day it will be cheaper to use modern phones that just PnP with snom ONE. Just my two cents

There is nothing built-in available... because recordings can be very long, it will be a problem to get for example a one-hour recording out of the system by email. Not sure if we should get over it and send them out, regardless of the size to solve this problem. But the recordings also need to be encoded with a format that can be used by clients. Using uncompressed 128 kbit/s linear makes the situation even worse. We have seen people writing a script that picks the files up, converts it to MP3 and then sends it out (but we have not seen their code ).

This is probably a problem with Linux installations that are either using the new PCAP recording feature or RTCP-XR (which is the default). The problem was that the network clock differs from the system clock, which results in those long differences. Next version will have it fixed (hopefully).

Yes, we found that one already... 5.1.2w will fix it.

We are now running 8.7.3.25 which seems to fix a lot of problems (the long-promised snom firmware).

Oh you are looking at the 64 bit. Okay, we uploaded that one again as well.

Well not sure what the problem is .... Maybe you have to use wget and download it manually. [build@centos32]$ ./pbxctrl-centos32-5.1.2v --version Version: 5.1.2v

Let me clarify: Did you put the link to the XML file into the software update field of the PBX? Did you make a manual update last time, maybe the name of the executable is not pbxctrl any more?

That's a pretty long time! Did you use the XML link from above? So you are using CentOS32? It should definitively say 5.1.2v.

On which device do you have the problem? If the problem is on the SPA, it might be a challenge because SIP has no real standard way of updating the caller-ID.

We did not make all OS yet. Anyway we have now made centos64 as well.

We have made 5.1.2v for Win32/64, CentOS64, Debian64, snom ONE mini and FreeBSD64. Those who like to run the latest versions are invited to update to this version, available from http://snomone.com/downloads/snomONE/version-5.1.2v.xml (you can copy & paste that link into the software update page on snom ONE). What you need to look out for: Make sure that you are using the domain country code. We have worked in several areas that interprets the numbers right. The trunk now really uses the settings on how numbers are presented on the trunk, also for inbound calls. This will help in many situations, but if you had it set up wrong you might have problems with inbound calls. We had issues with speed dial and calling the cell phone (*00), but those problems should be under control now. If you are using interoffice trunks you should also see if that works all right. We have changed the default snom phone firmware to 8.7.3.25. It seems that snom has kept their promise and came out with a stable firmware that can be used across all desktop phones. If you have made changes to the web interface you might have to take those changes back. We have worked heavily on the web content, which might conflict with your changes. What new features you can expect: The PCAP recording per trunk and extension. The blog post already talked about this. I will not repeat it here. The email CDR for the domain will now show the same information like on the web interface. That means not only calls that involved trunks, but all calls will be reported. It should also address the various problems that people had with including all calls from the previous day. Lots of performance improvements. The system behaves much better if you have hundreds of registrations and thousands of CDR and address book entries. Our hosted PBX partners will love to hear that. Inbound WebRTC calls. With this, you might not need a soft phone any more. There are lots of fixed bugs and also lots of smaller new features. Before the full release, we will of course update the release notes.

There is a setting in the domain called default ANI. Is that what you are looking for? Also, on each trunk you can set the ANI to be used on the trunk if the extension does not have anything.

We can give you a build of the latest version, send us a private message with the operating system that you need.

Your trunk provider or PSTN gateway must support T.38. When that is the case, the mailbox must pick up and be either in the FAX mode or play an announcement that is long enough the receive the fax tones. If you are running the PBX in the Internet and not behind NAT, packet loss (which can be still a pain for T.38) should not be an issue.

Yes that's the default. Given the size of modern hard disks, it should be no problem getting that number up. It is more a question of discipline not to loose the overview when the message number exceeds 100.