Vodia PBX

Just change the content of the audio_uk/ringback-wav and busy.wav (keep the format, 8 Khz mono WAV, 128 bit/s).

So you mean the Linux level is not able to send emails? Or the PBX? They are using different programs and set up for this.

You probably have to go through the excersize to set top the SIP headers. If you can give use the account data (private message) we can tweak it for you and then post the best settings for spitfire here on the forum.

That all looks beautiful. Any chance for us to log in via SSH (send us a private email)? Then we can take a look around.

Security can really become a pain in the neck :-( You might have to use the boot loader of the phones to get control back on them once that you have forgotten or lost the password for it.

How do you define bringing the PBX down? Was it just blacklisted, so that your server could not access the PBX any more or was the process gone? The SOAP interface has not as much exposure as the other stuff; however there should be no way to bring the PBX down from the SOAP side, ever. If you have found a way, we would be very interested and we would fix it of course.

Is the PBX also using DHCP? Apart from that, I am running out of ideas. In a simple LAN setup, such problems should not exist.

You mean through LDAP or XML? The SoHo runs pretty much the same PBX software like all other platforms.

Did you write global settings through SOAP?! Maybe you "nuked" the PBX by overwriting to the global settings. Also keep in mind that PBX might blacklist you when you do talk to it without authentication (make sure that you whitelist the IP address you are coming from).

By default the PnP does not provision that service snom the snom 300. I guess for other snom phones it works?

I think this thread describes it. http://plugcomputer.org/plugforum/index.php?topic=1551.0; maybe it is easier to ship it to snom and have the support guys reset the config.

The alternative might be to try a local DNS server (in the LAN). If that is not too much work, you could try that, and make sure that the server keeps the relevant entries in the case, so that the PBX does not have to worry about slow DNS responses.

Well, if the PBX does not receive any media, it assumes that the connection went down. In plain words, thats "one way audio". Unfortunately in VoIP that is not uncommon, especially when terminating calls over the Internet, where you can not always be sure where the call is being terminated. The user should have the one-way audio experience as well, maybe you can check next time with the involved user if he really experienced one-way audio.

That would reduce the probability of an unrealiable connection... Though we have seen cases where the Ethernet cable was broken. We have also seen cases with IP address conflicts with all kinds of funny effects (are you using static IP addresses in your office?). Are the phones still responsive after this or do they need a reboot?

If it all does not help, you'll have to use the console to log in (hardware). The RMA department has such a console cable. The next hardware revision of the product has a reset button, that will solve many of these problems.

I don't agree. Rebooting can never be "best practice". I would use ps or top and take a look at the process times, size, VM stat and so on. There must be a process/reason why the system slows down.

M9 Problem oder snom ONE Problem? Es gibt noch ein anderes Forum, forum.snom.com...

Wenn in der Domäne der Länder-Code (Country-Code) 49 gesetzt ist (und möglicherweise die 89 als Vorwahl), dann sollte das alles automatisch gehen.

The PBX does "SRTP transcoding", that means one side can be unencrypted and the other side is encrypted. Maybe you have a old firmware for the 820 that does not decode the SRTP right: Every SRTP packet contains a checksum, and a packet should not be played back when the checksum is incorrect. In the case that something went wrong with the key exchange, you should not hear anything, not white thunder-loud white noise.

Yes, the certificate works only if we have the private key as well. We'll keep it for ourselves, promise!

It is a valid scenario. I am scratching my head if this can be done or not, and how complicated it is. Forbidding others to call you is easy with the permission tab, but in that case the call is not being redirected. I guess the easiest answer is that we need to check in the permission denied case if the redirection on busy is set, and redirect the call there. Forwarding rules can be very powerful, but with a lot of power comes a lot of support. We learned that lesson with the ERE-based dial plan and want to stay away from complicated stuff and instead focus on the reasonable use cases.

Because you can not run the calls for one domain on more than one core.

Maybe you can give us a PCAP trace and the certificates in Base64 format (just send a private message). It seems there is something wrong with the certificate chain representation in the TLS stream.

The answer is: The PBX runs on one core. We will not change that, there are too many implications that will negatively affect the stability. You can still utilize multiple cores by running multiple instances of the PBX. Instead of virtualization, you can bind the PBX to different IP addresses and ports, run them in different working directories, so that they can co-exist on one system. The only limitation you have then is the number of calls in one domain, which will practically limit the number of extensions to something like 500 extensions.

I believe you are almost there... Because it is a chain, I would use the Web Server certificate, empty line, then the Intermediary CA from Geotrust, then the Root CA from Geotrust. Empty lines dont matter, just make sure that the ---BEGIN CRETIFICATE----- and ----END CERTIFICATE---- are there.