ShoreTel ECC MySQL rants, raves and solutions for email, chat and text (SMS) messaging!

Posted on November 13, 2014 by DrVoIP

If you have worked with ECC custom integrations for any length of time, you have build a library of solutions to work with. Most recently you have discovered that a 32 bit application like ECC, running on a 64 bit Windows 2008 or 2012 server needs a 32 bit OBDC driver! When you click on Data Sources in Windows, you are shocked to notice that none of the ECC database connectors are showing under the DSN tab in the OBDC data source administrator. You then go to add a driver for that new MySQL application your client wants and install and test it connects OK. Then you log into Contact Center Director and notice that the OBDC connector does not show up in the list of external database connections. WTF? Well this turns out to be a Microsoft issue, but you have to find a solution anyway! So you learn to ignore the normal Data Source Administrator installation procedure. Find the correct OBDC driver and download it to C:\Windows\SysWOW64 for example C:\Windows\SysWOW64\odbcad32. (Much thanks to Tyler and Mark at ShoreTel TAC for this insight). Clicking on this will bring up the 32 bit version of the OBDC Source Administrator and you will find that DSN now displays both your new connector and the existing ECC connectors!

Version 9 of ECC has some changes that you need to be aware of, most notable of which is the lack of support for POP email mail connectors. IMAP is now your only option. If you are going to create ShoreTel ECC Email connectors you will need to get the co-operation of the client IT department, most of which go nuts when you tell them that you want to turn this protocol on in their Exchange sever. If you are using Microsoft Office 365 you have other challenges. If you want to add CHAT then you will also need to get IT to provide you a Tomcat server! In a deployment with an ShoreTel iPBX, ECC and IRCC server and just cant bring myself to tell the client they need yet another instance of MySQL on yet another server! To overcome some of these challenges and to make my life as a deployment engineer a bit more predictable, I have developed my own solution!

If I work with a client that is going to deploy ShoreTel ECC using CHAT, Email and also expects to do some SQL data dips, I prefer to provide my swiss army knife solution. We created a Linux appliance that supports a number of required integration components that we can fully control without relying on the client IT organization. The small 19”rack mounted appliance houses the following:

(a) Our favorite distribution of Linux;
(b) MySQL Server and Postgresql Server;
(c) Apache Server;
(d) TomCat Server;
(e) Mercury Mail:
(f) VPN, SSH and FTP servers;
(g) Webmin and phpmyadmin admin tools;
(h) php, perl and some other development tools
(I) A library of network assessment and monitoring tools;

MySQL and PostgreSQL are absolutely necessary for doing any type of external “look up” and route functions. ShoreTel does not provide ‘root’ access to the MySQL instances running on the other three servers, so you have to do something! Unless you want to jerk around with the clients IT organization or database team, we recommend you roll your own. Likewise with email. Just setup Mercury Mail to handle your ECC email accounts and be done with it. It will cost you another C and MX record, but so what. Most of our ECC applications need a web sever and rather than deal with TAC on what is and what is unsupported on a ShoreTel server running Microsoft IIS, just use Apache and be done with it! To do CHAT on ShoreTel ECC you will need a Tomcat server as well. For less money than will be wasted on professional service hours chasing other folks around so you can do you work, this is a great solution for ShoreTel ECC integrations, email and Chat! (Since we do have root access to the vmware image ShoreTel provides for the conference server, that might also be an option. We will take a look and update you later – DrVoIP).

ShoreTel VPN or MPLS? What works and saves money?

Posted on October 13, 2014 by DrVoIP

An IPsec Virtual Private Network or VPN, is sometimes used as a backup route for a Wide Area Network failure. VPN’s are typically deployed as a “tunnel” through the Internet and as such are “point to point” solutions by definition. Unfortunately that will not get the job done for a VoIP deployment! If you have ever deployed ShoreTel over a VPN in a multi site network that has more than two sites, you will note that it has problems. The first problem you will note is that the Switch Connectivity display within the ShoreTel ShorewareDirector management portal looks like a Christmas tree. Normally in a finally tuned network you should see all green in the connectivity display. In an IPsec VPN network, using a “hub and spoke” implementation or “point to point” links you will see lots of Red and Yellow boxes and switch connectivity will be inconclusive at best.

