Hacking ShoreTel!

Posted on August 5, 2013January 14, 2024 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!

Will Technology Kill the Call Center?

Posted on October 17, 2012 by DrVoIP

We recently posted a blog on how smart phones could be used to bypass automated attendants and deep dial into a call center with a Smartphone visual menu. This blog received a lot of interest and the follow on questions clearly indicated a level of interest in just how technology impacts the traditional call center. The “call center” is now the “contact center”! Customers are calling more frequently from mobile devices and less frequently from land lines. What does that mean to your contact center? Have you integrated your website with your Contact Center? Can clients who visit your “online store”, hit a chat link and interact with the next available customer service representative? Are you formatting webpages for both the full size computer screen as well as the Smartphone screen? Technology is shaping the channels or touch points that your customers use to interact with your company and your call center will most undoubtedly go through a significant change in the very near future.

Will Technology kill the call center? Ashley Furness CRM Analyst for Software Advice, Austin Texas, hosted an online panel discussion to seek answers to the questions impacting the current transition of forward thinking contact centers. She asked industry experts: How have you seen consumer contact channel utilization change in the last decade? What role has technology played in this change? How do you see technology impacting the way customers contact a company in the future, and the kind of service they receive? Finally, Will technology eventually render call centers irrelevant?

These are very interesting subjects for those who have responsibility for managing customer experience, satisfaction and fulfillment. Industry participants from Avaya (Customer Experience), Drumbi (mobile), IntelliResponse (Virtual Agents), and Etech Global (Chat Services)discuss these questions and provide expert insight. These experts do in fact answer the question “Will technology Kill the Call Center” and the panel discussion is well worth viewing!

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

Posted on September 22, 2012 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 August 20, 2012 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 August 16, 2012 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?

ShoreTel analog connections and the 66 Block!

Posted on June 28, 2012 by DrVoIP

It is surprising that in the 21st century we are still punching down copper lines! None the less fax machines, credit card devices, postage machines and security circuits still populate the installed base of telephone systems. If you are converting from a legacy phone system to a VoIP solution, on premise or hosted, you will have to plan for “analog” devices. A “best practice” for any VoIP phone system is to have at least one analog telephone company provided central office line, per site, attached for power failure and E911 operation. ShoreTel, for example, has conveniently made it possible for one “port” on a ShoreGear switch to cut through to another port enabling basic POTS operation during a commercial power failure.

The venerable 66 type punch down block is typically used to accomplish analog device connectivity. We like to think of the 66 block as the “border controller” in the analog world. You can easily separate the telephone company (read WAN) from the customer owned and operated equipment (read LAN) by removing the bridging clip that separates one side of the block from the other. VoIP or not, the 66 block is not going away. Phone technicians love 66 blocks, but IT technicians prefer “patch panels”? Unfortunately, the telephone company typically delivers the circuits at the MPOE or “main point of entry” downstairs in the basement! If you want to get it up to your patch panel, you are going to have to deal with the 66 block.

The basic components are the 66M1-50 split 25 pair block and wall mount bracket. The block is designed to cut down two 25 pair cables on each side of the block using an industry standard color code. Typically you would put your equipment on one side of the block and your station distribution on the other side of the block. Generally “cross connect” pairs act as the equivalent of patch cables, interconnecting equipment and devices. A “bridge” clip is used to connect one side of the block to the other side. If you are thinking ahead, you might use a “rat tail” cable that ends in a male or female amphenol connector to limit punch down and facilitate quick connect.

The ShoreGear switches have a male RJ-21X amphenol connector on the face plate. You will need a female or red amphenol connector to bring 25 pairs of copper out to your 66 block or patch panel. Optionally, 66 blocks can be obtained with an RJ-21X amphenol connector built in. For reasons nobody can explain, the Male connector has a Blue cap and the Female connector has a Red cap over the connector pins for protection. Beware of what sex your connector needs to be!

There is an industry agreed color code and sequence that defines how a 25 pair cable should be punched down. ShoreGear switches, however do not use all pairs. Each switch type has a different port pin out, so pay attention to your planning and installation guide. Additionally, not all analog ports are equal on a ShoreTel switch. There are three types: Universal, Fxo and Fxs so make sure you know what device you are needing to connect and use the correct port type. Universal ports will support either a Central Office line (Fxo) or a Station device (Fxs).

The video walks you through the details of connecting a ShoreGear switch to a 66 block, outlines various cable alternatives and details the color code! With the help of our friends at cable supply.com there is a detailed presentation on how to “punch down” a 25 pair cable on a 66 block. Enjoy and as always comments are welcome!

QOS for ShoreTel VoIP Deployments!

Posted on March 23, 2010 by DrVoIP

