ShoreTel SIP Trunk Configuration – Version 14 update Part 1

Our older posts on this subject are getting a bit dated and an update is long over due.   ShoreTel has been using a version of SIP since day one.  We say a version of SIP because at the formation of ShoreTel, SIP standards had not yet been solidified.   ShoreTel SIP, therefor, was not interoperable nor did it need to be.   Our fist experience with ShoreTel was Version 3.1  back in 2001!    At that time, ShoreTel did not yet support IP phones, but ShoreTel SIP was and continues to be the call setup protocol used between ShoreGear switches.

Though ShoreTel introduced IP Phones in Version 4 with the private labeling of Polycom handsets, ShoreTel SIP for desktop devices did not become available until Version 8.   This early version of the SIP protocol required you to configure the first version of the IP8000 as a SIP trunk not a SIP Extension.  It was a step in the right direction, but it was not until V13 that we got a version that was more compatible with other SIP devices and not until Version 14 before we reached PRI parity on SIP trunks with the introduction of media termination points.

SIP in general is relatively simple to configure and mirrors most of the steps you take to implement a normal TDM Trunk Group.   The devil, however is in the details!  IP profiles, NAT, firewall, Digest Authentication and Carrier particulars need to be mapped out.   Generally, a Session Border Controller is a best practice for a SIP deployment.  Where does your network end and the carrier network begin?  Well, that is the single most important benefit of a SBC!  Additionally, the SBC can be the point at which we “normalize” SIP messages and translate between any dialectic differences between SIP implementations.

Generally, in ShoreTel you will setup your underlying resources by allocating ShoreGear switch ports, media  termination points, profiles, timers and DTMF handling configurations.  The  Creation of a SIP trunk group is very similar to the configuration of a PRI trunk group and the same options will need to be specified as to the use of this group.   Then SIP trunks are added to the SIP trunk group, the actual circuits on which phone calls will take place.   If the trunk group is to support tandem trunking and is connecting to another system as a tie line, the off premise extensions and digit translation options will also need to be configured.

The first video will walk through the configuration of a TIE trunk between two ShoreTel systems.  One system will use the TIE trunk to place all outbound PSTN phone calls through the other ShoreTel system.  Both systems will use the Trunk Group for extension to extension calling, with one system having extensions in the range of 200-299 and the other having extension in the 300-399 range.   We will walk through the basic configuration and then also take a look at wireshark captures to illustrate the SIP call setup message exchange.    In the second part of this update, we will the route calls out a SIP trunk to a SIP carrier for PSTN calls, using several different SBC’s.

Contact DrVoIP@DrVoIP.com to have us setup this up for you!  We offer flat rate configurations!

 

ShoreTel fail over options using Vmware – Part 3 the “HA” and “FT” Option!

A quick review of vocabulary before we go into this subject any further.    First when we refer to vSphere, we are talking about the entire VMware ecosystem and all of its components.   It is just a short hand for the entire system solution.    ESXi is a VMware hypervisor.  It is the “host” hardware on which the “guest” virtual machines run on.  vCenter is an administrative portal that enables you to manage multiple Datacenters.   A Datacenter is a collection of ESXi hosts.  I strongly urge all serious engineers to watch Kieth Barker’s presentation in CBTnuggets on this subject, particularly his presentation on HA and FT in the certification training for vSphere VCP5-DCV.  Kieth is a truly excellent instructor and he gets paid to make videos!

A more advanced ( read cost more money) strategy for managing server failures in vSphere is either High Availability or Fault Tolerance.    Assuming we have three ESXi hosts, lets take a quick look at how each of these strategies would work.   Using vCenter we would enable High Availability or HQ at the cluster level.  The first ESXi host to boot up, would be nominated Master. Assume the ShoreTel HQ is a virtual server running on this ESXi(1).  All the ESXi hosts in the cluster, would exchange heart beats over the management LAN that they all share.   Should the heart beat from ESXi(1) not be detected, it would be considered down and the virtual machine would be restarted on the secondary server in that cluster.

An VMware server running VMware Tools, can also generate heart beats between itself and the ESXi host that it is running on.   Should the host not receive a hear beat from the guest VMware server, it would consider it down and cause a new instanc of that VM to run.   Generally, it is a good practice to use a backup hearbeat to verify the failure of a machine.  For example, if the host machine does not generate a heart beat detected by the other hosts in the cluster a back up check could be made to see if the iSCSI storage is being accessed by the missing VMware server.  If that heart beat is detected, then the guest is not considered down, but is consider “isolated” and the new instance will not be started.

The issue with High Availability is how long does it take to bring up the replacement guest machine on a new ESXi host?   What is the boot time?   In Part 2 of this discussion we talked about a configuration that could survive this issue if it was the DVM that went down as the HQ would take over during the down time.  If this was implemented in vSphere with HA, the entire process would be transparent to users.