Next, you will undoubtedly experience instances of “one way audio”. Again, this is because an IPsec VPN is a “point to point” solution, when you really require a fully messed solution that can handle more than unicast packet transfers. Additionally, as IPsec applies encryption based on a “shared key” so the two end points must possess the key! IPsec does not support Multicast or Broadcast and this make it less then desirable for a VoIP deployment. Unicast is when you address the source and destination IP address to a specific target device. Broadcast is used when you must sent to all network devices because you do not know the destination address. Multicast is used when you send to a group of devices that monitor a target IP address for network management and service subscriptions. Using an IPsec point to point VPN might get your phones to register and enable you to make phone calls, but you will be plagued by network connectivity issues that will make your VoIP deployment problematic. Your technical support center or help desk phones will be constantly ringing with unhappy users and incomplete phone calls.

You don’t have to be a Network guru to understand a “hub and spoke” topology. All communications between devices at different sites (i.e. spoke end points) must traverse the hub site if they are to communicate between each other. This might work for unicast communication, but it is inefficient and invites disaster. For two sites (i.e. spokes) to communicate the have to go through the hub, unpacking and repacking, encrypting and decrypting, sharing keys before resending packets to the ultimate destination. Assuming you are using this configuration only as a backup during a real WAN disaster, this might be acceptable temporarily. Using IPsec VPN “hub and spoke” topology in a ShoreTel VoIP deployment, it is not very useful. We have two issues: first, IPsec does not support anything other than Unicast communication; and secondly “hub and spoke” is unworkable because “spoke to spoke” communication is required.

How do we solve this? Fortunately there are two strategies that fit the bill perfectly. First, GRE or ‘generic routing encapsulation’ should be used to support broadcast and multicast communications, a core component of any network deployment, especially those of a VoIP variety. Secondly, DMVPN or “dynamic multipoint virtual private network’ technology should be implemented to assure “spoke to spoke” communications. DMVPN, which employs mGRE (muti-point GRE) and Dynamic Next Hop Router Resolution protocol (DNHRP) technologies make it possible to deploy a ShoreTel VoIP solution over the public internet and achieve MPLS like connectivity at a fraction of the cost. Given sufficient bandwidth, this should be more than adequate.

What about encryption you might ask? ShoreTel, CISCO and most VoIP solutions provide encryption at the network and transport level anyway, so this component may not be needed. If you are also moving data over this mesh, then you can use DMVPN in conjunction with IPsec to assure confidentiality, integrity and authentication (i.e. CIA). The issue is that a fully meshed communications network is absolutely obtainable with VPN technology, but you have to implement the correct protocol to achieve the desired results!

WAN configuration is an exact science as is ShoreTel and CISCO VoIP technology. If you are fortunate to have that level of expertise in one individual or one vendor, then you are moving in the right direction with your VoIP deployment. If you need help in the WAN aspect of VoIP, then you need to call on DrVoIP. We can make the network.

ShoreTel Virtual Trunk Switch – Configuration and License impact!

Posted on September 3, 2014 by DrVoIP

ShoreTel currently has three virtual appliances that can be used in place of the Orange ShoreGear voice gateways and conference servers. These three virtual appliances are shipped within the ShoreTel core Server Software and consist of OVA files and ISO images. The tree appliances consist of the phone switch; the trunk switch and the Service Appliance, a virtual replacement for the SA-100 and SA-400 conference servers. Once they are virtualized, they install exactly like the hardware versions of the Orange ShoreGear boxes. The only noticeable difference, is that the configuration page in the ShoreWareDirector does not seem to offer up the image of the switch as it does with the hardware version. There are no drop down boxes for configuration of switch feature options in large part because each option is defined by the OVA file. We note only two ISO images in the FTP root of the HQ server, so we have concluded that the same ISO is used for the phone switch as is used for the trunk switch, the differences being set by the OVA file.

