Voip Service & Solutions Archives - Page 7 of 21 - DrVoIP

ShoreTel adds Siri features with SpeechBridge!

Posted on September 19, 2015 by DrVoIP

Anybody who has used Siri or Google to ask for directions while driving, understands the importance of being able to navigate through an automated attendant menu using voice commands! Natural language, speaker independent speech recognition has come very long way and can be economically integrated into every ShoreTel system deployment. One of the best kept secrets in the ShoreTel community is the availability of a low cost, high performance voice recognition solution that makes your digital automated attendant understand human speech! Folks driving along, even those stuck in a traffic jam, cannot be pressing extension numbers into their iPhone! Why not let them “speak” a name or extension number? Siri does it and so can your ShoreTel system.

SpeechBridge can hear!

Enter SpeechBridge by Incendonet of Encinitas, California! The company offers a speech recognition appliance, optimized for ShoreTel systems that can give your Automated Attendant ears! Using a SpeechBridge, callers can “Say or Press 1 for Sales;” or “Please say the name of the person you are trying to reach.” SpeechBridge easily eliminates that frustrating “spell by name” touch tone, key pad game that dumb automated attendants expect callers to play. SpeechBridge can also integrate with your Calendar and Email systems! The product is easy to install, and easily interfaces with back office systems like Exchange and Active Directory.

Easy to Configure!

As the name suggests SpeechBridge establishes a SIP trunk to your ShoreTel system. Inbound calls are directed to off premise extensions, where 2-8 ports of powerful speech recognition, are available to play the normal role of an automated attendant. Though the SpeechBridge can collect touch tone digits, it is optimized for Speech and the spoken word! Callers can say an extension number, voice navigate a menu or speak an internal user’s name. Using SpeechBridge “sounds like” patented technology, the system will sort through names and phonetically match the sounds uttered by the most inarticulate callers!

The system has a unique Scripting and Menu editor which enables you to rapidly implement new call trees and custom IVR applications. Use the bundled system prompts or upload your own prompts! The system can be used to look up, confirm and reschedule or create calendar events like appointments. The SpeechBridge can even create transcriptions of your voice messages and send it to your email! There are a variety of fully formed APIs that enable third party integrations for those who seek to use the appliance in custom applications.

Adoption Strategy!

When Voice Mail systems first came to market, smart marketeers would install them free of charge with each new phone system, on a “try it, if you don’t like it we will take it out” basis. Thirty days later, there is no way you could take away someone’s voice mail system! We recommend you make the SpeechBridge a standard part of your ShoreTel deployments! Give them the Speech enabled Automated Attendant.Then grow recurring revenue adding the many other applications where TTS “text to speech” and SR speech recognition can be applied! Include SpeechBridge menu and directory maintenance as a “service” offering and differentiates your company’s ShoreTel implementation!

The technology is not difficult to understand, implement or maintain! Incendonet has an excellent dealer education program, superior technical support and a growing product portfolio of speech enabled applications! If you like Siri on your iPhone, you will love SpeechBridge on your ShoreTel. The product is certified by ShoreTel and fully supported by Incendonet! Add Speech Recognition to your ShoreTel today, by calling Incendonet at 760-944-7698 and ask for Sales! (Before you ask us, yes, SpeechBridge can be integrated with any VoIP PBX that supports SIP trunks!)

Contact Center Remote Agent Locator!

Posted on August 8, 2015 by DrVoIP

We recently had a request for an “emergency locator” application with a different twist. Historically, we have written a number of “locator” type scripts, but this request had some unusual requirements. The client wanted to have live agent support for a technical support queue, even after the agents went home at end of shift. Basically, put the caller on hold and then go find an agent to assist! Now if agents are logged in, that is more of a remote VPN phone type of solution. This was different, the agents were not logged in and not on a VPN phone, but reachable by cell phone. The requirement was that the caller should have the same experience after hours that they might have during business hours.

The Challenge!

If that was not a sufficiently large challenge, they also had multiple CSQs and that would mean processing a list of agents that was CSQ specfic. Additionally, all of this should be reportable in the normal historical reporting process. If an agent could not be located, an email was to be sent to the CSQ team, and the client offered the opportunity to leave a VM or request a call back. What was different about this request for script assistance, was not that we had to locate an agent, but that we had to keep the client in the queue and somehow pass the client to an available cell phone based agent.

Not entirely sure if we could do this in a ShoreTel ECC, the CISCO UCCX has the ability to create scripts that manage multiple contacts. The “Triggering Contact” being the caller that launched the script, and then we need an email contact and an outside phone contact. There is no way, however to conference or transfer the caller to an active call. Additionally, we needed positive assurance that we reached a human and not an answering machine! This made for an interesting set of challenges!

