These days, more and more people want to stay in the loop as much as possible. With cell phones being almost a necessity, this statement holds true even more. We all want to be notified in one way or another when something of interest happens, whether it’s a Facebook message or a Twitter DM. Using PBX dial notifications can help keep you in the loop if and when you are on the go and not currently at your PBX extension’s location. I know I’m stepping out of the contact center realm with this PBX-specific topic and that’s ok. Let’s talk about these dial notifications. Continue reading Would You Like PBX Dial Notifications for Incoming Calls? You Can Have Them!
In my previous feature highlight posts they have often contained screenshots, details of the options, and given a sample a use case or two to help explain what could be accomplished with the features. The two that I’ll talk about today are mostly unseen in terms of the admin screens and really only come into play as a phone rings. So they are not as obvious as the past ones seen as options on the admin screens but could be just as useful depending on your use case. Continue reading Feature Highlight: A Couple of Hidden Features
The common conference room, a necessity in today’s world with employees working from home, travelling, and distant customers. No product with PBX functionalities should be without one.
The options seen are:
- Name – a Friendly name. If the room is used for a purpose, as our example is, then it’s best to name it after that. This will be the name seen elsewhere within the system.
- Extension – the extension used for directly dialing it from an extension.
- PBX Server – This is hidden if your system has a single PBX server. In the case where there is multiple this can be used to distribute load or in the case of a geo-diverse system ensure the conference is on the server closest to the majority of participants to ensure quality and limit bandwidth usage.
- PIN – a numeric pin to secure the conference with.
- Disable first member message – If checked this will not playback a message stating the first member is the only one in the conference.
- Announce user count on join – If checked this will announce to the user how many users are already in the conference they are joining.
- Play music on hold for single member – If checked this will play music on hold when the conference has a single user. Otherwise the user will only hear silence.
- Music On Hold Class – what music on hold to play when it’s a single user conference and the above is checked.
- Suppress enter/leave sound – If checked a user joining or leaving the conference will not trigger the tones to be played to all conference members.
- Announce names on enter/leave – If checked each user joining will be prompted to record their name before they join. This recording will be used as the join or leave
With all of these options you can configure the conference rooms you needed. However to fully leverage conference rooms, or any single feature, the ability to combine and interlink them to suit your needs is required. Let’s take the example of a daily standup which needs a conference room for a few remote employees. It’s always starts at 8am and lasts about 30 minutes. One way to ensure outside callers do not use it outside of this hours is a pin but you can also mix it with the Routing Rules so the DID or IVR/Auto Attendant option is not configured to point directly to the conference room but to a routing rule first. This routing rule will only route callers there at 8am until 8:30, although I’d recommend 15 mins earlier at least to allow early callers in and maybe a bit longer depending if the meeting has a strict end time or not. The routing rule can then send them to an auto attendant or elsewhere in the system if it’s outside of the hours — add multiple rules to allow different routing if it’s before to note they are to early, or if they are late to send them to a recording of the conference to hear what they missed.
In the past we have covered the Q-Suite’s Visual Dialplan Builder with its ease of use and capabilities to handle any, from basic to very complex, requirements of an IVR. However, before the Q-Suite had the dialplan builder, we had the auto-attendant features, which allowed for a menu structure to provide the caller options to select and be sent within the system. One can argue the dialplan builder can do everything the auto-attendants can and I would not disagree. However, the auto-attendant configuration screens have been kept in the product due to their ease of use that allows anyone to have a multi-level menu system up and going within minutes. Continue reading Feature Highlight: Auto-Attendants
For large installations configuring all the VoIP phones can be a pain. Perhaps you have polycom SIP phones which I have seen in the past delay starting the web configuration interface until after the phone is ready to handle calls. This is great when the phone is in use as the user can use the phone sooner while not waiting on the processes providing the configuration interface, however when configuring a large number of phones it causes delays if manually configuring each phone. Even when the config interface comes up fast it’s still a labour intensive task to go through each phone manually configuring them. During this manual process mistakes can and will, especially given a large enough set of phone be made, some of which may not be initially obvious. For example, if the dtmf mode of the 47th phone configured today left at the default of RFC2833 but the system is using SIP INFO? That phone gets used for a while but then the user goes to use an IVR and has to file a trouble ticket to get it resolved after finding out dtmf isn’t functioning as expected.
The solution to this manual headache and time drain? Provisioning. This is where the phone system will have the configuration for each phone and the phones download their configuration so they are synced with the phone system options.
Provisioning is usually accomplished via a tftp where the phones configuration files reside. At boot the phone gets an IP via the local dhcp server and the dhcp response has an extra configuration setting, usually Option 66, to inform the phone where the tftp server is. From the tftp the phone will generally request a general model configuration file, this can handle firmware upgrades and common settings specific to a model or make of phones. After that file a request is usually made for a file with the MAC ID to differentiate the phones. This MAC ID file is specific to that individual phone and will contain the details of the SIP connections, extensions, and anything else just for that phone.
The Q-Suite supports provisioning a number of SIP phones from various manufactures. With easy support via templating to extend to new models as needed. The administrator only needs to collect and input the MAC ID’s and choose the proper template when configuring the extensions and the generation of the config files will be done for them. With DHCP Option 66 is set properly boot up the phones and they’ll be functional and making calls.
Within the Q-Suite we have our dialplan builder with extensive options to route and manipulate calls. The dialplan builder meets the needs of most situations but from time to time you need to get low level and go right into the asterisk dialplan. If it is only a couple of statements the dialplan builder has the Execute command, but when it’s more involved that’s where the Q-Suite’s Asterisk Scripts option comes in. Continue reading Feature Highlight: Asterisk Scripts
In the Q-Suite, we use PBX Routing Rules as the proper name for Time of Day scheduling. This feature is the backbone of the CTI Campaign Schedules, but is still quite useful for people who may not want to venture into the Contact Center portion of the product and are perfectly fine with sticking to the PBX aspect. Let’s have a look at a simple example showing how to use this feature.
When managing PBX extensions and their users the requirement to limit what can be called is often needed. This can be done heavy handed at the trunk level but then no calls can dial out to the blocked numbers.
Using the Q-Suite feature Restricted Numbers is a more refined solution to the issue. It can be setup to restrict certain PBX extensions from dialing a set of numbers while allowing others. For example this is useful if only a group of users are allowed and expected to make international calls while another group are to be restricted. Continue reading Feature Highlight: PBX Restricted Numbers
Asterisk is a versatile VoIP PBX telephony engine that has experienced phenomenal growth from inception. Its market penetration is not easily measurable due to the diversity of applications using it. It should come as no surprise that Asterisk has a significant presence in Cloud installations as it can function as a telephone switch, a media server, a protocol gateway, and a conference bridge. Asterisk has become a preferred choice for the underlying telephony platform for setting up distributed multi-tenant PBX and call centers.
We are seeing more providers choose Asterisk or telephony platform built around it for their cloud deployments. For example a recent announcement about VitalVox selecting the Q-Suite platform which uses Asterisk.
Most providers are not going to roll their own Asterisk solutions due to the extensive toolset needed to maintain the dialplan while separating multiple tenants easily. This is where the value of a product like the Q-Suite comes into play as it handles low level configuration of Multi-Tenant PBX and Contact Center. Then of course there are Reports which are also included in these products which provide real time and historical system utilization, call stats, etc.