Handling wildcard in auto attendant

One of the lesser known features of the snomONE auto-attendant is handling of wildcard character x under the direct destinations section. This feature is very useful to perform some special operations within the AA.

The use cases can be as simple as sending the caller to an agent group or as complicated as performing a dial plan look up to send the call over to a branch office.

Example 1: Consider a case where you want certain user inputs to go to specific destinations and “all other inputs” should go to a general mail box. In a typical case, when a caller reaches your office, they are directed to the main auto-attendant. Then, say, you want DTMF input 1 to go to Sales, 2 to Customer support, 3 to Purchase and any other input should go to a general mailbox. This can be easily achieved by setting x as last setting under the User Input section of the AA. Basically, the snomONE will process each user input and tries to match to the configured settings. If nothing else matches, it will match the user input for x and send the caller to the general mailbox.

Example 2: Consider a case where you have 2 (or more) branch offices and you do not want your customers to dial different telephone numbers to reach different offices/branch locations. Isn’t it nice for the your customers to dial the local office number and get serviced from any branch office anywhere in the world?. In such cases you can configure the snomONE in main office to route the call seamlessly to all branch offices using the is AA feature. You can follow high level steps listed below to achieve what you want.

• Setup the AA->User Input to match the remote office extension. Ex: 4xx
• Setup the AA->Destination with some prefix. Ex: 777*
• Setup the Dialplan->Pattern to match this destination. Ex: 777*
• Setup the Dialplan->Replacement as everything but the prefix. Ex: *
• Setup the Dialplan->Trunk as the one that is connected to remote office. Ex: To-Remote-Office

So now, when your customer calls you and dials 425, the phone in the remote office will ring. This remote office could be in the next building or next state or in a different country. It is that simple!!!
Now with snomONE, your company can truly be a global company. Let the governments and politicians keep the country boundaries 🙂

Customization Series – snom phone web interface login

When snom phones are configured against the snomONE using the plug and play feature, everything is configured on the phone. Most of the setting are set on the phone based of the snomONE extension that the phone is configured against. The goal of the plug and play is to “do everything needed” for the proper operation of the snom phone automatically, thereby reducing the work for the administrator. This also means locking the phone’s web interface from the user with a user name and password. It is all good so far. But in some cases this can be an issue for the customers who wants to tinker with the snom phones.

As you know snom phones support multiple identities on each phone. In order to configure the multiple identities, you will have to enable the admin mode on the phone. But the plug and play disables the admin mode. As we already mentioned snomONE also locks the web interface with password. This is where the customization comes in handy. All you have to do is to change the admin_mode setting on the snom_3xx_phone.xml or snom_820_phone.xml from off to on. After the change, reboot the phone. Now you can login to the phone’s web interface and access all the phone settings.

Multicast Paging – for the hosted?

Paging, in a nutshell, a basic communication mechanism to announce to a group without really calling each one of them. We see the power of paging in an airport when they announce the boarding, departure or arrival information of a flight or in a hospital when they announce for a nurse, etc. So paging is a very useful tool to have in any PBX. There are couple of ways to perform paging – Unicast and Multicast.

It is a common knowledge that snomONE supports both unicast and the multicast paging methods. In the SIP world, the Unicast paging is achieved by sending a SIP INVITE to each of the phone with an auto-answer request. This works great regardless of whether the phones are on the same network as the snomONE. But when it comes to multicast paging, it is desirable that both the phones and the snomONE be on the same network. The main reason for this is that it is an herculean task(almost impossible) to get the multicast working over the internet. So, the multicast paging is pretty much limited to CPE installations. For the hosted snomONE installations you have to rely, mostly, on the Unicast paging.

Even though the Unicast paging is a good solution for both CPE and hosted implementations, it has some downside to it. They are – possible setup delay and CPU load. Because snomONE has to send SIP INVITE to each of the paging members and it can take few extra seconds(setup delay) if the group is really BIG. Also, the RTP streams have to be setup for each of these phones from snomONE (CPU load). So you really wish if there is a multicast paging solution that works regardless of the network structure.