The Solution

The caller handling front end was a typically call queue strategy, but the back end agent locator was tricky. First we had to create a way of searching a list of available agents. Not a single list, but a list for each CSQ as the agent skill set was product focused. That requirement was initially handled with a SWITCH step and later improved by use of an XML file. We place the caller on hold, then find the first agent and call them as the second outbound contact or new active phone call. To confirm we actually reached a human, we ask them to press any key to continue and when they press a key, we know we reached a human and not a machine.

Next we ask them to press one to accept the assignment, or two to reject the assignment in which case we have to return to the list and find another agent. If they accept the assignment, we tell them to keep the line free as the next phone call will be the caller on hold in the queue. We terminate the call and then retrieve the caller from hold and transfer them to the agent.

This all worked very well and we are now enhancing the features and script strategy to make the code portable and more flexible. If the agent had rejected the call, we would send an email to management and call the next agent on the list. We are eager to find ways of leveraging the script for more applications and welcome your input!

Upgrading CISCO with Prime Collaboration Provisioning

Posted on July 21, 2015 by DrVoIP

Don’t Procrastinate!

Sooner or later you will find you need to upgrade your VoIP deployment, regardless of the vendor. Differing upgrades is just prolonging the inevitable and increasing the complexity and the pain level. Let’s take the example of migrating a CISCO MCS based cluster that includes a CUCM at version 7.1.5, a UCCX at Version 8.0.2, and a Unity Voice Mail at version 5.0, and some of the components have HA options! Having put off upgrades for some time, this client will have to migrate from MCS server hardware to vmware ESXi virtual machines and upgrade to the now current 10.X release across the cluster and applications. In the case of Unity which has been replaced by Unity Connection, this is a completely new application addition. The complexity of this upgrade is about as challenging as they come! Additionally, the client expectations are that impact to the production environment will be non-existent!

Build out a “Mirror Lab” system

The decision was made to build out a completely separate “lab” system and to use the same ip topology as the production system. This in itself is an interesting set of configurations as you will still need to maintain connectivity with all network services, particularly DNS and NTP. This might best be accomplished with a set of temporary service providers on a completely isolated network. In this instance we made use of Prime Collaboration Deployment (PCD) tool to migrate and upgrade the CUCM cluster consisting of Publisher and two Subscribers. As the “lab” network was to mirror the production network, we actually had three of four subnets to configure as the HA servers were to be located at a different site than the Publishers. The PCD was relatively painless and very useful. We did learn quite a lot about the capabilities of this tool, and in the end, consider it to be of great value and we will continue to use it in future migrations. See our previous blog about lessons learned!

Plan 3 hours per server per Upgrade Step up!

Understanding the time required to complete this process should be established. The actual time to do a backup and/or a restore of a specific server will be determined in large part by the size of your deployment. A backup for a single cluster with 100 users will take considerably less time than a backup of a multiple cluster deployment with a 1000 users! For planning purposes we used one hour per server for installation of software including ISO, COP files and any required Engineering releases. Each backup added an hour as did each restore. Keep in mind that you may be making multiple upgrades to achieve your end goal. Each upgrade will take place in the “inactive” partition. Then you will be required to switch partitions. This process will take as long as a backup to progress! In this example we were moving from 7.1.5 to 10.6 and that would normally be a multiple step upgrade. In the case of the UCCX it most certainly was! So we have, in this example three CUCM servers, 2 UCCX servers, and 2 Unity servers for a total of 7 servers. At the base level that is a minimum of 21 hours of server operations for each upgrade step! Plan accordingly and set expectations to all stakeholders! There will be long periods of watching computer screens and the progress bars that hopefully give you some feel of where you are the process. CISCO upgrades list the number of tasks and also estimate the time per task. This is very helpful!

Take time to learn COBRAS!

Once we had the CUCM cluster established, we turned our attention to the migration from Unity 5.0 to Unity Connection. This was achieved by building out a new ESXi based Unity Connection Version 10.5. CISCO has a great tool to assist with this migration in the form of COBRAS which, if you have not used before, will take some study. Fortunately there are many training videos on the CiscoUnityTools.com website, where you will go to download the required software. You will need the CISCO Unity Export tool and the Unity Connection Import tool. The Export tool needs to be installed on the Unity Server as it will build connectors to the existing Unity configuration and User database. The tools are not difficult to learn, but do require some orientation. You can export the configuration including users, call handlers, mail boxes, prompts and even messages. If you set customer expectations that they will not have historical messages, you can eliminate importing messages which will simplify the process.

