Vodia PBX

You need to link the hunt group with the mailbox. For example if the mailbox extension is number 1200, you can put 1200 into the final stage. The mailbox will pick up immediately if you put in 81200, which means that it does not call any registered phone on that extension and goes to the mailbox immediately.

Hmm in principle a good idea. Generally we want to keep users from knowing their SIP password; this should be done during provisioning and based on the MAC address. The web password is another story, and there a readout could be useful; though right now we would only be able to read out numbers. And you can still send the welcome email later from the domain portal.

The snom ONE SoHo was a piece of hardware (a.k.a. the air freshener) and hostedi.am is a cloud service.

You can just buy a BeagleBone, or if you like you can also get a Rasperri PI (plus the enclosure you like the most). If you get us the SSH port, we can install it from the U.S. and save the time & money for shipping this over the Atlantic.

Yes the html folder should in the working directory of the PBX, which you can see in the status screen in the web interface; typically /usr/local/snomONE or in newer installations /usr/local/pbx. If there is not html folder then you don't have anything changed, which would be good. You can briefly check if there are changed through the web interface by checking out the directory webpages. Those files are kind of human readable, you can use a text editor to check if there is anything suspicious.

The easiest is to use the domain name in the browser when navigating to the PBX, for example if your domain name if domain1.yourhostedpbxservice.com then you would enter http://domain1.yourhostedpbxservice.com. Then you can just log in with the admin username and the password. Using DNS names also has the advantage that your clients really get the feeling that they have their "own" PBX service running there without really being aware of the fact that they are sharing the service with other tenants. Otherwise you would have to log in with the admin name @ the domain name, for example admin@domain1.yourhostedpbxservice.com as the username and the password.

Oh ok. There is plenty of information about the Windows Firewall. The point is to allow the pbxctrl.exe process to communicate with the network. I don't think that the installer can take care about this (would kind of defeat the whole purpose of the firewall); at least the Vodia PBX installer definitively does not do that for you. So you have to open the Windows firewall and add the process. For the local server that's it.

There is information on http://www.vodia.com/documentation/install_win when you are done with 5.2.3 just upgrade to 5.2.5 from there. For those who are using older Windows version it is better to install some much older versions like 5.0.1 and upgrade to the latest from there, as some of the 5.2 versions are incompatible with XP. Should not be the case for Windows 7, but just in case someone reads this with a older version...

The look has changed. Believe it or not, we have customers that have more than 50000 records to show on that page, which was cluttering the page with the index. So we took it out and just display the first few records. Then you can narrow it down with the search. When you upgrade you need to make sure that you don't have old files in the html directory or have changed the respective web page in the portal. This creates problems with the upgrade like the one we see here.

Hmm. I don't think there should be any problems between 5.1.3 and 5.2.5. Maybe you can get a PCAP trace that includes the LDAP packets?

Well, explaining you every single setting in the provisioning file would take a long time. I suggest that you automatically provision the phone and see if the problem is solved.

Right now, there is no option for this. Do you want to control this per user or should users generally not have the possibility to see their recordings?

Did you automatically provision those phones? If yes, they should use LDAP for the address book.

There was a bug

The new algorithm for auto blacklisting is still under development, this was just a hint that you might experience problems in that area.

Made a new build, one more try with 5.2.5a http://vodia.com/dow...sion-5.2.5a.xml (for i386 32/64 bit). This build has a new/improved automatic blacklisting feature, hopefully it did not break anything else.

I think this would be the best starting point http://www.vodia.com/documentation/trunk_branches

It would not depend on the OS itself; it would depend on the build of the PBX. We did not build 5.2.5a for all OS, that is why I was asking... Anyway the versions for Debian32 and 64 are available for 5.2.5a http://vodia.com/downloads/pbx/version-5.2.5a.xml

Ok I took a look at what is going on inside. The setting is not used any more. Time to take it out from the web interface. As far as I can tell we changed the behavior because it caused problems with Polycom phones and there is a simple replacement with one subscription per button. We reduced the refresh speed of the subscription to a level that is not a problem from a traffic point of view, that is why the list did not make any sense any more. I also don't believe that it is long-term maintained any more by snom or any other vendor.

Maybe trunk-to-trunk routing could come to your rescue? Then you don't have to involve extensions.

Die Dokumentation ist unter http://www.vodia.com/documentation/tsp zu erreichen. Estos verwendet auch CSTA, da würde ich gar nicht über TAPI gehen.

What OS are you using? I remember there was a glitch in one of the around-5.2.5 versions because we have introduced another call limitation per trunk that could have backfired into the regular call counting. Maybe there is a 5.2.5a available for your OS which behaves differently.

Bei Version 2.0.4 sollte es auch möglich sein eingehende Anrufe zu signalisieren. Das haben wir mit irgendeiner Software ausprobiert, der Name fällt mir aber nicht ein. Insgesamt würde ich es aber eher als "wackelige Lösung" bezeichnen. TAPI ist aber eine Technologie des vergangenen Jahrhunderts; es ist extrem schwierig Software für TSP zu schreiben da alles immer in den Windows-Kernel geladen werden muss und man nur sehr indirekt debuggen kann (und wenn man Pech hat schmiert einem das ganze Betriebssyxstem ab oder vielleicht haben wir uns auch nur blöd angestellt). Ich würde generell empfehlen für neue Projekte kein TAPI zu verwenden sondern eher auf HTTP-basierte Protokolle aufzusetzen das ist viel, viel einfacher umzusetzen. CSTA ist ein Mittelweg, da gibt es immerhin eine ordentliche Spezifikation und es gibt eine Menge Tools die darauf aufsetzen.

Well we ordered a IP connection ourself, however it will take a week before it is available at least. It seems that whole Germany will get that trunk very soon, so yes we do have an interest to make it easy to set it up.

Well the log message itself makes sense. The question is why there are two calls... What do you see on the web interface, e.g. status screen or calls? Is that in line with what you would expect? Maybe there is a dangling call that gives you the trouble. Also did you do any limitations as admin for the domain?