Category: VoIP Tech Tip

V14 Trouble Shooting ShoreTel SIP

Posted on 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!

ShoreTel fail over options using Vmware – Part 1 Building a VMware Test Lab!

Posted on by DrVoIP

The most often asked question we hear among ShoreTel system administrators is how best to achieve “fail over”, assure high availability and assure business continuity? There is no simple answer to this question nor is there any one “best practice”. It is going to depend on any number of interrelated issues including budget, facilities, availability and down time goals. With unlimited funding there are many more options then there are if we have a very limited budget. Is our deployment located in a single facility or scattered across multiple sites? Do we have an onsite data center or a “cloud” or collocation facility. Can we tolerate any down time at all or are we looking for hot fail over with no service interruption?

Redundancy by itself is not sufficient to guarantee high availability or continued uninterrupted business operations. Two power supplies are always better than one (especially if they are plugged into separate electrical sources) and RAID disk arrays are more reliable than a single spinning hard disk and iSCSI may even be a better. Many system administrators have explored commercial options like Double Take with its active/active fail over strategy.

At the end of the day, our view is that multiple hosts across multiple locations in a virtual or cloud based deployment are you best options. We think VMware and Amazon are unstoppable solutions providing high availability and business continuity assurance that maximizes budget, simplifies administration and with the lowest risk. Though we will have much more to say about Amazon Web Services, especially how it can best interface with VMware, we are going to demonstrate several configuration built on the vSphere ecosystem.

In our opinion  your ShoreTel partner should have installed your deployment on VMware from the onset.  A single VMware ESXi hypervisor host running your ShoreTel HQ Server and a ShoreTel Distributed Voice Mail server with the DVM installed at the same site and at the same level as the HQ server, will provide a very effective fail over solution at the lowest possible cost.   VMware Essentials gets you ESXi and vCenter for $540, what is to think about? A single hardware host with two virtual Windows servers, a shared iSCSI data store and a copy of FreeSCO  will best any effort to run redundant HQ servers!   ShoreTel servers can fail up, so just put all of your HQ switches and Users on the DVM and if it fails, HQ will take over.  If HQ fails, no  real harm done.

Sounds like a lot of hardware complexity but we are going to demonstrate this on a lab system consisting of a single Windows Laptop! Through the miracle of VMware,  Openfiler and FreeSCO we are going to create this entire solution and use it to prove out several different “fail over” strategies that can be used to develop “high availability” options for your ShoreTel deployment.   Additionally if your are just learning VMware, this will be an excellent  “play pen” and “sand box”and learning environment,  well within the budget of any serious student of virtualization. If you can access a lap top the rest of the requirements can be obtained as open source “free ware” or evaluation software. So lets lose the excuses and get to work!

Building your “Sandbox”!

Our test environment will consist of 3 ESXi Hosts, an iSCSI data store, a CISCO compatible routers; two Windows servers; and  two XP or better Windows PC’s.  As this entire lab will be built out on a single device here is the “parts list”:

(a) Windows laptop – If you have several spare PC’s or servers that you can make use, of great but we can build out this entire test lab on a single laptop. The only requirement is that we need 16GB of RAM! as long as you can expand the memory to at least 16GB.

(b) Your first lesson in virtualization is to understand the difference between a type 1 and a type 2 hypervisor. VMware ESXi is a type 1 hypervisor and that means that it is installed on a bare metal host computer, typically an appropriately configured server.  VMware Workstation is a type 2 hypervisor meaning it is installed on top of an operating system, like Windows,  already installed on a bared metal hardware platform.  In this case, we have a laptop running Windows 8 and we are going to install VMware Workstation on top of Windows. You can download an evaluation copy of VMware Workstation from http://www.vmware.com/products/workstation/workstation and when the 90 day  evaluation is up, if you can find $249, it is our recommendation that no VoIP Engineer or Field technician should be without this a lap top running product.

(c) ESXi is a type 1 hypervisor and the really good news is it that it is still available absolutely free of charge. This will be the core of our test lab and we will build out three hosts, all running in VMware Workstation on our laptop, to support our ShoreTel deployment.

(d) Building out a ShoreTel HQ server under ESXi as a single server is what most folks do.  If you are going for high availability, however, you need to consider the size of your data store.   Even if you are only restoring a “snap shot”, the size of your data store may be the limitation that determines down time.  Rather than store the application data on the Windows server used for your ShoreTel HQ erver, we recommend that you install an iSCSI data store on your LAN.  In this way , if you have to restore the server, you will already have the data store available (this is where AWS S3 comes into play, so see our previous blog regarding backup strategies).  You can download community edition of Openfiler  the iSCSI data store we are going to deploy in this lab from http://www.openfiler.com/community/download as we will be configuring our deployment based on the availability of network area storage.

(e) One of the “must have” software tools in our Engineering laptop tool kit is a three interface router named FreeSCO!  It is pronounced “Free CISCO”as a take off on our favorite company to hate.  For those of you who ever wanted to deploy a fully functioning CISCO router from a USB drive,  down load this now from www.freesco.org or download the ova we created which is available in the member portal of the DrVoIP web site.

(f) Lastly, you will need Windows Server software, either Windows 2008 or 2012.   You can  download an evaluation copy from Microsoft at http://msdn.microsoft.com/en-us/evalcenter/dn205302.aspx if you do not have a copy kicking around your lab.