As we know, there is a solution for every problem. The same goes true for multicast paging on a hosted installations too. With the snomONE-mini based paging manager (well, not an official name :-)), you can really have the multicast paging for the hosted snomONEs.

The overall setup is really simple.

• Provision the remote phones with the multicast paging group address as usual.
• Throw in a snomONE mini at the customer premise.
• Register a trunk from snomONE mini to a hosted extension.
• Create a multicast paging account on snomONE mini matching the registration trunk account and the same multicast address as the one on the hosted system.
• Now pickup any phone on the customer site and dial the multicast paging account on the snomONE mini. You should hear the paging on all the phones that are provisioned on the first bullet.

That’s it for the setup. Yes, it is that simple!

Shared line appearance, CO Lines, Key system….

Shared line appearance is one of the useful features that the good old traditional PBXs have. People refer this feature by different names – SLA, CO line, key system emulation, etc. Basically, this is a feature of mapping the line appearance (or a function key, button) on a phone to a analog port or a co-line or simply “the trunk”. When you map a specific co-line on multiple phones, you can monitor and/or use it on all those phone. So, if the “line1” is busy, everyone will know about it. If “line1” has an incoming call, anyone of the mapped users can pickup the call. If “line1” has a call on hold, you can pick it up on any one of those phones.

This feature is extremely useful especially where employee do not always sit at their fixed desks. Consider these cases – a furniture store, a warehouse, department store etc., where most of the employees on their feet all the time. In these stores the telephones are installed throughout the floor at strategic locations. So, any employee can pickup an incoming call, put it on hold and then announce to the floor where the call is. You might have heard, while shopping, “Joe, you have a call on line2”, or “Mary, please pickup the call on line4”, etc. Joe or Mary can walk to the nearest telephone and press the “line2” or “line4” to pick up the call and continue conversation.

Now you have an idea how useful this feature is. If a feature is useful to you, snomONE decides to provide it for you! Well, snomONE always had this feature but not quite complete. But things have changed recently. The most recent version 4.5.0.1075 does cleanup the issues in that area and made it easier to use. The folks at snom have done a wonderful job in documenting this feature with respect to their snomONE plus product. This product includes the NetBorderExpress from Sangoma technologies. You can find the documentation at the following location – snomONE Shared lines

snomONE – 3rd party phones

When snomONE was introduced more than a year ago, it already had one thing on its side. That is a proven base from pbxnsip IP-PBX. Yes, snomONE is a slightly modified version of pbxnsip’s “rock solid” IP-PBX.

The pbxnsip IP-PBX supported a wide range of SIP devices and provided plug and play mechanisms for several vendor devices. They include – snom(all models), Polycom, Cisco, Aastra, Yealink, Unidata, Linksys to name a few. But when the snomONE was introduced, the support for 3rd party phones was drastically reduced. There was no plug and play for non-snom phones, a limit put on how many 3rd party devices can register with snomONE etc. This was done for few of reasons. They are –

• Dedicated focus on providing zero-touch plug and play options for snom phones.
• Lack of integration support from the 3rd party phone vendors when they release newer versions. This was really a big issue for snom engineering division.
• Offer much more economical solution with snom phones and snomONE.

Well, even though all of these are done with good intentions, one important point was missing in that thought. That is, what about the folks who already invested in the 3rd party devices and still want to use the snom IP-PBX. After a long internal debate, the folks at snom decided to bring back all those features to snomONE. The result of that is a license key based support for 3rd party devices. This is implemented from the following version onwards.

Coma Berenicids(2011-4.5.0.1050)

So, today snomONE supports plug and play for 3rd party phones and also the limitations on the number of 3rd party devices has been lifted. So, you can now happily plug in those 3rd party phone of your choice alongside the beautiful snom devices!

snomONE – Under the hood

