Author: DrVoIP

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!

What is new in ShoreTel 13?

Posted on by DrVoIP

There are a number of major enhancements to ShoreTel in Version 13. Most enhancements have been related to bringing ShoreTel SIP into compliance with the standards accepted by the SIP community at large. Though there are enhancements for other features like the SA-100, this release is notable for what it does NOT announce. The marketplace is demanding enough but the issue of having your development agenda driven by an outside company must be dreadful! In this case, Microsoft dominants many of the decisions that ShoreTel must make with respect to the priority of features and releases. So how tightly is ShoreTel bound to Microsoft? Why have they not followed the path chosen by CISCO and others to move to an “appliance” built on Linux?

Historically, ShoreTel server side functionality was driven by Microsoft. Simple issues like changing FTP port numbers between 32 bit and 64 bit servers might seem like trivia, but it is maddening for change management. Microsoft products continue to drop support for their older computing model that used CSIS and TAPI in favor of the Client Application Service or CAS model. We saw the first effects of this in Version 11 with the release of the Communicator for Web. In Version 13, CAS support has now been extended to Communicator for Windows. In fact, Version 13 ShoreTel no longer supports TAPI, CSIS or MAPI and for this reason ShoreTel will no longer run on Windows 2003! At the end of the day, how long until ShoreTel cuts its dependency on Microsoft completely? We think this is something that the company must do if not to remain price competitive, then to control its own product development priorities!

ShoreTel SIP meets RFC 3264 Compliance!

Actually, ShoreTel adopted SIP before any other major competitor outside the Asterisk community. The early adoption of SIP meant that ShoreTel had to design solutions before the community had solidified around a standard. Time goes by and here we are more than a decade later and SIP has had many changes, while ShoreTel’s Enhanced SIP was not in step with these changes. Version 13 is all about bringing ShoreTel SIP into compliance with key areas if SIP and making a SIP trunk feature equivalent to a PRI trunk. This is accomplished through compliance with changes in the Session Description Protocol and the creation of “Media Proxy Ports”.

SiP is used to setup calls. The actual media stream between the end points is handled by other protocols, namely RTP. When a SIP end point generates an INVITE it might send a session description (i.e. SDP) of how it would like the call to take place, indicating its capabilities and preferences. The other end might accept the INVITE with or with our modifications of the SDP thus the Offer/Answer definition of RFC 3264. ShoreTel historically had no way to deal with the SDP information treated this as an “INVITE with no SDP”. The usual response to this type of INVITE would be to send back a SDP, but ShoreTel generally responded with “Not acceptable here”. With the release of Version 13 ShoreTel will now be fully complaint with RFC 3264 and play nice with the other kids in the Offer/Answer game.

Once the SIP parameters have been established, the media stream is generally setup between the end points. This means that the actual voice packets are going between the two connected phones. Now if you think about this a minute, you will understand almost intuitively why features like Call Recording, Office Anywhere, Monitor etc. did not work on SIP trunks using earlier ShoreTel versions. If the media is streaming between my end point and your end point, who is listening for any DTMF tones that might indicate we want to activate a feature? How would you play Music-on-Hold?

Enter ShoreTel Media Proxy ports! These will be switch resources set aside to enable a point at which ShoreTel can mix or “mesh” media streams. This means that features that previously could not be activated on a SIP trunk should now work. On switches that can support Media Proxy Ports (not all ShoreGear switches can) you will find a new option in the drop down menu for configuration ports to enable “SIP Media Proxy”. The proxy is actual for one SIP trunk and a media proxy so it wipes out 5 SIP trunks or 5 IP phones. The ShoreTel 220/T1/E1, 220T1A , T1K and E1K can also be used to provide SIP media proxy functionality. You will find a new check box that allocates all configurable ports on that switch to this function. For this reason, currently a switch that supports a PRI can only support 20 channels. On the other side of the coin, you were replacing that PRI with SIP anyway right? The good news is SIP trunks will have feature parity with PRI trunks and these ShoreGear switches can be re-purposed.