The Unity Connector Import tool can be installed on a Windows laptop. You will need to download and install IBM Informix drivers to connect to Unity Connection Server using a Microsoft OBDC connector. In this example, we moved from a system that had many less features to a system that had many more features. Our expectation was that this would be the most painful part of the migration journey, but it turned out to be comparatively easy. The Unity Connection Server came up with most of the old call handlers matching definitions for new call handlers, and the user database imported with out error. We choose not to import old messages and set an expectation with the client that there was a point in time in which they would need to clear out old messages as they would not be on the new system.

List and have available all COP files!

Now the upgrade and migration of the UCCX was in fact the most challenging part of the journey. With the Call Manager now on Version 10.5 the current UCCX 8.0.2 system could not communicate with the call manager. At first this was not thought to be an issue. We backed up the UCCX 8.0.2 server and built out the same version machine on ESXi. Then we did a restore and now had a virtualized UCCX 8.0.2. You will not be able to log in to the UCCX administration page, however, as the user database is on the CUCM, and the two systems are currently incompatible. There is a very long list of steps to get to UCCX 10.6 and each step required a backup and restore! The clock is ticking!

We upgraded the 8.0.2 software to 9.0.2 and found that we need a license key to be able to log into the Administration portal. Given that we were only temporarily stopping here, and ultimately would license under Prime License Manager, we did not plan for this. However, we wanted to make sure that all data was successfully migrated to the new version. So we obtained a demo license through TAC to take a look at our repositories and verify that all scripts, prompts and documents etc. were successfully migrated. We noted that the Call Control Groups were not in place, but determined that was a result of a Jtapi version incompatibility. We next need to apply COP files and migrate to 9.0.2SUS2 in preparation for the journey onward. At this point, we found a error in the database replication of UCCX servers and elected to remove the secondary server, which we would add back in at a later step. This required TAC assistance to log in as root and run a script to strip the database of any reference to the second UCCX server.

There are hardware reconfigurations that change as you move through to 10.6 so be aware of them. As you might have done on MCS upgrades to 9.0.2, you will add RAM and maybe disk drives depending on the size of your UCCX. So moving from the ESXi virtual 8.0.2 clone we attempted to build out the ESXi machines using Version 10.6 OVA files, but ended up having to download and use an OVA for version 9.0.2. The upgrade to 10.6 required yet another COP file before the upgrade could be started. Again, it is important to study the various upgrade paths as you may be moving through several upgrades, patches and COP files, so keep track and write it down! After the COP file, yet another backup! Finally, we were able to move to 10.6! Once on 10.6 we now needed to add the HA server back into the mix. Actually, in the future for any multiple upgrade steps it may be best to remove the HA server before starting the upgrade. Generally this is not a CISCO supported method, but you can see how much time it cuts out of the project as you do not have to upgrade two servers, backup and restore two servers at each step of the process!

Now that we have a complete system upgraded and virtualized, we can do some testing. Specifically working with firmware and CTL issues if any! Though we did not have any gateways to connect with the outside world, we were able to bring up phones, assign users and make phone calls to the UCCX and the Unity Connection. What remains is scheduling the maintenance window to facilitate the “go live”. The plan was to take the old system offline and put the new system online. Keep in mind we used the same machine names and IP topology in the “lab” as we did in the production environment!

The Browser Wars taking control of “hosted” applications!

Posted on July 13, 2015 by DrVoIP

“”As more and more applications become cloud based hosted solutions, the more urgent your choice of Internet Browser will become! The desktop warfare, in our opinion, is really getting out of control! You would think that you can use any browser for any website you want to surf, but such is not the case. We recently made the mistake of trying to pay our Microsoft Office Online invoice while using a Firefox browser. Only when we switched over to a Microsoft IE browser could we complete the transaction!

In yet another painful situation while working with CISCO Prime Communications Deployment tools, we were experiencing a database access error. This error stalled development for several hours as we tried to find the root cause of the connectivity error. Only by accidentally switching to IE from Firefox, did we uncover that the connectivity error was a fraud perpetrated by our choice of browser. (Granted we think the only useful thing you can do with IE is download Firefox).

WTF is Control C?

Those of you who have been working with fat client based solutions, like Microsoft Outlook might actually be somewhat discouraged from using Microsoft Office 365. All of the usual operations like right clicking on an object to copy and paste are suddenly replaced with pre-historic multi key chord strokes like Control C or Control X. Personally, I find both Google and Microsoft cloud solutions to be frustrating! The simple act of high-lighting a range of text might cause you to go completely over the edge! The application will “bark” at you with an error recommendation as you try to replicate the desktop experience with your browser based application.