In the age of statistic junkies, who does not want to know what is under the hood of the software you are using! Many times we like to see the global view of important data that a software or an application is using for its operation. Sometimes it is just out of curiosity, other times to analyze the behavior of the application. The stats are always useful for both the customer who is using it and the software vendor who creates these applications. The information gathered is a useful tool to improve the quality of the software.

The snomONE displays some of the data and statistics on the system status page. But it also has some built-in statistics commands. These are not exposed to the web interface by default. But one can modify few lines of snomONE HTML to make those statistics or the data available on the web interface. Here are few examples –

List of call ports

If you like to see the active call ports (relates to the call legs), you can use the SSI command – call_ports. This command will display all the call ports that are currently active in the snomONE. This is useful to inspect and compare number of calls to the number of call legs.

List of audio files in the cache

The audio files are loaded to the memory before playing out to the user. Be it the ringback file, personal greetings file or music file. Some files are loaded and kept in the cache. This is generally a good thing as it improves the performance of the snomONE. But in some other cases it can create some unwanted behavior. Consider a case where a personal greeting is loaded to the cache and kept in the cache eternally. The changes made by the user to the personal greetings after is loaded to the memory will not be used until you restart the snomONE. This is not a good thing. By looking at the list of audio files using – audio_cache_files, you can figure out the cause of the issue.

List of DID numbers

When you have a lot of DIDs spread across different accounts on a single domain or spread across different domains, it is always see all of the DIDs on a single page. That’s why we introduced a new command – did_list.

There are many more of these SSI commands to display registrations, DNS cache, MAC addresses associated with the accounts etc.

As a note, these commands are mostly used for analyzing the behavior of the snomONE. So, use them wisely!

Uploading audio files on snomONE

The snomONE PBX needs language specific audio files, ringback file and music on hold files for the normal operation. But uploading them to the system is not something universal across the different operating system versions. It is relatively easy on the desktop operating systems like Windows. But under the Linux based versions, it is not that easy for many of us. In the recent versions snom has introduced a web based mechanism to download the language specific audio files as explained here – http://wiki.snomone.com/index.php?title=Software_Update#Updating_audio_files. This mechanism allows you to download the complete set of audio files. There was no mechanisms to upload specific files so far.

But there is good news for those who wish to upload language specific files or overwrite the existing files from the most recent version Coma Berenicids (2011-4.5.0.1050). Also, this new version allows you to upload new ringback wave files that can be chosen at the domain, hunt group levels to provide a customized experience. The configuration can be accessed via Admin->System->Upload Audio web page.

There are few possible syntax options depending on where the file needs to be uploaded.

• Just the file name – new_ringback.wav. In this case, the file will be copied to the selected audio language folder. Ex: audio_en/new_ringback.wav
• File with relative path – audio_de/new_ringback.wav. In this case the file will be copied to the specified audio folder under the PBX working directory.
• File with full path – C:\Program Files\snom\snomONE\audio_sp\new_ringback.wav or /usr/local/snomONE/audio_sp/new_ringback.wav. In this case, the file will be copied to the specified path.

Busy lamp, speed dial, etc….

It is always a struggle to get a balance between the features and usability in most softwares. Sometimes (or most of the times?) engineers try to cram-in all the features and totally forget about the usability or the user experience!. The snomONE PBX software also suffers from this bug every now and then. One such case is related to the busy lamp field (BLF) button functionality.

At one point, snomONE had speed dial button doing just the speed dials (as it supposed to) and the BLF doing monitoring and speed dial actions. Over the course of time the call pickup functionality was slapped on the BLF button due to popular demand. Life was good for a while and then started to hear that it really can cause undesired results, especially with a busy receptionist phone.

So, snom went back to the drawing board and made some modifications to the BLF functionality. With the new change, you have couple more options. They are –

