Vodia PBX

Ja wir werden versuchen das alles zu übersetzen und dann werden wir wohl mal wieder eine Polycom-Runde machen...

Danke für die Info. Wurden die Telefone manuell provisioniert oder PnP verwendet?

Well the first choise is still snom, but you can also use phones from Polycom, Grandstream and Yealink.

I guess there is something wrong with the certificate. Please make sure that you have make sure that the certificate is in the PBX: -----BEGIN CERTIFICATE----- MIIDVDCCAjygAwIBAgIDAjRWMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9i YWwgQ0EwHhcNMDIwNTIxMDQwMDAwWhcNMjIwNTIxMDQwMDAwWjBCMQswCQYDVQQG EwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UEAxMSR2VvVHJ1c3Qg R2xvYmFsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2swYYzD9 9BcjGlZ+W988bDjkcbd4kdS8odhM+KhDtgPpTSEHCIjaWC9mOSm9BXiLnTjoBbdq fnGk5sRgprDvgOSJKA+eJdbtg/OtppHHmMlCGDUUna2YRpIuT8rxh0PBFpVXLVDv iS2Aelet8u5fa9IAjbkU+BQVNdnARqN7csiRv8lVK83Qlz6cJmTM386DGXHKTubU 1XupGc1V3sjs0l44U+VcT4wt/lAjNvxm5suOpDkZALeVAjmRCw7+OC7RHQWa9k0+ bw8HHa8sHo9gOeL6NlMTOdReJivbPagUvTLrGAMoUgRx5aszPeE4uwc2hGKceeoW MPRfwCvocWvk+QIDAQABo1MwUTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTA ephojYn7qwVkDBF9qn1luMrMTjAfBgNVHSMEGDAWgBTAephojYn7qwVkDBF9qn1l uMrMTjANBgkqhkiG9w0BAQUFAAOCAQEANeMpauUvXVSOKVCUn5kaFOSPeCpilKIn Z57QzxpeR+nBsqTP3UEaBU6bS+5Kb1VSsyShNwrrZHYqLizz/Tt1kL/6cdjHPTfS tQWVYrmm3ok9Nns4d0iXrKYgjy6myQzCsplFAMfOEVEiIuCl6rYVSAlk6l5PdPcF PseKUgzbFbS9bZvlxrFUaKnjaZC2mqUPuLk/IH2uSrW4nOQdtqvmlKXBx4Ot2/Un hw4EbNX/3aBd7YdStysVAq45pmp06drE57xNNB6pXE0zX5IJL4hmXXeXxx12E6nV 5fEWCRE11azbJHFwLJhWC9kXtNHjUStedejV0NxPNO3CBWaAocvmMw== -----END CERTIFICATE-----

Well I would say you don't have enough bandwidth. G.711 @ 20 ms takes 80 kbit/s. I don't think this is because of the phone type; probably it is a location that does not have enough bandwidth to the PBX.

A long time ago, we have also tested against Estos and it was working okay. TAPI remains to be a pain in the neck, it is very difficult to develop/debug TAPI software. We used dialer.exe mostly for testing. As far as I remember 2.0.3 is the last version that we made.

