One of the challenges in any ShoreTel deployment is the desktop Call Manager client installation. You can breeze through the complexity of a ShoreTel multi-server, multi-site deployment only to be foiled when the desktop clients need to be installed or updated. Nobody wants the thankless task! As most users do not have Local Administration rights to install software on their desktop machines, the system administrator gets a new task. So it is either “sneaker net” or an Active Directory Group Policy push out. Meanwhile, the ShoreTel deployment is otherwise complete! Frustration as the entire deployment is good to go, but the desktop clients have yet to be installed or updated! When does the admin team get here?
Now there is a tool out there that makes sense and can be a great help to the field implementation team, charged with getting the ShoreTel system installed, on time and on budget! Enter the rock stars at AdminArsenal with a very kool software solution named PDQ deploy and put an end to this client install fiasco! The product makes it easy to do a network based push out of the ShoreTel client, by the ShoreTel installation team as long as they have an Admin account and meet these two conditions: The target computers must be on the same network. This is not an over the Internet install. The application or patch must support a silent install. Most do, however there are some who do not. The admin must determine what the silent parameter is (/s, /quiet, etc.) to do the push. (Here are package details).
Think if this as a great tool for a deployment in which the ShoreTel implementation team needs to do all the onsite work when they might not have access to the client desktop help desk. PDQ will let you install MSI files to multiple computers! If your are a ShoreTel VoIP engineer, you need to add this solution to your tool kit! Check out a free trial!
Virtualization has significantly altered the options available for your choice of deployment models. With the introduction of ShoreTel 14.2 you can completely virtualize your VoIP deployment right down to the Gateways! If you have no Analog telephone device requirements or telephone company lines, you can now eliminate those ShoreTel Orange boxes! This is a significant advancement in the state of the art and one that will become increasingly more prevalent as we look for viable business continuity strategies. The ShoreTel virtual switches come in a number of flavors: Service appliance, phone switch and trunk switch. The Virtual appliance is similar to the ShoreTel SA100/400 server and is essentially a free feature enhancement! The ShoreTel Virtual Phone switch can also be used as the “spare” switch available for use by phones that need to register with a new switch when the ShoreGear switch they were using fails. Again, no cost associated with this unless you leave them on that virtual switch for longer than the normal 45 day grace period.
The VoIP technology in general has become more complex demanding new skill sets from those who install them. In addition to the telephony, network, firewall, SIP and Microsoft software applications that historically touch your ShoreTel deployment, you will now need to understand VMware ESXi deployments including the use of OVA files. The ShoreTel Virtual switches are now distributed as a part of your HQ and DVM server images. They live in the FTP server and can be retrieved in one of two ways. You can either download the image file when you configure your appliance in the Shoreware Director portal, or you can load it as a URL in the VMware machine configuration as the target for your OVA file.
If you are familiar with VMware, the installation process is relatively simple, straight forward and easy to understand. Once the machine is specified the Vmware configuration is as simple as adding the basic network IP components including the address of the Shoreware HQ server. The machine will ultimately configure, load and become available as a virtual machine on your ESXi platform. From that point on, there is little difference to the installation of a virtual appliance or a real ShoreGear switch in Shoreware Director. The basic difference has to do with the selection of the hardware platform type. Normally you would select an SA100 or a ShoreGear 50, for example. In the case of a virtual appliance, you will select a new category from the drop hardware list, that indicates what type of appliance you are installing. The rest of the configuration is the same. The virtual appliances behave like the normal orange” boxes, even requiring a firmware upgrade. They appear in both the Diagnostic Monitoring and Quick View and in all respects operate like their real world hardware brethren.
We should all understand that those little orange boxes contain application specific microprocessors or digital signal processors (DSP’s). The real heavy lifting normally done by those chips for CODEC work, for example, will now be done in software. Additionally, don’t make the mistake of deploying virtual appliances at sites logically, without understanding that the VMware hardware platform location is just as important on over all performance as ever! All and all this is a major step forward for ShoreTel and you can expect these virtual appliances to become a standard part of your deployments over time. The video clip reviews the actual installation of both a phone switch and a service appliance!
Note – The ShoreTel news here is that the actual Voice Gateways are virtualized, not just the application, but the Gateways!
I am found of repeating that “product development is a process not an event”! Though the marketing folks need to package, position and promote products based on feature sets, generally products emerge over time. Building on previous releases, customer feed back and recommendations, products continue to emerge with new functionality. Most product development focuses on features that have market demand or differentiate one product from another. Occasionally, a new product feature is targeted at someone other than an end user. Engineers and Technicians are typically the last group of people to get a feature developed that makes their lives a bit more easy. Such is the case for ShoreTel Version 14 and the introduction of a “Diagnostic and Monitoring” tool!
The latest Version of ShoreTel has added a capability that we think is essential in iPBX technology as SIP becomes more of a standard. If you have ever attempted to trouble shoot SIP without the ability to do packet capture, you will know how valuable this feature set is. CISCO long ago had RMTM tools as a standard part of a Call Manager deployment. ShoreTel has now added that functionality to its standard product offering and it is dramatic! Now part of the ShoreWareDirector user interface, the Diagnostic Monitoring tool is a complete glass cockpit with a variety of monitoring tools. These tools include real time status updates of system areas including connections, trunk groups, bandwidth utilization, voice quality, switch status and service conditions. Combining “Quick View”, with other tools that previously required loading modules or a putty session, the Diagnostic Monitoring center is a self navigation center for trouble shooting.
We are particularly excited about the “remote packet capture” feature of the Diagnostic tools. This tool enables you to remotely capture packets and bring them to a local pcap file. You are offered the opportunity to capture everything or limit your capture to specific areas of interest. For example, if you want to capture only SIP packets related to the ShoreGear switch you are running your SIP Proxies on, the diagnostic tool set lets you select these options. The files are WireShark compatible and if you have that application on your server, a simple click will launch the application and bring up your capture for analysis. This is a very power capability and simplifies some of the issues associated with setting up WireShark for remote capture. We think this feature set was long over due, but we are just mere engineers, what do we know!
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!
Anyone who has been deploying telephone systems for any length of time has run into the “language” issue. Though I am personally tired of having to “Press one” for English, the fact remains that we market on a global basis even if we are a small local business. It is rare to encounter an Automated Attendant or Call Tree that does not offer us the option of selecting another language. In the States, Spanish tends to dominate the motivation to change language and it is invariably offered to all callers.
Setting up a basic automated attendant to handle a language change is relatively straight forward. You end up recording your prompts in at least two languages and then you navigate a different tree based on the selection. Providing a language option in an IVR Script for a ShoreTel ECC or CISCO UCCX, for example, is an entirely more complex process. Yes, you end up having to record your prompts for each language offered, but do you really want to write to sets of call flow? Contact Center Scripts can get relatively complex very quickly. If you apply the same solution to a Contact Center Script as you do an Automated Attendant Call Tree, you will end up having to create at least two scripts: one in English and one in the other offered language.
You will really want to focus on a single call flow and a single set of prompts. Do you want to have the complexity of writing a script that says play “WelcomePromptEnglish.WAV” and then have to write the same call flow again, but this time the script says play “WelcomePromptSpanish.wav”. As my Grandson says, “REALLY”? Would it not be more economical to write and to maintain a script that simply said play “WelcomePrompt.wav”? At some point you are going to have to ask the caller to press or say something to change their language choice. How about we run the same script and the only thing that changes is the subdirectory that the prompts are retrieved from? In this way we only have one call flow script to maintain and scripting writing is significantly relived of the duplication of effort that language options often require.
ShoreTel and CISCO both manipulate the language option in their respective script editors differently. Here we take a look at how the Java based Script Library in the CISCO UCCX would implement a language option using a single call flow script.
It is almost expected that a modern call or contact center be able to offer a “call back from Queue” option to your callers. In fact some call centers are now offering a Call Back with no phone call required from your caller at all! The caller can text a message to the call center and receive a text back with an approximate wait time until the next agent is ready! Take the time to develop a custom “smartphone” application and the incoming text message can also contain business appropriate CRM information like a client ID or policy number.
While you are waiting for your contact center to be updated with this advanced SMS text caller option, most modern contact centers can offer a “Call Back From Queue” option.
Generally, we want to capture the inbound call, route it to an available agent and if the agent is not available, we will play a customer care message to the caller and keep them in Queue. Should an agent not become available in the next programmable period of time, we will play yet another customer care message, but this time we might invite them to “press 1” to arrange a call back without losing their place in queue.
Should the caller elect to activate this option, they might then be asked to enter the number that they can be reached at when an agent becomes ready.
Optionally you can offer to call the customer back at a scheduled time in the future and also prompt them to enter a date and time for call back. How this is accomplished is dictated to by the system that you are planing to use for your call center. Generally, some kind of IVR functionality that can “prompt and collect digits”. The ShoreTel ECC and the CISCO UCCX both enable this option though they do it quite differently.
ShoreTel offers a scripting tool that enables calling options through per-programmed routines encapsulated in high level Icons. These Icons are interconnected on a pallet that graphically mirrors your call flow. This is “brilliantly simple” and is often all that is required to establish control and options over your call center. CISCO uses a scripting option based on Java and you will be more comfortable with this option if you have a background in software development. CISCO is a bit more demanding then the ShoreTel scripting tools, but along with its complexity comes greater flexibility in feature definition. In the hands of a talented programmer, you will be able to create features that could not easily be encoded in a higher level graphical scripting tool. The UCCX Scripts enable you to not only “prompt and collect” but also to “prompt and record” the callers voice message for playback to the agent prior to placing the out bound return call.
Call Back from Queue is a useful customer service option in those business centers that care about customer satisfaction. I would not expect to see this on the IRS toll free line, but rest assured that Charles Schwab will have it! As the cost of keeping callers on the line continues to escalate with the cost of wireline facilities, you can expect other options to become more available. The SMS option, being one, offers higher customer satisfaction potential while reducing the infrastructure costs associated with paying for more telephone lines than you have agents to handle the calls! Keep your eye on this option as it is sure to change the nature and value of existing call center strategies!
As Contact Center implementation consultants we get to work with both ShoreTel ECC and CISCO UCCX. The fact of the matter is they are both really excellent solutions and very similar in many respects. Historically, ShoreTel has had a single administration portal for the deployment of their iPBX solution. You go to one portal to define your Users, Gateways, Call Flow, Automated Attendants, Workgroups and Voice Mail. Add a User in ShorewareDirector and that user has a voice mail box, is instantly in the online Directory and it is “brilliantly simple”. CISCO has always been bit more challenging to configure. You have multiple Administration portals, the Call Manager Users are not necessarily in the Unity Voice Mail and you most definitely go to different portals to administer these systems. Gateways are programmed in addition to being created and registered with the Call Manager and multiple servers are the rule regardless of the number of sites.
When it gets down to the Contact Center, both companies have very similar implementations. For example, both companies use a separate server to run the Contact Center run time engine, manage agent states, store configuration data, usage data, scripts and prompts. The system use the CTI strategy of Route Points to logically interconnect the host PBX to the Contact Center and they both have separate administration interfaces. Both Systems require you to define your Agents twice, once in the iPBX and then again in the Contact Center, though CISCO has an import capability. ShoreTel is clearly migrating toward a single browser interface for the entire product line, but currently, you open one portal for the PBX and another for the Contact Center. CISCO does the same thing and clearly does not think that multiple administration portals is a market requirement.
ShoreTel has a straight forward license model for the ECC. You get a fully feature contact center to which you just add agents and IVR ports. Email, Chat and Campaign dialing are options, but everything else, at least with Version 7, is included. Pricing is simple and easy to understand. Real time reporting, historical reporting and the ability to do custom reporting are standard platform features. Integration options include DDE, Triggers and Active X. CISCO is a bit more complex in its packaging offering Standard, Enhanced and Premium packages. The Standard package, however, provides all that is required for a fully functioning Contact Center. The Standard package does not provide CAD or CISCO Agent Desktop. CISCO has the ability for phones to subscribe to XML based services and Agents use that option to log in, log out and generate wrap codes. CISCO provides all IVR ports in the base system, where ShoreTel has ten packs to grow IVR ports as required.
From a sizing perspective, the CISCO UCCX supports 400 Agents and 400 IVR ports, while ShoreTel boasts 1000 agents and 250 IVR ports. I used to operate with the understanding that I could have a maximum of 150 IVR ports on a single server and would required a three server solution for 300 IVR ports and Agents. I was not able, thought I did try diligently to get ShoreTel product management to confirm the server requirements and specify Busy Hour Call Handling, but could not get anyone at ShoreTel to respond ( DrVoIP is not a ShoreTel partner, so why bother? Then again, we are not a CISCO partner either and they sent us truck load of documentation, lab licenses, Virtual Machine Templates and answered all questions). If you do the arithmetic with 1000 agents and a maximum of 250-300 IVR ports, something does not add up? IVR ports are used to prompt and collect as well as source media streams for music on hold. Clearly if you have 1000 agents, nobody is holding and 250 IVR ports may be more than appropriate. Why the large disparity in Agent and Supervisor sizing for these two solutions?
The ShoreTel ECC Script Editor is a powerful little box of goodies and just gets the job done! Clearly, there are always ways to improve capabilities, but I have yet to encounter a client requirement that we could not resolve with the ECC tool kit. I would like to see the ability to import and export scripts; run the editor when not connected to the server and a simple record to file capability. XML document processing and HTTP triggers could be improved, but again, we have always been able to meet the client requirements and at the end of the day that is what it is all about. CISCO has a script editor that is also very powerful and offers options for XML document processing and configurable HTTP triggers. We particularly like the ability to run the editor while disconnected from the Server. Makes travel time more productive for us consultants!
CISCO has a number of desktop applications to support both Agent, Supervisors and Administrators. We value the fact that the applications are downloaded from the UCCX server via a web page. CISCO phones have a native ability to subscribe to XML services and a display large enough to make this a viable option. In many UCCX deployments not Agent Desktop application is necessary. ShoreTel provides an Agent and a Supervisor desktop application. The desktop Agent application is currently a two EXE solution, one for the ECC application and one for the ShoreTel Communicator. Again, ShoreTel has done an excellent job of integrating the two desktop applications, but there are in fact, two applications running on your desktop. Some end users like the smaller Agent toolbar anyway, so I vote to keep it as a desktop option! CISCO has a powerful tool named the WorkFlow Administrator which enables the creation of Agent buttons, work flow processing, web page push that enable a range of optional agent capabilities without the need to grant administrator rights.
Both systems have a long history and have undergone many changes in packaging and functionality. ShoreTel is about to release Version 8 and CISCO is at about the same level. The ShoreTel engine is running on a Windows server, where CISCO has migrated away from Microsoft to a Linux platform. ShoreTel uses MySQL and CISCO uses Informix for the configuration, activity and repository database functions. There is no reason that you could not have multiple ECC or UCCX servers on a single PBX. In fact, why not? They would not share the same Agent database or inbound trunk groups, but that may not be necessary in a large multi-site enterprise spanning the country or globe in which there are multiple business units.
We find both Contact Center solutions to be powerful, fully feature and very capable of handling blended activities at very aggressive price points. Though it may be such that you choose a PBX based on the Call Center, it is more likely that you will select your Call Center based on which vendor PBX you select! In either case DrVoIP can help develop your Contact Center call flow and scripting!
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!
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!
We had a lot of requests for examples of telneting into the SG Voice switches, so we though we would do a quick video on that process.The V switch is a very different animal from the rest of the SG family.Basically, a small Linux server lives inside the switch and contains a Flash memory card to hold Automated Attendant and Voice Mail for users assigned to that “server”.There are some characteristics about the V switch thatyou should know and we have tried to summarize them below.One of the most important characteristics, is that a V switch MUST have a time source or bad things will happen!
The entire telnet process into this switch is different.You can find your way down to the subdirectory that contains the famous IPBXCTL security shell and run it using the normal command sequence.You will see the “telnet enabled” message, but you will pull you hair out before you can telnet into the V switch.To get inside the switch, you will need to use an SSH client like Putty.You will also need to log in as either the Admin or the Root users.The Admin gets you to a safe menu configuration option and you should have no problem configuring the switch.Remember, you have to have that NTS in your configuration!Log in as the root user however, gets you a more powerful set of trouble shooting command and enable you to back up the Flash card, and to some other debugs that you can not do from the admin user.
The video clip below walks you through the process.Here are some of the highlights we have discovered working with the V switch,
·Limited media stream capability.
·1U Half Width Switch
·Voice Mail stored as 8-bit WAV files from G.711/G.729
·Switch can negotiate ADPCM but can Not proxy G.729
·Switch runs under Linux (not VxWorks)
·Voicemail Switch uses Qmail not SMTP and does not support SMDI
·SG90V supports 90 voice mail boxes
·1GB Compact Flash stores about 1500 minutes or 15 minutes per user
·Full CF Card = “voice mailbox full” message
·Holds all Automated Attendant Messages?
·Store prompts for up to four languages
·At boot, requires connectivity to HQ server for configuration
·Once operational, does not need server connectivity for VM/AA