(g) Lastly, ShoreTel has never asked for our opinion but they do not make evaluation software easily available to lab environments or to students who hope to be future ShoreTel VoIP engineers.  ShoreTel software can only be legally obtained by purchasing a system or through a support agreement from either a ShoreTel partner or directly from ShoreTel TAC.  If you are a partner or covered under a support agreement, you can down load all sofware from the ShoreTel site.  The iPBX software will run license free for 45 days.   Our lab is going to make use of the ShoreTel HQ server, the ShoreTel DVM Server and several virtual Shoregear voice gateways.

The DrVoIP video demonstrates how this lab is constructed and how the various components are installed and is part of the over all VMware training material available (or soon to be posted) on the DrVoIP website.   This lab will enable you to not only become very comfortable with VMware in general, but help you explore the various options for providing high availability and business continuity to your ShoreTel deployment.

AWS S3 – a ShoreTel backup strategy!

Posted on by DrVoIP

Amazon Web Services (AWS) has a range of storage options that make them our first choice in cloud based storage solutions and an ideal location for our ShoreTel data backup. In fact, now that ShoreTel has moved to virtualized hardware for voice gateways, we have moved our entire ShoreTel deployment into the AWS EC2 environment, but that is the subject of a separate blog! AWS is an ideal solution for backing up your ShoreTel configuration. You can choose to back up to the Glacier storage service if you can stand a few hours of down time retrieving the backup files, but S3 (simple, scalable, storage) is the best solution for setting up a shared network drive to faciliate your ShoreTel Server backups.

Backups should be a regular part of your IT hygene and should automate the process of securing data offsite. Enabling AWS S3 is a very simple, cost effective and can be fully automated. You can also take advantage of other AWS services like SNS push notification services to send verificaiton and administration alerts. Given the global foot print of AWS, the growing base of AWS data and availability centers, even your backup solution can have a backup solution! AWS is an infrastructure as a service so you will still need to manage the process.  The provide facilities, but you share responsbility. For example, you wil need to find a client side solution to enable your backup. You can use an AWS provided sample API if you want to write an interface into an exsiting backup solution but most deployments can more than benefit with a simple software solution installed directly on your ShoreTel server. We recommend either the TntDrive or the Cloudberry solution, both are excellent and even have freeware and trial versions!

Opening an AWS account is very easy to accomplish and if you already have an Amazon book buying account you are already good to go! Just log into AWS, bring up the menu page and select S3 from the storage and content delivery options. It will take about two minutes to create a an S3 “bucket” and apply then apply a security profile! You will need to note your identity and security keys as they are used to “log into” your new bucket. Once the bucket is created, you can then go to your ShoreTel server and establish a shared drive using one of the client side solutions like TntDrive or Cloudberry.  (You might also want to check out the comparison of other backup solutions for Mac based computers).

The ShoreTel Data file still contains all the information you need to rebuild your system from a bare metal server and you can also make use of the ShoreTel provided backup scripts to further assist your efforts. Our standard best practice is to include AWS cloud backup as part of our ShoreTel support agreements for all DrVoIP clients so there is no reason for any company, regardless of size, not to have a current backup of their ShoreTel deployment safely stored off line!

DrVoIP will provide free ShoreTel backup for any ShoreTel system owner that asks us to do so! The DrVoIP Video walks you through the process of setting up backup using AWS S3, from bucket creation to client side install!

ShoreTel VPN or MPLS? What works and saves money?

Posted on 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 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

 

 

Run ShoreTel on Vmware Player or Oracle VirtualBox!

Posted on 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!

 

 

 

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

Posted on 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.

Contact us with your ShoreTel application requests especially if they require SMS connectivity to your Call Center!

Slamming it with ShoreTel Call Manager desktop deployment option!

Posted on 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 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.

 

ShoreTel V14 Real-time Diagnostic and Monitoring Dashboard

Posted on by DrVoIP
I am found of repeating that “product development is a process not an event”!   Though the marketing folks need to package, position and promote products based on feature sets, generally products emerge over time.   Building on previous releases, customer feed back and recommendations, products continue to emerge with new functionality.    Most product development focuses on features that have market demand or differentiate one product from another.   Occasionally, a new product feature is targeted at someone other than an end user.   Engineers and Technicians are typically the last group of people to get a feature developed that makes their lives a bit more easy.   Such is the case for ShoreTel Version 14 and the introduction of  a “Diagnostic and Monitoring” tool!
The latest Version of ShoreTel has added a capability that we think is essential in iPBX technology as SIP becomes more of a standard.   If you have ever attempted to trouble shoot SIP without the ability to do packet capture, you will know how valuable this feature set is.    CISCO long ago had RMTM tools as a standard part of a Call Manager deployment.   ShoreTel has now added that functionality to its standard product offering and it is dramatic!   Now part of the ShoreWareDirector user interface, the Diagnostic Monitoring tool is a complete glass cockpit with a variety of monitoring tools.  These tools include real time status updates of system  areas including connections, trunk groups, bandwidth utilization, voice quality, switch status and service conditions.   Combining “Quick View”, with other tools that previously required loading  modules or a putty session,  the Diagnostic Monitoring center is a self navigation center for trouble shooting.
We are particularly excited about the “remote packet capture” feature of the Diagnostic tools.    This tool enables you to remotely capture packets and bring them to a local pcap file.   You are offered the opportunity to capture everything or limit your capture to specific areas of interest.  For example, if you want to capture only SIP packets related to the ShoreGear switch you are running your SIP Proxies on, the diagnostic tool set lets you select these options.  The files are WireShark compatible and if you have that application on your server, a simple click will launch the application and bring up your capture for analysis.   This is a very power capability and simplifies some of the issues associated with setting up WireShark for remote capture.   We think this feature set was long over due, but we are just mere engineers, what do we know!