Category: ShoreTel Configuration

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!

ShoreTel Version 14.2 is “Virtually there”!

Posted on by DrVoIP

We have previously argued that ShoreTel should shed the hardware business and focus on software development only.  Just our opinion and personal hangup!  We believe that unless you have the Market Capitalization of an Apple, it is hard to walk both sides of the street and do both Hardware and Software!   Even Microsoft, does only Software!     Well ShoreTel may in fact be moving to Software only through the introduction of a family of “virtual” machine offerings.   Though versions prior to Version 14.1 offered some level of Server virtualization,  ShoreTel deployments would still require lots of those “Orange” ShoreGear switches.

On January 28th ShoreTel will begin to ship the first release of Version 14.2 and all components of the ShoreTel architecture will be virtualized!   This means that you don’t need those “Orange” boxes unless you are connecting to analog or digital trunk lines!   ShoreTel Switches including Conferencing servers will be available as OVA files for VMware deployments.    ShoreTel will begin to offer  a virtual phone switch, a virtual service appliance and a new family of virtual SIP Switches with complete PRI parity.  The ShoreTel compatible Ingate SIParator will also be available as a Virtual Session Border Controller.   Licensing can be significantly reduced to a phone or trunk license, now how kool is that?

The ShoreTel virtual phone switch will support between 250 and 1000 phones based on calculated VM resources.  The virtual phone switch will will support all ShoreTel features including backup automated attendant, make-me-conferences, hunt groups, bridged call appearances and extension monitoring.  Pricing is estimated at 8-15% below the cost of another “Orange” box and you can mix and match virtual and real boxes! The virtual SIP trunk switch is estimated to be some 50% below “Orange” box costs!  The virtual service appliance will offer IM and Web conferencing from 50-200 simultaneous sessions.  Instant Messaging is now without charge from ShoreTel when implemented on a virtual server,  just your usual VMware hardware costs!

We consider this the strongest move that ShoreTel has made in its product line, since it moved from analog phones to SIP handsets!  Though ShoreTel is following the examples of others like CISCO Version10, we see this a the right next step in the process for ShoreTel product development.   With the enterprise world solidly focused on virtualization and the rapid but steady migration from TDM to SIP, a Virtualized ShoreTel is an essential element of a successful business continuity and disaster recovery program.    ShoreTel is starting to look an awful lot like a pure software company and we think that is not only “brilliantly simple”, but very smart.

– DrVoIP

Hacking ShoreTel!

Posted on by DrVoIP

I though  I had seen it all!

When you have been involved with the design, deployment and management of customer premise telephone systems for as long as we have, you think you have seen it all. Over the years as we learn from our mistakes we improve our “best practice” list to assure others gain from our experience. When I was barely a teenager, I learned how to assemble a string of MF tones using a Hammond organ keyboard.  Recording two keys at a time, you could create toll call routing instructions that could be played back after making a 1-800 toll call before the terminating end answered! That, along with the famous Captain Crunch 2600Hz cereal box whistle, kept me and my friends entertained for years, stacking toll tandem switches and meeting other hackers in far away phone booths!  Things have changed as in-band signaling has long ago been replaced with out of band signaling and whistles no longer work. Toll fraud however, continues to be a major source of unanticipated costs for business and the toll bandit syndrome is still alive and well in the Internet age.

Just like a web sever which uses well know port 8080 to serve up web pages, SIP phone systems use a common port.  Scanning ports for open port 5060, then banging away for a user login and password to create a registration was child’s play and most companies now have this locked down. The fact that most Voice Mail systems used a common password was also a source of hacking entertainment, but now most manufacturers do not create mailboxes until someone needs one, eliminating a source of illegal phone calls though remote access.  Direct Inward System Access or DISA used to be a favorite tool for making fraudulent toll calls. Users would call into the system, put in a pin and then be granted access to make phone calls.  It did not take long to figure out how to abuse that feature!

