Category: Cisco Voip

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.

VoIP QOS Network Monitoring and Pathview Cloud!

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


Path Preview status

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!

How does a ShoreTel SBS compare to a CISCO CCME in $?

Posted on by DrVoIP

I am always being asked to compare ShoreTel and CISCO in one or another area.    CISCO has a family of products that range from the UC500 through the CCME and on to the full blown Unified Communications Call Manager.    One way to compare these two systems is to look a the raw cost of equipment, generally the tip of the ice berg in a voice over IP deployment, but a useful starting point.    Lets assume an small configuration of 85 users, with a PRI and a need for 24 analog telephone devices for fax, modem, credit card, elevator, etc.    I configured the ShoreTel single image solution using the Small Business Version of the product as this was only a single site example.   The equipment list came in as follows:

  • ShoreGear-220T1   =           $5995
  • ShoreGear-24A   =               $2995
  • (2) ShorePhone IP 560 =     $698
  • (8) ShorePhone BB 24 –     $2392
  • (75) ShorePhone IP 230 –    $19425
  • Small Business Server and Voicemail – $1,500
  • (85) Extension and Mailbox License = $11,900

The ShoreTel solution would come in at approximately $49245.50 in equipment charges and warranty support, but not including Installation or Service.

For the CISCO I choose to compare this with a CISCO CCME,  Basically a CISCO 2851 Integrated Access Router with phone software and a Unity Voice Mail module inserted in the IAR along with a four port FXO card and a PRI card to bring the specs in line with the ShoreTel.

  • (1)  2851 VOICE BNDL W/PVDM2-48 FL-CCME-96 SP SERV 128F/256D   8595.00        = $8595
  • (1) 1PORT 2ND GEN MULTIFLEX TRUNK VOICE/WAN INT CARD – T1/E1  1300.00         =$1300
  • (1) CISCO UNITY EXPRESS NETWORK MODULE ENHANCED SPARE  3000.00            =$3000
  • (1) UNITY EXPRESS LICENSE 100 VOICE MAILBOX-AUTO ATTENDANT-CCME            =1000.00
  • (1) 24PORT VOICE OVER IP ANA.GATEWY   5395.00 MSRP                                         = $5395
  • (75) CISCO IP PHONE 7945 GIG COLOR WITH 1 CCME RTU LICENSE  665.00                =$49875
  • (4) 7916 IP PHONE COLOR EXPANSION MODULE  495.00 MSRP                                      =$1980
  • (4) IP PHONE POWER TRANSFORMER FOR THE 7900 PHONE SERIES  45.00             =$180
  • (4) 7900 SERIES TRANSFORMER POWER CORD NORTH AMERICA  10.00                    =$40
  • (2) CISCO IP PHONE 7975 GIG COLOR WITH 1 CCME RTU LICENSE  955.00                  =$1990
  • (1) US ONLY SNT NBD 8X5 + SAU 2851 VOICE BUNDLE  876.00                                        =$876
  • (1) US ONLY SW APP SUP+UPG CISCO UNITY EXPRESS NETWORK MODULE – ENH   $270.00
  • (75) US ONLY SMARTNET 8X5 NBD CISCO UNIFIED IP PHONE 7945  8.00 MSRP          $600

The comparable CISCO CCME came in at approximately $75101 for equipment and warranty support, but not including Installation or Service.

Both are excellent solutions and both have strength.   Each has a desktop call manager that integrates with Outlook.  Both would require the addition of Ethernet switches with POE capability.  One might argue that the CISCO has the advantage of being the router and optionally, the firewall as well.  Clearly these are published MSRP and I am sure you can beat the hell out of your business partner to get these prices down. But at the end of the day, before installation costs the CISCO will cost you about more than 50% over the cost of a ShoreTel at this line size anyway.

VoIP and SRST/AES Encryption!

Posted on by DrVoIP

Encryption of VoIP traffic was, for some of us a humorous concept. I remembered as a young development professional how much fun it was to use a packet sniffer to capture the bosses packets and reassemble his email over the LAN. Years before that when I worked at the phone company as a central office test engineer, it was not uncommon to find an interesting phone call and plug it into the over head paging system to provide entertainment for the late night test crew. There are times I still think the concept of encryption on VoIP is humorous, but it is becoming less funny all the time as we move toward end to end VoIP with no TDM at all in a world populated by terrorists and other evil doers. In any VoIP environment today, you can at some point use the usual tapping tools to capture a phone call as it hits the TDM gateway and is converted from VoIP to traditional analog or digital signals. From an induction coil to a line mans butt set, you can still intercept a VoIP call as it crosses the TDM boundary.


Now that VoIP is being used end to end, we do need to have a mechanism for encrypting at least the media stream. Today we generally do that with SRTP and IETF standard in combination with AES. AES or the Advanced Encryption Standard was adopted by the US Government and comprises three block ciphers: AES 128, AES 192 and AES256. Each AES cipher has a 128 bit block size with key sizes of 128, 192,and 256 respectively. This standard has generally replaced the former Data Encryption Standard or DES. It is important to understand the difference between encryption and authentication. Determining that a signal is “authentic” and originated from a source we believe to be authentic, and encrypting the contents of that communication are two very different issues. Media authentication and encryption ensures that the media streams between authenticated devices (i.e. we have validated the devices and identifies at each end) are secure and that only the intended device receives and reads the data. We need to encrypt both the media (i.e. the voice) and the signaling information (i.e. the DTMF). In most VoIP systems today, SRTO or secure RTO is implemented to assure media encryption. Understand that this encryption is not passed through to the TDM network, so once the media stream leaves the VoIP environment it is subject to eavesdropping.

Clearly as we are now able to employ VoIP end to end, SRST/AES encryption has very powerful ramifications for both the good guys and the bad guys!

Your ShoreTel Provider – What does it take to implement VoIP!

Posted on by DrVoIP

If you ask your average IT professional what a T span is, the usual response will be that it is a 1.5MB connection to the internet. Ask your average telecom tech what a T span is and you will be told it is 24 channels of dial tone! As a VoIP Engineer what a T span is and you should get the answer:, “what do you want it to be”? One of the great challenges of implementing a VoIP solution is the absolute requirement that the implementation team possess an interdisciplinary skill set. The solution demands expertise in a range of specialized skills including IP network, switching, routing, supplementary telephony services , server technology management and application call flow integration. If the user group is going to fully realize the benefits of a VoIP implementation, then each of these specialized areas of technology are going to be necessary to a successful deployment. Traditional telephony vendors are comfortable with all things TDM. They like to punch things down on 66 blocks and use “butt sets” to test for “dial tone”. Network professionals have their area of comfort as to Microsoft or Linux server professionals. Call Center professionals understand caller greeting, salutation, screening, call routing, message acquisition and message retrieval at the application level, but seldom understand the underlying technology. At the end of the day, you can shop the internet and find out who can sell you a shiny new telephone thing cheaper, but finding a team that can execute the delivery of a VoIP solution is worthy of the time you would invest selecting a new CFO! You need to work with a team that can demonstrate proficiency in each of the required discipline and accept responsibility for every aspect of the implementation. From concept to “go live”, the voip solution provider you select  must know the difference between a “dress rehearsal” and a “take”.