ShoreTel will support “on demand” media proxy as well as dedicated resources. Change and configuration management skills will most certainly be tested here, as the configuration is non-trial. Music-on-hold for example will need to be carefully considered. Historically, MOH could be played by any switch in a site. If you want to play MOH to your SIP trunk you will have to use the ShoreGear switch that is configured as the media proxy. Other items of note are support for Digest Authentication and enhanced fail over detect. The ShoreGear switch can now provide registration credentials when presented with a CHALLENGE request. The ShoreGear SIP Profile now provides for the OptionsPing to test for 5XXX/6XXX network error to mark a trunk group out of service. Major enhancements in ShoreTel SIP!

The use of an Ingate like device is still a requirement. Candidly, a serious enterprise should not be implementing SIP trunks without some form of “border controller” so get over it. SIP Message Normalization, NAT traversal, Pinhole management, network separation and providing for more SIP Channels then you can get on one ShoreGear switch are reasons that you need a border controller. Currently all SIPTrunk certifications by ShoreTel have been completed with an Ingate in the equation.

There are a few changes to the System Administration Interface to facilitate the media proxy configuration. With the death of CSIS, TAPI and MAPI there are also some changes to the Windows Communicator. We will get a video posted soon! As always, comments are invited!

ShoreTel SIP Trunks meet the Scopserv!

Posted on by DrVoIP

Anyone who thinks Asterisk is a toy is not playing in the real world of VoIP Telephony. You may be surprised to learn how many commercial product offerings are built on an Asterisk base. For this reason, we have become more involved in this code base as each day goes by. We are becoming increasingly more interested in its properties, capabilities and proper place in our solutions tool belt. Yes, Asterisk might be “free”, but does that disqualify it from serious consideration? Did “free” limit the acceptance and rapid adoption of Linux, Php, Perl, Filezilla, WireShark and a growing library of other contributions that continue to define new industries?

More often than not, these software contributions have been bundled with support and ongoing research and some amazing products have resulted. In fact, when we think we already know about all the most popular Asterisk Distro’s we stumble over a gem of a solution that is an astonishing implementation of an Asterisk base. A Canadian based company has been making significant advancements in the Enterprise market on a global basis, with a stellar product that far exceeds the offerings of other popular Asterisk distributions. This company has to be the best kept secret in the industry and we are over whelmed at the scope of there accomplishment and the depth of their feature set.

The company that has us so excited produces Scopserv a fully formed iPBX telephony solution. We were introduced to this solution quite accidentally, but after working with this solution, we now see it as among the best implementations of Asterisk in the market today. The solution offers a fully featured iPBX with all of the bells and whistles. The GUI interface is an amazing step forward in the state of the art and includes most of the functionality that others might obtain through third party add-on. The solution provides for “tenant” services and buddies a very complete Automatic Call Distribution solution with advanced graphical web reporting, complete with wrap codes! Phone provisioning can be accomplished automatically and is predefined for most of the popular VoIP phones in the market.

We recently had a ShoreTel deployment in which there was a desire to add SIP trunks and provide for a small remote office. Using the Scopserv, we were able to easily accomplish this integration. The Scopserv provided “friend” connectivity to an ITSP for local DID’s in a remote market. We then created a SIP tie line between the Scopserv and the ShoreTel. The tie line included a number of off premise extensions that were SIP extensions registered to the Scopserv at the branch end of the TIE line. The TIE line easily passed phone calls both ways, enabled LCR access to the remote SIP lines and generally provided to be an excellent solution! There was no need for any external firewall beyond that provided by the Scopserv.

The Scopserv folks have done a remarkable job! They have taken Asterisk to a new level, packaged it with proprietary functionality and wrapped the entire offering within an excellent documentation and support package! The company has a considerably large installed base outside of the US and for that reason, the are virtually unknown in the American market. On a global basis, however, they are doing very well! They have a growing list of success stories and new feature capabilities! To accommodate the 10 minute limit, I have two video clips: one on configuring ShoreTel SIP using the Scopserv as a border controller; and one that reviews the Scopserv in great detail. As always, comments are welcome!

ShoreTel analog connections and the 66 Block!

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

Configuring SIP Trunks on ShoreTel!