Each of the virtual devices install in a very similar manner, with little difference as it relates to the bring up under VMware. Open the proper OVA file and the hardware is appropriately configured. Launch the machine and you will be required to provide the normal Network configuration data and identify the location of the ShoreTel HQ/FTP server. After the machine is configured you can log in as root, run Ifconfig to check your network card settings and note the MAC address for configuration in the ShoreWareDirector. Then bring up the cli interface using “stcli” and you will be greeted with the familiar and easy to navigate ShoreTel Switch menu system. You will need to add the FTP, NTP and DNS address information. Having a primary NTP source is of critical importance especially when configuring the Service Appliance used for conferencing applications.

Now that the virtual machine is configured and running you can add it in the ShoreWareDirector. Again aside from the lack of an orange switch image on the configuration page, it installs like any other ShoreGear device. From a license perceptive, no harm done until you actually configure a SIP trunk. In addition to the normal SIP trunk licenses you will need for any of the hardware gateways, the vTrunk switch will require licenses as you add trunks to the virtual appliance. All in all this is sweet stuff and you should have a ball playing with virtual switches! The video walks you through the entire setup! – DrVoIP@DrVoIP.com

Hacking ShoreTel with Wireshark or Trouble Shooting One way Audio.

Posted on August 19, 2014January 14, 2024 by DrVoIP

My First Hack?

When I was a little kid, back when there was black and white TV sets and 33 RPM records, I was always amazed at the work of the telephone company repair man! At that time there was only one Phone Company. When they sent a repair man out your house he arrived in a drab olive trunk like those used by the Army. The telephone repair man had a belt of tools including a very Kool line mans “butt set” or handset and some really super hand held drills and other stuff.

I remember watching as he installed our new “touch tone” wall phone! Then I watched as he took the “butt set” from his tool belt and like all those spy movies, he clipped it across the copper wires, which I later learned were Tip and Ring, to test the circuit! I did not even have to ask, I could hear it. When he clipped across the wires he could hear the conversations that were being held on that circuit. How freaking Kool is that!

Now with IP or VoIP telephony, the butt set has gone away, but listening in on phone calls is still possible. Forget the NSA, is one of your employees copying and recording your conversations to a USB drive and posting it on Facebook? The fact of the matter it is easier than using that old “butt set” which required a physical presence and an ability to touch the circuit. With VoIP, you can “remote “in from anywhere on the planet, do a remote packet capture and leave little or no trace that you were even there. In fact, using some deep net technology like Tor, or stacking multiple virtual machines in an Amazon cloud, not even the NSA could trace your route!

Network engineers long ago figured out they could not see the packets that run around the local area network, let alone those that go off into the Internet. Tools were needed to capture the packets, slow them down and sequence them through a protocol analysis. One of the early on tools to do this, now named Wireshark, is the minimum daily adult requirement for network trouble shooting and must definitely for VoIP problem analysis. With this software tool, a network engineer can capture all the traffic moving over the wired or wireless network that interconnects your office to the World Wide Web, and save it for future analysis. The TCP/IP protocol, though a mystery to the uninitiated, is like a microscope to a network engineer or serious hacker.

It continues to amaze me that technologically I can position myself as a “man in the middle” and basically watch as you type your user name and password into your favorite website. Bored teenagers or “script kiddy’s” now do this for light entertainment. Again, forget the NSA, your teenager has more ability to track your internet activity and probably more reason to do so. Now apply this concept to your VoIP network, and you have much the same situation. It is very possible to gather up the packets on your local network, or in route to your SIP provider and reassemble them into complete phone calls.

Next to QOS issues, “one way” audio issues are among the most common of VoIP network issues. When trouble shooting these kinds of issues on ShoreTel deployments, we typically telnet into each phone in the conversation and ping our way from the phone, to the default gateway and back to the other end. Invariable we find a configuration error in a default gateway somewhere on the network. QOS issues are best solved with a protocol analysis and verification of call control signals.

This is where Wireshark comes in.

Version 14 of ShoreTel simplifies the use of Wireshark. As a Network Engineer you are aware that if you install Wireshark on the ShoreTel HQ server, you are only going to see unicast packets sent to the Server or multicast broadcasts set to all devices on the network. Wireshark will not see unicast packets sent to the other devices on the network unless you setup remote monitoring or port mirroring. With Version 14 of ShoreTel, you can setup remote monitoring from the HQ server and copy packets for analysis and assembly. Voice or RTP media between ShoreTel phones and ShoreTel Switches is encrypted while on the network. Media traffic between devices in not encrypted and can be captured and played back. MGCP, unlike SIP, treats RTP as UDP and you will need to modify Wireshark preferences to capture it as playable voice.

