Author: DrVoIP

Peter S. Buswell (aka DrVoIP) is a rare blend of C-level executive leadership and deep technical expertise in telecommunications and cloud infrastructure. With a career that began at AT&T in 1970, he has founded and led multiple industry-defining companies, including Dextr.Cloud—acquired by AWS Global Partner CloudHesive. Peter has held senior roles at firms like Exxon Enterprises, Intervoice/Brite, and Franklin Telecommunications, and has consistently driven innovation from traditional PBX to Amazon Connect cloud deployments. A hands-on architect with certifications from Cisco (CCNP/CCDP, UCCX/UCCE) and AWS (Solutions Architect, Developer, SysOps), he combines strategic vision with engineering precision. Known as DrVoIP, he continues to bridge the gap between enterprise goals and technical execution in today’s evolving cloud communications landscape.

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!

Hosted PBX? CISCO Voice in a Router? (BE6K-S)

Posted on June 8, 2015 by DrVoIP

The economics of a “hosted” or “cloud” based data and voice service is generally based on moving costs between the hosted provider and your office. The most dramatic example is the cost of the Internet connection. There is an inverse relationship between bandwidth and the equipment location. The more voice and data services that are hosted or cloud based, the more bandwidth you will need to interconnect them to your office. Regardless of which model you go with, however, there are requirements for your “must have” premise equipment that will not change. For example, if your VoIP system is “hosted” in the “cloud”, or if it is located at your office premise, you will still need the very same list of computer network equipment. The equipment requirements for a Firewall, Router, Network Access and Control System, Power over Ethernet switches and phones will exist regardless of where the applications are hosted.

CISCO seems to continually push the marginal cost of adding phone service to that equipment list lower and lower each year. The CISCO Unified Communications Manager, including a fully featured Unity Connection voice messaging and VoIP Paging system with Jabber and presence can now be installed within your network router! If you have an office with less than 150 users and 300 devices, the marginal cost of adding CISCO Unified Collaboration features is basically the software license for the ISR-2900 series router that you will need to purchase anyway! Remember, with the hosted solution you still need to purchase phones and PoE switches to power those phones! Your local area network requires a router to interconnect it with the Internet to reach your service provider. Why not get a router that can act as your firewall, offer advanced intrusion detection and threat protection, and also provide a full range of Unified Communications features?

The BE6K is essentially the same Unified Communications Management and Collaboration solution that is provided in a family of CISCO Collaboration solutions built around the CUCM that ranges upwards of 30K end points! It provides advance phone system features, voice mail, and includes the Prime Collaboration Deployment tool to enable ongoing adds, moves and changes after your system is installed. Jabber enables you to stretch your office extension to anywhere you can carry your smartphone or Ipad! Optionally features include Teleconferencing and Unified Contact Center Express functionality. So what is there to think about?

For the technically oriented business manager, the Unified Communications functionality is running on a VMware ESXi engine installed inside the CISCO router. The normal CISCO router functions are augmented with a single slot blade server, the CISCO UCS E160D, 6 core, 2Ghz 16 GIG Ram processor that supports ESXi. Take a look at this screen shot!

Think of the possibilities! Only a true geek could get this excited but really, VMware running inside a router!

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).

V14 Configuring ShoreTel SIP Trunks P2 -SonicWall or InGate SBC?

Posted on May 6, 2015 by DrVoIP

A question that keeps coming up in the support ticket system is the subject of InGate and Session Border Controllers. Folks want to know if you need a SBC to configure a SIP trunk. Why not just use a Firewall? Can you configure ShoreTel SIP trunks to work without a SBC? The simple answer is “yes” but the smart answer is “no”. In our humble opinion, just because you can do it, does not mean you should do it! Session Border controllers, like those offered by Intuit for ShoreTel, provide functionality not normally found on a firewall. “Normalization” for example, the ability to mediate ShoreTel SIP and your carrier’s SIP, as they most likely speak a different “dialect” of the common language SIP, is not a standard firewall feature.

Application Level Gateways, sometimes take actions that are injurious to SIP messages. Remember, SIP was not designed for NAT based networks. Something has to keep track of which internal private trusted network users made a SIP request for service to another IP address across an untrusted boundary! Which RTP (voice, video or “media”) ports need to be opened to support this request? SBC can do this more effectively than firewalls. At the end of the day, you end up turning off the SIP ALG functions in your firewall to make it work! (In SonicWall turn off “consistent NAT” and “SIP transformations”.)

We have never recommended bringing your SIP services into your VoIP deployment over the same circuit as your Internet circuit, but so be it. At least, let’s use a separate IP address and make use of the DMZ port on your firewall, if you are not going to use a separate circuit! Let us try to keep the SIP traffic from undergoing the same port specific inspections you put the Internet traffic on! Again our best practice recommendation for ShoreTel, if you are serious about SIP trunks as the main Communications link for your company, is get an Intuit SBC and bring your service in on a separate circuit or IP!