Posted on by DrVoIP

We continue to get a lot of questions about SIP trunks and how best to use them on ShoreTel. Our preferred strategy at this point, is to focus on a TIE line solution that brings both off premise extensions and DID numbers into the ShoreTel. Many branch offices, for example, are just not able to justify even an SG30V to support 8 extensions. Creating a SIP Tie line strategy to deal with these situations is both economical and appropriate.

Not withstanding the usual DrVoIP speech on WAN connectivity, QOS and SLA it is very possible to setup a remote office on a shoe string budget. Using a appliance from Siplistic, we were able to plant a node at the end of a VPN between the HQ and the remote office. Then, create a SIP tie-line between an SG HQ switch and the remote Siplistic appliance. The remote office should have local Internet access in addition to the VPN back to the HQ site. In this way, the Siplistic appliance can setup a “peer” with the ITSP, bring in both local dial tone and DID numbers while also providing SIP extensions off the ShoreTel HQ site, to that location. The basic Siplistic appliance comes bundled with your choice of a DID number, a four channel “peer” and support for 10 Extensions. The DID cost about $5 a month and the “peer” is a flat rate.

Meanwhile back at the mothership, you have created a new trunk group, provisioned static trunks for that group and pointed them to the remote site appliance. The trunk group is accessible for “dial x” by authorized User Groups like any other ShoreTel trunk Group and is even considered for inclusion in Least Cost Routing. It can also be part of the dialing plan and includes a list of the off premise extensions in the branch office. If you want those OPX’s to have mailboxes on the HQ switch you will need to do some digit translation and call forwarding, or you can just let the branch appliance support VM for those users. We have been testing a Siplistic solution that is actually deployed on a ShevvaPlug (see also: http://www.blog.drvoip.com/shoretel-compatible-audio-conference-bridge-on-a-plug-server ) if you can believe that!

SIP firewall traversal is the major stumbling block for most implementations. You can get lost in a CISCO CUBE or other border controller, or you get configured using a STUN server solution. Port 5060 is as subject to hacking as your Webserver Port 80, but somehow we manage to survive! Most SIP registrations and RDP streams run on UDP which, unlike TCP, is connectionless and less hackable. Most SIP hacking happens because people do not use strong passwords. Even high school level hackers are using SIPVicious to scan for open 5060 ports and then scripting for log in and password. The wild west of the Internet, but at the end of the day, SIP is a real solution and there is no reason you can’t interconnect SIP DID’s to a ShoreTel.

The embedded video is just a trailer for a new 45 tutorial on ShoreTel SIP configuration we have added to the DrVoIP video library!

An iPBX in an Amazon Cloud? A disaster recovery story!

Posted on by DrVoIP

Did you every think that your company would be physically unavailable, the building not accessible and the phone system unmanned? The issue of business continuity and disaster recovery is on your ‘to do’ list and hopefully you can get to it before it gets to you. Recently, we had the experience of having to resuscitate a client from near death when their physical facility became unavailable. Clearly, the phone system was very high on the list of “must have” operational now.

Here is the solution we employed with amazing results. First, we signed in and created a brand new account at the Amazon EC2 cloud offering. This itself was an amazing experience. Once your account is open, which can take a couple of hours if you do not already have an Amazon account (is that possible?), you can create and access a server with the OS of your choice within minutes. We already had an Amazon account so adding the AWS functionality took less than 30 minutes. We then created a Microsoft 2008 SP2 32 Bit Server and provision RDP access in less time than it is taking to tell this story. The AWS service provisions and assigns a DNS public IP address, creates a security instance (‘firewall”) and candidly, that took more time to make operational then it took to build an “instance” of our Windows based HQ server!

Once the sever was provisioned, we were able to make “firewall” changes to meet our security requirements. This is all accomplished through the AWS management console. Then the fun started, we downloaded our favorite PBX system! All of this is taking place in the cloud and under a time constraint, but we were able to provision our PBX and get in a configuration mode very quickly. Using our preexisting ITSP SIP account we were able to provision a multi-channel SIP “peer”, obtain a DID number and have dial tone in and out of the system within 15 minutes!

From then on it became near Childs play and basically the same as any other deployment. We brought up the most urgent User profiles first, established remote call forwarding and even enabled several SIP softphones. We were able to get the phone company to call forward the clients main BTN to the newly provisioned DID number and we had this client back to worrying about business issues that had nothing to do with phone service pronto quick. The entire process from account setup, to first phone call took two and a half hours to commission!

Clearly, not the carefully conceived business continuity and disaster recovery plan that should have been in place, but a success story none the less. We keep a pre-paid ITSP account available at all times which enables us to bring up 4 channel SIP peers in a heart beat. It seems we never know when we are going to need a new DID and Peer. The Amazon AWS is mind boggling in terms of what you can do and you are billed on a metered basis. Currently they have a program that bundles some 750 hours of usage a month for free. They also have some canned AMI’s (Amazon Machine Images) that cost literally penny’s an hour to operate.

Not that we needed another reason to have a software based VOIP iPBX but this is an example of just how powerful these tools can be to create and deliver viable telecommunications solutions on demand! AskDrVoIP and we will provide you the list of software solutions we used to accomplish this emergency deployment and we are planning to recreate the entire experience for a another DrVoIP video cheat sheet.

ShoreTel – Does a “single image” deployment always make sense?

Posted on by DrVoIP

We continue to be a major fan of ShoreTel solutions, but that does not mean that they we accept everything without question.  One of the most touted advantages of the ShoreTel architecture is the concept of a “single image” solution with no single point of failure.   We find that in large enterprise deployments that may not be an advantage.  Just because you can deploy as a single image, does not mean that you should!  Lets take a closer look at this battle cry and test that claim against real world situations for large enterprise deployments.

First, the concept of a “single image” system.   All phone systems, bar none, have to deal with the realities of a database.   Generally a phone system has two databases;  the configuration database and the run-time or state machine.   Again, all telephone systems have the same challenge as there can only be one copy of the primary data base.   In a ShoreTel system, the primary database through version 10 was located on the HQ server.    If you lost the HQ server, you could not make any changes to the system configuration.  This meant agents could not log in or out of workgroups and automated attendants could not change from day to night mode.   If a user, as another example of a “state” , had their calling mode set to “out of office”  you were going to stay absent until the HQ serve came back!

Lets consider a large system deployed over several time zones.  Assume a HQ server in the PST zone and a workgroup in the UK on GMT, with maybe a few branch offices in the EST and CST!    Any network issues, even a simple flapping WAN, will result in the UK agents going off line and not being able to log back in.  After Version 10 ShoreTel implemented “distributed’ databases and optional, distributed workgroup services.  You had to make a choice however, either you could distribute your database or you could distribute your workgroup service, but you can not do both.    As you can have one but not the other, it seems that though the workgroup service might be available the current state would not be available to change.  What does this mean?

If we distribute workgroup services, in the above example, away from the HQ server to a distributed server running in the UK,  ShoreTel workgroup functionality would be enabled for  continued operation in a WAN down scenario.     Agents, however, would not be able to change their states from log in to log out or back again.   This is because the availability of the only read/write database is still unavailable.  ( Generally, we would recommend that workgroup services , in a large ShoreTel deployment, not be distributed for this reason, opting to have the ability to change call handling modes and have workgroups fail over to hunt groups).

Nobody that has had responsibility for maintaining or upgrading a multi-site deployment with the geography as defined above, would ever vote for a “single image” solution!  Imagine organizing an upgrade for the above scenario?  All of the servers, switches and phones across all time zones would have to be upgraded in a single maintenance window.   Then again,  this might have been the wrong deployment model to begin with!  Just because you can install as a single image, does not mean you have to deploy using a single image.   The above scenario could have been deployed using two separate systems, one in North America and One in Europe.   They could have had a uniformed dialing plan that would have masked the two system as a single system to the users, through a SIP tie line between the two systems.  Clearly, they would have had two voice mail systems and two administration portals.  On balance, however, it  might be a more stable model with less operational head aches and certainly a lot more manageable when it came time to upgrade!

Then again, that deployment strategy model would look an awful lot like a CISCO deployment!