Peter S. Buswell (aka DrVoIP) is a rare blend of C-level executive leadership and deep technical expertise in telecommunications and cloud infrastructure. With a career that began at AT&T in 1970, he has founded and led multiple industry-defining companies, including Dextr.Cloud—acquired by AWS Global Partner CloudHesive. Peter has held senior roles at firms like Exxon Enterprises, Intervoice/Brite, and Franklin Telecommunications, and has consistently driven innovation from traditional PBX to Amazon Connect cloud deployments. A hands-on architect with certifications from Cisco (CCNP/CCDP, UCCX/UCCE) and AWS (Solutions Architect, Developer, SysOps), he combines strategic vision with engineering precision. Known as DrVoIP, he continues to bridge the gap between enterprise goals and technical execution in today’s evolving cloud communications landscape.
We recently posted a blog on how smart phones could be used to bypass automated attendants and deep dial into a call center with a Smartphone visual menu. This blog received a lot of interest and the follow on questions clearly indicated a level of interest in just how technology impacts the traditional call center. The “call center” is now the “contact center”! Customers are calling more frequently from mobile devices and less frequently from land lines. What does that mean to your contact center? Have you integrated your website with your Contact Center? Can clients who visit your “online store”, hit a chat link and interact with the next available customer service representative? Are you formatting webpages for both the full size computer screen as well as the Smartphone screen? Technology is shaping the channels or touch points that your customers use to interact with your company and your call center will most undoubtedly go through a significant change in the very near future.
Will Technology kill the call center? Ashley Furness CRM Analyst for Software Advice, Austin Texas, hosted an online panel discussion to seek answers to the questions impacting the current transition of forward thinking contact centers. She asked industry experts: How have you seen consumer contact channel utilization change in the last decade? What role has technology played in this change? How do you see technology impacting the way customers contact a company in the future, and the kind of service they receive? Finally, Will technology eventually render call centers irrelevant?
These are very interesting subjects for those who have responsibility for managing customer experience, satisfaction and fulfillment. Industry participants from Avaya (Customer Experience), Drumbi (mobile), IntelliResponse (Virtual Agents), and Etech Global (Chat Services)discuss these questions and provide expert insight. These experts do in fact answer the question “Will technology Kill the Call Center” and the panel discussion is well worth viewing!
Businesses communications technology is at the heart of every business but can be difficult to manage and expensive for SMEs. James Passingham at business communications provider, Foehn, thinks cloud and hosted telephony could be the answer.
From sole traders to global enterprises, cloud-based services have had a big impact on business decisions. And any company thinking of installing a modern business communications platform like hosted telephony will be looking to the cloud for its answer. That’s because IP telephony and cloud services are actually the same – both are hosted by a provider and accessed over the internet or through a direct connection to the provider. Those same organisations, working in our connected world, also know that legacy telephony like ISDN – digital transmission over copper lines – can’t keep up with the demands of modern communications.
Legacy telephony lacks scalability, isn’t feature-rich and requires onsite tech support when it breaks down. It’s also loaded with hidden costs due to the private branch exchange (PBX) systems taking a fiscal chunk out of CAPEX and OPEX budgets through installation and maintenance. That’s why so many enterprise outfits are looking to cloud communications, or hosted telephony, to provide a modern communications platform that’s as adaptable as their business.
Simply, hosted telephony routes all business communications over a high-speed broadband connection to a provider’s hosted network and it can be setup over any existing telephony infrastructure. Instead of paying upfront costs to install PBX phone systems, providers host all communications and the only hardware costs are for IP phones. Providers can offer even soft-phones and hook up employees’ mobile connected devices, enabling companies to rolling out remote working from home or in the field. That cloud management also means there are no costs or tech support required for onsite servicing or maintenance – all costs are covered by a low monthly fee and priced on a per user basis. And because it’s hosted in the cloud, providers offer robust security back-up and 24/7 business continuity, enabling enterprises never to miss any mission-critical communications.
But before any enterprise hooks up to hosted telephony, they need to consider any potential disadvantages as well. Some companies worry that they lose control of their business communications if they outsource to a provider and quality of service (QoS) of voice calls has traditionally been a pain point. But these days, most providers do a great job of managing business expectations by providing robust support for their services. And QoS was more of a problem when there wasn’t enough bandwidth to support hosted telephony. Now many UK companies have access to superfast broadband, ensuring a much higher quality of service.
Hosted telephony also has to be always on. In other words, it needs a 24/7 power supply to work properly and business communications can only operate when a provider’s server is up and running. However, modern hosted telephony solutions have fault-proof redundant backups, giving enterprises a much more reliable service.
The benefits of cloud communications far outweigh the negatives and there’s so much more to hosted telephony than the cost-effective management and its’ simple to deploy nature. The technology is entirely bespoke and deployed at a user-level, making it supremely flexible and scalable to match very specific business needs. Whether renting or buying, that “pay as you grow” philosophy also means it can be scaled back to a couple of features or installed as a fully integrated cloud platform with feature rich applications like audio conferencing and missed call email alerts, allowing businesses to spend their time and resources where they’re needed.
From real-time conference management and company directories to multi-level auto attendants to plug-and-go simplicity, I think cloud-based hosted telephony has pushed the envelope for SME business communication into the next-generation.
The trend in the Unified Communications industry is to charge a “per seat” license for access to VoIP Business Phone Solutions. In large part a legacy “flat tax” from the old TDM world, phone system suppliers continue to license based on the number of users that the system supports. Microsoft, ShoreTel, Avaya and CISCO all seem to have software licensing based on the number of users. Some licensing strategies become more complex as features and services are added. ShoreTel has by the simplest licensing strategy of the major suppliers, but they do count the number of users as the base software license cost. Additional license fees are assessed for “Professional” Communicators or Communicators that access Workgroup functionality for Agents and Supervisors. It is all rooted, however, in the number of users the system will be hosting.
If we consider a simple 100 extension solution, ShoreTel will have a $20K software license fee before you purchase any of the required VoIP hardware. Basically, you are paying $200 per user for an Extension and Voice Mailbox. After you purchase your software license, you will still need to purchase handsets, gateways and servers! Microsoft, CISCO and Avaya, though significantly more complex in their licensing strategies, start from the same basic “per seat” model. In fact, if you look across the business communications landscape all suppliers have to offer basically the same set of components Yes, all automobiles are different, but they generally have four wheels, a steering, seats, dashboards and a power source!
Clearly this has a significant impact on your ongoing cost of support. For reasons that I have yet to figure out, “technical support” is somehow a function of your system acquisition cost? The industry trend is in the range of 10-20% of your total system cost, including software licenses, will then be used to calculate your ongoing cost for software insurance and technical support. I know there are smarter people than I that have been working this out, but I just cant see the relationship between the cost of equipment and the cost to service that equipment? I get “making money”, but I don’t’ see the value relationship in punishing customers for buying more equipment?
Is there another model out there? Are we forever bound to the “per seat” license model? In fact there is another model out there! Enter low profile, high performance, global provider of Unified Communications, 3CX! These guys amaze me and I think they are harbingers of how the communications industry will work as we move deeper into the 21st century. Now hear this, they do NOT charge a “per seat” license! Contrary to the industry trend, they also include most functionality that the other players generally “option”. Full chat or IM services, presence, fax server, call center and mobility services, soft-phones, iPhone and Android applications are included with no “per seat” cost! Then how do they bill for their software? Simple. They license based on “simultaneous connections”. Clearly, if you have a 100 user system and a PRI for PSTN connectivity, all your users are not on the phone at the same time. Why not pay only for the maximum number of live phone conversations that you project for your business? 3CX pricing ranges from 4 to 1024 simultaneous connections and that can cover both large and small deployments. Lets assume that same 100 extension system and instead of $20K or $200 a user, you paid $5K to support 64 simultaneous phone calls?
This is not some small upstart trying to buy market share. This company 3CX, a certified Microsoft Developer, has been deploying on a global basis since 2006. They have a fully formed, Unified Communications solution that can match the established players, feature for feature. They will not compete with ShoreTel and CISCO in the 1000 seat market, but in the larger 25-250 seat multi site segment, they are a serious contender. Technical support is offered on a global basis, is astonishingly effective and uses a combination of traditional TAC center live remote support but leverages alternatives like video wiki, community, email and chat support. ( In future blogs, we will do the architecture comparison thing).
I know I am alone in the belief that you can not be both a hardware company and a software company! I think you have to pick one side of the street and really do it well to create a defensible market share and posture for growth! My Son argues that that is a ridiculous position, “just look at Apple they do both and have the best products on the market”? Not withstanding Microsoft, I think that the issue of comparative size plays a key role in enabling a company to pursue both. If you are a comparatively smaller player (Market Cap: SHOR $247M, APPL $611B, CSCO 100B) I would argue that it is more important that you figure out if you are a hardware company or a software company!
I would identify 3CX as a software company that you need to pay very close attention to!
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.
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.
“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!
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? 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:
In ShoreWare Director, select “Administration > Users > Individual Users”
Edit the user you wish to include in the simultaneous ring group
Click on the “Personal Options” tab
Click on the “Program IP Phone Buttons” button
For the appropriate button: Select “Monitored Extension”
Enter a Label such as “SUPPORT”
Choose the “SUPPORT” user’s extension
Set “Ring Delay” to “None” (This will cause the phone to ring immediately)
Set “Show Caller ID” to “Only when ringing”
Set “No Connected Call Action” to “Unused”
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!
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!
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!
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!