SonicWall has for sometime, had a number of “service objects” to support the ShoreTel MGCP phones. In fact, before SIP was enabled on ShoreTel, all media flowed on port 5004 which was really great for enabling transport level QoS! Though there is a steady trend to use TLS and get both SIP messages and RTP over a single port, most SIP carriers expect to send messages on UDP 5060. So if you are using a SonicWall, you will need to create new Service Objects, and put them in new Service Groups to get SIP to work. You will need to configure Network Objects for your ShoreTel SIP proxy and configure access rules. We recommend you also create a network object for your ITSP rather than enabling an open 5060 for all the script kiddies running SipVicious!

We will do this again on a CISCO ASA 5505 just for giggles as we get a lot of requests for that as well! At the end of the day, however, for a serious business application of SIP trunks on ShoreTel, get a separate circuit and invest in an Ingate SBC! Heck, you can even get a virtualized version of InGate!

Network Security begins with an “Acceptable Use” Policy!

Posted on May 2, 2015 by DrVoIP

Most folks seem to understand what a firewall is and why it is so very important. They intuitively understand they need something between the “trusted” internal computer network, and the wild west we call the Internet! The installation of a firewall is generally something all business do, from the wireless network at the local coffee shop, to the medium size law firm and the giant multinational distributed enterprise. The barbarians are at the door, but with a firewall we all feel protected! The largest percentage of cyber security risks, however, do not come through the front door and your firewall will never see them enter. The largest risk to the security of your network comes from the employees and guests allowed, either connected by wire or wireless, to attach to your corporate network.

As a CISCO Certified Security Professional, DrVoIP does a great deal of work in the area of computer network security. When called on to do a “Security audit”, “voice readiness” or “network assessment”, the first question we ask executive management is where is your AUP? After all, we can tell you what protocols are running around on your network, and even which user is consuming the most bandwidth. We cannot, however, tell you if they are allowed to use that bandwidth! The creation of an “acceptable use” policy (i.e., AUP) is an essential first step in network security. The AUP communicates to all network users what is supported and what applications are allowed on the network. It describes what is acceptable regarding personal email, blogging, file sharing, web hosting, instant messaging, music and video streaming. It defines what activity is strictly prohibited on the network and clearly outlines what constitutes “excessive use”. The computer network is a valuable corporate asset and as such, it needs to be valued, protected, and secured.

Does your company have a network access and authentication policy? What is the “password” policy? Do you even 0need a password to use the company network? Can anyone just come in and plug whatever phone, pad or computer device they happen to have into the company network? What is the data storage and retention policy? Do you allow VPN tunnels that extend your company network to a home office or coffee shop? Do you allow your users to connect third party provided equipment to your network? Is it acceptable that Bob just added a hub to his office network connection so he can plug in his own printer? How do we feel if Bob plugs in his own wireless access point? Do we have a “guest” network and do we let those folks know what is acceptable on your network?

What are the legal ramifications and liabilities you are exposed to if you are providing a computer network as part of a lease agreement? Are you liable for damages if your computer network is unavailable or “down for any reason? If Home Land Security shows up because your company’s public IP address was traced as originating a terrorist treat, do you have the user agreements in place to mitigate the costs you are about to incur defending your good name and reputation?

Computer network security is more than a firewall. A computer with an Ebola virus, Adware or nefarious RAT (remote access terminal) will infect all computers on your network, threaten your corporate data and render your firewall as useless as a screen door on a submarine. If your company has taken the prudent step of providing a Human Resource or employee manual that spells out the company’s position on work force violence, sexual harassment, vacation day accrual and drugs in the workplace, why don’t you have a manual that defines the acceptable use of your most vital corporate assess, the computer network?

Contact DrVoIP@DrVoIP.com and ask us to send you a sample AUP! We can assist with the creation of an acceptable use policy that makes sense for your company and your employees while protecting your valuable communication and collaboration asset, the company Intranet! Then and only then can we do an effective “network assessment”. – DrVoIP

V14 Trouble Shooting ShoreTel SIP

Posted on April 30, 2015 by DrVoIP

ShoreTel SIP is just not that hard to configure! When things go right, and it all works, it is relatively painless and very easy. When things don’t work however, you will need to sort out the problem and figure out how to make it work. The good news is that SIP is a clear text, english like “requests” and “response” message exchange that, once understood can be relatively easy to work with. Using packet capture tools like Wireshark can be a real assist. ShoreTel has built “remote packet capture” into the V14 diagnostic portal and makes debugging sip issues even more easy to digest.

The message exchange for SIP “extensions” is not much different than that for SIP “trunks”. So to learn SIP why not study a successful SIP connection first, before diving into a debug session. What we have tried to do in this tech tip, is to illustrate the process of a SIP extension registering with a ShoreTel proxy server. We picked a configuration that is comparatively complex, but not unlike one that you might find in the real world. SIP extensions can unit remote office workers into a seamless call handling workgroup. As such your remote worker will traverse a couple of firewalls and routers on its way to the SIP proxy.