Setting up QOS on your routers to support ShoreTel VoIP across a WAN connection requires that you employ some creativity in your configuration. Think of Class Marking as a way of “coloring” packets so that the routers no how to treat the packets when there is any kind of congestion. We want voice packets to have a priority over data packets, so we color them and tell the carrier or WAN router which color is voice. Generally, QOS strategies employ the use of Differential Service Control Points or DSCP values.

These values are established by convention and can be generally summarize as IP Precedence Level 5 (101xx000 = DSCP bits) or DSCP Values of 160-184 to representing “Express Forwarding” with a decimal value of 41. The TOS byte in the IP header allocates the high order 6 bits to the DSCP value, making Express Forwarding or EF equal to decimal 41 or 10111000 binary. Most carriers will comply with this class marking and will put IP packets marked with this value in the Low Latency or “go fast” queue. (See note below).

In the ShoreWare Director Portal you will find a link under Call Control to “options”. On this page, you will find a box for DiffServ/ToS Byte (0-255). This is where you will set your DSCP value, generally 184. This will mark all voice packets originating from ShoreTel Voice Switches and IP phones. A QOS configuration generally consists of three elements; The Class Map, the Policy Map and the Service Map. The Class Map tells us what it is we are looking for. The Policy Map tells us what do when we find what we are looking for and the Service Map applies this information to the proper interface, generally the WAN side of your router.

Here is an example of a simple QOS configuration:

class-map match-any VoIP
match ip dscp ef

policy-map QoS
class VoIP
set ip dscp ef
priority percent 50

Basically, we are telling the router to look for incoming IP packets that have a DSCP value equal to Express Forwarding. When we see these values we are going to know they are VoIP packets and move them to our LLC where we have reserved 50% of the available bandwidth for use by the voice application. It is important to note that queues in routers only take effect when we have contention for bandwidth. The QOS statements help the router make decisions as to what queue gets serviced first. Understand that, should queues fill up, the router will start “tail drop” and throw out packets no matter what the class mark! This is a key issue, as the queue is for outbound processing. What happens if some idiot is down loading Avatar from NetFlixs? The incoming data flow could drown out any attempt to service outbound queue handling.

Lets look at modifiying our ShoreTel QOS strategy to provide for some additional configuration options. One option is to set up an Access-List to capture information that might not be generated by a ShoreTel switch or IP phone. ShoreTel uses a specific set of TCP/DUP ports that we can easily identify. You also know the IP address of your ShoreTel server. Why not set up an access list to look for traffic originating from the ShoreTel server or traffic originating or terminating on specific ports? Here is an example, created by Brain Krail, of a configuration that establishes the access list and also sets up several classes of service for voice, mission critical data and best efforts data:

access-list 197 remark “All SHoreTel”
access-list 197 permit ip any any dscp ef
access-list 197 permit udp any any eq 2427
access-list 197 permit udp any any eq 2727
access-list 197 permit udp any any eq 5004
access-list 197 permit udp any any range 5440 5446
access-list 197 permit udp any any eq 5060
access-list 197 permit tcp any any eq 5060
access-list 197 permit udp any any eq 111
!
access-list 198 remark Mission Critical
access-list 198 permit tcp any any eq ftp
access-list 198 permit tcp any any eq telnet
access-list 198 permit tcp any any eq smtp
access-list 198 permit tcp any any eq 3389
access-list 198 permit udp any any eq 3389
!
access-list 198 remark VPN Traffic
access-list 198 permit esp any any

class-map match-any VoIP
match access-group 197
match ip dscp ef

class-map match-any mission
match access-group 198
!
policy-map QoS
class VoIP
set ip dscp ef
priority percent 50

class mission
set ip dscp af41
bandwidth percent 30

class class-default
set ip dscp default
fair-queue
random-detect

int ser 0/1/0
max-reserved-bandwidth 100
service-policy output QoS
!
In this configuration we use our Class Map to look for packets that match our Access-List. Clearly, we are scanning for matches and based on the match, we classify the traffic as voice or mission critical. The Policy map then assigns the proper value or class marking based on the Class Map matches. The Service-Policy at the end applies the Policy to the Serial Interface on this router, most likely going off to the Carrier. Your previously co-ordinate agreement with the carrier will result in them treating the packets as marketed an handling them accordingly. We find that QOS configurations that use Access-Lists to further search out traffic and host IP addresses that generate voice media streams, do a much better job than those that rely solely on the DSCP mark setup in the ShoreTel Director.

Now about that ugly issue of the user downloading NetFlix! How do we tell the carrier not to exceed a certain about of traffic inbound to our router? The following configuration is an example of “Policing” an inbound interface to throw away any traffic that exceeds the CIR rate we set up. This configuration increases the likely hood that QOS will be effective outbond, by making sure the inbound bandwidth is not over subscribed by a user downloading over your voice traffic!