Kevin Mitnick needs my help?

Like I said, just when you think you have seen it all, something new shows up. You have to laugh at how obvious and simple it was.  I was recently contacted by a guy who you would think has seen it all, Kevin Mitnick. If that name does not immediately “ring a bell,”  then maybe you might remember a couple of his books:  The Art of Intrusion,  The Art of Deception and most recently Ghost in the Wires.  Kevin has not only seen it all, he has done it all!  Anyway, Kevin was researching a compromised ShoreTel system for a client and wanted to compare notes with DrVoIP.   Apparently someone had gained unauthorized access to the system and was making toll calls that were costing the target company a small fortune. If you have ever experienced toll fraud you know that your vulnerability is broadcast all of the Internet in just a matter of minutes.You will find yourself explaining to Homeland Security why you are making so many phone calls to Dubai!

Kevin had a sheet of CDR records that showed the date and time of the calls. Unfortunately the calls seemed to be originating from the Automated Attendant so they could not be traced to a particular extension number within the system.  We brain stormed some possibilities.  I thought for sure this had to be an inside job!   Maybe someone was using the “find me follow me” feature, but that would only send the call to a single number. These calls were all over the map! Literally all over the globe! ShoreTel does not have a DISA feature and VM boxes do not exist unless they are assigned to a user. The password must be changed as a part of the setup process.  So how was this system hacked?

Well, I could tell you but that would take all the fun out of hearing from you as to your thoughts on how this was done.  I will promise you that it takes one to know one and Kevin, genius that he is, figured this out, not I!   Even DrVoIP was taken in by this clever ruse!  Post your comments below with your thoughts on how this was accomplished and we will send you the puzzle answer Kevin uncovered.  My thinking is that all we can ever hope to do is to raise the bar, keeping out the less sophisticated mice.  There will always be someone smarter, someone more dedicated and focused, who will make it his mission to crack your safe!

Updated with Answer September 1, 2013

– Well a couple of people actually broke the code (excuse the pun)!    What Kevin learned was that one of the great flaws in VoIP is the complete lack of control when it comes to secure Caller ID!   Simply stated, there is no security or verification of Caller ID!   Using any number of readily available tools, it is possible to spoof your caller ID. You can make your phone display any number you want!   ShoreTel has a voice mail feature that enables you to listen to a voice message and then return the call by pushing a voice mail menu option key!   This is a very handy feature, especially if you are calling into your voice mail from you car, just hit the “return call” option and provided the system was able to capture the inbound Caller ID, the ShoreTel will place an outgoing call to that number and conference you in!    So lets put this simple ShoreTel hack together – the hackers gained control of a voice mail box, then called into the ShoreTel Voice Mail system with a spoofed Caller ID and the left a brief message.  Calling back into the system, this time to check their voice messages and then hit the “return call” option key, which then placed a call to an International Middle East location all billed to the the ShoreTel system owner and showing up only as a Call Detail Record owned by the Automated Attendant.    Great feature, but we would recommend that you don’t allow the VM system to place International phone calls!    Thanks to all who took time to write and special thanks to Kevin Mitnick for a really fun Service Call!

 

CISCO UCCX or ShoreTel ECC – CCadmin script and power to the Supervisor!

Posted on by DrVoIP

If you have managed a contact center of any size, sooner or later, you will be asked to make a change on demand.    A contact center supervisor feels the need to have a “team” meeting in the middle of the work day and needs the entire staff to be present.  This means nobody will be logged in to take calls.    This is the point they call you, the contact center administrator,  and ask that you not only close the queue but record a new closed greeting.  This happens so often that we determined to automate the process and put the power of opening and closing a queue in the hands of the Supervisor or Team leader.   We created a Script, named CCAdmin,  that is always running and waiting for a Supervisor to call it and make that famous request.