We have many clients who require us to use a variety of different tools when we work on those projects. For example, some folks like Google mail rather than Outlook OWA as implemented in Microsoft Office 365. Web conferencing tools like Webex from CISCO and Lync or Skype for Business by Microsoft have very different results depending on your choice of browsers.

Desktop Warfare winners?

Who is winning the war? Well is seems that Google Chrome is the hands down winner with a 44% market share largely resulting from losses by Firefox and Microsoft IE. Apple’s Safari seems to remain relatively constant and newcomer Opera does not seem to be making an impact. These numbers hold true regardless of the platform, with Apple and Android showing the same browser preferences as their desktop competitors.

So how do you survive with this level of warfare? We find that both Chrome and Firefox have outside developers who support the browser by creating add-ons. Our particular favorite is Firefox as they seem to have a wider community of developers. (We also figure anything you type into a Chrome browser is immediately searchable by the entire Internet population). Though feature comparisons are useless, and most folks just pick a browser based on personal preferences or device (Safari is an Apple product), we think Chrome and Firefox are the most open solutions. We are Mac freaks, but at the end of the day, WebRTC will most likely be developed by Chrome and Firefox who are not defending hardware market share or erecting proprietary application. The kool kids typically pick one of these two browsers if they are going to change from the browner that shipped on their Windows or Apple platform.

As you use more and more cloud based applications you will become increasingly more aware of the browser warfare taking place on your desktop! At the end of the day, you are going to end up using more than one browser to get your work done!

Hey watch how easy it is to get the password you left in your browser!

Is your Contact Center “Smartphone“ enabled?

Posted on July 10, 2015 by DrVoIP

“When it comes to customer engagement options, digital contact will surpass voice contact in contact centers in less than two years. This prediction by Dimension Data also highlights not only are most Contact Centers unable to deal with Smartphone input like SMS or “text” messages, more than 80% do not have the IT structure in place to manage the migration to digital customer contact.

Text my next appointment please!

It is simple enough to test the validity of this claim. Does your contact center currently support SMS or “text” message routing to the next available customer service agent? Can a customer of your company send a text message that says, “Call me at this number please”? Intuitively you know that a text message costs less than a phone call. We know that the info structure to support a text message is significantly less that the cost of the info-structure to support large numbers of incoming telephone lines. So if you do not support SMS today, is it on your Contact Center road map?

“We are rushing the kids to school not waiting for the next available agent!”

Website “Chat” seems to be a feature adopted by Contact Centers but is that the correct digital engagement strategy? It is the correct strategy for visitors to your website, but not for those dropping off the kids on the way to work! Chat is great for website visitors, SMS is the best solution for our highly mobile society! If you are using Email in your Contact Center then you are a small step away from allowing SMS and Text messages to reach your agents! The technology is simple to implement and readily available. Agents can hit reply and send an Text Message right back to the original cell phone, quickly and, all text messages are archived and reportable for compliance purposes.

Being able to send a “chat” to someone who is on your website is a step in the right direction, but being able to open a real time voice conversation with that website surfer has much higher customer service impact! So, what role does WebRTC play in your Call Center? Customers are used to hearing Music on Hold, but with WebRTC the option for Video on Hold is a reality. Think about it! Is it on your Contact Center development road map?

‘TEXT2ECC’ to 702-956-8700

The issue is not Cloud versus Customer Premise. The issue is “voice” versus “digital” engagement strategies in customer service focused call centers. Send the keyword ‘TEXT2ECC’ to 702-956-8700 along with your email address and we can set you up with a T2E (text 2 email) account free of charge. The video clip shows you how to access our WebRTC demo! Give it a try and let us know what you think!

Use an Ingate SIParator and you are “virtually there”!

Posted on July 7, 2015 by DrVoIP

We have written on the subject of SBC quite extensively in the past and have also covered the easy installation of the Ingate product (see DrVoIP here). Readers must find this interesting because the hit counter for our Ingate videos continues to grow, indicating engineers are eager to learn more about this product. We generally regard ourselves as CISCO brats, but when it comes to Session Border Controllers, we remain deeply impressed with both the Ingate product and, most importantly, the Ingate support team! Pre-sales support is typically as good as it gets when developing a relationship with a vendor. Post sales support, however, is where the true value system of a company is tested and Ingate passes with high marks.

Ingate SIParator as a virtualized appliance

