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.
My brother came from New York to visit with me in San Diego over the Thanksgiving Holiday. During his visit, he was frustrated by the fact that his brand new iPhone 4s battery could not last through the day!
I did not pay to much attention to his ranting on this subject, but during his 10 day visit, his iPhone battery charge never lasted more than half the day before it was a dead as a stone. For the Christmas holidays I traveled to New York from San Diego. During the first day, I noticed that phone had shut off because the batter had gone dead. Never having experienced that before and, owing to the fact that I have my iPhone 4s wrapped in a case that has an expansion battery pack built in, I concluded that I must have forgotten to charge it over night.
That night I made sure to charge both the iPhone and the external battery case. Next day, not half way through lunch, I noted my iPhone had gone dead again, burning through both the internal battery and the external battery? WTF? My brother started laughing as I now knew exactly what he was talking about during his visit to the left coast. In my line of work (VoIP Tech Support), being without a cell phone is stress inducing to say the least! I set about trying to figure out what was different and why my phone could not last a day before running out of battery juice?
What made this all the more interesting was the fact that I travel with an iPad2 as well? Both devices have the same IOS level? My iPad was also a 3G model, so I concluded that AT&T roaming was not the issue. After all, would it not effect both devices the same if the issue was related to roaming on the 3G network? It must be something different about the two devices? I then set about turning off everything I could think of in the iPhone. I turned of the most obvious drain, Siri! I turned off all notifications? I turned off all the location based applications (so much for running up points on foursquare)! I even turned off the GPS and Bluetooth!
Nothing seemed to work? I benched marked my iPad2 against my iPhone 4s. The iPhone battery would be dead in less than a single day. The iPad with all the applications on, that I had switched off in the iPhone, ran for two days before needing a battery charge. My wife, who had my hand me down previous iPhone 3G did not have the problem. The issue seemed to be specific to the iPhone 4s! The iPhone 4s battery gauge looked like the gas tank indicator on a Ferrari, moving from F to E in record time. Maybe it was 3G data when no WiFi was available? Nope, I turned that off, even though I did not have to do it with my iPad. Email notifications were set to manual?
I began to scoure the Internet and could not find a single solution, though I found a recurring theme. Apparently, when you travel with an iPhone 4s, especially outside of the US, this basttery strangeness is a real issue for everyone. I can find no statement from Apple on this subject thought the forums seem to be filled with people sharing the same experience. I am particularly certain it is unique to the iPhone 4s as my iPad did not have the problem nor did the older iPhone 3G?
Magically, on return to San Diego my home turf, the problem just went away. My battery lasts the entire day with all the applicaitons, notification, Gmaill, Siri and GPS turned on! Migrating Alpha Pariticles? I know I am not the only peron to have this experience, so come on Apple, what is the story?
I don’t think your average business professional wakes up in the morning and says “Gee, I need some SIP”! They do however ask questions like how do we get an Area Code from New York to appear on our System in San Diego? Do I really have to buy 23 channels of voice on a PRI when I only use about 12 channels max? Can’t we just “burst” up to 23 or 50 channels when we need them? Can we have our phone calls re-routed to our branch office, if something happens to our main location? These are market drivers that are encouraging businesses of all sizes to consider implementing SIP trunks.
What is a SIP trunk? If you mention a T1 to a telephone guy, he will think you are looking for a channelized voice path to the telephone company. Ask an IT guy the same question and he will think you are talking about a 1.5MB connection to the internet! Now bring an integrated T1 into the conversation and things get a bit more interesting. Ask about a SIP trunk and you may get both of them scratching there heads. If you are not working SIP trunk integration today, you most certainly will be doing so in the very near future!
To over simplify for purposes of discussion, a SIP trunk brings “dial tone” to your phone system over an Internet connection. In most PBX systems, the connection to the phone company has been through a traditional TDM interface. In a ShoreTel PBX, for example, you would come from the phone company provided “smart jack” to an SGT1K. You would then use the Shoreware Director to configure the parameters that make a vanilla T1 a Primary Rate interface like defining the CO Switch type (e.g. NI2, ESS5, DMS100), framing and signaling.
In a traditional TDM deployment, the separation of the PBX system from the Telephone Company is clear and unambiguous. In fact, you often trouble shoot analog telephone lines by going to the 66 punch down block, known in the industry as the “D Mark” and remove the bridging clips that connect the phone company with the customers phone equipment. In this way you can easily determine which side of the block has the problem. With SIP there si a new challenge: how do you separate the customer premise equipment from the telephone company provided network connection? Where does your network end and the telephone companies network begin?
As we add SIP trunks to our network, the border of our network can easily disappear. For this reason, we need to introduce a “enterprise edge border controller”! The Border Controller is an essential element in provisioning a SIP trunk and is generally a dedicated appliance that provides a range of functionality that includes NAT traversal, Security, Port management, Normalization, Call routing and most importantly it acts as a “D mark” for your network, setting up a B2BUA between your iPBX and your border controller; and between your border controller and your ITSP. In this way you can think of your Border Controller as logical equivalent to a a 66 Block!
Why not use a Firewall to manage SP? Clearly, if you are connecting your phone system to the Internet, there needs to be a “firewall” function. A SIP RTP media stream is basically your phone conversation and it will take place over a 1000 different firewall ports. Clearly nobody is going to open 1000 ports in a firewall or you might as well not have a firewall! So a key functional requirement for a SIP trunk implementation is the ability to track legitimate requests to open a port and then to close it when the session is over. Firewalls that are “SIP capable” have this ability and are the minimum requirement for establishing SIP trunks on a phone system.
There are other equally critical functions that you must have in place for SIP trunking that exceed the ability of a Firewall and are more appropriately handled by a Border Controller. “Normalization” for example, enables the appliance to provide language translation. Like English or any other language, SIP sessions have “dialects” and ShoreTel SIP might be different than SIP from Level3, Net Solutions or Paetec. The Border Controller can mediate these difference enabling interoperability between these systems.
Two of the most widely deployed Border Controllers in the market are the CISCO CUBE and the Ingate SIParator. Both are excellent solutions, offering the required functionality to securely enable SIP trunking, including NAT traversal, Normalization and Security. If you are integrating SIP Trunks with a ShoreTel iPBX, you will be very pleased with the Ingate “SIPParator” solution. The Ingate solution “Start-up” tool that is designed to get your up and running as quickly and as painlessly as possible. If you know the basic configuration parameters of your ShoreTel and ITSP, the start up tool is the shortest possible path to your first SIP phone call from a ShoreTel iPBX. Using the start-up tool you can quickly configure the basics, sanity test the basic configuration, upload it and then use the Ingate Web based Administration portal can then be used to further your configuration, logging, reporting, monitoring and trouble shooting. The SIParator has been tested with a long list of SIP carriers and has many of the ShoreTel required parameters per-configured. The support team at Ingate is both knowledgeable, patient and committed to making your ShoreTel deployment a success.
Unified communications is a revolutionary technology that integrates many worlds of communication at one place. The way unified communications has converged many services is something unprecedented. You can get all the great features of unified communication like instant messaging, video conferencing, data sharing, electronic whiteboards, and call controls etc through one service. Recent developments in the VoIP industry have made it possible to integrate VoIP with the unified communications. Key VoIP service providers like Packet 8, Axvoice, and Nextiva have already integrated unified communications in their phone services. One unique advantage of integrating unified communications is that you can access them through different devices. A key benefit of unified communications is that the end-user can respond to any type of incoming communication within no time. You will also be able to view one type of communication on a different type of device originally received on another device in a different data format.
Vulnerabilities of Unified Communications
Unified communications are vulnerable to different types of attacks. Let us review these threats which can exploit the weakness of unified communications.
Denial of Service Attack
This is one of the most commonly used ways of attacking unified communications. The attacker can use different attacking techniques to target the end user or even the servers involved in carrying out the whole process. The attacker usually uses SIP messages for the denial of service attack. The attacker waits for an incoming call to a phone user. Once the INVITE has been received by the end user, the attacker immediately sends the cancellation request. Resultantly, an error is generated by the invitee’s device and the call is ended. The main purpose of this attack is usually to disrupt the service. If the end user receives these kinds of calls repeatedly, the unified communication environment can direct the calls to other routes like email, voicemail, message store etc. The other dangerous type of denial of service attack occurs when the dialog is initiated between the two users. The end result is the BYE attack in which the call ends before it starts. This attack is also geared towards disruption of the service.
These both kinds of denial of service attacks can be overcome by a well designed SIP device. An intelligently built SIP device should be able to recognize if a CANCEL or BYE request is initiated by the end user or not. In the same way a private network directed through the UCS is not normally vulnerable to this kind of attack.
Eavesdropping
One of the key features of unified communications is that the end user can send the other user a RE-INVITE in the middle of a conversation for changing the type of communication. This RE-INVITE could also mean change in the location of the conversation. In this change of location, during the RE-INVITE, the attacker many invite someone else to join the conversation as well. The best way for the end user to shield himself from this kind of attacks is to only accept these kinds of invitations from the user who he really trusts. End user is strictly prohibited to send extremely confidential information like credit card number, passport number and other personally identifiable information unless very sure about the intent of the user at the other end.
Message hijacking
This is one other dangerous attack on the end-user. In this particular type of attack all the messages that are sent to the attack are re-sent to some undesirable user or users. The messages may contain very important information like meeting dates, critical document drafts, or other sensitive data. Only share this kind of information through secured means and only with known trusted users at the other end.
Prevention measures
Usually advanced unified communication systems implement a proper authentication system before enabling end to end communication. There needs to be a secure connection between the client and the server by matching the exact security protocols supported by each one of them. Encryption of the communications is one way of ensuring the security of the data travelling between two mediums. Secondly, all devices that are requesting authentication with the unified communication systems first need to be properly and clearly identified before any such permission is granted. A SIP aware firewall installed can also be deployed which can evaluate the SIP headers to ensure their compliance with RFC. Lastly standard techniques should be deployed to protect email servers, voicemail servers, and gateways which are critical to the unified communication environment security.
ShoreTel currently runs on Microsoft Servers. There are a number of Windows components that need to be installed to support the deployment. If you have been installing ShoreTel for any period of time you already know that FTP and SMTP services along with Microsoft Windows ASP.NET, IIS and certain of its components are also required including Active Server Pages and Server Side Includes. I also recommend that you get HyperTerminal, or better Putty to support SSL connections to ShoreTel switches loaded on your HQ server. I find SQLyog to be an effective trouble shooting tool, so I also get that on the HQ desktop. Having Adobe available will enable you to read the online documentation that ShoreTel provides. If you are new to Microsoft 2008 servers the process for loading Windows Components is a bit different, so this silent video clip will walk you through the process.
When someone is on your website, it is like they entered your store. Clearly, they have an interest in what you are about or they would not be there. It is at this moment that they are most receptive to learning about your product and services. Would you not like to know when someone hits your website? Better yet, would you like an opportunity to interact with a visitor to your website? If so, you want to enable a CHAT function, a link that says “connect with a company representative now”! Clicking that link opens a real time conversation channel with an internal human resource at your company! Research proves that the sales conversion rate on these transactions are without equal. Do you suffer from “shopping cart” abandonment? Maybe that last minute question could have been answered if your site had a Shoretel Chat function!
ShoreTel ECC 7 Website Chat
Contact Centers are different that call centers in just that way. In a contact center we know that people interact not just by phone, but by email and web interactions like Shoretel Chat. If you are running even a small contact center, you need to experience the high impact customer development strategy of enabling Chat on your website. The application is relatively straight forward, especially if you have a contact center operation. It is hard to find a company today that does not have some kind of web presence, so why not integrate the two?
The ShoreTel Enteprise Contact Center has a real time ShoreTel Chat function. Visitors to your online store can click on a link that immediately opens a chat window with the next available Agent. The same rules and options that govern your handling of an inbound voice call, can be applied to a Chat session. Chat sessions can be “queued” for the next available agent and will even show up on the Supervisors display as a customer waiting for service!
ShoreTel Website Chat Doesn’t end here
The transcript of a Chat session can be automagically emailed to the website visitor, and a copy can also be sent to the contact center for archive. Chat sessions are presented to your Agents in manner that is consistent with the behavior they employ on a voice call. They see the Chat session “ringing” in on their tool bar, click answer and a browser window opens up and they can are now in a real time Chat session with a visitor out on the world wide web. Agents can select from per-authored files and screen of information that can be sent through the Chat session with a mouse click.
Chat is among the most valuable customer interaction tools that you can add to your arsenal of sales aids. It can often mean filling a shopping cart that might have otherwise been abandoned! The film clip give you an overview of how to implement Chat using the ShoreTel Contact Center!
As both a ShoreTel Certified VoIP Engineer and a CISCO CCVP I have been working exclusively in VoIP since 1998. For this reason, one of the questions that is most asked of me is which is a better solution: ShoreTel and CISCO? Since I have the sales skills of Attila the Hun, I assume that the question is being asked because someone is truly interested in understanding the architecture of the two systems. At the end of the day most people just want to pick up the handset, hear that warm reassuring sound of the dial tone, press some digits and talk to their target! How that all happens is generally of little interest to the average user. So why else would you ask that question unless you were generally interested in understanding the two systems and how they compare when resolving traditional telephony applications. I thought it might be useful to drill down on the two solutions in a few key areas toward the goal of understanding how they both work.
First, which systems to compare? CISCO actually has a family of VoIP solutions under the brand banner of Cisco Unified Call Manager. For example, they have a small 24 user system that is marketed under the model 320W. The next model up would be the UC500 series, then the CUCM-Express and finally the CUCM. Even the CUCM has different models. The most recent edition, the Cisco Unified Call Manager Business Edition Version 8 is a 500 seat, 5 site variation of the full blown 40,000 user Cisco Unified Call Manager. Since ShoreTel actually has only one product family that can take you from 25-10,000 users, I chose to use the Cisco Unified Call Manager Business Edition (CUCM BE8) as our comparison product.
Both product lines support a range of Unified Communications Options that include Contact Center, Presence, IM, Video Conferencing and Microsoft Integration. The list of options goes on and on, so where do we draw the line in our comparison? My thinking is that we stay focused on the basics: the telephone and Voice Messaging System. In this way we can look at the two architectures and free ourselves from the additional servers most of the options will require. Lets keep it simple!
Let me first make a blanket statement about telephone system features and “feature sets”. For a very brief period on the calendar, one system might have a feature that the other system does not have. Understand that within six months, both systems will not only achieve parity, but will reverse roles. The one that did not have the missing feature, will now have it and the other one will be missing one! My sense of it is, that you would no sooner buy a phone system because you like the color of the phone than you would because it had a feature that was not available in the other system. I guess it is possible that someone would make a purchase decision based on that criteria but features are maturing all the time and with major feature releases usually twice a year, all phone systems achieve feature parity very quickly. So this brief comparison is not going to talk about features at all. They are both the same, lets drive on.
One high impact characteristic that is of immediate interest, however, is the concept of Software Versions. ShoreTel is currently running on release 12, having migrated over the last ten years from Version 3. Without exception, each release of ShoreTel has been backwardly compatible with the previous version of ShoreTel. What this means is that If you purchased hardware from ShoreTel in 2001, you can upgrade it today to Version 12 in 2011. Both companies have been slowly migrating away from Microsoft. ShoreTel and CISCO both came to market using Microsoft Servers and Microsoft database utilities. CISCO has moved more aggressively in this area, shedding Microsoft Server for Linux, but with a heavy toll on the installed base. If you were on Version 4.x of Cisco Call Manger there is no easy upgrade path to CUCM BE8 and prior versions are either not supported or end of life.
ShoreTel is still using Microsoft Servers though one might project a product road map in which they move to Linux. Historically, ShoreTel used Microsoft Access as the configuration database for its phone system and call detail records. By Version 8 ShoreTel had moved from Microsoft Access to MySQL for all of its database requirements. This transition was made with nominal breakage and early ShoreTel adopters can continue to upgrade to later versions of ShoreTel. CISCO database was built on Microsoft SQL engine. Cisco release 4.2 ran on Windows 2000 and Version 4.3 was implemented on MCS OS 2003 a Cisco proprietary version of Microsoft. With the release of CUCM 5, Cisco moved to the IBM Informix database running on a Linux engine (Cisco VOS). Cisco 6 moved to Linux Red Hat Enterprise and would no longer support the previous Windows based Call Managers. Cisco Version 8 was introduced in 2010 and is now the current release for the entire CUCM product line.
ShoreTel uses the Microsoft Server family and currently supports Windows 2008 64 bit OS servers. Cisco began to support virtualization under VMware in Version 8. ShoreTel began to support VMware virtualization in release 11.2. Generally ShoreTel will allow you to pick your own hardware provided it meets the basic server requirements for the release being implemented. Cisco requires the use of an approved MCS server, generally an HP or IBM hardware platform. A key difference is that under Cisco, the server is considered to be an “appliance”. Aside from being able to set up the network parameters, the root is completely unavailable to the maintenance of the system. On a ShoreTel system, you have complete access to the underlying OS as the system administrator. Treating the hardware as an “appliance” while hiding the OS does have its advantages from a support perspective. On the other hand, most IT managers will be very uncomfortable with a server that does not allow access to the base OS.
Culturally, Cisco is defined by extension numbers and ShoreTel is defined by Users. It is a subtle but very interesting differential. Both systems will allow you to auto provision a group of phones. In Cisco you can arrange to automatically assign a range of extension numbers sequentially to phones as they come up and register on the network. The auto registration process can also assign calling permissions to those phones. In ShoreTel you can bring up a group of phones and they will automatically register over the network with the system. The ShoreTel phones will, however, not have extension numbers. They will be “available” which means they can not be called until they have a User assigned to the phone! This means the calling permissions are based on the User not the Extension number. Cisco allows you to assign a User to the phone, but the concept of an extension can exist independently of a User profile.
Both solutions offer the ability to integrated geographically distributed locations into a single call handling plan. ShoreTel has a distributed call processing model and Cisco uses a centralized call processing model. When Cisco is deployed using a distributed call processing model, this means that a separate Call Manager cluster is setup at that remote location. The deployment models for both systems can get complex quickly, but the best way to understand the impact of the deployment model chosen is to study the failure mode. In the Cisco model, your phone registers with a Call Manager server. No Call Manager Server, no dial tone. For this reason the Cisco best practice is to have multiple Cisco Call Managers in a cluster that phones can register with in the event of a single Call Manager failure. The ShoreTel solution has the phone register with a Shoregear switch, a hardware appliance or what Cisco would call a “media gateway”. If the ShoreTel HQ server fails, the phones still have dial tone and phone calls in and out are still completed. If the Shoregear hardware appliance that a phone is registered with fails, the phone can register with another resource anywhere in the system. The loss of the ShoreTel Server has impact only on the Voice Mail and Automated Attendant.
Both systems make use of similar call processing protocols, most notable of which is MGCP. Cisco phones communicate with their Call Manager using a Cisco proprietary signaling protocol referred to as “skinny” or SCCP. The Call Manager communicates with its Media Gateways using MGCP if it is loc ally attached or H323 if it is a Gateway across the WAN at another site. ShoreTel phones communicate with the Shoregear Switch they have registered with using MGCP protocol. The Shoregear switches communicate with each other using SIP. Both systems also support SIP end points including SIP extensions and SIP trunk lines.
System administration and support are also key areas in which you will want to drill down for comparison purposes. The best way to understand this difference is to actually log into both systems and do something useful like add a user. ShoreTel has a single web portal in which the system definition is configured and through which adds, moves and changes are made. This is one very key differences in the architectures of these solutions. Remember, the ShoreTel is a self contained solution that includes the Voice Mail system. The Cisco solution requires a separate Unity Connector voice messaging system. So when adding a user for example, in the ShoreTel you would create your user and simultaneously create the directory listing and voice mailbox. In Cisco this would be separately configured system administration interfaces.
ShoreTel Shoregear Media Gateways, are very similar to Cisco gateways but differ in how they are configured. Bringing up a T1/PRI at a remote site in ShoreTel is no different that building out a T1/PRI in a locally attached Gateway. It is all done through the ShoreTel administration web portal. In Cisco, you would define your T1/PRI gateway, but you may be required to actually go to that device and code at the IOS command level. You can use the Cisco web administration portal to define the gateway device, but the device itself is often configured separately in IOS.
I think I will leave the entire subject of fail over to a dedicated blog on that subject. Again both solutions have a strategy for dealing with the loss of a WAN link, and they provide for the continued operation of the disconnected remote site. How they each do this, is really quite different and deserving of a dedicated blog. The issue at this point, is how to administer that fail over capability and how to configure the system for continue operation. Cisco SRST (Survivable Remote Site Telephony) is an interesting set of administration tasks that requires a bit of explanation. Basically a remote site becomes a Cisco CCME and continues on as an independent operating entitiy and will require manual intervention to bring it back into the main system when the Wan is available. ShoreTel, requires no additional configuration beyond what was defined in the original system deployment and no manual intervention is required.
The film clip below reviews most of this text, but will also show you what to expect when you log into each solution. First we take a look at the ShoreTel solution and then we log in and take a quick tour of the Cisco administration portal.
Adding Users in ShoreTel is among the most common tasks a system administrator will be expected to perform. We suspect once the ShoreTel solution is fully deployed, you will generally not have to tweak Trunks, Switches and Application Servers, but you will always be handling requests from USERS to make changes. These changes will run from adding New Users to changing the feature access of existing Users. Most User options can actually be changed by the Users themselves but often they will call System Administration or the “help desk” and expect your assistance. ShoreTel Users have wide range of very rich features that they can configure to meet operating business goals. The list of features ranges form “twinning” to “find me follow me”, call handling modes, and “personal operators”. There is also a range of options for customizing ring tones, wall paper, Communicator Tool Bars, and phone buttons. Adding users is easy! Understanding feature configuration options and how they interact with the ShoreTel system requires a bit more study.
Generally, ShoreTel phone extensions to not exist without an associated User. This is a cultural issue as much as an architectural issue. In a CISCO deployment, for example, it is very possible to setup auto-registration and allow a range of new phone to plug into the network, register with the Call Manager, obtain an extension number and be come a fully functional phone. In the ShoreTel architecture a phone can register with the ShoreTel sever but it does not receive an extension number until a User account has been associated with the device. These are modest but interesting differences in iPBX architectures.
We also have the concept of Class of Service and User Groups when we consider user configurations. All systems generally have this concept. Again, in a CISCO deployment you would work with Partitions and Calling Search Spaces and they are virtually the same as User Groups and Class of Service permission containers. ShoreTel has a very flexible User Group and Class of Service container strategy that is easy to configure, manage and assign. Generally, we want to create individual User accounts, but we often want to make changes to a Groups of Users. For this reason there is a handy Batch utility for making it easy to make mass changes to your system configuration.
Working with User configurations is an essential part of ShoreTel System Administration. The attached video clip outlines the process of making User Configuration Changes in ShoreTel using Version 12 of ShoreTel ShoreWareDirector!
We have been experimenting with mobility options for some time now, setting up SIP phones on mobile devices like the iPhone. ShoreTel has a range of mobility options, most of which we have discussed here in previous blogs, so setting up a softphone is nothing new for ShoreTel. Recently, I discovered a new SIP softphone by CouterPath Corporation the company that brought you X-Lite, one of the most popular free phones on the net. The new offering is named Bria and is ideally suited for your iPad. Bria is a more of a “carrier grade” softphone enabling both voice and video calls over IP, the ability to send IM messages and transfer files to your contacts. I particularly like the option of downloading additional Codecs like G729 which is really useful for a ShoreTel remote phone. Bria also has Enterprise features like LDAP/Active Directory integration and some Workgroup capabilities like a Busy Lamp Field. Most importantly it seamlessly integrates with your iPad VPN which brings me back to ShoreTel.
We have configured a bunch of different SIP phones to work with ShoreTel. Candidly, they all work really well internally, on the Enterprise WiFi. Setting SIP up on ShoreTel is a relatively straight forward process. Pick an ShoreGear switch in the site you are planning to register with and set up a port for SIP. You do this through the drop down menu on the SG switch through ShorewareDirector. Set the port for 100 SP Proxies. Note the IP address of the switch. Now you have to set up your USER and note the SIP password for that User. When you setup your softphone you will need this information so keep it handy! (In the library there is a Video Cheat Sheet that shows you how to set up SIP in ShoreTel). The Bria setup is also very straight forward. Remember that when it asks for Account Name it wants the Extension number of the USER you created in ShoreTel. Put the IP address of the ShoreGear switch that provides proxy services as the Domain and enter the SIP password you created for the USER. The Display Name can be whatever you want.
The Bria phone should register if you have WiFi and you should be set to use your iPad as your ShoreTel extension. This is great for wandering around your own facility. If you have the ShoreTel ”WebAgentDashboard” you can wander around your Call Center with a Supervisor Real Time display and have a ShoreTel extension with you the entire time. Kool stuff, but what about when you are at Starbucks or some other location? How will your Bria connect with ShoreTel? We have successfully created a L2TP VPN back to the ShoreTel Server from both the iPhone and the iPad. Apple cleverly built a VPN client into all devices. Once the VPN is operational, you can bring up your Bria softphone and extend your ShoreTel extension to any location that has WiFi access. Optionally, you can bring the Bria connection up over your G3 data network. You can extend that Supervisor Real Time Display as well! The Bria comes up and completes a SIP registration with the ShoreTel and the performance is remarkable.
At first I had some reservations about using the Bria on an VPN over G3. Establishing the VPN tunnel, then running a Ping back to the Server, indicated Latency in the 425 ms range! Not exactly within the recommended target of 150ms mouth to ear. None the less, it worked and was very usable. We are fooling around with using the Bria as an IM agent on the ShoreTel Collaboration server (see previous blog) and I guess we will figure out how to make use of the Bria video and presence.
At the end of the day, you have a range of Mobility options on the ShoreTel and you should figure out which option is the most effective for your mode of operation. It is very possible to take your office extension with you, in fact we think the Desktop is dead! Your cell phone is your desktop!
The blog on the ShoreTel Mobility Router as one of the options offered by ShoreTel for remote worker connectivity, generated a lot of email requests. I have an opportunity to install, configure and test the solution including the Roam Anywhere Client on an iPhone. It is really a great product and should be well received in the market for campus wireless as well as for the growing Mobile workforce. The attached video provides a quick overview of the SMR System Administration Interface and is not meant to be a tutorial on the subject, just a quick tour of the basic admin portal.
System configuration is relatively straight forward, but very specific. Without getting into the infrastructure requirements, there are steps in the configuration that must be accomplished to bring up a useable platform. The SMR will connect to your PBX using both SIP Extensions and SIP trunks. Licenses, Authentication SSL Certifications, Time Servers, DID numbers and Network Interfaces are all necessary components to a successful deployment. The ShoreTel Roam Anywhere Client or RAC, can be downloaded from the Mobility Router itself for Crackberry and Nokia, or from the Apple AP store if you are installing on an iphone.
We were able to use a ShoreTel SIP extension and drag it half way round the world to China! It worked flawlessly. The RAC comes up, attempts to register with the local server IP through a WiFi connection and failing that, negotiates a SIP registration through the public IP as an SSL connection. Once provisioning has completed, you have a fully functional Extension on your state side ShoreTel PBX as a SIP extension. You can place extension to extension calls and dial 9 calls as if you were standing in your home office. A call to your primary extension is typically set to ring both your desk phone and your SIP extension out over the Campus WIFi or over the internet to the WiFi WAP nearest you. Answering on your iPhone SIP extension and nobody would know you were working remotely. Think of the cost savings!
The ROC will attempt a WiFI connection first, then try over your Cellular Data plan and then finally a Cell Call. The router tracks all of that and reconfiguration happens automatically. You might want to set your ROC to use WIFi only. If you do not have a local access number where you are traveling, the Cell Call will be back to the SMR DID stateside, entering the router as a SIP trunk. Setting the Network options to WiFi Only assure that all your calls are made through the Secure Voice facility, basically an SSL connection over WiFi to a public IP address that port forwards to your mobility router. The router requires care and feeding and constant monitoring, but the platform has a wide range of maintenance and troubleshooting tools. The documentation is excellent, but your deployment team will need expertise in SIP, telephony, computer networking and have a strong background in controller based wireless technology.
Though now owned by ShoreTel the router will work with CISCO, Avaya and basically any PBX that supports SIP trunks and extensions. When we find a moment, we will compare the RAC and SMR functionality with a BRIA SIP soft phone, both on an iPhone.
ShoreTel Recently announced the availability of Version 7 of the Enterprise Contact Center. It is not secret that I am a big fan of this product, so I was anxious to see what the new version had to offer. The product has a number of new features and capabilities that are both feature specific and impact the infrastructure of the product. Anyone who has worked with the ShoreTel iPBX for any period of time will become instantly comfortable with the new ECC system administration interface. It is now a browser based portal, very similar to the interface used for the iPBX administration. In fact I would be willing to bet that the new ECC portal will become the standard for the ShoreTel product line and the iPBX Shoreware Director will take on some of the characteristics of the new ECC 7 administration portal.
Another area in which the ECC has adopted the exiting iPBX paradigm is in the area of licensing. Early versions of the ECC required the installation of a hardware dongle on the server and each desktop that ran the Supervisor software. Dongles are a pain for everyone and beginning with Version 6, ShoreTel began to migrate away from this requirement by eliminating the dongle requirement for Supervisors. Previous versions of ECC required the installation of the USB Hasp on the server before installing the ECC application. No dongle, not ECC! With ECC 7, not only are the dongles not needed, you get the familiar 45 day grace period to run the ECC application and try all the features before you have to provide the license keys. The server key locks to the MAC of the server, in a fashion similar to the iPBX key. The ECC application also reads the BIOS serial number of the server for added software protection.
Other infrastructure changes include the support for Windows 2008 R2 64 Bit Servers. The ECC will support Citrix and WTS clusters and most importantly, roaming profiles are now supported. The system will now allow for 100 concurrent Supervisors and 1000 concurrent Agents, though you may define 2000 agents in the database configuration. The application support 400 DNIS reports and historical data can now be kept for 24 months allowing for year over year trend analysis.
An exciting new feature is the addition of Personal Queues. I am sure we have all had the experience of working with an “agent” on a particular customer service issue, maybe given a “home work “ assignment only to call back and have to start over with a new agent. The concept of a “Personal Queue” makes it possible for inbound callers to reach specific agents, if you desire that option. In this way, after completing the “home work” assignment, you can call back in and queue for the agent that originally handled your call in the first place. Agents can move high priority calls to their personal queue with a simple mouse click. Historically, if you wanted this option you had to configure a group and service for each agent that required a personal queue. With Version 7, this process has been streamlined with the creation go a new entity that defines how the caller should be handled while in the personal queue. A very powerful option and very useful in direct selling environments.
The familiar graphical scripting tools has not changed and scripts are generated using the established procedure. The Diagnostic console has been upgraded and is more usable for trouble shooting at the System Administrator level. I am particularly excited about the creation of a Lab SKU, something I would like to see ShoreTel do with the entire product line. The Lab SKU makes it possible for you to purchase and run a small scale Contact Center along side your production environment. In this way you can create new scripts, strategies, call flows and of course, test new upgrades before putting them into your production environment!
