Vodia PBX

Sieht so aus als ob da was mit der Deutschen Übersetzung schief gelaufen ist. Sind bei dem System Anpassungen in der Sprache durchgeführt worden (im Webinterface)?

Try to load an empty license key (base64-encoded) first, then apply the activation code again with the case changed (e.g. Abc instead of abc). We have found problems when moving away from the snom ONE free license code to a activation-based license code because the license URL is changed by the snom ONE free code.

You dont have to actually use a DNS server entry for that. You can as well set the outbound proxy on the phone using the IP address, and the domain name as the "DNS" (text) address. It all works automatically if you use PnP.

Remember that the PBX uses HTTP sessions with variables inside the PBX, not the browser. Can you reproduce the problem if tenant 1 is using one web browser/computer and tenant 2 is using another one? If those changes are made within the same session, you must make sure to switch between the tenants by going to admin/domains to switch the domain.

Well as we are adding features, we also add audio files... From time to time we re-record the language specific files, and then those updates include additions. A way to deal with this is to use theaudi_en directory, then rename it to audio_uk, and overwrite the prompots with the latest UK version, so that the US-version is there as the default file. As for the UK, I hope the users can live with US-prompts for time being.

Is this about the cell phone virtual assistant? Then it could be that the audio files are simply not recorded yet.

Yea XP is really difficult, cuz we are using some later stuff for displaying the content from Windows. But Windows Vista/7 should work... (in case anybody is still running Vista ).

Interesting DoS . I guess we need to check if a SOAP operation like this can exceed the license.

Could be a problem with the right .net version; the XamlParse problem sounds familiar... We'll have to take a look at this and see if there is something that we should not use.

We need to take a look at this on Monday back in the office.

Not sure if that got mixed up in the translations and you actually need to put that into the permission tab of the boss (maybe put the boss into the secretary and the secratary into the boss, then it should really work and then try to take one out...).

Where did you set the value? On the one who calls or the one being called? The DND override feature is supposed to give the "secretary" the power to call the "boss", and the setting is supposed to be in the secretaries extension. What did you put in there (list of space-seperated extension numbers)?

Well, thats why we have these reports This problem is usually caused by extensions behind "crappy NAT routers" where the port changes all the time. There is a feature that sends an email to the admin every time the registration changes in the registration tab for the extension, turn it on at least for those who have remote registration and you should see in your inbox which ones make trouble.

Mein Punkt war für outbound calls vom Handy (Inland) ins Ausland. Schöner Seiteneffekt, die Caller-ID der Nebenstelle wird angezeigt. Grundsätzlich ist die Idee, das das Handy wie eine Nebenstelle funktioniert, mit ## kann man den Call halten und dann z.B. intern weiterleiten oder eine Konferenz machen. Wenn man mit dem Handy im Ausland ist und ins Inland telefonieren will, kommt es sehr darauf an, was die Datenverbindung kostet und hergibt. Dann kann man ggf. ein Soft phone auf dem Handy einsetzen und dann quasi "native" als Nebenstelle agieren.

es gab schon größere Peinlichkeiten in der Geschichte des Computers...

Ja vermutlich ist der normale User verwirrt dass das System so perönlich ist... Zuhören! Dann kann der normale Benutzer auch z.B. ganz leicht international telefonieren ohne die Handy-Rechnung zu stressen.

Das "Twinning" kann man natürlich abschalten indem man einfach keine Handy-Nummer verwendet. Diesen speziellen Aspekt abschalten, hmm bin mir nicht sicher ob das geht. Aber wenn man vom Handy direkt eine Nebenstelle anruft (keinen AA), dann sollte es auch dort direkt klingeln.

Das ist in der Tat sehr seltsam. Lizenz abgelaufen (das muss dann aber eine recht alte Lizenz sein)? Oder zuviele Konten auf dem System für diese Lizenz? Provisionierungspasswort geändert?

Hmm. Hier ein paar Ideen. Welches Rufschema ist der Nebenstelle zugewiesen? Könnte 120 eine Notrufnummer sein? Wurde das Telefon mal auf die Fabrikeinstellungen zurückgesetzt und damit alle vorherigen Einstellungen übergebügelt?

Könnte es sein dass der Anruf vom Handy kommt, welches einer Nebenstelle zugewiesen ist? Dann ist das ein Feature... Einfach mal von einer anderen Nummer probieren.

Hmm. Das ganze findet im LAN statt? Dann wäre es schon sehr seltsam wenn dort die TCP-Verbindungen verloren gehen (das wird aber durch die Änderung des TCP-Ports dort oben suggeriert). Die anderen Telefone machen keine Probleme? Vielleicht gibt es ja Ärger mit einem Ethernet-Switch oder Kabel welches zwischen dem Telefon und dem Server ist.

Whow, that is clearly a "warning shot" and you have to so something. If you are using SIP trunks, make sure that you either use an outbound proxy or explicitly specify the IP addresses where you expect traffic from. If you dont do that, the PBX assumes that traffic from unregistered sources are coming to that trunk (search for SIP ENUM if you want to find out more). It can be a feature and usually you can call only internal extensions, no outbound dialling; but if you dont want that, you definitevely want to shut this down. When you have set up the trunk without outbound proxy, you should have seen a warning about this. Also, make sure that you use "good" passwords. Some people turn the password policy to "off", and then it is possible to use trivial passwords: Then you are really in trouble, because then outsiders are really very close to make some "free" international calls, paid by you. In the web interface, then you will see warning signs next to the accounts that have trivial passwords. If you are provisioning phones, you should also consider setting a good password in the domain for the plug and play. And of course, you should have set a good password for the administrator. Most of the problems come because people choose trivial passwords: 1234, computer, password.

I dont think this is a license problem. We tried a similar setup some time ago with "mixed" results. I agree the solution of the virtual IP address is the right way to go; however you must pay attention to the routing and make sure that the PBX uses the right (virtual) IP address when failing over. At the end of the day, the failover time is far longer than with a virtual machine, where registrations stay up, and calls dont get dropped during the failover. Anyway, the automated failover may help to provide a simple solution.

SIP works different than HTTP. While it might be possible to forward the TCP/TLS connection like you forward that to a web server with a successful registration, this does not work with RTP any more, as this is UDP-based. The PBX needs to "advertize" it's address for UDP; it probably tells the phone to send the RTP to a private IP address, which cannot be routed from the phone. There is a lot of talk about this problem, search for SIP and NAT--you'll get the idea. My short form is: You need to be able to route packets to the PBX from anywhere where you want to use the service and the PBX host needs to be aware about this. This is a classical problem in SIP and VoIP. There are some tips at http://wiki.snomone.com/index.php?title=Server_Behind_NAT.

Okay. If you run wireshark on the PBX, you should see that the PBX is using the IP address that was assigned to the VoIP DSL line. It is easy to mix that up with the address of the other line, escpecially if you want other traffic like HTTP to run through your "data" DSL line. Actually it is quite difficult to really seperate both on the PBX host, so I would tolerate some non-RTP and non-SIP data that goes to the PBX (like HTTP and TFTP for configuration) also to go through the VoIP DSL line. So in other words, the PBX host should have only the public IP of the VoIP DSL line, and not the one from the data DSL line.