Ingate, began shipping product as early as 2001 and has its roots in firewall security products. Ingate has now made its very popular SIParator Session Border controller available as a virtual software appliance. The SIParator E-SBC, scalable from 5 -20K sessions can be obtained as either a hardware appliance or as a software package. There are over 10K SIParators installed and working worldwide, making Ingate the “go to” knowledge base for documented SIP deployment experiences that is without equal on a global basis! Those of you working with ShoreTel have already discovered how powerful a vmware ESXi deployment can be. New options for fail safe, high availability and increased reliability magically appear when you virtualize your deployment! Ingate is no different and the availability of the Ingrate SIParator as a virtualized appliance adds a significant level of both reliability and flexibility to your ShoreTel deployment.

The most widely asked question in the DrVoIP technical support forum: “Is there a need for a Session Border Controller?” Why can’t we just use our firewall is a common theme. Though it is possible to use a firewall to do a SIP trunk implementation, it is not our best practice recommendation to use a firewall in that way. Even firewalls with AGL SIP functionality fall short of the wide rage of features needed for true SIP arbitration. We are firm believers that firewalls already have enough work to do and are being attacked even more ferociously every day by a wider group of hackers and evil doers than ever before. If you are committed to using a “firewall” to do SIP deployments, then we urge you to consider at least using an Ingate SIParator Firewall as a best of breed solution!

A dedicated Session Boarder Controller

Session Border Controllers have a lot of work to do! The concept of normalization alone could fill a text book. The fact is, not all SIP implementations are equal.It is often necessary to swap SIP message headers to achieve the desired results! Try getting your firewall, unless it is a SIParator, to do a SIP message header translation and you will quickly understand why a dedicated Session Boarder Controller makes sense!

The software SIParator is easy to obtain, easy to install, easy to configure, and easy to license. Ingate has adopted a pay as you go philosophy, and though the software product scales from 5-2000 channels, you only pay for what you use! In fact, Ingate is so confident in the adoption rate of its product over competitors, they offer a 30 day free trial. Just click here to take advantage of this outstanding offer.

The video is Part one of a two part video on the product! Part one shows how to obtain, download, and install the virtual SIParator software package. Part two goes through the configuration of the SIParator on a ShoreTel system for use in SIP trunking deployments. This material was previously covered in our YouTube video on Ingate and that material is still relevant!

Kudos for Ingate

Lastly, we want to commend Ingate not for having a great product, but for the quality of the support they offer the entire industry by an ongoing commitment toward the education of the market place on SIP and, now WebRTC technology. We are not talking about thinly masqueraded advertising, but serious SIP education programs for serious technology students, and a demonstrated sincere desire to advance the state of the art! They offer an endless variety of webinars, seminars, ebooks and even work in partnership with the SIP school to further develop and educate industry stake holders. Excellent work Ingate and well done! – DrVoIP

Cisco Prime Collaboration Deployment—Lessons learned!

Posted on June 29, 2015 by DrVoIP

Upgrading is always a challenge!

Upgrading collaboration solutions like ShoreTel or CISCO has always been a challenge for system administrators. The technology for VoIP solutions has become increasingly more complex with many touch points that are outside the base communications systems. Folks want to use their iPhones, Androids, tablets, laptops and a variety of other endpoints both software and hard! Collaboration requirements are more than just voice! Folks want to chat and IM, hold Web meetings and Video conference. This is a long way from the standard single line touch tone telephone that dominated the landscape when we first entered the industry.

Depending on the size your your deployment you will have several servers to upgrade, some may even be across time zones that span the country if not the globe. The configuration management and cross referencing of O/S versions and application compatibility, including desktop software can become a major research project in and of itself. There is no easy way to approach this, it is hard work and it must be done. Upgrades require very careful planning and preparation before setting the all important “maintenance window” and the notification of the end user group.

With CUCM Version 10 CISCO has migrated exclusively to virtualized servers, eliminating bare metal installs completely. For those who have not upgraded their deployments in quite sometime, you will not only have to upgrade servers, but twill also have to migrate to virtualized environments. CISCO Collaboration no longer runs on MCS class servers, but on Unified Computing platforms, like the UC220, which run vmware ESXi. To assist with the complexity of this process, CISCO has introduced the Prime Collaboration Deployment tool. It is not a substituted for the research you will need to do, but it does take a great deal of pain out of the labor of a combined migration and upgrade.

Prime Collaboration Takes the Pain out of Migrations!