access-list 199 permit ip any any dscp default

class-map match-all test
match access-group 199

policy-map testPolice
class test
set ip dscp default
police cir 1000000
conform-action transmit
exceed-action drop

QOS is an essential part of any VoIP deployment. ShoreTel Deployments can benefit measurably by getting creative with your Configurations and thinking outside the simplicity of DSCP! NOTE – you need to dig deep on circuits provided by carriers that are peering with another carrier to deliver a complete circuit solution. We have experienced situations in which the carrier taking the order adhered to our QOS markings and acted according to plan. However, when that carrier hands the packet off to another carrier for final delivery, you need to make sure that they are in fact, honoring the same QOS markings. In one situation, though our carrier was handling DSCP as agreed, the carrier that they handed off the packet to for final delivery, did not use DSCP on the MPLS circuit in question. Some carriers, by inter-carrier agreement, use the Experimental Bits to deal with QOS. Be Careful as the techs you are working with may not even know this, swearing all the time that QOS is setup per DSCP value!

Give us a call if you want assistance on QOS setup for Voice and Video!

ShoreTel Database Replication and Manipulation of MAXDBQUERIES!

Posted on March 4, 2010 by DrVoIP

It really doesn’t matter what VoIP system you installed they all generally have one architectural characteristic in common; the configuration database. Depending on the system, you might find a database engine that ranges in complexity from an Access Database to a full blown SQL database. The database will store configuration information, status information and often, call detail records that document phone system activities. The characteristic of the database that is consistent across all architectures is the fact that there can only be one “read/write” copy of that database!

Some phone systems distribute the database across multiple servers. ShoreTel, for example, distributes components of the database to application servers and distributed voice mail servers that characterize the single image architecture in a multi-site environment. We need to better how a change to the database effects the operation of the system, the bandwidth of the WAN links and the demand on the database engine. First, what constitutes a change to the database? Well clearly any configuration change that is made to the system. For example, adding or deleting a User are clearly going to cause a database update! Lets take a more subtle example, however. Lets consider what happens to a Agent in a Workgroup, located at a remote site, behind a distributed voice mail server. Each change that Agent makes on their Call Manager represents a database change. Logging into the system, and Logging out of the system are database changes. How about, accepting a call being offered to the Agent by a Workgroup?

Each of these Changes is communicated to the database. The change is first made on the “read/write” database and then replicated to the remote database copy. ShoreTel system processes use MS Distributed Component Object Model (DCOM) objects to share information from the configuration database among themselves and to write configuration information to the database. User configuration options are written to the database from Personal Call Manager, and the telephone interface. Each ShoreTel service on a distributed server caches it own copy of the configuration database. When a distributed server loses connection to the HQ server (read “read/write” database) any changes made are no longer received by the distributed server. If a DVM restarts without a connection the HQ database, services are started but are not functional. When the network connection is restored, the configuration is retrieved and again cached by each service as the services become functional.

If there is a flap in the WAN we note that the DVM will in fact reload a copy of the database. This movement of the database between the HQ server and the DVM servers clearly uses bandwidth and also makes additional demands on the database engine. In ShoreTel the database engine, is now MySQL. The question becomes how many simultaneous database access (read, modify, write) transactions can the MySQL server handle at one time? What happens if the transaction can not be completed? Does it queue and retry? In a large system of say 700 workgroup agents at a site, is it possible to overload the MySQL database with state change requests? If you dig down through the Server registry you will find the MAXDBQUERIES is set by default to 100. It has been our experience that, defending on the size of the system, it is sometimes necessary to dial this number back to eliminate overloading the database. This adjustment should be made only on the DVM’s in the configuration and not on the HQ server. You will need to reboot your DVM servers after making this change. You should also note the difference between HEX and Decimal!

The following SILENT file clip demonstrates how to make this adjustment.

ShoreTel Enterprise Contact Center Call Routing based on Schedules!

Posted on December 5, 2009 by DrVoIP

If you have been following our tech tips, you know that route points in the ShoreTel IPBX have a matching IRN in the Contact Center. If you want to route a call to a different destination based on the date and time that a call hits the Contact Center, how and where would you apply the schedule? Technicians familiar with the ease of creating schedules in the ShoreTel IPBX, might immediately apply a schedule to a route point. After all, each call to the Contact Center hits a route point first, why not apply the OnHours/OffHours call handling directly to the route point?

