Vodia PBX

Check out http://www.slideshare.net/rmaclean/json-and-rest

In multiple domain environments you probably have to use real DNS names (that can be resolved with the DNS server). It looks like the FXO gateway needs to resolve the domain name with DNS and then send the request there.

The snom ONE mini comes with a older software version. It costs money to upgrade it. That explains why it is so cheap. If you want a very cheap PBX without moving parts and low power consumption, you can as well buy a Rasperri Pi or a BeagleBoard and run the PBX version on it. If you have 3-4 person in your office, you should be able to keep the total damage much lower than the price of a snom ONE mini and you are even running the latest version.

As we are moving everything to REST, you can eventually even design your own wallboard using JavaScript. We have the real-time call reporting already done using websocket, and that technology can be used also for filtering out the ACD-relevant calls. One thing is for sure: The wallboard will be based on HTML5 and JavaScript (probably not only for snom ONE).

I agree. We are in the process of pulling the various sources together from wiki.snomone.com and kiwi.pbxnsip.com and put it on the regular webserver. The training videos are also something that we need to re-address; however we will change the format, essentially to show the text written in the documentation "in action". For many people, that is a fast track on how to get things done.

The m9 is different because of the DECT protocol. The m9 does not change it's ringtone because of the SIP header.

You mean IVR node? If you have a PCAP, is it unencrypted? If that is so, try to play back the audio stream. This way we can exclude that the phone has a problem.

What is in the "generated" folder of the PBX? Can you check the SIP trace of the phone if there is anything going out?

Well in the dial plan you can send a call to an extension. You might have see that already. That means that the FXO gateway needs to register to the PBX like an extension. Then when the PBX sends the call to the gateway, the question is where is the number to be dialed. Here the gateway must look into the To-header, not the Request-URI. Then his project might become possible.

The easiest way would be to run the gateway on a public IP address. Then you can just set up a regular trunk to the PBX as if this would be a LAN deployment. Of course you should make sure that the gateway accepts traffic only from the IP address of the PBX. But for most quality PBX, that is not a big problem. The good news here is that hosted PBX have a static IP address.

Yepp, that's another way to do this especially when USB media is so cheap. In this case you can also use this (notice that the z is not in cvfz): cd /usr/local/snomONE tar cvf /media/usb/backup-pbx.tar . >/dev/null

Well if if works well then there is nothing else to do but make a backup (also on the network configuration in case your host hardware breaks)

Thanks for sharing this with us! It was something hard to find.

Now I am puzzled. What do you see in the INVITE packet that is being send from the PBX to the ATA? I guess that's the key question now.

You should wait for the 2nd ring; in the analog world, the caller-ID is transmitted between the first ring and the second ring. I guess you did that already. Before the 2nd ring you will always see "Incoming Call": Actually it is not so much the problem of the ATA to render all characters; the connected telephone must of course also support all characters. I am sure that the ATA supports "IA5"; at least I don't think it is worth going too deep into the encoding path. The only characters that could be a problem are ( and ); they are used in the hunt group caller-ID setup when you want to mix the group and the caller-ID. Maybe give an extension the username "A(B)" and see if the ATA can display that.

The ATA is responsible for encoding in IA5. In short words: Try to choose a very short name for the group and choose only simple characters (e.g. SG1 instead of "Sales Grüppchen 1"), so that you don't exceed the limits of the caller-ID display on the ATA.

Did you plug and play the phone? What is in the "generated" folder of the PBX? Can you check the SIP trace of the phone if there is anything going out?

Windows has a lot of great documentation on how to set up network interfaces. I don't want to repeat that here. However what is important is (like in Linux) that the packets that are being sent to the public Internet are using the public IP address of the PBX. This is like in Linux depending on the routing setup of the PBX. In Windows, you can control that with the metrics on the interface. If the metrics are the same, Windows tends to choose the one with the higher bandwidth. Unfortunately, in many environments the LAN has higher bandwidth that the WAN, in which case you end up with the wrong routing. To verify that the packets to the Internet are using the WAN interface, use the "route print" command. In addition to that, what I have said in the Linux port before also applies to the Windows installation. Be aware about the fact that there are scanners in the Internet who are testing port 5060 for SIP replies. Make your that your passwords are okay by setting the password policy to medium, make sure that you get email (or text) notifications and consider running the service on a different port than 5060. You can actually have the internal service listen on port 5060 and the public IP listen on a different port, with a port setting like this "192.168.4.5:5060 212.213.214.215:8458", which would mean "bind one socket to port 5060 on the IP address 192.168.4.5 and another one on port 8458 on the address 212.213.214.215". Also, if you are running Windows Server on a public IP, make sure that the general rules for securing a Windows server are being applies. However, make sure that the pbxctrl.exe process has the right to communicate with internal and external sources.

Okay, Linux first... Most distributions have a very detailed description on what you need to do to set up interfaces. For example, in Debian you find that information in https://wiki.debian.org/NetworkConfiguration. Once you have the interfaces configured and one has a private and the other one has a public IP address, you must make sure that the routing works okay. The important point here is that the default route must use the public IP address, so that when you send a packet out, the host inserts the public IP address of the PBX. You can verify that with e.g. whatismyipaddress.com, for example by using "wget http://whatismyipaddress.com". It is definitively worth spending some time on making sure that the routing is fine; once that you have the routing set up you will enjoy out-of-question quality inside the LAN (on the private IP address) and you will not have problems with NAT problems on the public IP address. Another point that you should consider when running the PBX on public IP is that you are now exposing the PBX to scanners. You should definitively set the password policy of the PBX to at least medium, so that those scanners don't find trivial passwords. You should also have your email notification as administrator set up, so that you will get notified when the PBX blacklists IP addresses because of attacks. You can also have the PBX operate on a different UDP port than 5060; this makes it less probably that someone finds the PBX on public IP.

The PBX runs in /usr/local/snomONE. You can use tar to make a backup: cd /usr/local/snomONE d=`date +'%Y%m%d%H%M'` tar cvfz ../backup$d.tgz --exclude 'audio_*' --exclude tftp --exclude 'recordings/20*' . >/dev/null Then you can fetch the file in /usr/local with sftp or psftp (if you are using Putty). The SSH password is the same like you have set for the admin account in the web interface of the PBX. If you restore the directory on another server, you need to re-activate the license key or get a new one. snom ONE permits one re-activation; however you need to reset your license key from the snomone.com account first. Because snomone.com is available 24/7 (not like humans), you can do this fail-over rather quick. But you can do this only one time; we had cases in the previous version where customers had ten or more "hardware failures" and I think that was going too far.

Just log in with SSH and make a file system backup. The web interface is not the right way to generate huge files.

Maybe we should rename the item to "automatically recorded calls where the extension was involved"...

I would be thinking that the device has a problem with the character set (I believe that IA5 is the encoding here) or the length of the caller-ID. The length between the first two rings sets a limit on how long the string can be.

Hmm. There were some JavaScript problems in the domain overview. Either move straight ahead to 5.1.2 or check out if there is anything in the log of the browser.