Recently we had and experience that is not uncommon with the upgrade of a CISCO CUCM deployment. We had a client with a Version 7.1.5 CUCM Publisher and two subscriber servers. (The cluster also supported Unity 5.0 and UCCX 8.0. on traditional MCS servers, but that is the subject of another blog). The goal was simple: migrate the cluster from MCS hardware to vmware servers and upgrade to Version 10.5 across the cluster! Also, the production environment, running in a medical facility could experience no service interruptions! Though no client ever says, “Come over Monday morning and take our computer network and voice system down and take your time upgrading it”, the no service interruption required some further conversation to set expectations appropriately!

Ultimately, we determined to build out a separate network and to use CISCO Prime Collaboration Deployment (hereafter called “PCD”) to accomplish the migration. The process was interesting and full of opportunities to learn new techniques and options. We would like to share a few with you in hopes that you might benefit from our experience. First understand that the PCD can be used to migrate and to upgrade. Understanding this vocabulary is important. Upgrades assume that you are already on a vmware ESXi platform and at the appropriate software level to upgrade both CUCM and your other applications. Clusters that are on specific versions of CUCM 6.1 and 7.1 are about the earliest versions you can tackle with PCD version 10.5. If you are running a Call Manager with an older version, the process is considerably more complex and outside the scope of this blog! Applications like Unity and UCCX must be at least 8.6 for both migrations and upgrades.

Our first step was to directly migrate from an MCS based Version of CUCM running 7.1.5 to an ESXi implementation of CUCM Version 10.5, and to do this in a single step! We had two major locations in this deployment, so we set the servers up so they could be relocated later to support the “go live”plan. CISCO Prime Collaboration Deployment supports two modes of migration: (a) use the existing host names and IP address topology on the migrated cluster; or (b) change the host names and IP topology of the new cluster. As the use of the same host name and IP address options requires shutting down the production server at some point during the migration, we elected to go with a change of names and ip addresses. This would enable us to run both in parallel and test without impacting production.

PCD Lessons Learned—Get the DNS Records right before you start!

Lesson Learned—Make sure you go through the PCD documentation and note all the prerequisites! Something as simple as using the correct browser will save you some pain! We had a situation in which after the PCD install and a few start up configurations, like adding the ESXi hosts to PCS, were getting database access errors! “An error occurred retrieving cluster data from the database” is really enough to scare you to death! We were using IE, and when we used Firefox, the error disappeared. WTF? We noted many differences between using each browser. If something fails, try the other browser before believing the error! Make sure you use the supported browser for the PCD version in use. Make sure that all required OVA, COP, Firmware and ISO files are in the correct directory on PCD, generally \fresh for migration. You will need FileZilla to do this and we recommend having putty or your favorite SSH solution available. Trying to run Cli command through the vmware client Console connection is very painful! SSH to PCD if you need Command line access!

Lesson Learned—Generally you will deploy your ESXi hosts first, getting your management port established and your vmware client launched. Once this is accomplished you will then deploy PCD. The installation of PCD is not unlike the installation of any other CISCO Collaboration application. There are many great videos out there which demonstrate this process. What we learned here is DO NOT install the ESXi free license on your vmware host before completing your PCD install. If you install that license to operate a free version of ESXi, you will get warnings about features that may not be available. Remove the free license from vmware if you have not already done so! (See our blog on setting up a vmware lab system for similar input on using the vCenter evaluation software on free ESXi).

Lesson Learned—If you have worked with vmware in the past, you know that generally you will need to put your OVA and iSO files on a local storage resource available to your vmware client. After installing PCD you will note that an NFS data store is created and available as a storage option in your vmware host inventory. You will also note using FileZllia that there are two directories: fresh install and upgrade. These are for storing the various COP files, Firmware loads, ISO and other files you may need during your migration. This greatly reduces sneaker net and the movement of software back and forth from the vmware client desktop to your ESXi host. Watch total storage use however!

Make sure your have your IT Network Services Accessible!

Lesson Learned—You must have DNS, NTP and SMTP services available on your migration network. The installation of all CISCO applications require these basic network building blocks. Make sure your deployment network has access to these network services. If at all possible, use the same services that your existing cluster uses. If you do NOT setup DNS A records for your new cluster, if new host names are being used, your migration task list will fail at the launch of your first new CUCM server. If you just waited six hours for your first task, the backup of your cluster to the PCD to finish, you will want to jump off a roof if you think you have to start over (actually you don’t have to, see below). In fact before you even activate your task list, go to the CLI of the PCD. Use “Utils Network Ping Hostname” to verify that PCD can in fact resolve new host names and even this is not a guarantee!