The accompanying video walks you through the process of capturing VoIP traffic, looking at both MGCP and SIP call control and how to assemble voice and media streams for playback.

Run ShoreTel on Vmware Player or Oracle VirtualBox!

Posted on July 14, 2014 by DrVoIP

With the release of ShoreTel Version 4.2 the company introduced the concept of virtual appliances. These software objects, had the potential of replacing the Orange ShorGear hardward boxes that typically characterize a ShoreTel deployment. The wisdom of trading the power of dedicated hardware based digital signal processing chips for the variable power of a shared computing resource aside, there are any number of advantages to using “virtual machines”. Currently ShoreTel supports Vmware ESXi and Hyper-V, so we thought we would push the envelop and try alternatives, for example Oricales Virtualbox and Vmware’s Fusion and Vmware player and see what results we could achieve. Just for kicks we thought we would see if we could inport and OVA file into Amazon Web Services and run a ShoreTel switch instance in the cloud!

The ShoreTel OVA and ISO files are distributed with Version 14.2 and you can link to them in several ways. They are in the intetput, ftproot folder on the ShoreTel HQ server. You will find two folders TSU and TSV, each with an OVA file and an ISO image. The TSU folder contains the objects necessary to create the Conference Appliance and the TSV folder contains the Phone and Trunk Switch objects. Think of the OVA file as a configuration profile that draws the outline of your virtual machine and defines the basic hardware configuration. The ISO image, contains the operating system. In the case of the ShoreTel ISO, it is in fact a Windriver Linux distribution, which has its roots (excuse the Linux pun) in the https://www.yoctoproject.org.

Clearly, ShoreTel is cutting the cost of goods, by reducing the need to produce Voice Gateways. It does not look to us however, that they are passing any of that reduction off to end users however. The cost of implementing a virtual ShoreTel Gateway is not much different than the cost of actually buying the hardware solution. The motivation for using the Virtual machines must be based on something other than acquisition cost. For we engineers however, it is fun to play with. You can spin up a machine in short order and use if for 45 days before you have to pay for the licenses. In the case of the conference appliance, there does not appear to be any cost other than the hardware used to run your Virtual Machine.

There appears to be three options for virtualization: the conference server; a phone switch and a trunk switch. The conference server lets you create an environment for web based conferencing and desktop sharing. The phone switch is a direct replacement for the ShoreGear family of users switches. Likewise the Trunk Switch, enables you to create SIP Trunks. If you have no hardware to connect, there is no reason that you can not put your users on a virtual switch. In fact if you have no copper connected to your VoIP deployment in the form of analog phones, telephone company analog lines or digital lines, your entire ShoreTel soltuion can be a figment of your imagination, living only in a virtual world, HQ server included!

Ingate apparently has made a Session Border Controller that is virtualized and may be integrated with the ShoreTel Trunk Switch, but we have yet been able to get a test device in our lab. Having a Virtual Switch configured and available as a “fail-over” solution or secondary switch in a ShoreTel deployment makes a lot of sense to us. You can configure the switch, put it live in your deployment and you only pay for it if you actually fail users over to it and you have 45 days to think about it! We have been able to successfully deploy ShoreTel in an Amazon Cloud, completely in software, using SIP trunks and remote phone registrations over VPN. There are lots of powerful options for deploying a virtualized ShoreTel, limited only by your imagination!

We attempted to deploy ShoreTel on an Oracle VirtualBox but keep running into an issue with the network adapter settings. The ESXi version of Vmware allows you to create a soft ethernet switch and route it to the rest of yoru network. The VirtualBox achieves the same flexibility allows you to NAT, Bridge or establish a host only NIC card. As the Virtualized ShoreTel switch needs to communicate with the rest of your deployment, you need configure the NIC card to Bridge or NAT. Both Fusion on a MAC and VMware Player on PC’s resulted in working ShoreTel switches without to much drama. We were able to bring up VMware Player on the ShoreTel HQ server and build out a Conference Server replacement for the SA-100 Hardware solution with little issue.