We have made 5.2.3a (http://vodia.com/downloads/snomONE/version-5.2.3a.xml) for centos32. Sorry for the inconvenience.

If you have set up the 870 for automatic provisioning and did not change the provisioning template, it will also upgrade the 870 to a newer version that we found to be more stable than the previous releases. P.S. Make a backup of the PBX working directory before ANY upgrade.

Yes, that is a know issue. The virtual machine for CentOS32 somehow got lost... Hopefully we will have it back soon.

This means that the username and/or password did not match or that you simply don't have a license for CSTA, which is necessary for TAPI.

5.2.3

Is the PBX running on public IP (exposed to scanners)? In that case you could really experience the DoS protection. Even after 9 months it should not deteriorate. For the record, which version is this?

The max_udp_invite setting is limiting how many requests the system accepts per second on UDP transport layer. This is simply about situations when the system gets flooded with INVITE requests. There are other settings how many calls you can have per system, or domain and even per extension. The log should show you why ca call gets rejected.

Well, 5.0.3 is already pretty old. Why not upgrade to 5.2.3? Maybe the phone got automatically blacklisted; also the newer versions provision a better firmware for the snom phones.

First of all, there is a reason why that limit is 50 %: We want to avoid that customers end up with jittery calls, especially in situations when a lot of calls suddenly hit the system. Because "a lot" is relative depending on the system size, this settings is changable in the pbx.xml file. You can either do the web interface trick to change global settings by hand-crafting a url-encoded GET or just edit the pbx.xml and restart the system. After you change it, you should closely watch your system if it hits and performance problems.

The shell password is set when you set the admin password for the PBX (it copies the password into the Linux). If you have a USB cable, you can still access the system (see http://elinux.org/Beagleboard:Terminal_Shells). I am not hte biggest expert on this, but there is plenty of information available.

It is indeed looking very strange. I would definitively run a PCAP (tshark) on the Asterisk system to see "their point of view". Maybe there is a firewall in between slowing down the INVITE. If the Asterisk still believes that there was a timeout, then things get really wacky. Especially because the REGISTER seems to work as expected, and just the INVITE makes problems. But I think the retransmission timeout does not mean that the request was too slow. I read this as that the retransmission did not make it at all. You see by the sequence number that the 2nd INVITE (CSeq increased by one) probably does not hit the Asterisk system at all. You will see that in the PCAP on the Asterisk system. So why would the 2nd INVITE get lost and the first one not? The first INVITE is 810 bytes and the 2nd one is 993. There is a reason why we put those numbers into the log: UDP Fragmentation. in the LAN it is usually around 1500 bytes; but in your case it might be lower and just between those two packet lengths. But as it looks to me, I would try to follow the path from the Vodia PBX to the Asterisk PBX and try to isolate where the 2nd packet gets lost.

Also die Sprache und Weblanguage lauf Settings ist Deutsch, das ist ja schon mal gut. Viel mehr kann die PBX eigentlich auch gar nicht liefern. Ich bin mir nicht sicher ob bei den 3xx-Modellen aus Speicherplatzgründen nur noch English vorinstalliert ist (die vielen neuen Features brauchen halt Platz).

Yea it should also complain about that in the logs. However you will see it very clear in the SIP messages, potentially a PCAP or just the regular log with the SIP packets inside. If you want to share logs, open a ticket on zendesk (the Vodia support system).

Ja es kommt in der Tat 415 Unsupported Media Type. Ist denn das Telefon automatisch provisioniert worden?! Dann sollte sowas eigentlich gar nicht passieren können. Was ist denn auf der PBX bei den Codecs eingestellt? Das Yealink ist sogar so eingestellt dass es nur G726 anbietet. Da ist es kein Wunder wenn da keine Verbindung zustande kommt. Am besten mal Factory Reset machen und die Telefone neu provisionieren und auf der PBX mal schauen ob da die Codecs zu restriktiv eingestellt wurden.

Ja, das wundert mich nicht. Die Daten können über sftp runtergeladen werden. Am besten ist es aber, sich erst mal über SSH einzuloggen und den genauen Pfad zu finden (/pbx/pcap/datum). Username ist root, und das Passwort ist das Passwort für den Administrator-Account der PBX.

If the PBX sends a BYE right after the ACK it is usually because the codecs don't match or there are not enough codecs available any more (e.g. G.729).

For a gateway trunk, that is okay because there are no REGISTER messages being sent. But for an outbound call, there should be a message going out to that IP address. You should be able to see that in the log. For incoming calls you should see a message coming to the PBX. Double-check that the outbound proxy on the PSTN gateway is correct. Also I would try to ping the gateway from the PBX (shell level) or ping the PBX from the gateway. Or at least try to ping them both from a client (e.g. PC) in the LAN. Maybe there is something wrong with the IP configuration, which can easily happen when you are using static IPv4 addresses. For example, if the netmask is incorrect, you may have such effects.

One-way Audio sollte eigentlich Vergangenheit sein... Ich würde mal ein PCAP aus dem Webinterface machen damit man sieht was die PBX sendet und empfängt. Normalerweise liegt es irgendwie an der Netzwerk-Konfiguration: Firewall oder falsches VLAN/VPN. 722 würde ich übrigens nicht nehmen. PSTN macht nun mal G711, und wenn man von von G722 auf G711 übersetzt klingt es wie aus der Dose, auch wenn man glauben mag dass 722 eigentlich besser klingen sollte. Bei der Umsetzung gehen aber immer Informationen verloren, die Qualität kann immer nur schlechter werden.

Das wird gesteuert über die Einstellungen für die Sprache in der Domäne oder der Nebenstelle. Falls Deutsch fehlt, liegt das daran dass die deutschen Sprachfiles (.wav) nicht geladen sind.