Vodia PBX

Man kann ja jeder Nebenstelle mehere Namen zuweisen, z.B. "40 41 42 47 030398330 03039833111" ist völlig legal. Die erste Nummer ist die primäre Nebenstellen-Nummer, die bei ausgehenden Anrufen herangezogen wird (falls keine ANI für externe Anrufe definiert wurde). Das hilft allerdings nicht dabei, die Klingeltöne zu definieren. Von snom ONE aus sehe ich als einzige Möglichkeit, den Anrufe über eine Rufgruppe zu schicken; dort mann man dann die Klingelmelodie auswählen--wenn auch nur im bescheidenen Rahmen aber immerhin. Auch bei den Rufgruppen kann man mehere Nummern zuweisen.

Der PBX ist es egal ob das PSTN-Gateway "intern" oder "extern" ist oder ob es überhaupt ein Stück Hardware ist (Service Provider). Wichtig ist das das Gateway SIP spricht. Meiner Meinung nach sind die Karten eher problematisch, da sie fest im PC verbaut werden müssen und den Störungen des PC ausgeliefert sind, was vor allem bei Analogleitungen m.E. ein Nachteil ist. Seperate Gateways haben meiner Meinung nach auch längere Investitionszyklen als PC-Karten, stehen im Zweifel auch mal zehn Jahre oder länger da (solange es noch ISDN Anbieter gibt!) während Server es normalerweise nicht ganz so lange machen. Für ISDN gibt es einige Gateways zur Auswahl wie z.B. Beronet, Patton oder AudioCodes. Man kann sogar über eine FritzBox mit ISDN-Anschluss raustelefonieren, da die FritzBox auch mit SIP klarkommt; allerdings waren meine Erfahrungen vor ein paar Jahren beim Thema Echo eher "suboptimal". Das Gateway kostet Geld; läßt sich aber auch mit anderen PBX einsetzen und ist insofern kein rausgeschmissenes Geld falls snom ONE doch nicht zum Einsatz kommt.

Asterisk oder snom ONE macht kaum einen Unterschied. Beide müssen Daten von A nach B schaufeln, dekodieren etc. Ich würde mich mit den Investitionen auch erst mal zurückhalten, bei einer kleinen Installation reicht auch ein PC der schon einige Jahre auf dem Buckel hat. Zum Vergleich: snom ONE mini schafft mit einem 1.4 GHz ARM und 512 MB Speicher 10 Gespräche gleichzeitig (im Labor haben wir es auch auf 30 gebracht, mit ein paar Abschlägen empfehlen wir dann doch eher 10). Ich denke dass das ein 5 Jahre alter PC auch locker schafft. snom ONE läuft ja unter allen möglichen Betriebssystemen; ich würde einfach mal einen alten Rechner nehmen, dort snom ONE installieren und ein paar Anrufe parallel machen. Ich wette, dass der CPU-Load Graph mit 4 Telefonen daran auf der Status-Seite nie die 5 % übersteigen wird.snom ONE mini würde ich mir dann überlegen wenn alles läuft und die Stromkosten für den weiteren Betrieb des PC (manchmal 400 Watt!)ökonomisch für snom ONE mini sprechen.

Sorry, this is not like in the old DSP times when you had 30 channels, guaranteed. The question how much calls you can make is sometimes like "how many emails can I send from my Exchange server?"... Registrations can scale up into the thousands (TCP/TLS connections require 64 bit OS at such numbers), and the key element for memory is how many CDR you want to keep in memory. The key factor is the calls. As a rule of thumb, you can run around 100 simulteneous calls on a modern, but not top-notch core. Dual core makes sense, so that the OS can run the PBX on one core and everything else on the other (quad-core is a waste on the PBX). If you go highest CPU, you can get up to 200 calls running. The intensitiy of the call CPU load depends if you must perform transcoding (translate between different codecs), record calls, SRTP encryption and decryption, and of course conferencing and call barge in, whisper mode and listening in. The CPU performs a real-time CPU monitoring and begings to block additional calls when the load is getting to high, so at the end of the day is what probability you want to take that calls are being rejected because of resource exhaustion. My recommendation is to start with a ~1000 USD standard server and monitor the performance load (sent every day). If the load gets regulary into the 50 % area, then it is time for a hardware upgrade. Otherwise and most often, the 1000 USD server will be a good investment and can run the service for many years. Instead of spending 2000 USD for a single server, I would rather buy two standard servers and run them in a virtualized environment with failover (e.g. Hyper-V), so that a hardware failure will not result in a long service shutdown: In such a case, your service might continue in a blink of an eye.

Hmm. The log looks "beautiful". Sometimes the provider also change things, which can drive you nuts trying to figure out if any change on your side is the problem. The PBX also allows that in addition to listening to RFC2833 (RFC4733 now) you can also do inband DTMF detection. Maybe this is the way to go for you now.