Candidly, these are not supported ShoreTel configurations, but we are just engineers playing with all the kool stuff! Remember that if you clone your virtual machines you will need to change the NetBios names and IP addresses before they can be useable in the same deployment. The embedded video is an overview of how to configure both the Free Oracle Virtual Box and the Vmware Fusion for Mac and Vmware Player for Windows to run ShoreTel. Keep the cards and letters coming and remember to support the GNU project!

SIP as a Disaster Recovery Strategy? EtherSpeak answers the call!

Posted on May 30, 2014 by DrVoIP

As a standard deployment practice, we at DrVoIP implement SIP trunks as a “fail over” on every system we install. As reliable as your PRI circuit has been, they do fail from time to time! In fact, we recently lost 27 PRI’s at a major San Diego Hospital when a carrier ( who’s name will remain anonymous) experienced a fiber cut taking out most of their clients in the region! Stuff happens! Having an alternative circuit in place is not only a wise step to take, but by using SIP, can be very economical. We find that most carriers offer a “circuit down” capability that can automatically reroute incoming calls to another number if they detect a “D” channel failure, a sure sign that your PRI is out of service. If you have not yet done so, you should get with your carrier and set this up as many carriers require that this feature be programmed into their central office switches and is not something that can be easily done on demand. This should be configured in advance of a real system failure, and always on line, ready for use!

EtherSpeak Inc, always the innovator and at this point a “senior citizen” in the SIP service community, is now offering an intriguing disaster recovery product free of initial charge! Throughout June, you can add a three channel SIP trunk, 100 minutes of talk time and a Virtual DID number for absolutely no cost! EtherSpeak was among the first providers to interconnect with ShoreTel systems, for example, without the need for a Boarder Controller. They simply built a private IP-sec site to site tunnel, from your system to their soft-switch. This is a huge savings in both money and aggravation! This is an extraordinary value and eliminates any excuse for not implementing a disaster recovery plan to assure telephone calling services in the event your PRI goes down! Simply work with your carrier to have your main telephone number call forwarded to the virtual DID number provided by EtherSpeak and callers will never know your PRI failed! Calls will ring in over the SIP trunk and be handled by the ShoreTel like any normal phone call. Clearly, you only have three circuits, but EtherSpeak will be happy to increase the number of circuits. In fact, you might find that SIP is really all you need and you might just migrate over to EtherSpeak as your main provider!

The adoption rate of SIP technology, by both large and small enterprises, is staggering! Once the domain of only the true geek, today SIP is a very reliable, cost effective and viable alternative to traditional copper circuits. The EtherSpeak disaster recovery package is not only a prudent business continuity move, but it will allow you to get comfortable with SIP. Remember a PRI commits you to 23 paths regardless of how many you actually need. If you need 30 talk paths, the only way to get that capacity with PRI is to contract for a second 23 talk path circuit! SIP enables you to purchase exactly what you need and you may even be able to “burst” upwards if special circumstances require more talk paths! Truth be told, your carrier is most likely delivering your PRI over a SIP trunk anyway! As the cost of maintaining copper lines has continued to escalate, carriers have been slowly migrating over to soft switches that bring SIP trunks to the customer premise. Using an Integrated Access Device or IAD, the SIP trunk is then converted back to a PRI for hand off to your PBX. If you have a ShoreTel T1/PRI switch you can re-purpose that switch by converting it for use as a DSP resource to support your SIP trunks, so your original equipment investment is protected.

We are not sure what you have to lose? Free installation, no additional equipment, free virtual number and 100 free minutes of talk time? Let the boss know you are thinking and taking actions in the best interest of protecting the business and get with the good folks at EtherSpeak by clicking here and taking advantage of this free offer!

Sending Text Messages to your Shoretel ECC or CISCO UCCX Contact Center?

Posted on March 13, 2014 by DrVoIP

We recently had an opportunity to create an emergency notification text messaging system for a financial service application built on ShoreTel iPBX and ECC technology. The requirement was to push out text based alerts to individual or groups of ShoreTel phones based on external events. These were typically stock tick updates and very time sensitive! The requirements document also required the ability to send text messages on manually on demand. The text messages would either be created by the Receptionist entering the text into a webpage for transmittal to the select phones or group of phones; or based on the receipt of a SMS text message. The SMS message would be relayed to the ShoreTel Phone API and then passed off to a group of phones for follow up by brokers as required to satisfy the client requests.