• Monitor only option. No speed dial, no call pickup option in this.You can just see if someone else is busy or not.
• Monitor and speed dial. This option does not let you pickup the call. Also, when the LED is blinking, i.e., when monitored extension is in the alerting stage, you can’t speed dial to that extension.
• Monitor, speed dial and pickup. All in one option. If you want to monitor you can do that. If you want to speed dial, go ahead. Or if you want to pickup the call while the LED is blinking, you can do that too.

This change will be available from April 2012 release. We truly hope that this will make your (and in turn our) life bit more easier when administering snomONE!

Making the most out of snom ONE SOHO

As we all know, the snom ONE PBX comes in different sizes! That’s right, different sizes! The smallest of them all is snom ONE SOHO. The device is built to industry-standards with no mechanical parts, increasing its durability and stability. This maybe one of the smallest IP-PBXs in the world and consumes only 1/10th of the power compared to a typical computer. Pre-installed with snom ONE IP-PBX software (with a free license), the snom ONE SoHo is a convenient, purpose-built hardware solution that supports the full range of snom features. One of the cool and useful features of snom ONE is the multiple language support. But this is something that we did not encourage on SoHo, so far. It is not a feature issue on the snom ONE, but it is the space issue of the SoHo. It has only 512MB storage. The audio prompts for each language need roughly 15-20MB. That can be an issue if you want to have 5-6 different languages on this small device. But, thanks to Linux and some improvement to the snom ONE software, now you can keep these audio files on a external drive (ex: USB) and tell the snom ONE to read from this drive.

All you have to do is to create symbolic links to the audio folders under the snom ONE working directory.

Examples:
audio_en -> /mnt/usb/us_english
audio_sp -> /mnt/usb/spanish_prompts
audio_de -> /mnt/usb/audio_de

Restart the snom ONE service and you have all the language support that you wish.

snomONE virtual appliance

In the world of IP-PBXs, snomONE has been serving many happy customers over the years. This is one of very few IP-PBXs that runs on pretty much anything – a CPU, an OS and some memory- that’s all it needs!. If you love Microsoft, then you have windows based snomONE. If you like Mac, then you have one that works on Mac OS. If you are one of the many Linux lovers, you are in luck too. It can run on several Linux operating systems, CentOS, Debian, SuSE, to name a few.

Now it gets even better. Just recently, snom has come out with a Linux based virtual appliance(to know more about the virtual appliance, please refer http://www.vmware.com/appliances/getting-started/learn/overview.html ).

With the introduction of snomONE virtual appliance, the customer does not worry about how to install the OS, how to download and run the snomONE etc. All you have to do is download the snomONE virtual appliance, add this as your new virtual machine under the VM environment either internally or on the cloud.

The download links are here –
The ZIP version – snomONE virtual appliance zip .

• Download the above zip file
• Extract the file to virtual machines repository folder under the VM server. This generally extract to snomONE_VM folder.
• Using the “VMWare Infrastructure Web Access”, choose the “Add virtual machine to inventory” option and select the snomONE-CentOS-appliance.vmx file. You will see snomONE_appliance added to the list of VMs.
• Now, start the VM. Once the snomONE_appliance is started, you can login to the virtual appliance web interface using https://x.x.x.x:5480. The default user name and password is root/snomONE
• Then you can login to the PBX using http://x.x.x.x with admin/no password

The OVA version – snomONE virtual appliance – OVA .

This file is an archive of OVF file and the disks. If you already know how to deploy the virtual machine using the OVA format, please go ahead. I have not tried it due to lack of necessary infrastructure.

But nasman at http://forum.snomone.com has posted some steps. Here they are –

VSphere Client

• File Menu -> Deploy OVF Template
• Choose source OVA file
• View template Details
• Accept License
• Name & Location of Appliance
• Choose Host
• Choose Disk Format – Thin or Thick Provisioned [ I have tested with Thick ]
• Option to setup network requirements during install, but can be left blank for defaults.
• Finish to Complete

Also, the detailed instructions on how to do it is here Deploying virtual machine using OVA file

Have fun with snomONE virtual appliance!