At the end of the day, Contact Centers are designed to provide management, detailed information to facilitate staffing, allocate resources, decrease call holding time and increase customer satisfaction. Candidly, it is all about REPORTS! My personal prejudice is that contact centers should be designed by starting with Reports! What is it that Management wants to see? If we want to know how many callers are hitting the Contact Center during Off-Hours, for example, we can not apply the schedules to the Route Points. If the Schedule applied to the Route Point deflects the caller to a Voice Mail box, that call will not appear in the total Calls presented to the Contact Center.

If you want the call to be counted, it must actually enter the Contact Center! For this reason, most Contact Center deployments are deployed with the Automated Attendant functionality being defined within the Contact Center. In this way we can accumulate accounting information on all calls that hit the Contact Center, regardless of how they are ultimately routed. The ShoreTel Enterprise Contact Center has a very powerful configuration capability as it relates to defining Schedules. Schedules are defined as “types of days” and “shifts”. At first this concept is a bit difficult to digest, but once you play with it you will realize just how powerful and impact this configuration strategy can have on your overall Contact Center call flow.

The Working Times facility enables you to define a type of day and then associate shifts to that day type. The normal ShoreTel Schedule works on a binary On-Hours Off-Hours call handling model. What happens if you want to build a call flow that needs to have calls routed differently between specific hours of the day. For example, between 12AM and 8PM, we want incoming calls to be routed to the Guard Station. Between 8AM and 12 Noon we want a live answer point at the Reception Desk. Between Noon and 1PM calls need to be routed to an outside answering service; and between 1PM and 5 PM they need to be routed back to the Reception desk. Now any technician that has been working with the ShoreTel IPBX for any period of time has developed several strategies for handling this often required call flow. The strategy usually involves cascading Hunt Groups in combination with Workgroups to achieved the desired result.

The Working Times facility within the Contact Center would handle this complexity with ease. You would define a Day Type (i.e. WeekDay) and the define the various Shifts that comprise that day. In the example above, the ticking of the clock would transition through the various “shifts” resulting in a different destination based on the time of day. This is advantageous in a call center environment and significantly less demanding to administer than the cascading Hunt group strategy. Contact Center call flow is often managed on a time of day, day of week and holiday basis at a level of sophistication that goes way beyond the On-Hours Off-Hours approach to call handling. The ShoreTel Enterprise Contact Center Working Times facility is a power strategy for achieving maximum call routing control.

VoIP QOS Network Monitoring and Pathview Cloud!

Posted on December 3, 2009 by DrVoIP

Trouble Shooting VoIP issues in a multi-site deployment is a challenge to even the most talented network engineer. It is often difficult to determine what is a voice equipment issue and what is an issue aggravated by a network conditions. As network engineer troubleshooting an issue, having access to network monitoring tools is essential. Sometimes we have to use the basic ICMP tool sets and ping our way through a trace route, but network connectivity is only one element of QOS related areas in a VoIP deployment. (Actually, it would be great if clients invested in putting network monitoring tools in place, but they only seem to appreciate their networks when something goes wrong)!

What is that we need to monitor anyway? We split the monitoring world into two basic camps: Flow based accounting and Health checking software. Flow based monitoring enables us to check the source/destination IP address; source/destination port; IP protocol; TOS and Ingress interface. This is helpful when you are trying to figure out what applications are running on your network and who is streaming real time media. Clearly important stuff, but at the end of the day, when it comes to logging into someone’s network remotely and trying to figure out why some remote user has garbled phone calls, there is nothing like an in place Health check!

When we talk about the “health” of the network we are interested in knowing about Bandwidth capacity, Loss, Jitter, Mean Opinion Score (MOS), latency and tagging.These are the words that make a VoIP engineer smile!Would it not be wonderful to log into your clients network and have this kind of history available between key end points of a multi-site deployment?Rarely, do I ever publically endorse a product but the folks Apparent Networks have gone out of their way to make their product available, useable and free!You need to stop what you are doing and download Path View Cloud, a host based network monitoring solution from Apparent Networks.

Not only is this software as useful as a button hole, but you can download a fully functional 5 node solution for absolutely no money! In previous posts, I have discussed the fact that, despite best practice, clients continue to attempt VoIP phone deployment over DSL through VPN tunnels! Path View Cloud enables you to collect real-time network health information about key endpoints in your network. Typically, it is the remote user or the WAN points that you are going to want to study. Path View Cloud enables you to create monitoring solutions that regularly report on health checks and trigger alerts when “violations” have been detected. Yes, Virginia, there is a Santa Claus and you can see packets!

Clearly Apparent Networks believes that offering 5 free nodes will get you to order more!The offer is, however, compelling and I can tell all you cheap, penny-pinching, tight wads that will not invest in network monitoring software, that you will sleep better at night with this Path View Cloud solution in place.Network and VoIP engineers and technicians, you need this arrow in your quiver to make troubleshooting more visual!