Vodia PBX

Well it is a standard Linux running there. I would check if there are languages installed on the system that you dont need (login through SSH), each of them make 15-20 MB. There is plenty of stuff installed there that you don't really need, for example phython, perl, httpd. We did that for the next production lot for you; be careful removing critical files that will make it impossible to login again. We did that a couple of times when preparing the new SoHo, and we have to restore the file system with the JTAG connector after that :-S And you still have the chance to use external media, e.g. USB sticks or SD cards. That makes sense if you really have to put a lot of data on the system.

Yes, the upgrade from 4.3 to 4.5 comes with the problem that in many cases, you have to review the trunk header representation. 4.5 adds great flexibility, and this way you can deal with practically all providers (take a look at http://wiki.snomone.com/index.php?title=Trunk_Custom_Headers); however this is not 100 % backward compatible and you might have to try again a few combinations. The good news is that most prople who upgraded found the right combinations after a few tries.

That's debatable. Generally speaking, HTTPS is so much mainstream today that it is not a big problem to use it. The only problem is the availability of a trusted certificate, so that every web browser accepts the content. But also with HTTP, someone else would have to know the username and password in order to execute something. The risk that you are talking is that someone records the traffic to the PBX and then filters out the username password; in a WLAN scenario in public places that is something I can think of (a bored traveller who has nothing better to do than running Wireshark to see what is going on). I would always use plug and play for the phones. Then you can just ask the user to reset the phone after someone has screwed the configuration up. In the age of facebook, pictures are considered not sensitive information any more I guess...

Check if the file system is full (you can see that in the status screen of the PBX). If thats is the case, remove some files and make a backup from the web interface. Dont just reboot, as then your config might really get screwed up.

If you have problems with the quality, most likely you simply don't have enough bandwidth. Keep in mind that there is upstream bandwidth and downstream bandwidth. While the upstream can be relatively easily be controlled by you and you equipment, the downstream can only be controlled indirectly by you (AKA traffic shaping). If you hear packet drops, it is most likely the downstream. Some people just get a 2nd DLS line to deal with the problem and use the 2nd line exclusively for VoIP traffic.

The later executables (4.5 and higher) update the Linux root password when you set the PBX admin password from the web interface (regardless of what your admin username is). Before that, the default password for root is "nosoup4u".

Right now thats hard coded. We can change it or make it a setting, this would be a safe path for you to get this problem solved finally. However, it would be good to know why other programs can use PLAIN and we cant. Can we give you a test build where try one more time to use PLAIN, but with only one ID? (What OS are you using?)

Hmm. Actually the PBX does not support CRAM MD5; it supports only PLAIN and LOGIN. Is there something in the middle?!

Well, I would triple-check if the password is really the same... And what else you can do is to take a look at the log messages when another client registeres. Also, check if the PLAIN authentication is okay for the user voicemail. Maybe the server does advertize it, but does not accept if this this user.

Apart from scanners in the internet, even valid devices with wrong passwords can be a problem as some of them retry to register without thinking, which becomes a DoS. Maybe that is the case with this m3. Other problem cases are when a snom phone with an extension board uses a SIP subscription ("dialog" state) for each button, which also looks like DoS for the PBX (workaround: use the button assignment on the PBX). The whitelisting works only on the IP address. This can be a problem especially when there are multiple devices behind a NAT router and one of them has the wrong password, which can blacklist all devices behind that NAT.

Unsere snom ONE plus läuft auch auf Public IP, kein Problem. Ich würde mir aber vom Support das SSH-Login freischalten lassen (Passwort ändern).

Okay, now we are talking secure... So are you sure your username is voicemail, and not voicemail@mail.alabu.com? If you have other clients working, that should be easy to figure out. Also, did you double check the password? For PLAIN authentication, it is possible to have authorization identity and authentication identity different (though the PBX does not support that difference). Could this be the problem? Any log from the mail server? I think we are close.

Ja, letztlich ist es so dass die PBX mit einem Interface auf public IP ist. Damit hätte ich auf der PBX-Seite kein Problem; aber ich würde noch überprüfen ob noch irgendwelche anderen Dienste auf dem Server laufen die nicht laufen sollten (z.B. FTP). Den Bintec router kenne ich nicht; sollte aber nicht allzu schwer sein, die Pakete anhand er IP and das richtige Interface weiterzuleiten.

Im Prinzip ja. Ich würde mir vorher allerdings nochmal die Routing-Tabelle vor Augen führen. Der PBX-Teil ist der einfachste (wenn das Routing klar ist), die PBX macht das dann alles automatisch.

Import the following certificate (available from https://certs.godaddy.com/anonymous/repository.seam): -----BEGIN CERTIFICATE----- MIIEADCCAuigAwIBAgIBADANBgkqhkiG9w0BAQUFADBjMQswCQYDVQQGEwJVUzEh MB8GA1UEChMYVGhlIEdvIERhZGR5IEdyb3VwLCBJbmMuMTEwLwYDVQQLEyhHbyBE YWRkeSBDbGFzcyAyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA0MDYyOTE3 MDYyMFoXDTM0MDYyOTE3MDYyMFowYzELMAkGA1UEBhMCVVMxITAfBgNVBAoTGFRo ZSBHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR28gRGFkZHkgQ2xhc3Mg MiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggEN ADCCAQgCggEBAN6d1+pXGEmhW+vXX0iG6r7d/+TvZxz0ZWizV3GgXne77ZtJ6XCA PVYYYwhv2vLM0D9/AlQiVBDYsoHUwHU9S3/Hd8M+eKsaA7Ugay9qK7HFiH7Eux6w wdhFJ2+qN1j3hybX2C32qRe3H3I2TqYXP2WYktsqbl2i/ojgC95/5Y0V4evLOtXi EqITLdiOr18SPaAIBQi2XKVlOARFmR6jYGB0xUGlcmIbYsUfb18aQr4CUWWoriMY avx4A6lNf4DD+qta/KFApMoZFv6yyO9ecw3ud72a9nmYvLEHZ6IVDd2gWMZEewo+ YihfukEHU1jPEX44dMX4/7VpkI+EdOqXG68CAQOjgcAwgb0wHQYDVR0OBBYEFNLE sNKR1EwRcbNhyz2h/t2oatTjMIGNBgNVHSMEgYUwgYKAFNLEsNKR1EwRcbNhyz2h /t2oatTjoWekZTBjMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYVGhlIEdvIERhZGR5 IEdyb3VwLCBJbmMuMTEwLwYDVQQLEyhHbyBEYWRkeSBDbGFzcyAyIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5ggEAMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQAD ggEBADJL87LKPpH8EsahB4yOd6AzBhRckB4Y9wimPQoZ+YeAEW5p5JYXMP80kWNy OO7MHAGjHZQopDH2esRU1/blMVgDoszOYtuURXO1v0XJJLXVggKtI3lpjbi2Tc7P TMozI+gciKqdi0FuFskg5YmezTvacPd+mSYgFFQlq25zheabIZ0KbIIOqPjCDPoQ HmyW74cNxA9hi63ugyuV+I6ShHI56yDqg+2DzZduCLzrTia2cyvk0/ZM/iZx4mER dEr/VxqHD3VILs9RaRegAhJhldXRQLIQTO7ErBBDpqWeCtWVYpoNz4iCxTIM5Cuf ReYNnyicsbkqWletNw+vHX/bvZ8= -----END CERTIFICATE-----

Das ist selbstverständlich und wir machen das tagein-tagaus. Vielleicht hat Marketing vergessen, das überhaupt zu erwähnen . snom ONE kommt mit mehreren IP-Adressen klar, z.B. 192.168.1.2 und 213.214.215.216 (man kann sogar IPv6-Adressen da reinmischen). Wichtig ist es den den Betrieb im Internet, dass die Adresse geroutet werden kann. Im Klartext: Das Telefon zuhause muss der PBX auch ein Paket schicken können. Klingt trivial, wird aber oft in Frage gestellt. Wenn eine Firewall in der Firma im Spiel ist, ist es am einfachsten die PBX in eine DMZ zu stellen, aber nach wie vor eine öffentliche Adresse zu verwenden. Port forwarding funktioniert gut bei Web-Servern, da die PBX aber auch RTP (UDP) Daten schicken und empfangen muss, bringt ein einfaches Port Forwarding nicht viel. Mehr unter http://wiki.snomone.com/index.php?title=Server_Behind_NAT auf Englisch...

Okay, one step closer... So I assume that port 465 is the right one? The connection refused suggests that there is something wrong with the port number... You can also set TLS logging to log level 9, to see what is going on on the SSL level. There should be some handshake messages going back and forth.

Whow, danke.

Mapping a button to the record function should be possible for snom 300.

We tried it here and it did work. We could see the certificate in the list. Hard to say what the problem is... Maybe the browser has a problem to encode such a "long" packet?! Yes, you can try to edit one of the XML files and see if that way you can get it in. Also, double check if you have accidentially modified the reg_certifiate.htm web page in the web page control panel.

Yes thats a valid request and it is in the works. Another option would be to use G.726 (known from DECT), which is 32 kbit/s. If you consider the packet overhead for 50 packets per second (16 kbit/s), you'll end up woth 32 + 16 = 48 kbit, versus 8 + 16 = 24 kbit/s for G.729A and 64 + 16 = 80 kbit/s for G.711.

I agree this is a stupidity that we have on the SoHo devices. The next generation will just use the DNS server that is provisioned by DHCP or statically. The PBX ready the /etc/resolv.conf file. Quick & dirty workaround is to edit the file, and then make it read-only so that other processes cannot overwrite it. If you want to do it properly, you need to drop dnsmasq (using aptitude), but once you get into that path, you'll probably have to update a lot of packages. We did that now for the next generation, so we know what we are talking about :-( so maybe you just do the quick & dirty workaround.

Sollten wir vielleicht dann auch mal im Template auf der PBX ändern....

Ja, genau. Ist ein schwieriges Thema. Die Telekom wird deswegen ihr ISDN nicht ändern...

Ansonsten ist es ja auch möglich, die Konfiguration auch auf Nebenstellen-Ebene zu steuern. Mit anderen Worten, man kann für jedes Telefon das Template so anpassen, dass dort z.B. die CRM-Einbinding gleich mit provisioniert werden kann, ohne dass man sich mit dem HTTP-Login auf dem Telefon rumärgern muss.