Ultimately we realized that we should have installed the DNS Client option during the PCD installation. We used Utils to set it after the fact and had the painful realization that the addition of “Set Network DNS Primary” will cause the server to reboot! Six hours of data collection, and we were about to blow it up. This is why SMTP is important. You can have PCD email you at the end of each step so you dont have to keep playing policeman! We committed to the change and watched the server reboot. Much to our suprise, PCD came back up with a CANCEL, RETRY and CONTINUE button indicating that we were at the point we were before we rebooted the server! Lesson Learned and Shared here! Get DNS working and all A records for both host and FQDN names resolved before you start the migration task list in PCD!

Once PCD is installed the migration process is simple to follow, but may take a very long time. Typically we estimate 1 hour to backup and 1 hour to restore each server in your cluster using the manual process. PCD does not save time, so plan ahead! The steps can be summarized as (a) discover your existing cluster; (b) create your new cluster; (c) establish migration tasks; and (d) manage the tasks through to completion. You MUST have the OS administration user name and password for every server in the cluster! Don’t even think of starting without it! After PCD “discovers” your existing cluster you will then be asked to create a Migration cluster using either existing host names and IP or changing them. Pick your options and then set up your cluster.

Once you set up your cluster, you can then establish your task list. Tasks can be automated (again suggest setting up email notifications) and run at scheduled times or started manually. Each task is reported and may be programmed to stop before continuing. Certain stops are mandatory. For example, if you are using the same host names and IP address, you will be required to turn off the production server before bringing up the new cluster. At this point it is a waiting game as PCD first backs up and copies the production cluster. During our migration we failed two times after the six hour backup task. The second task of firing up the new CUCM Publisher would not load the ISO. The first time was because of DNS issues. The second time was for DNS issues (are you following this)?

No Need to Delete the entire machine, just delete the disk!

The most important lesson we learned that will make this the most rewarding blog for you is this: When a task like starting up a new OVA file that defines a new machine and ISO fails here is how to recover. Shut down the machine in the ESXi inventory list. A better solution is to edit the settings on that machine. Delete the hard drive completely, then reinstall a hard drive. Generally you will have to recreate that machine, using the OVA file, but this trick save you that effort. Once the machine is edited, you can return to the monitor page of PCD and hit the RETRY option. This will restart the migration task from where you left off . If you fixed your issue (DNS reverse look up), you should continue with no further issues!

Lesson learned—If you are going to talk to TAC, they will want to have both the Tomcat logs and the PCD logs. Add a Serial Port to your PCD so you can output log files to a predetermined file location on failure! Do this before you need it! Learn how to use the cli to collect the Tomcat server logs!

Summary

CISCO Prime Collaboration Deployment is an excellent solution for migrating your CUCM from an earlier version to the latest ESXi based version. If you attend to the prerequisites including researching the required upgrade files, you should have a very comfortable experience. If you have ever done a migration from MCS to ESXi using the “jump” process, you will find this remarkably more efficient! You will need to get your other applications up to a supported version before you can upgrade them using PCD, but once you do, this tool will become your new best friend!

The ROI of a “Call Back” option!

Posted on May 24, 2015 by DrVoIP

In his newly released ebook, Fonolo founder, Shai Berger, defines Abandoned Calls Rate as the Number of Abandoned Calls / Total Calls. Abandoned calls represent not only a lost revenue opportunity, but they cost you hard dollars. Shai does a masterful job at outlining these costs in a way that business folks can understand. Throughout my 35+ year career in telecommunications, I have witnessed the pain of Call Center management endlessly struggling to increase customer service levels and response times with limited available resources. One solution, hire more agents until there are no busy signals is never considered. Yet business managers never tire of adding more incoming telephone lines, queuing more and more customers to wait on hold for longer periods of time, resulting in lower customer service levels and higher abandonment rates!

Recently we heard of a company, HOLDYR, that actually makes a product that allows people to select what music they want to hear while on hold! As Shai points out in his book, if you think this is a joke, take a road trip with your browser open to onholdwith.com to see the rants of folks who have been on hold. Putting customers on hold will result in lost business and high frustration levels. You will also be tying up a phone line for the duration of that hold period. Couple that phone line to an incoming toll free number and the cost per minute of hold is even more dramatic. Only the IRS can leave folks on hold and care less about abandoned call rates, most competitive businesses prefer to take action.

Call Backs offer reduced operating costs, smooth traffic demand, and fully employ customer service resources, so why not provide callers that option? After answering an incoming call and finding no agents are currently available, the caller is offered the option to “receive a call back without losing your place in queue”. If the customer elects this option, we can confirm their caller id or ask for the number we should call them back at. Fonolo offers a number of equipment agnostic “virtual queuing” solutions that can be added to an existing call center.