In the case of the CISCO UCCX, the script makes use of the Recording Step and the ability to read an XML document.   Each operating script in the contact center has a “getstatus” subflow at the start of each script.  This subflow checks an XML document, named for the queue, that has a single status variable.  This is a simple boolean operation and it is either set to true or false.  During normal operations it is set to false.  The main queue script calls the subflow, finds the status as false and continues its normal routine of servicing clients.  If however, the status is true, meaning that we have a special closing, the script branches to the closed section of the script and plays a special closed greeting, made by the Supervisor when they called into the CCAdmin script.

The CallCenterAdmin script has the matching setstatus subflow that is checked by the main script.  When a Supervisor calls into the CallCenterAdmin script, they are prompted to select their queue by menu number.  They are asked to Press 1 to open a Queue or 2 to close the queue and make a new recording.   Then they are prompted for a PIN, which compares to a previously stored Integer to determine the Supervisors authority to make a queue closure.  Assuming the PIN is correct, the CallCenterAdmin script, then prompts them to make their recording, thanks them and hangs up.   The CallCenterAdmin script then setstatus to true and waits for the next request. All of the queue scripts in the call center have the getstatus subflow as part of their normal definition.   As each script launches it tests for status and if closed plays the newly recored closed script and hangs up.  When the Supervisor desires to open the queue again, they just place a call to the CCAdmin script and start over.

Though the concept is very straight forward there were a few kool tricks that needed to be developed.  First of all, you need to define a naming convention that allows you to use a standard XML naming convention.  So if we are checking the getstatus of the CustomerServiceStatus.xml we could use the same code we used to check the getstatus of the TechnicalSupportStatus.xml document. The setstatus of the CCAdmin script would also have to address this challenge.  Likewise, making a recording and naming it so that you could use the same body of code or script was also an interesting brain teaser.   CISCO UCCX enables the creation of Recordings wihtin a script, but ShoreTel does not.   Likewise, CISCO UCCX can make use of XML documents as the database record, but ShoreTel would need a flat file or OBDC connector.    I have been able to do the same script on a ShoreTel ECC, but I had to use a standard closed announcement as changing files in ShoreTel ECC on the fly, is not possible.  You can point to a different previously recorded wav file, but you cant create on on the fly.

The application however, is very useful and we now deploy this as a standard for all Contact Centers we deploy.    I will ultimately get the entire CCAdmin script into the lesson library along with the full prompt library as recorded by the first lady of all our prompts, Karen  Brace of OnHoldAdvertising

Compare ShoreTel ECC and CISCO UCCX – Handling Language Options

Posted on by DrVoIP

Anyone who has been deploying telephone systems for any length of time has run into the “language” issue.   Though I am personally tired of having to “Press one” for English, the fact remains that we market on a global basis even if we are a small local business.  It is rare to encounter an Automated Attendant or Call Tree that does not offer us the option of selecting another language.  In the States, Spanish tends to dominate the motivation to change language and it is invariably offered to all callers.

Setting up a basic automated attendant to handle a language change is relatively straight forward.  You end up recording your prompts in at least two languages and then you navigate a different tree based on the selection.   Providing a language option in an IVR Script for a ShoreTel ECC or CISCO UCCX, for example, is an entirely more complex process.  Yes, you end up having to record your prompts for each language offered, but do you really want to write to sets of call flow?  Contact Center Scripts can get relatively complex very quickly.  If you apply the same solution to a Contact Center Script as you do an Automated Attendant Call Tree, you will end up having to create at least two scripts: one in English and one in the other offered language.

You will really want to focus on a single call flow and a single set of prompts.   Do you want to have the complexity of writing a script that says play “WelcomePromptEnglish.WAV” and then have to write the same call flow again, but this time the script says play “WelcomePromptSpanish.wav”.  As my Grandson says, “REALLY”?    Would it not be more economical to write and to maintain a script that simply said play “WelcomePrompt.wav”?    At some point you are going to have to ask the caller to press or say something to change their language choice.   How about we run the same script and the only thing that changes is the subdirectory that the prompts are retrieved from?   In this way we only have one call flow script to maintain and scripting writing is significantly relived of the duplication of effort that language options often require.