Fault Tolerance is the solution when there can be no down time whatever  should the HQ server fail.    FT is activated through vCenter as easily as HA, but generates a “mirror” image host that is always running.    For example, a ShoreTel HQ server running as primary on ESXi(1) might have a “mirror” host running as a secondary on ESXi(2).   Should the primary ShoreTel HQ host fail, within microseconds the ShoreTel HQ mirror or secondary will take over.  Not only will it take over as primary, but a new secondary mirror could be started on ESXi(3)!

Clearly FT is the way to go if you feel you can not survive a ShoreTel HQ loss under any condition.  Understand that it is resource intensive, as you are minimally running twice the horsepower!  Also to keep the “mirror” images alike, you will need a high bandwidth connection between ESXi hosts to provide for “FT Logging” which is all the activity to copy real time between hosts.

As previously mentioned, a copy of VMware vSphere Essentials Kit which includes ESXi for a total of 6 processors or 3 severs with 2 processors each and a copy of vCenter along with updates for 1 year is about $560.  vSphere Essentials Enterprise Plus which adds in the functionality of vSphere Hypervisor, vMotion, Cross Switch vMotion, High Availability, Fault Tolerance, Data Protection, vShield Endpoint, vSphere Replication is $4229.   Support on all products can be purchase as needed or for term.

Out next project is to figure out how to do this all on Amazon Web Services and at what price!

The video shows key elements of this discussion!

 

A ShoreTel Communicator for the Mac?

We recently had an opportunity to work with a ShoreTel client that was exclusively using Apple Mac’s throughout their enterprise.   We asked how they made that decision given the clear cost advantage WinTel PC hardware had over your basic Macbook.   The answer was simple and clearly economic.   They had used Windows in the past, but found that they had to many problems with virus, email, drivers and the annual cost of license renewals! Yes the Mac’s cost more but they just seem to work and they don’t have to worry license issues.    Interesting.

This was a ShoreTel deployment so that made for some interesting trade offs when it got down to the desktop software.   The ShoreTel Communicator is optimized for the Windows based machines.    There are several license types for Personal, Professional, Workgroup Agent, Workgroup Supervisor and Operator Communicators.   With the Mac, there is only one Communicator and it has the functionality of the ShoreTel Web Communicator which is basically a Personal Communicator.

It does however get the job done as far as call handling modes, inbound primary phone options, multiple call management and visual voice mail.  You can setup your call handling modes including your personal operator and find me functions for each mode.  You can configure and select 5 alternative phones and setup your incoming call routing to include simultaneous ringing of other phones.   The visual voice mail tab works just like you would expect and you can also select a history and call details tab.

The noticeable difference is the absence of IM options.  ShoreTel had been suggesting the use of iChat for that function as that client was supported on the ShoreTel SA-100/400 conference servers.   In the Communicator there is always more than one way to do something: point and click, right click, use some chord sequence on the keyboard that includes the control key.   Right clicking on a Mac Communicator however is not going to work!  There is however, drop down menu options that appear as required to assist your call management.   All in all, the Mac client is an excellent solution if you have a Mac and a ShoreTel.  You can download the MAC dmg installation file from the ShoreTel HQ server and you are good to go!

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

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!

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 ECC MySQL rants, raves and solutions for email, chat and text (SMS) messaging!

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

 

Editing ShoreTel System Prompts or WTF is a PHR file?

“Welcome to the ShoreTel Conferencing” sounds like a commercial announcement and many system owners want it changed! After all they just paid a big whack of money to own a brand new brilliantly simple phone system! Now when they have a client conference, they sound like they transferred the call to an outside third party service!  Though it is a smart move for ShoreTel marketing efforts, it is hardly the image a system owner wants to convey to their clients!  For this reason, we are often asked to change the prompt to something that sounds more like “Welcome to mycompany conferencing”. This seems like a reasonable enough request and something that should be easy to implement, right? Yet ShoreTel professional services gets about $600-$1000 for a custom prompt!  Is there a way around this?

The fact is, that it is not very easy to modify these prompts at all! Most ShoreTel vendors can’t even find the application to play the file let alone edit it as it is not a normal wav file! The file is actually a “phrase” file and is usually found with a .phr file extension.  On the ShoreTel SA-100, for example, you will find this in ftproot directory of the HQ server in the path \Inetpub\ftproot\tsu\phr\UCB. The UCB folder contains all the .phr  files for all the languages supported by the system. When the conference appliance boots up, these files are loaded onto the sever. (For you Unix heads, the appliance is a Linux platform, and you can find the files in the ShoreTel/Lib folder by entering ls -lt *.phr after changing the directory to the ShoreTel/Lib folder).  Remember, if you edit the prompts,  you will have to recreate this change  every time you upgrade the phone system and on all servers that use the conference appliance!

