Vodia PBX

8.7.3.19 is already 10 months old; We did not try it yet, but there is a beta version available at http://wiki.snom.com/Firmware/V8/Beta, with release notes at http://wiki.snom.com/Firmware/V8/Release_Notes/Change_Log_V8_7_4 (maybe SCPP-4592 is the one). The release notes are impressive.

Most of the configurations write the provisioned data into the generated folder. If you look into e.g. snom_3xx_phone.xml, you can see what passwords have been provisioned to the phone. Needless to say, if you feel that this is not a feature but a security risk, you can turn this off in the provisioning settings of the PBX.

We were chasing this error and the only explanation that we found was some strange behavior in the phone. Because of this we recommend to use 8.4.35 for the 3xx series.

If you whitelist the addresses, does that solve the problem?

In 5.0.7 we have already added the cell phone. We have also tweaked the LDAP settings on the phone, so that the phone can sort the results according to local rules. Email? Interesting thought. The PBX does not really use that field; but maybe the user agent can. Images are also interesting, but this will require that we store those images somewhere. The core problem here remains that people upload their images from their smart phones, 18 MB each and we need to scale them down first. Unfortunately, this is not a simple task.

(Sorry for the English answer) Some old versions had problems where the trunk did not come back by itself; however the newer versions (published in the last 12 months) should have that problem solved. Also, some problems are related to DNS. What you can try to do is to use an IP address instead of a DNS address for the trunk outbound proxy. In some cases, that helped to reduce the time to get the trunk back online.