ShoreTel and CISCO both manipulate the language option in their respective script editors differently.  Here we take a look at how the Java based Script Library in the CISCO UCCX would implement a language option using a single call flow script.

Compare ShoreTel and CISCO – Extension Mobility Options!

Posted on by DrVoIP

Do you run a business in which the day shift and the night shift share the same telephone instrument?   This is a very common feature requirement in call centers, help desks and order lines.   In the Health Care Profession,  a very common staffing requirement is to rotate the  “front office” staff,  with  the “back office”e staff from time to time.   If your business or organizational requirements demand that you match a telephone extensions with specific named individuals for voice mail or activity tracking,  you need “Extension Mobility”.    If you want to travel between your geographically distributed office locations and you do not want to be tied down to a single telephone instrument at a specific desk location, you need “Office Anywhere”.      The ability to “log in” and make any phone in your business organizations VoIP deployment your phone is a very powerful and useful feature.

Both ShoreTel and CISCO offer this advanced functionality but they implement it in very different ways.   This is, in our humble opinion, the result of the “cultural” difference in their system architecture.   We have written on this subject before and it is one way in which the two systems distinguish themselves.   ShoreTel does not allow an extension to  exist without an associated user.   Such a phone is “anonymous” and, though registered and available as a system resource,  it can not be “called “as it does not have an extension number!   Until it is associated with a specific User, it has very limited capability.    It is the User that associates a “class of service” or set of permissions and an extension number to the phone.  CISCO separates the concept of a phone device from that of a User profile.   CISCO phones can in fact exist without being assigned to a User.   They can have an extension number, be called and make calls.   It is the Line Number or Extension number that determines the “class of service” or permissions available to that device.    Users are defined separately.   This is a subtle but very significant difference in these two systems.

“Extension Mobility”, on the other hand,  is an optional feature in a CISCO deployment and it requires configuration by a systems administrator.   Given the logical separation between a “device” and a “user” in CISCO, it is necessary that both entities must be configured for this feature to work properly.   Extension Mobility is an XML service in a CISCO deployment, that both the user and the device that a user might log into, must both subscribe.    An “Extension Mobility” profile must be created for any CISCO user who desires this licensed feature.   It might be possible to have a situation in which a User with an “Extension Mobility” profile, can not log into a different phone because that phone has not subscribed to the service.  Given that this is a licensed feature, it is not generally deployed on all phones during the installation.

“Office Anywhere” and “Extension Mobility” are excellent solutions for “hoteling” employees,  and “hot desk” environments where the staff moves between desks and do not have assigned seating.

Configure redundant static WAN routes when ShoreTel is in the data center?

Posted on by DrVoIP

Installing your ShoreTel HQ server at the Data Center is becoming a standard deployment practice to increase business continuity during network and power outages and other disasters.   One of the most common Ask DrVoIP question we hear is how to create redundant WAN paths to the data center using only simple static routes.  In a typical deployment scenario we see at least a two site scenario in which the ShoreTel is located in a “missile silo” or colocation facility and connects to an operational office site at another location.   The connectivity between the two locations is MAN (Metro Ethernet) or MPLS, but is usually has a VPN through a wide band Internet connection as a backup connection to assure business continuity should the MAN go down.    What is the best strategy for configuring this option?

We recently had an opportunity to make use of a CISCO IOS feature, “IP SLA” and it worked remarkably well and is very easy to understand and configure.    In our real world scenario we have a two location ShoreTel deployment.  The HQ Server, ShoreGear registration switch and all the clients supporting data servers were located at the Colocation facility.   At the main office location there was a DVM, the required ShoreGear switches to support PRI PSTN connectivity and support users.   Two CISCO 2900 Series access routers connected the two site through a carrier provided Metro-E and two SonicWalls, provide a VPN connection through T1 Internet connections.   The trick was creating a scenario in which, should the Metro-E go down, there would be an automated failover of routing table to the backup VPN route.

