ShoreTel analog connections and the 66 Block!

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!

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!

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.