In this configuration we register a SIP soft phone, remotely from the ShoreTel HQ site, over a site to site VPN tunnel. The VPN tunnel is between a CISCO ASA and a SonicWall TZ250. We note that 90% of the SIP issues we see having nothing to do with the configuration of the ShoreTel equipment and everything to do with the network devices, routers, switches and firewalls that are part of the SIP solution. Small business solutions, for example, tend to bring the SIP trunks into the phone system over the same connection they bring in their internet connection. This means the SIP trunk is passing through the firewall, another most likely candidate for inducing a SIP failure.

This tech tip walks you through a successful SIP registration of a remote soft phone. In our next tech tip, we will walk you through configuring a SIP trunk through a SonicWall and then look at fixing some broken SIP connections!

A ShoreTel Workgroup is a Contact Center for the rest of us!

Posted on April 8, 2015 by DrVoIP

We have been working around the call center space for a long time. Actually, it is our first love! Does everyone need a full blown Contact Center? If you have a real boiler room operation, with shifts of agents that are heavily manged, counted, recorded, measured complete with staff forecasting and multiple channels of client communication, yes you need an Enterprise Contact Center. As Arlo Guthrie might say “what about the rest of us”? The small to medium size business that is really not cracking the whip on customer service agents, but making efficient use of “knowledge workers” who often participate within a group setting. How do we organize customer calls to this group?

A techncial support group or an order entry group might be a good example. By grouping these folks into a “workgroup” we can funnel calls to them in a call center like fashion without the call center overhead of application servers and third party middle ware. ShoreTel has an embedded call center like feature aptly named “WorkGroups” that is an ideal solution for this environment. You can organize a group, route calls to group members and even queue the call until a group member becomes available. While callers are in queue, you can organize the messages they hear, the time they wait between care messages and you can also provide “bail out” options at each step of the way.

The workgroup can be reached as a menu selection off of an automated attendant or have a phone number assigned that enables outsiders to call directly to the workgroup! The workgroup can have an operating schedule applied that routes callers to alternative answer points if the group should be reached after hours. Group members can Log in and Log out of the workgroup using their ShoreTel Communicator and still maintain their personal extension number and mailbox. While logged into the workgroup, they can share the group voice mail box and see callers waiting in queue! Supervisors can monitor the callers in queue and manipulate resources to meet call demand. Reporting statistics on the group are maintained and easily obtained by the workgroup supervisor or administrator with reporting permissions.

We are now even making it possible for Callers to TEXT into your workgroup! Group members can even email back a TEXT message!

The ShoreTel Workgroup strategy is a powerful call center like functionality and very cost effective. The marginal cost of adding agent and supervisors license when you plan to implement a ShoreTel iPBX when compared to adding a complete Enterprise Contact Center is amazingly low! We would be happy to explain the difference between a Workgroup and the ECC, so just contact us for details!

TEXT the keyword “workgroup” along with your name or email to 702-956-8700 and we will respond immediately!

VPN’s and VoIP – Getting Connected!

Posted on April 7, 2015 by DrVoIP

We see a lot of VoIP deployments that come to us for trouble shooting. A common problem statement is that our HQ site can call both Chicago and Dallas, but Dallas and Chicago can’t call each other. Savvy network administrator will have figured out that there is a routing issue, but how so? Clearly HQ knows how to reach each remote site and the remote sites know how to reach HQ, so where is the break down! At about this time, we learn they have VPN’s that provide tunnel connections to each location and we go clear!

The standard “tunnel” solutions include IP Security (IPSec), GRE, Easy VPN and the new “tunneless” Group Encrypted Transport VPN (GET-VPN) VPN’s are the connectivity options we currently have available. Most folks make the mistake of picking IPSec for connectivity and being an inherently point-to-point technology, they end up with the problem statement summarized above. Even a “hub and spoke” solution is not ideal unless we make it possible for “spoke to spoke” connectivity. Ideally, we need to configure our VPN so Dallas can communicate with Chicago, without passing through HQ!

IPsec is really an encryption and authentication technology that enable secure communications through a public internet. It is generally used in a multiple vendor deployments. IPsec does not support any protocol other than IP, so it can not be used with the routing protocols that might otherwise be used to solve our issue. For this reason, many deployments will use GRE over IPsec. GRE to address the routing protocol issues and the IPsec to provide the security of authentication and encryption. We are still however, in a point to point mode, or in heavy manual administration mode to configure a simple mesh!

The smart money is on “next hop resolution protocol or NHRP” used in strategies like FlexVPN, GETVPN or DMVPN. These solutions provide a full mesh option while providing for encryption and data integrity. In the problem statement above, had we installed GET-VPN, a tunneless solution, the Chicago and Dallas sites could communicate directly without having to route through HQ at all