One of the problems with determining a carrier down situation, is that the router may not see a down or RED condition.   The router may in fact see a GREEN condition as the physical interface is in fact still operational.  This is where IP SLA (Service Level Agreement) really shines.   To configure an IP Service Level Agreements (SLAs) Internet Control Message Protocol (ICMP) echo operation, use the icmp-echo command in IP SLA configuration mode.

icmp-echo {destination-ip-address | destination-hostname} [source-ip {ip-address | hostname} | source-interface interface

Think of the IP SLA as generating a “Ping <Destination-ip-address> – t”   or ping until fail.  The IP SLA generates a ping and when the ping is not returned, the interface is consider down.  The route is then removed from the routing table and the alternative route is brought on line.     There are a variety of ways to configure this route table update, but in this particular example we choose to use was to create alternative routes, based on the SonicWall VPN tunnel.  These default routes had an Administrative Distance higher than the primary route:

ip route 0.0.0.0 0.0.0.0 10.100.8.1 track 1
ip route 0.0.0.0 0.0.0.0 200.1.1.42 10
ip route 200.1.10.40 255.255.255.252 200.1.1.42

The default route has a TRACK 1 reference that points to the actual IP SLA configuration below.  The default route statement is repeated with the secondary route option and the 10 makes this a more costly route.  The default route will be used until the IP SLA returns “unreachable” at which time the secondary route will become the primary route between locations..

The actual IP SLA configuration looked like this:

track 1 ip sla 1 reachability ;
ip sla 1
icmp-echo 10.100.8.1 source-interface GigabitEthernet0/0
threshold 2
timeout 1000
frequency 3
ip sla schedule 1 life forever start-time now

The configuration is very simple, yet very powerful.   Should the “Track 1 = unreachable” then the default route will be replaced with the higher cost secondary route.  This happens quickly enough for there to be no service interruption.  When the track becomes reachable again, the route table is updated and all returns to normal!

The actual trouble shooting of the SonicWall VPN took more time to resolve than this IP SLA took to configure and test.   This is just one of the strategies that can be employed to accomplish this vital task, but it is powerful and readily available and yet another reason to use CISCO routers in your deployment!   The following video recreates the actual network issue, routes and was created to prove out the revisions that needed to be made in the SonicWall to support the deployment.

Backing up your iPBX Call Center, what is your plan?

Posted on by DrVoIP

“The Check is in the Mail”;
“I gave at the office”;
“The software if fully tested and bug free”;
“We are working on the documentation”;
“Go ahead tell me, I promise I won’t get mad”;
“Yes we backup our data every day, off site”.

These are just a few of our favorite white lies.   That last one, however, is a real resume creation event.  Today I took my late model SL convertible in for a smog inspection.   You could have knocked me over when the technician informed me that the car failed the certification!  Just the day before I had the car into the dealership to get the “consumer electronics” battery changed and have the normal scheduled maintenance.   Apparently, at least here in the peoples republic of California, if you have On Board Diagnostics (OBD)  in you automobile, that data is submitted or evaluated as a part of your smog inspection.  Having just had the battery changed, my dealer had failed to backup or protect this data and as a result the OBD  had no history.  I failed the smog check , wasted several hours of my life and can now retest when I get 100 miles of driving history back into the on board automotive computer.   Clearly my dealer had no data plan or process in place to protect the data during routine maintenance.

Now imagine if that had been your VoIP phone system or call center?   Simple server upgrade? New Version of the iPBX being installed?   The question is, does your dealer have a process in place to protect your data during routine maintenance?  More importantly do you have a plan and process in place for backing up your iPBX configuration database, system prompts, voice messages, call detail records and even your maintenance history (e.g. Logs)?   Want to play, “bet your company’?   Chances are that you have this on your list of “things to do” but you just have not had the time to execute.   You may even be trusting that your dealer is taking care of this as part of that expensive maintenance contract you entered into.

If you are really feeling secure about your iPBX failover plan why not just pull the power plug and test things out?  There is nothing like a crashed phone system to bring out the facts about database backup, recovery and the  business continuity preparedness of you and your vendors!  The facts are that having an active emergency back up and restoration plan in place is absolutely essential in this day and age.   Cloud backup automation services abound and there is not acceptable reason for not having this process in place.  Just as important, is a restoration plan that is periodically exercised.  You can have all the data available on backup, but if you can not restore that data, it is useless to you and your business.   Yes, it may be just another “fire drill”, but it will save your company if you include this process in your maintenance activities on a regularly scheduled basis.

Very recently we have had an opportunity to experience cloud based, on demand, iPBX redundancy and disaster recovery strategies.  We have explored some of the current cloud options for both day to day redundant operations and disaster recovery.  In one case we were able to bring up a complete PBX in the cloud in a matter of minutes, on demand using predefined Amazon Machine Instances.  The results were remarkable, dramatic and redefined operational readiness. Hit the AskDrVoIP button for details!

ShoreTel SIP, Mobility Router & the Firewall (Part 1)

Posted on by DrVoIP

This is not a SIP tutorial,  only an overview on the issues that impact remote SIP phones on any iPBX.  When you set up a SIP call between two end points, there are upwards of four “holes” that might need to be punched in your firewall for the phone call to work properly.  Clearly, there is the entire process of registering a remote phone and the process of setting up a phone.  Once these events have been negotiated, we  then have the issue of the media stream between the two phones.  Generally the registration and call setup are taking place through TCP/UDP port 5060 on a public IP address that terminates on your firewall.   Generally, your Firewall will have these ports forwarded to your SIP Proxy or iPBX which lives on your internal private network.   (Take note:  Public and Private IP, we will talk more about that later).

Once the call is setup, there is a “mouth to ear” path setup for each leg of the call.  These “dial peers” are really just media streams.  These media streams take place over UDP ports using RTP protocol, one for each “mouth to ear” stream, so that is two more ports open on the firewall.   Each of the RTP streams has a UDP cRTP protocol port requirement as well, so we need to open two more ports your firewall.  So to summarize, you will have TCP/UDP port 5060 open on your Firewall all the time, and four UDP ports open for each active phone call.  Your firewall is starting to look like a sponge?

You don’t have to be a network security guru to figure out this strategy has some obvious challenges!   12 year old Elementary school kids run port scanners looking for open 5060 and then run Sipvicious  in hopes of registering a rouge phone.   Through in the fact that your ISP may or may not block 5060, and or refuse to use the same ports and you have the making of a SIP nightmare!  SIP was never expected to traverse from public to private IP addresses either!  So we have SIP savvy firewalls and border controllers to help us out.  These devices, among other features they provide, can police ports, opening and closing them as required when a legitimate connection is required between an inside phone and an outside phone.   They also translate between the public IP address and the internal private address keeping an internal scratch list of who is using what, closing ports when done to increase security.

Is there a better way?  What if we could create a secure “tunneling strategy”?   Not a VPN,  but a strategy for getting the SIP call control and Media Stream to move through a single firewall port?   Sound like a winner?   This SIP Proxy Tunnel can combine all SIP (signaling) and RTP (media) VoIP Packets from one location (typically a remote office) and deliver them to and from another location (typically the PBX Server) using a custom TCP protocol.  This simple concept allows us to exploit the SIP Proxy Tunnel to overcome difficult situations, or to simplify a network scenario.

The SIP Proxy Tunnel can be used for the following reasons:

Resolve issues of NAT Traversal at both the remote and the PBX location
Simplify Firewall configuration at both the remote and the PBX location
Overcome difficulties with ISPs that block VoIP Traffic based on port numbers
Allows VoIP-over-WiFi in some restricted locations, such as Hotel rooms
“Fixes” Firewalls that cannot handle VoIP traffic correctly or which are very difficult or problematic to configure correctly, such as:
Microsoft ISA Server
SonicWall
What if “remote” also means a mobile phone?   When you have a user who is roaming around with a SIP soft phone extension on their cell phone,  we have no idea what IP address they will be connecting from!   The answer (excuse the pun) is an android or iPhone application  that enables you to create the tunnel from you mobile phone, bring up your iPBX extension and move your desk outside, down the hall or across the globe.  At the end of the day this would be a true Mobility router.   Last year ShoreTel acquired Agito Networks and obtained this very same technology and it is an outstanding solution. The ShoreTel Mobility Router and Roam Anywhere cell phone client can do all this SIP magic and even move your call seamlessly between WiFI and Cellular while your walking out to the parking lot.  How great is that?

How to Ring more than 16 phones in a ShoreTel Hunt Group?

Posted on by DrVoIP

How to ring more than 16 phones in a ShoreTel Hunt Group? Can’t say that we recommend this strategy, but none the less, we continue to see business applications in which the client insists on ringing a group of 16+ phones simultaneously! In ShoreTel, HUNT groups and WorkGroups have a limitation of 16 members per group if you want to ring them simultaneously. You can configure some 300 group members, but you can only ring 16 of them simultaneously. Why? Because call setup and feature processing (winking and blinking phone buttons) is not only processor intensive, it is done on the general purpose processor of a ShoreGear Switch not by the server. Basically, you are setting up 16 simultaneous phone calls and it takes lots of computer work, thus the limit of 16 phones per group.

So how do you ring more than 16 phones at a time? Well, there are two solutions that you can consider. One solution is to purchase an additional cost software package appropriately named “Super Group” that will ring upwards of 100 phones at the same time. The software package has the additional benefit of being shunupported by ShoreTel. The other solution, is to configure creatively and to push ShoreTel to do things it really was not designed to do. This option will work, but it is not supported and if you really cause your ShoreGear switch to overwork, strange and unpredictable results will be observed!

First, configure a new Hunt Group as you would normally do and give it an appropriate name (i.e. Customer Support). Configure the Hunt Group with a call stack of 16. Make sure that “skip a member if already on a call” is NOT selected. The Hunt group will support 16 phone calls before searching for the call stack full destination. You can also configure the “no answer” destination and even assign a schedule. So far, the configuration of this Hunt group is the same as any other, the only difference is that we are only going to add a single member to this hunt group!

Though you can use an existing User, you might even find it useful to burn another extension only mailbox license and create a new user expressly for this purpose. The trick here, is that this User will be the only member of the Hunt group and you will then configure your member phones to MONITOR this user extension. You should be able to configure a master user and then copy this users custom buttons to the other members of the group.

Here is what you will need to configure:

  1. In ShoreWare Director, select “Administration > Users > Individual Users”
  2. Edit the user you wish to include in the simultaneous ring group
  3. Click on the “Personal Options” tab
  4. Click on the “Program IP Phone Buttons” button
  5. For the appropriate button: Select “Monitored Extension”
  6. Enter a Label such as “SUPPORT”
  7. Choose the “SUPPORT” user’s extension
  8. Set “Ring Delay” to “None” (This will cause the phone to ring immediately)
  9. Set “Show Caller ID” to “Only when ringing”
  10. Set “No Connected Call Action” to “Unused”
  11. Set “With Connected Call Action” to “Unused

It would be wise to distribute the phones representing the member extensions across several ShoreGear switches. Don’t have all the group members be registered to the same ShoreGear switch if it can be avoided. This combination of Hunt group and extension monitoring will enable you to exceed the 16 member limitation when ringing phone simultaneously. Use it cautiously, but it will work!