All of the architecture “geek speak” aside, CISCO and ShoreTel have fundamental “cultural” differences that defines their approach to the entities of a “phone” and a “user”. Simply stated in the ShoreTel world a phone can not exist without a user, but the CISCO world a phone can exist without a user. Now this is not a bad thing or a good thing, it is a just the way it is thing! What does that cultural distinction mean to you and your business? Does it mean anything? From a system definition perceptive, it does change how you think about your deployments.
In the CISCO world, you can bring up a range of phones, auto-assign an extension number, have a fully functioning dial plan and never define a user! In a ShoreTel deployment you can auto-register a range of phones, but they can not participate in a dial plan until they are assigned or “owned” by a user. In one solution, the privileges that a phone has, like being able to make International phone calls, is set by the privileges of the user. In ShoreTel a user is associated with a user group and that group has privileges associated with it.
In the ShoreTel world, users are licensed but phones are not directly licensed. You clearly have to have ShoreGear resources for the phones to register in the system, but aside from the cost of the phone and ShoreGear switches, the phone is not directly licensed. If you deploy that phone in the “Parts” department you will need to create a User and associate that User to the phone. So we now need to create a user and user name like “Parts Desk1” and assign it to a phone. Optionally, we could create a user named Tony Slavetore who works in the parts department, but that brings up the issue of of separating a “function” from a “person” which is an entire deployment discussion in itself and the subject of another blog.
In the CISCO world, you can have phones with extension numbers and they do not have to have a User profile associated with them. In a CISCO deployment, phones belong to “partitions” and “calling search spaces” and that is what determines the phones privileges. In fact the concept of a “partition” makes it possible to separate phones in such a way that “staff” for example, can not dial “executives”. ( If asked in a ShoreTel system to restrict a phone from being able to dial a specific other phone, I would have to puzzle that one out ). Again, this is not a which strategy is better discussion, but it is a distinct cultural difference that we seldom hear about.
The included video demonstrates adding a user and a phone in both the ShoreTel and the CISCO CUCM solution. System Administrators will spend +80% of there time in this area! Adding, deleting or modifying Users is a key part of the day to day maintenance of a phone system.
All telephone systems have to deal with the same key architectural issues regardless of who manufactured the equipment. All phone systems have to provide for the definition of a system “dial plan”; trunk groups, call flow options, phone devices, gateways and user profiles. The dial plan, for example, not only has to identify the patterns used to route callers between system extensions, but as is often the case in a VoIP deployment, between geographically distributed corporate locations or “sites”. The dial plan identifies the legitimate patters that define system end points and also include system extensions. System extension define various facilities and features with in the system. The Automated Attendant, for example, has a system extension number that can not be used by another extension in the system. Likewise so does the conference bridge, park feature, hunt groups and paging groups.
The phone system defines Trunk Groups which in turn contain individual telephone lines. Permissions are defined within the system to enable access to these different trunk groups and also define what other facilities a user might have access to. Devices are defined within the system, typically consisting of phone instrumentation, media gateways to the PSTN or Remote Sites and collaboration facilities like conferencing and presence. Other application servers are also defined in the system to provide for advanced functionality like Contact Center.
The entire subject of User configuration is contained within the system database as both a comparatively static form as well as a run time representation. A user name and extension number, is an example of a relatively static configuration data parameter. Which mode or state that users is in, would be an example of a “run time” state. Which phone the user is currently assigned, where do their voice message reside and what restrictions have been placed on them are all examples of administrative options that need to be configured.
Both ShoreTel and CISCO have developed Web based interfaces to enable system administration. ShoreTel argues a single “brilliantly simple” portal to all system configuration facilities. CISCO argues a level of control over configuration details that enable laser like configuration options. For example ShoreTel operates on the concept of canonical dialing. If a user dials 123-4567 ShoreTel will translate that into +1 (123) 456-7890. CISCO anticipates “dial-patterns” that make it possible to strip +1 (123) 456-7889 out from +1 (123) 456-7890 and route it differently. The System Administration portal is the interface that is used to configure, define and revise all system options and for this reason it is as important as the phone set itself!
Over the next few blogs we will look at the actual web portal interface of both of these solutions. In this first video, we will go over the portal interface in general, comparing both systems. In subsequent blogs on this subject we will compare different administrative activities such as adding users, phones, gateways, sites and configuring call flows including automated attendants and hunt groups.
Having deployed literally thousands of phone systems of all sizes and levels of complexity, we have distilled a set of rules and check lists that work. (see our “network readiness check list” and our “VoIP planning guide”) When phone systems were analog or traditional TDM based solutions, deployments were challenging enough! You always had the User group, Call flow and “K plans” to hammer out along with the usual Telephone carrier challenges. With VoIP solutions however, the level of complexity has dramatically increased. This technology touches so many other infrastructure domains that it is becoming increasing more difficult to draw a box around what is included in the project! Consider that you are required to integrate a phone system with Active Directory, Exchange, CRM applications and deploy over a geographical topology that might be global in scope! You need a road map for success and project management becomes an essential component of a successful deployment.
The first post sale step should be to organize a “kick off” meeting. The kick off meeting is an opportunity to set expectations and establish guidelines that will help complete the project on time and within budget. When you leave the kickoff meeting, everyone on the project team must be on the same page. It is imperative that we identify the key “stake holders” in this project. Minimally this list has to include an Executive sponsor, the Account manager and the Project manager. During this meeting you will want to spell out goals, objectives and deliverable identities then obtain “buy in” from the kick off team. You will introduce the project team members and identify their individual “roles and responsibilities”. Setting a target for “go live” often helps drive the milestones that have to been executed if that time line is to be achieved, so I am a big proponent of working backwards from a target date! Developing a contact list should be accomplished at this meeting and if the project will use a web portal for communicating, it should be demonstrated. Allow for the possibly that there may be outside vendors that need to be identified at this time and added to the contact list. Finally, assign “home work” and set due dates for the next meeting.
The kick off meeting is almost a social event and is a time for people to associate names and faces. It is not a working session, but an effort to set expectations for all that will be either on the project implementation team or will be impacted by the implementation process. There is a wide range of personalities and skill sets at a “kick off meeting” so it is important to adopt a language that is comfortable for all. The team will consist of very technical people, financial professionals and technology consumers (We are trying to avoid using the work “users”. There are only two industries that call customers users. The IT community and the drug trade). It has been my experience that we will almost always get all of the technical stuff settled; all the speed and feeds, bits and bytes. The area that is always the most difficult to extract is the Call Flow information . For this reason it is imperative that the team have a representative that can speak for the User group. Someone has to define a callers experience and the scripts that are head by the caller as they progress through the telephone system (see also: http://www.blog.drvoip.com/call-flow-the-callers-experience-when-reaching-your-business ).
Some of the internal players that will need to be included on the implementation team are responsible for key infrastructure components. Active Directory integration is now almost always a part of a VoIP deployment. Messing with a companies domain and user authentication polices are never take lightly and you will need to get key intellectual resources involved to pull this off successfully. Clearly, the computer network both LAN and WAN will touch the the new phone system and this area requires even more planning and communication. Generally, there will be outside vendors involved especially as it relates to the WAN connectivity. Getting the carrier to the table early on in the process will greatly facilitate the success of the project.
Facilities management or property management and the bag full of deal killing goodies needs to be addressed early on! If you are deploying in a “greenfield” you will have a different set of challenges then if you are replacing an existing phone system. Often a “greenfield” is another word for “new construction” and construction always means scheduling conflicts and delay. This is where your project management software really gets exercised!
The actual deployment of equipment is almost reduced to a task list. Properly managed most of the heavy lifting has already been accomplished before the equipment is actually installed. The network has been assessed, made ready, routes updated and QOS applied. The user database, IVR scripts, trunk facilities, Extension lists, Hunt groups and system definition have already been programmed. We are down to “rack and stack” and set placement in anticipation of exercising our detailed system test and acceptance process.
It is about this time that we will want to have the Training team make an appearance. Generally, it is best to schedule user training as close to the “go live” dat as possible. We have found that we can brake user training into two groups. The first group is a an abbreviated session design to assure that all can answer an incoming call, park, transfer and conference. If users can do that by “go live” only good things can happen. The second group is an extended session augmented by multimedia and other online solutions. This training is for your power users and special users like Operators, Agents and Supervisors. Actually, this is a process not an event and your training program has to be ongoing over the life of the deployment. People come and go in any company. Your reputation and phone system stay. Make sure new users have a good impression!
The “go live” is also more of a process than an event. Moving the old numbers to the new phone system, might be a single task in time, but it is part of a process that includes a series of collateral events. For example, how do we get our Voice Mail off the old system? In fact, what happens to the old system? Was Garbage removal in the project plan? A new VoIP deployment needs a “post cut” support plan that includes establishing a “help desk” and identifying a problem reporting process and resolution team.
If there is a “kick off” meeting there should also be a project close and review meeting. This is where we can review what happen and how to transition the project to a support mode. There should be an “as built” documentation package that is handed off from the project team to the operations team. These documents will be outdated in less than a month, but it makes ongoing support viable if we have a record of changes to date, so make the extra effort to get this package completed as part of your project plan. Ultimately you will want to have a 30 day review. Keeping a client takes as much effort as getting a new client, so make ongoing client contact and system optimization part of your service offering. Include ongoing training and you should be able to keep a client for life!
We are often asked for an opinion on the subject of what is better solution: a hosted “virtual” PBX or owning your own phone system? Lets take a look a quick look at both solutions and see if anything stands out as making one solution more obvious than another. First, let me lay out some quick assumptions! We have to make some assumption about the size and scalability requirements for your phone system. If you are a one or two man shop, don’t waste anymore time reading this blog, call Vonage or get a Magic Jack and be done with it! If you are a start-up, and your hosting company is willing to provide all the equipment you need at no cost to you, you can stop reading here also. We assume that you are a viable business, with some scale or plan to scale and 10+ desktops and “who can provided the cheapest “dial tone” is not your only criteria!
We have given the “your VoIP deployment is only as good as the computer network it is built on” so often, we will omit it here other than to say; crappy computer network, crappy phone service! However, one of the biggest misunderstandings about “hosted” anything, is the issue of equipment. Regardless of which solution you run with, you are going to need equipment at your place of business. The equipment list includes:
a high speed connection to the Internet;
a Router;
SIP savvy Firewall;
Quality CAT5 or better Cabling!
a Power Over Ethernet Switch;
and the actual telephone handsets!
Much the way you would still need a desktop display and keyboard if you have a “hosted Microsoft Office”, you are still going to need a handset and all the cable and connector stuff. So then, from an equipment standpoint what is the difference? Well someone has to provide the “box” that does all the Unified Communications Magic everyone wants in today’s business world! All that Voice to Email, Digital Receptionists, Mobile connectivity and web based call control. That box has to live somewhere and it is either in the hosted “cloud” or down the hall with the rest of your stuff!. My guess is that you will not save much money on equipment by going “virtual” phone or computer. (Read Return on Investment. At sometime you will own the box).
Lets take a look at that Internet requirement. If quality means anything to you and your business, you are not going to be running a business of any size on a DSL connection to the internet if you are hosting your voice services in the cloud! In fact the more of your voice that you move into the cloud, the more bandwidth you are going to need. You don’t have to be a VoIP engineer to understand that when Bob picks up his phone to call Sue down the hall, the box has to connect them. If the “box” lives in the cloud the we are going to use two times the band with for a simple office to office phone call. If every phone call in or out of your place of business needs to go over that Internet connection, your own ramp is going to need to be very broad! Generally, a dedicated T1 service will be required! (Read increase variable monthly cost).
Quality will always be an issue for VoIP, again, regardless of where the “box” is located. If every phone call is over the Internet then we need to understand that, unless the service is provided by the Internet provider you get your phone service from, you will have a quality issue. What is this mean? When we send anything over the Internet, we can not guarantee the quality of service unless we have a “private” path through the pubic Internet and an SLA (service level agreement) with our carrier. Generally, if you are getting your hosted VoIP service from Cox, for example, and your Internet connection is provided by Cox you will have a more predictable experience. If you are getting your VoIP service from the “The Big Box in the Sky VoIP Company” and it is delivered over a COX circuit, you will not have the same level of service. That is a fact.
Business continuity and disaster recover? Clearly, if you lose Internet connectivity, you lose everything. Hopefully your VoIP service provider continues to handle phone calls and allows you to re-route your phone calls to your cell phone! (Read, feature check list addition). Actually, this is one area in which I prefer to design with a “hybrid” approach. Regardless which solution you go with, I would argue that you need both Internet and Local Telephone lines. If the Internet goes down, you have your local telephone lines to fall back on. Like wise, if your local lines go down, you have your VoIP dial tone to make use of. The bigger issue is this: In a hosted or “virtual” solution where would you connect some local telephone lines for back up? Remember the “box” lives in the cloud!
The “hosted” world, both computer and phone, boast that virtualization will enable you to free yourself from maintenance, backup and some electricity! Not sure if I can buy into this, as we still have all that equipment onsite we have already outlined! Someone still has to take care of that equipment. Have you called your favorite credit card company lately? How was the customer service? So now that we have killed off our onsite tech support, we are going to bet that the hosted provider has a customer service organization that is more responsive to your business than your credit card company?
Application Integration? If you have unique applications, your “hosted” provider may not be able to accommodate you. Many can integrate with Salesforce.com but if you are using a proprietary Medical, Dealer Management, IVR, Predictive dialer or if you have extensive call center needs, this may be an area that will be a key determinant in your decision to host or own. This seems to apply to hosting your computer system as well. The more you move outside the basic Microsoft Desktop Office Suite, the more difficult it gets for “hosted” providers to accommodate you. You may also need to evaluate any regulatory “compliance” issues as they may also dictate what you can do in a hosted environment.
At the end of the day, VoIP over IP “dial tone” has some real value in either solution. You are able to get DID numbers form any geography around the country or around the world! You do not have to have a “hosted” phone system to get this functionality, however. We can bring VoIP DID lines into any telephone system, so that is not a determining issue. What then is the determining issue? If you think like we do, you want the best of both worlds! A hybrid solution! VoIP lines or SIP trunks, remote access for my mobile workers/branch office and back up telephone lines on the back end! I think the CFO needs to get involved here as there is no way that renting forever, can compete with the ROI of a equipment purchase!
Lately, we have been playing with a Windows based solution offered by 3CX. We remember the “UnPBX” products of the late 90’s early 2000! There were a few companies that tried to build PBX systems on Microsoft Platforms like Windows NT. Popular gateway cards were produced by companies like Dialogic and inserted on the back plane buss of a Microsoft engine. Unfortunately rebooting your phone system everyday was not received well and these products fell to the wayside. Our personal experience with COM2001, Alexis and Xantel were part of our learning curve! We approached the 3CX product with some trepidation because of these early experiences, but we were pleasantly surprised at how far this product had come. In the SIP world, it is not necessary to put gateway cards for analog or PRI connectivity in the Microsoft engine. You can use an external gateway of your choice or do a complete deployment using only SIP trunks.
The 3CX is a fully featured phone system with all the bells and whistles for a Unified Communications platform. It runs on the most current version of Microsoft Desktop or Server OS. For a small installation you can bring it up under Windows 7 using a small PC hardware platform. As the demand for redundancy, scale, backup and memory expand the Microsoft 2008 Server makes more sense. What impacted us the most was how easy the initial installation and system bring up were. With all our product evaluations we use these basic criteria:
Ease of Installation (qualitative judgement)
Administration Process (GUI or Command Line)
Phone Provisioning (automated or manual)
Feature Set and Licensing options
Automated Attendant and IVR functionality
Integration with popular CRM
Mobility Options (find me follow me)
Multiple Site and Remote User Connectivity
Call Center Options
With this list in mind, we would rate 3CX very high! The installation was flawless. We downloaded a free copy from there Webiste and later obtained a license key that opened up the full feature set. Within 30 minutes we had operational telephone extensions defined and working. We create SIP trunks to our provider and had outside dial tone connectivity as fast as we could complete the SIP trunk definition. We provisioned the first few phones manually, but later setup the appropriate profiles for auto provisioning. The 3CX was following the best practice of the big boys like CISCO and ShoreTel. Using DHCP options, we could stuff a new phone with its extension and feature set. We also brought up the 3CX soft phone application on an apple iPhone! Again, this was very straight forward and registration with the mothership and connectivity with the other phones was as straight forward as the implementation of an onsite wired phone.
The feature set covered the minimum daily adult requirement for phone usage. The advanced feature set was impressive. Call Queuing, recording and message notification options were all available to the individual users through a web based application. Each user had the option of bringing up a browser and having a visual call control application for their individual extensions. This was impressive, but the integration with Microsoft Outlook Salesforce and Exchange was equally available and effective. We noted a HTTP api that seems to enable integration with any application that supported web based CRM.
The Automated Attendant was robust, but our real focus was on tenant services. Many small business have multiple identities under one roof. If the client wants to be able to have one phone number answered by an Automated Attendant with a script for Company A; and another for Company B this simple requirement sometimes knocks out a contender. The 3CX handled this brilliantly and we were able to direct a caller to different Automated Attendants or Digital Receptionists based on the number dialed. You would think all phone systems can do this, but you would be surprised to find that many can not. We love the CISCO 320w, but if tenant services was a requirement, we would not be able to meet that expectation.
Mobility options enabled a caller to an extension set up with a “find me follow me” option to reach a cell phone. Again, this is a feature that is becoming an absolute standard for a VoIP deployment! 3CX was able to do this quite easily and also enable the individual user to manipulate these options without the need for the System Administrator. The last couple of steps we are just playing with and will report more as we explore the Call Center and Site options. Technically, we see no reason that we can not have remote users. The key issue is, can we plant a 4960 type PRI gateway at a remote location over a WAN and operate a remote trunk group. More on this later, but we are eminently impressed with the 3CX product and would recommend it for a small business deployment, or as a remote site for a large ShoreTel or CISCO deployment.
Interestingly the system is licensed not by features, but by simultaneous calls. A very interesting approach! You can set up a system with a 100 extensions, the issue is how many calls will the system allow. Do you license the system for a 100 calls? Not likely, but you would have to make a determination as to how many of your 100 extensions can be making use of the system at the same time. Generally, we like that licensing strategy. Other systems might be licensed based on the number of extensions. In a ShoreTel deployment, for instance, you would be paying some $20,000 dollar in license fees to bring up this 100 user deployment. Licensing based on simultaneous calls is an interesting approach and it is being adopted by most of the systems that are sold and supported by other than the freeware community.
At the end of the day , your Dad was correct when he said “you get what you pay for”. Yes you can download a free phone system from the internet. We should all thank Mark Spenser for the creation and contribution that Asterisk has made to the telecommunications universe. The derivations of this contribution are global! More an more new products are based on the core contribution that Mark has made. Unless you are a true phone geek and you want to play with Linux and Asterisk code all day, you are not going to create a scalable, supportable telecommunications platform without an organization to stand behind it. Yes community support is available, but at the end of the day, you want a 1-877-DrVoIP1 number available that is answered by a support organization that can be there when you need assistance. ( We have arranged some exciting packaged solutions with our partner VoipLink so see our DrVoIP Recommends section or click here for a sample http://www.voiplink.com/product_p/3cx-cisco.htm ).
We will continue to review the products we support! Our current list of supported products has now grown from ShoreTel and CISCO to include Digium, Elastix, Astrisk in general and 3CX when it comes to a Windows solution. If you are planning a VoIP deployment of less than 100 handsets, 3CX offers a fully feature Unified Communications solution at a price that is compelling!
Since we published the blog on the ShoreTel SIP implementation using Ingate, we have been deluged with requests for more detail. Specifically, people want to know if there is a more economical solution for bringing SIP dial tone into the ShoreTel architecture when you are trying to add just a few local lines to a branch office. Historically, given the feature depreciation that users might experience with a SIP trunk on ShoreTel, we had discouraged the adoption of SIP dial tone entirely! In fact, if you already have a ShoreTel T1/PRI supporting your deployment there is little economic benefit to be gained by replacing the PRI with SIP. After all you already own the PRI gateway and now you have to go buy an Ingate box. Might make sense for a new deployment, but it does not make since for an existing deployment or for adding just a few SIP dial peers at a remote office location.
Well then, what about, keeping the ShoreTel PRI but bringing the dial tone in over a SIP trunk?
The fact of the matter is, that many carriers do bring the PRI circuit in over a SIP trunk! They then run the circuit through a Integrated Access Device (e.g. IAD) that converts the SIP trunk to PRI and the resulting hand off to the ShoreTel is a traditional TDM flavor of PRI. This makes the carrier happy and the ShoreTel PRI continues to operate with no feature depreciation as everything from a ShoreTel perspective remains TDM! The original investment in ShoreTel equipment is protected and you get some of the benefits of having a SIP trunk like foreign DID’s and more fail over options.
This got us wondering if we could do the same configuration by rolling our own? We came up with two solutions.
First we created our own SIP Appliance using a low cost Linux box running CentOS and our favorite Asterisk dis tro, both of which are available as freeware. For the SIP to PRI configuration we added a Digium T1 card bringing our total hardware cost to less than $900 for both the PRI hardware and the Linux computer! Next we setup a simple T1 Tie line between the ShoreTel iPBX and the SIP appliance. We then created an IAX trunk to our SIP provider from the WAN side of the SIP appliance, assigned our DID’s to the SIP dial peer and we were up an running in no time! The configuration is a classic B2BUA and it works just like the carrier provided CISCO or Adtran IAD!
Next we set out to build a SIP solution that was a pure dial peer with no TDM hardware at all! Lets assume you have a remote branch office and you would like to provide a local DID for that branch. Using a SIP DID and less than $500 dollars worth of Linux computer hardware ( see our blog on the Shiva plug) you can easily make this happen. We used the same appliance we created for the PRI conversion, this time without the Digium T1 card. We specified the remote SG50 as the IP trunk source and terminated it on the SIP Appliance. Again we created a SIP dial peer from the Appliance to the SIP dial tone provider and assigned our DID numbers. It worked flawlessly as a simple, end point SIP dial tone solution providing local DID numbers to that remote branch office.
One of the challenges of ShoreTel is that the entire architecture needs to be described, from an IP topology, inside a private address space. That is why you can’t just interconnect a ShoreTel SIP trunk group with an ISP. When establishing your SIP Peer to your provider, you are generally going to link with a public IP address. Using our SIP appliance we were able to bring up a remote branch office with an end point that supported 4 SIP Peers and used a local DID for that branch. (ShoreTel SIP trunks are licensed in packages of 5, while all SIP dial peers provide dual channels?) Again, the SIP trunks between the ShoreGear SG50 and the SIP appliance was created completely within the required private IP address space, yet the appliance interfaced with a public IP address to create the multichannel SIP dial peer. The Asterisk configuration we created enabled us to configure on the LAN side of the firewall, yet specify a public IP address for the dial peer end point with no NAT issues to contend with.
At the end of the day, there are a variety of solutions for bringing SIP into your ShoreTel deployment! Sometimes the best things in life are free! We are no busy integrating the ViciDialer with ShoreTel to provide an enterprise class Outbound dialing solution for the contact center using freeware! More on this later……
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.