For this you can use a IVR node (see http://wiki.snomone.com/index.php?title=IVR). In your case, the pattern !E!-! should do the trick.

As far as I can remember, in version 3 and also in early version 4, it was "all or nothing" regarding G.729A. This codes is special because it must be licensed per call from the patent owners and they don't change their contracts for us. The argument was that you can re-INVITE a call with G.711 and switch to G.729A; so it would eat up one G.729A license if you use it or not. Later, we introduced some more intelligent way to offer the codec or not. That definitively explains the 415 error messages. The 501 messages are usually for requests that the PBX does not process in that context. For example, if you disconnect a call and the call object is already gone, than the PBX would answer a BYE with 501. This is perfectly okay; in later versions we beautified that a little so that you get a 200 Ok on such late packets as well. But the 501 would not be of my concern at this point.

What I was trying to say is that not the DTMF detection, but the processing has changed from version to version. So it could be, that 3.3 behaves differently with the recording than 3.1. Actually, it is probable. We don't make changes to those versions any more as they are several years old, so all we can try to do is to find workarounds. If it is Polycom phones, the only way to start recording is DTMF; there is no workaround for that. I would say the easiest solution is to go to your previous version.

The recording via DTMF tones were changed a couple of times. E.g. when sold as snom ONE the point was that you must use snom phones to turn recording on and off (what phones are you using). Not sure what the situation was with 3.3.1.

We actually just finished an overhaul of the Polycom provisioning for 5.0.7. One key question is what firmware to use. For new installations with 5.0.7 we recommend 4.0.3; if the device does not support that firmware it will be more 3.3.5. You also have to make sure that you use a recent bootloader. The phones can be sitting there for a long time if the bootloader and firmware don't match the phone model. We found http://downloads.polycom.com/voice/voip/sip_sw_releases_matrix.html very useful. As for the downgrade, I would (1) make a backup of whatever you have and then (2) use the http://snomone.com/downloads/snomONE/version-5.0.4.xml for the software "upgrade". The PBX does not look at the numbers, so the downgrade should also work through the web interface. However the key question is if the provisioning put the username/password for 5.0.6 into the phones (the username is equal to the MAC). If you are on 5.0.6, make sure that you open the extension for provisioning in dom_accounts.htm for 10 minutes, so that the phone can reboot and fetch the new settings. You might have to do that twice with 5.0.6.

Hmm at first glance I would say revert back to the previous version. It could be that the definition of calls and call legs has changed between 3 and 4, I don't really recall any more as this is already a couple of years ago.

Hmm... The PSTN gateway is not even involved in the 51485d7c70dc-m9xajgf82xni call. I guess if you make 100 calls to the mailbox, 5 will fail? I suspect the problem is related to the codec names which we have changed from pcmu to PCMU; we'll put some extra normalization rules into 5.0.7.

We will leave this to the JavaScript now. The pre-5.0.6 pages were overloaded with all kinds of stuff that was a burden for the PBX (e.g. 5 MB images for each and every extension). Instead we are now trying to include links so that the user can easily get to the right page with all the gory details.

I believe that function has not been used for years. I would not use it for new functions.

There is also a TAPI service provider available at http://wiki.snomone.com/index.php?title=Snom_ONE_TSP, which can now also signal incoming calls.

There is also a TAPI service provider available at http://wiki.snomone.com/index.php?title=Snom_ONE_TSP, which can now also signal incoming calls.

The "DialExtension" looks suspicious to me, there should be something like \1 between the two !! there. Also, I would put sip: in from of the outbound proxy, so that it is a SIP URI. The message "REMOVED DYNAMIC REGISTRAR FAILED" is somewhat cryptical. If this is a gateway trunk, the PBX should not be a registrar at all. Does the Patton try to register? Maybe there is a time when that fails and then it redirects the calls.

That looks like the private key does not match the certificate that you have entered. Did you load only the certificate or also the intermediate? If you also load the intermediate, as far as I remember, the intermediate must be below the certificate for the server (wildcard).

You mean uploading the cert into the PBX? The cert needs to be in the base64 form ===BEGIN CERTIFICATE===, and you also need to import the private key with that ===BEGIN RSA PRIVATE KEY===. When uploading the cert as the system certificate (not domain certificate), the PBX does not check what the subject is; so it can be anything, including wildcards.

Aha. So essentially what is needed is an option to prefix the number with *90 on the BLF buttons? That sounds easy...

How do you want intercom and speed dial on the same key?!

Give us a few days. Vacation...

... or wait a few days for 5.0.7. The PBX now requires the support of websocket in order to see live updates of contents. IE10 supports it, but IE1..9 does not.

Well, first of all ZRTP also does not solve all problems. I don't think that ZRTP automatically improves security over TLS + SRTP (ZRTP actually also uses SRTP). Okay, it does not have the centralized approach like PKI; so that users don't have to worry that someone stole the private key of on of the big Root CA or trusted intermediates. But if you have a closed user group, you can also set up your own PKI with no intermediates and then it all depends on you. But ZRTP needs to establish a trust relationship with each and everyone. Especially for people who have a lot of initial contacts (cold contacts) have to trust the other side the first time, always. And the mutual authentication is not trivial either. Reading out numbers involved the users, which IMHO is annoying. In embedded devices, the space is not endless, so there will be records that are being dropped; the relationship needs to be re-negotiated Also, because the hashes are stored in the devices, they are usually much less protected than Fort-Knox like the snom m9. At the end of the day, the snom m9 is also only protected with the password that you choose. What would it mean is someone can get access to one device? Not being the biggest expert here, but it would mean that the credentials on that device can be used for all devices that this one has ever talked to. In some cases the decentralized approach can be a disadvantage compared to the centralized approach: You have to protect a lot of simple devices, compared to protecting one Root CA instance. Of course the other topic is if ZRTP can be seen as mainstream. As far as I can tell, TLS is still very much mainstream today. If TLS 1.0 or 1.1 is frightening people, IMHO it would be better to focus on getting TLS 1.2 done instead of completely changing the approach. In the PBX, a lot of information is written to the file system, including private keys. But when someone has file system access, that person can pretty much do anything with the PBX anyway. You must make sure that only authorized people have access. ZRTP does not change that. Not being the biggest security in the world, I would rather set up my own PKI and do a lot so that the private key of the Root CA will not leak out. Then you should be in a very good shape. Also keep in mind that if someone wants to wiretap you, they can also use other mechanisms like laser and bugs which operate independently from the whole SRTP stuff. And don't forget that DECT broadcasts the traffic anyway...