We can take this strategy to yet another level by providing call back options that do not even require a call to your customer service center at all! Web based call backs are one example, in which a client on your website provides a phone number and requests a call back. We are particularly fond of TEXT based solutions in which the customer sends a text message, and either receives a call back immediately, or receives a text with an estimated call back time. This text can prompt for an alternative call back number or time for call back. In both cases however, there is no need to queue callers or to have more telephone lines than you have customer service agents. (In fact, if you think about it, under the right conditions you might not need a call center at all!)

Send “TextMyECC” to 760-867-1000 for a sample interaction. We can even build these solutions around Smartphone apps which completely eliminate automated attendants, IVR and queuing, but allowing the customer to directly interact with the correct call center queue to schedule a “call back”!
[show_related ids=”1749, 1753 , 1699, 1598″]

The sad sound of a silent voice

Posted on May 23, 2015 by DrVoIP

Since late 1998, I have had the pleasure of working with the wonderful folks at OnHoldAdvertising! The husband and wife team of Brent Brace and Karen Kelly have produced literally millions of voice prompts for thousands of systems throughout the American Business Communications landscape. Karen can be heard on more automated attendants and voice mail systems in this country than we have touch tone keys to push! Behind the scenes, unless you required a superior male voice artist, was Brent working away tirelessly as the editor and producer. They brought “a human voice to a technical wilderness” and great joy to those they worked with.

Brent had been fighting one of those long term muscular and neurological diseases for years, but not once did you ever hear him complain about it. A Vietnam Veteran, Brent soldiered on, and built an outstanding business, and a greatly admired professional reputation. Most recently in the Denver area where he and Karen had relocated from Southern California, he had been teaching voice artistry workshops. Brent entered Hospice at home a few weeks back, yet he was still directing our voice production! Unfortunately, Brent passed away in the early morning of this Memorial day weekend. We will miss his voice forever! Our heart is heavy and we are again reminded that “business” is conducted by “people”.

Karen will continue the wonderful work of On Hold Advertising but will need some time to process all that has happened this year. If the voice these folks have produced has touched your life, please send Karen a note of care and consolation.

“Soft and safe to thy my brother, be thy resting place.”

ShoreTel ECC “Sticky Email” ?

Posted on May 19, 2015 by DrVoIP

Call Center or Contact Center?

Call Centers had no sooner become “Contact” Centers when multimedia “nice to have” features became “must have” requirements. The more mobile the customer base, the more likely they are on a smart phone and not sitting at a desk computer. They want “contact”, however they want to communicate. That used to mean voice by telephone, but might now mean text, chat, email and now video! (See our Blog on this subject.) Email, however, is an interesting option as it cuts across platforms and can be read at the desk or on the phone. For this reason, it is still a strong feature requirement on the Contact Center landscape.

ShoreTel has had the ability to route an incoming email to an agent, much the way an incoming phone call is routed to the next available agent. Send an email to customerservice@yourcompany.com and the ShoreTel ECC will grab it from the mail server and route it to the next available Agent. ShoreTel ECC will even allow an Agent, already engaged in a phone call, to take that email and work with it, increasing Agent productivity and cutting customer service response times.

One of the challenges with ShoreTel ECC email however, has been the ability to route the email to the same agent who initially responded to the customers’ first email request. An Agent might get an incoming email, answer the email and send it back to the customer. The customer might have a follow up request and when they hit reply, to the reply, there is no assurance that the original Agent will get that same email. Often the email is routed to the next available agent, as if it was a first time contact.

Why do you “Sticky Email”?

The solution here is to create a “sticky” email. One that will relate the original customer request to the Agent who initially handled the response until such time as the case is closed. This can be done with the existing ShoreTel ECC tool set. Using the C2G or Interaction reporting database and some SQL glue, an incoming email can be reviewed before it is passed on to the Agent. That review process would check the Interaction database to see if the FROM field has been previously entered into the database during, say the last 30 days. If so, the email is routed to the personal email queue, within ECC, of the Agent who responded to that email!

Simple, elegant and actually it is really quite cool! We have been using this process to manage our Text to ECC email messages for some time and have now adopted it for ShoreTel ECC routing. Text the word “STICKY” to the phone number 858-223-1040 or email us at DrVoIP@DrVoIP.com. We can get your Contact Center connected! While you are at it, we can set you up with TEXT to Agent as well!

(Note – The CISCO UCCX has “sticky email” built into the application along with Chat, and Social Mining! This is a great overview of how CISCO does this feature).