In the United States the correct file is the “en-us.phr” file.  If you play this file, you will understand very quickly that this is not going to be easy! The file is actually a “library” and actually contains all the “phrases” used by the system to prompt callers with audio help. The application software has to be able to set  pointers to the correct location in the .PHR phrase file.   This is similar to a format used by Dialogic back in the 80’s that set the standard for “indexed play mode” for all telephone applications.  This indicates that a phrase file must contain a unique id for each phrase in the library, so the .PHR file is more than an audio file!  Here is a list of the phrases in the .PHR file:

thank you for calling ShoreTel conferencing goodbye
a duplicate conference has been detected you will now be transferred
a duplicate conference has been detected please try again later or contact the conference host.
you will now be disconnected
sorry the key sequence entered is invalid
The conference has ended goodbye.
sorry all resources are busy please try again later or contact the conference administrator
ringsound welcome to ShoreTel conferencing, please enter an access code then press pound.
sorry that access code is invalid please try again
the conference is currently locked, please try again later or contact the conference host
you are the only person on this conference please stay on the line
the conference host has not joined the conference please stay on the line
to turn off the music please press one
please wait while your call is connected
sorry that access code is invalid good bye
at the tone please say your name and then press pound
please wait while your call is placed into the conference
has joined the conference
has left the conference
ringsound please enter the conference hosts voice mail password then press pound
if you are the conference host then you may enter the host access code followed by pound at any time
invalid password please try again or press star to join as a participant
this scheduled conference can not be started at this time as it is to early. please start it at its scheduled start time.
this scheduled conference can not be started as it is past the scheduled start time.
to start or stop recording
press pound for
this call is being recorded
the recording has been stopped
the recording can not be stopped because desktop sharing has been enabled
the recording can not start because of insufficient disk space
the recording can not start at this time
to unmute your line press pound one
to mute or unmute all lines press pound two
your line has been muted
your line has been unmuted
all lines have been muted
all lines have been unmuted
the conference has been locked
the conference has been unlocked
to lock or unlock the conference press pound five
to raise or lower your hand press pound six
your hand has been raised
your hand has been lowered
the participant names are not available
to list the participant press pound three
to return to the conference please press star
to join the conference as a participant please press star
you have been requested to join a conference please press one to be placed into the conference
to end the conference press pound 99
this scheduled conference will end in the next five minutes
this scheduled conference is starting
the conference has not yet started
please wait

It is possible to play the file using an editor like Audacity,  which will NOT recognize the file format if you double click it.   To overcome this you must  import the file as “raw data” by setting the file attributes on the import menu.  Set encoding to to ulaw and sampling to 8000 hz.   This will enable you to play the file.   That is the simple part, the trick here is to edit the audio prompts without destroying the index which is used by the application software to know how to pull the correct prompt from the phr file!   That is why professional services gets big bucks to change the prompt and why your average ShoreTel partner will not be able to help you!  Remember ShoreTel is also going to make the voice artist used is the same as the rest of the ShoreTel prompts (though some of the files in the existing en_us.phr file are clearly male voices left over from the development team).   All in all, this is a lot of work for somebody and worth every penny you pay for it!

 

Is there a RAT Virus in your phone system?

If you have a device on your network that you do not have root privileges for, then your entire enterprise is at risk for a Cybercrime! Do you want to know what a Trojan horse might look like? It might very well look like a Linux appliance provided by an outside manufacturer, delivered and installed on your network. This might be a network camera, firewall, phone system or monitoring device. As network security professionals we would never allow any device to be connected to our network, in which we did not have root administrative authority. IT Directors who budget for network security, intrusion prevention and detection and apply best practice to the care and feeding of their enterprise networks seem to overlook this very large potential security vulnerability. Every day, new networking equipment, appliances and hosts are connected to your network and nobody every questions the fact that you do not have root authority?

Most of the younger folks carrying an Android device have “rooted” their phone, why? Yet you will allow your company to install equipment for which you do not have root authority? Makes no sense to us? The fact is that most modern VoIP phone systems like those from ShoreTel and CISCO are delivered with key components built on Linux like platforms. These devices are placed on the network inside the firewall and perimeter security devices yet the root privilege is not available to the system owner. A very curious practice, would you not agree? Even if you have no clue about network security and hacking, would you allow someone to come into your place of business and install a “box” for which you have not access rights?

Anyone with root access could easily put programs on that appliance that could act unnoticed by network security devices. No virus protection would take note and the device would have complete access to the entire network. A common and popular hack is the RAT, a Trojan horse that can easily be placed on an unsuspecting users phone, computer, or other network device. These RAT’s or “remote access terminals” can be remotely controlled to turn on you microphone, camera and would have full access to all files and network resources. They become remotely controlled “bots” or computer zombies. The good news is that most modern virus protection will find these RAT’s if they are installed on a host computer. What about that appliance you just added to your network, the one you do not have root access privileges? You would never even know that RAT was there and you do not even have access permission to check!

Business owners, regardless of their personal level of technical savvy, need to question every device installed on their enterprise network. Who owns the box and who administers the box? Do you have root administrative authority on every device in your network? If not, why not?

ShoreTel Virtual Trunk Switch – Configuration and License impact!

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.

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.