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 :)
Posted in snomONE
Tagged AA, attendant, autoattendant, branch, dialplan, PBX, remote office, routing, snomONE, trunk, user input, VoIP
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.
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!
Posted in snomONE
Tagged CPE, hosted, multicast, network, paging, PBX, SIP, snom, snomONE, unicast, VoIP
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 126.96.36.1995 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
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.
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!
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!
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-188.8.131.520). 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.