You need to cd to the working directory of the PBX. If you are not sure, you can search the PBX process with ps -C pbxctrl or ps auxww|grep pbxctrl, then you will see in the argument what the working directory is (or cd /proc/<pid>/cwd). Then in that directory you'll either already have a html directory or you make it with mkdir html. Then cd html, and there you have to copy the pnp.xml file, e.g. cat >pnp.xml (then copy & paste the pbx.xml from the web interface into the terminal window and press ctrl-D). After this, you need to restart the PBX as it does not re-read the file system every time that it provisons a phone.

The PBX takes any number which is set from the web interface. In old versions, we just used an input field where you could enter any number, for example 31415927. In order to increase the usability, we changed that to a HTML select element and propose only a few entries that make sense, hopefully. In your case, it obviously did not make enough sense. But with the ability to change the web page content through the web pages portal of the PBX, you can change it easily on your own and add those values that you would like to see. Then you can go back to the page and select the dropdown from the (new) list, including your changed number. We dont have to build a new software version for that.

The /prov should not be included when expanding the {http-url}. If that version does that, sounds like a bug to me. Woraround: replace the {http-url} in the template yourself with the IP address of the PBX until we have a build with a fix.

Hmm. Last resort is to put the file under html/pnp.xml. This overrides the internal data in the PBX executable. In that case, make sure that you remove the webpages entry for that page either on the file system or by restoring the default from the web interface.

Every web page on the PBX can be customized. For that, log into the web interface as administrator, then make sure that you are in admin mode (not domain mode), then navigate to the web page settings, select the page where the cell phone timeouts are (some usr_core file I believe) and change the select HTML statement there. Then you should be able to select the values you added there.

This will also be included. Maybe the beta version is still struggling with it; however attendant without transfer would not make too much sense. However this will require that the attendant is using a headset (no 3PCC for external phone).

The timeouts are just proposals. If you dont like them, just change the web site template and add another option 60 seconds.

The password is the domain PnP password, which is stored on the PBX. If the phone is provisioned by the PBX, you can change the password there and then the phone will take the updated password.

If outgoing calls work, you must be close. Can you get us a log for the incoming call? Does the PBX receive an INVITE?

Well... That feature was born at times when the phone were only able to display single images; and it was the PBX job to use that feature for moving pictures. In the meantime, the phones support at least MJPEG, so that the buren of animating pictures can be moved to the phones. It is not done yet, but at this point we also dont want to invest more effort in the single picture moving topic.

We dont link statically. There are some issues with binding to "all addresses", in order to make IPv6 migration easier some OS also bind to IPv6 addresses. We tell the OS no to do so, but maybe something really is different in the library that screws it up. Anyway, the /proc interface has a settings for that (/proc/sys/net/ipv6/bindv6only), you can try to put a "1" into that and then the PBX should always bind only to the IPv4 and Ipv6 interface seperately.

Could be as simple as it tries to fetch the generic (MAC-independent) file which is not there, but that is no problem. If the phone is registered and has it's settings, I would say problem solved.

Why dont you just use the cell phone twinning feature? You can also tell the PBX to wait 10 seconds before start calling the cell phone.

Bingo. Check out your pnp.xml file from the web interface and add a line that matches the PolycomSoundStationIP string (it is PolycomSoundPointIP there). We'll also change it in the code, so that future version will have this fix automatically.

What you can do is run a web browser and select the calls tab for the agent group account in the domain on the screen.

Hmm. When the HTTP protocol is used, the PBX web server looks at the user-agent type in the request if there is no session established--if it is something "well known" it looks for files in the tftp directory (and PnP files). It seems like the IP 6000 sends something different from the other Polycom phones. Workaround is to use TFTP, where this mechanism is not neccessary and all phones are grabbed out of the tftp folder. Otherwise if you can tell us what HTTP request the phone sends, we can check if we can change/add that in the default configuration.

Well the term dial plan causes some confusion sometimes. On the PBX the dial plan tells the PBX how to route outbound calls if no internal resource matched the dialled number. Phones may also have local "dial plans", that essentially tell the phone when it should assume that the dial button has been pressed. You probably provisioned a phone dial plan with the domain PnP settings "use 3 digit dial plan". Then customers have to put a "1" in front of the 10-digit number that they want to dial (always 11-digit dialing in NANPA region USA/Canada). IMHO it obsolete in 2012 as really everyone now is used to cellphones where you always have to use the green check button to initiate the calls--and you can do the same thing on the IP phone.

Yes, you might want to pay attention to the PBX executable to make sure that you have the latest version. But apart from that you can just copy & paste the PBX working directory.

There is a description on the Wiki on how the PBX routes calls to the right extension: http://wiki.snomone.com/index.php?title=Inbounds_Calls. The country code setting (http://wiki.snomone.com/index.php?title=Domain_General_Settings) is also important; the PBX uses it to interpret numbers that are not clear as global nombers (for example 398330 is translated into +4930398330). So in short words: (1) Make sure that your domain has the right country code and the right area code. (2a) Either use the alias names of the accounts (e.g. "40 004930398330") to listens to what account has which telephone number. or (2b) use the trunk regular expressions to for example extract the last 2 digits from the MSN and use that as extension number.

The attendant console will be able to show the status of other extensions.