We have long contended that SMS application will find their way into the Call Center as triggers to initiate a scheduled call back as alternative to “please hold for the next available agent”. The opportunity to implement such an application was for us very exciting. Smartphones, undeniably ubiquitous, offer the possibility that customer service applications can be developed to enable customers to contact an inside “agent” without having to navigate a call tree! Why increase the number of telephone lines coming into your call center, just to put callers on hold until the next available agent can accept the call? People on hold, are people frustrated. If clients could just send a text message to the call center, targeted at the specific agent group responsible for problem or opportunity resolution, assured by return text message that they will be called at place and time certain, over all costs for all would be reduced and customer satisfaction increased. The concept of “abandoned” calls would be eliminated and real time reports, dramatically redefined!

We invision a Call Center in which there are actually very few incoming lines. The entire call center is based on Agents calling clients back based on agreed to call times defined in an incoming SMS Text message sent from a smart phone or smart phone application. The application, though functionally generic, could be made specific to a company product or service and also include the CRM links necessary for an Agent to service an account when they call the client back at the appointed time. This is a much more stream lined approach to Call Center operations in which telephone lines are optimized, Client service is customized and Agent time maximized.

There are any number of SMS gateways that can be integrated as an internal server or as a subscribed service and combined with the display functions of a ShoreTel phone to enable this scenario. Additionally, Waze can send real time location updates that can also be routed to ShoreTel phone displays. Imagine the application of location based services to SMS text messages out to the display of ShoreTel phones in a call center environment! ShoreTel does an excellent job of documenting the SDK and API interfaces necessary to support this application. In fact the standard API itself is more than useful and is demonstrated in the accompanying video.

Slamming it with ShoreTel Call Manager desktop deployment option!

Posted on March 7, 2014 by DrVoIP

One of the challenges in any ShoreTel deployment is the desktop Call Manager client installation. You can breeze through the complexity of a ShoreTel multi-server, multi-site deployment only to be foiled when the desktop clients need to be installed or updated. Nobody wants the thankless task! As most users do not have Local Administration rights to install software on their desktop machines, the system administrator gets a new task. So it is either “sneaker net” or an Active Directory Group Policy push out. Meanwhile, the ShoreTel deployment is otherwise complete! Frustration as the entire deployment is good to go, but the desktop clients have yet to be installed or updated! When does the admin team get here?

Now there is a tool out there that makes sense and can be a great help to the field implementation team, charged with getting the ShoreTel system installed, on time and on budget! Enter the rock stars at AdminArsenal with a very kool software solution named PDQ deploy and put an end to this client install fiasco! The product makes it easy to do a network based push out of the ShoreTel client, by the ShoreTel installation team as long as they have an Admin account and meet these two conditions: The target computers must be on the same network. This is not an over the Internet install. The application or patch must support a silent install. Most do, however there are some who do not. The admin must determine what the silent parameter is (/s, /quiet, etc.) to do the push. (Here are package details).

Think if this as a great tool for a deployment in which the ShoreTel implementation team needs to do all the onsite work when they might not have access to the client desktop help desk. PDQ will let you install MSI files to multiple computers! If your are a ShoreTel VoIP engineer, you need to add this solution to your tool kit! Check out a free trial!

Keep those comments comming!

Repurpose your CISCO 7900 phones as ShoreTel sip Extensions!

Posted on February 22, 2014 by DrVoIP

The CISCO 7900 series of phones have been a very popular handset in the “hosted” PBX space. CISCO discourages the use of these phones on other than CISCO systems, but there are so many of them out there, that they end up being used on a range of other systems from 3CX, ShoreTel to Asterisk and FreePBX. A company moving from a “hosted” solution or converting from a CISCO Call Manager to a ShoreTel system, for example, would normally wanted to protect their investment in handsets and repurpose them for use on ShoreTel. The CISCO 7900 family of phones has been shipping since at least 2002 and estimates have been that over 1 million handsets ship to market every day! By any measure, the market is littered with these phones. We would caution you however, before you hit Ebay, to understand that what you save in the purchase of handset hardware, you may end up spending in professional services and cumulated aggravation! If you are still committed to burning up IT staff or professional service hours, there are a few key issues you will need to understand.

First, CISCO Call Manager solutions have historically used a proprietary protocol named “skinny” of SCCP. Most hosted solutions have used the industry standard SIP protocol and because of its wide adoption by vendors in general, most new systems can support SIP end points. CISCO 79X0, 79X1 and 79X2 handsets most have their firmware converted from SCCP to SIP before they can be used on any SIP based system or on ShoreTel. The process of converting the firmware is not all that difficult but does require some basic resources like a CISCO login account and a TFTP server, though we have found the needed firmware all over the Internet. Setting up a TFTP server can be implemented in a number of ways from open source solutions like PumKin or Tftpd64. We prefer Tftpd64 for field deployments as it can also provide DHCP services that include the ability to specify required scope Options 150 and 66!

You can try flashing the phone without defaulting the configuration by just unlocking it and setting the Alt TFTP server to the correct IP address. You unlock your CISCO phone by hitting the Menu key, scroll to the network settings, hit unlock (**#**) for Alternative TFTP server, set it to yes and then in the next field enter in the IP address of the TFTP server. Experience has proved, however, that you should reset the phone. There are subtle differences between how the reset and unlock method is executed based on your exact model. Generally, you reset the phone by holding the # key while powering the phone and when it starts flashing orange and red, enter 123456789*0# on the keyboard, then be patient. Make sure your TFTP and DHCP servers are setup and working. DHCP Option 150 and Option 66 must point the phone to the TFTP server and directory containing the firmware files.

Again you will find that you really need to tweak the SiP software version as one may run and another version may not!

You should be aware that v4.4 code uses the following tftp files (which areall case sensitive):
 OS79XX.TXT  (This file must be on the TFTP as it defines the software load WITHOUT .bin extension).
 SIPDefault  (This file denotes parameters for all phones)
 POS3-04-4-00.bin
 SIP<your mac address>  (eg, SIP00036BABD123 parameters for a specific phone)
 RINGLIST.DAT         (optional) 
 dialplan.xml		(optional)
 ringer1.pcm		(optional)

Early versions of the SIP code did not require all of these, however if they are in the tftp directory, it doesn't hurt the loading process.  Later you will still need the TFP server to obtain configuration file when you boot your CISCO phones. Power on your CISCO  and the phone should display "upgrading" and you should see file transfers in your TFTP server log.       Be careful as the phone will from time to time looks like it is dead, but it is still loading files.  It takes time and patience  will ultimately yield a phone now flashed for SIP!

That was the easy part, now you have to understand the configuration files, how to edit them and the boot process. When the phone boots, it makes a DHCP request for usual IP configuration parameters including the necessary vendor specific options. ShoreTel uses Option 156 to specify the FTP server where its phones can download firmware and configuration files. CISCO uses TFTP and specifies that IP address in CISCO Option 150 and Industry Option 66. When the phone boots it will first look for a “install trust list” or certificate file which it will not find in your TFTP directory, so expect that file failure. It will then look for a SIPDefault.cnf which has information for all phones, and then a file that contains configuration data for a specific phone which is named SIP<macaddresss>.cnf.

Edit the SIPDefault.CNF in Notepad file and change the first three values: The first line of the file,image_version, sets what firmware version we are going to use. This needs to match either the firmware version already loaded on the phone or the firmware version that you have available in the tftp folder for the phone to upgrade to. The second setting, messages_uri sets the extension number that the phone will dial to access the voicemail system. The third setting, proxy1_address, sets the IP address for the phone system so the phone knows where to send it’s registration information. In the case of ShoreTel make sure you point this at the ShoreTel SipProxy IP NOT the ShoreTel HQ server!

For real detail on the content of the config file click this link. Each phone requires its own configuration file based on the MAC address of the phone. If our MAC address is 00175989A49E, then our configuration file will be named SIP00175989A49E.cnf. This file contains a list of XML tags. You will need to modify several tag entries. You can use notepad, but if you can make use of an XML editor like Komodo or Eclipse it will help you eliminate poorly formed XML tags. Scroll through the file and edit the following tags:

<processNodeName>172.16.1.100</processNodeName> should be set to the IP address of your ShoreTel SIP Proxy, NOTE the ShoreTel HQ server!

For Each extension line you want to register you will need to set the following parameter:

<authName>1234</authName> to your ShoreTel SIP UserName
<authPassword>1234456</authPassword> ShoreTel SIP Password

The lines also have other configuration data for displaying the Name and Extension number and you should find those XML tags easy to locate. The above tags however are the 3 minimum tags required to get your phone to register with ShoreTel. It should be understood that getting your phone to register, make and receive calls is not the same as integrating your CISCO phone with ShoreTel. Getting feature buttons to work and interfacing with the telephone book is an entirely new opportunity for head banging. Some of it can be accomplished by editing XML configuration files, but well outside the scope of this nugget ! The most likely success stories for CISCO on ShoreTel are the 7940/7960 phones. Be aware that there are subtle difference between the rest of the family like the 7941G/7960G and so forth. The 7942 and 7945 take extra tweaking and you many need to SSH into the phone to debug. It takes time, patience and perseverance to tinker with the various phone loads and XML options, but it can be done! As we get more examples, we will upload sample configurations to the Member portal.

How to install the ShoreTel Virtual Switches!

Posted on February 10, 2014 by DrVoIP

Virtualization has significantly altered the options available for your choice of deployment models. With the introduction of ShoreTel 14.2 you can completely virtualize your VoIP deployment right down to the Gateways! If you have no Analog telephone device requirements or telephone company lines, you can now eliminate those ShoreTel Orange boxes! This is a significant advancement in the state of the art and one that will become increasingly more prevalent as we look for viable business continuity strategies. The ShoreTel virtual switches come in a number of flavors: Service appliance, phone switch and trunk switch. The Virtual appliance is similar to the ShoreTel SA100/400 server and is essentially a free feature enhancement! The ShoreTel Virtual Phone switch can also be used as the “spare” switch available for use by phones that need to register with a new switch when the ShoreGear switch they were using fails. Again, no cost associated with this unless you leave them on that virtual switch for longer than the normal 45 day grace period.

The VoIP technology in general has become more complex demanding new skill sets from those who install them. In addition to the telephony, network, firewall, SIP and Microsoft software applications that historically touch your ShoreTel deployment, you will now need to understand VMware ESXi deployments including the use of OVA files. The ShoreTel Virtual switches are now distributed as a part of your HQ and DVM server images. They live in the FTP server and can be retrieved in one of two ways. You can either download the image file when you configure your appliance in the Shoreware Director portal, or you can load it as a URL in the VMware machine configuration as the target for your OVA file.

If you are familiar with VMware, the installation process is relatively simple, straight forward and easy to understand. Once the machine is specified the Vmware configuration is as simple as adding the basic network IP components including the address of the Shoreware HQ server. The machine will ultimately configure, load and become available as a virtual machine on your ESXi platform. From that point on, there is little difference to the installation of a virtual appliance or a real ShoreGear switch in Shoreware Director. The basic difference has to do with the selection of the hardware platform type. Normally you would select an SA100 or a ShoreGear 50, for example. In the case of a virtual appliance, you will select a new category from the drop hardware list, that indicates what type of appliance you are installing. The rest of the configuration is the same. The virtual appliances behave like the normal orange” boxes, even requiring a firmware upgrade. They appear in both the Diagnostic Monitoring and Quick View and in all respects operate like their real world hardware brethren.

We should all understand that those little orange boxes contain application specific microprocessors or digital signal processors (DSP’s). The real heavy lifting normally done by those chips for CODEC work, for example, will now be done in software. Additionally, don’t make the mistake of deploying virtual appliances at sites logically, without understanding that the VMware hardware platform location is just as important on over all performance as ever! All and all this is a major step forward for ShoreTel and you can expect these virtual appliances to become a standard part of your deployments over time. The video clip reviews the actual installation of both a phone switch and a service appliance!

Note – The ShoreTel news here is that the actual Voice Gateways are virtualized, not just the application, but the Gateways!