This is an ever changing world we live in. Not that long ago we were communicating by sending mail one to another (not talking e-mail here). As romantic as it sounds, it’s quite a process to be able to exchange a piece of information between two parties.
With technology evolving into its modern state, we now have the luxury of entire army of different ways to communicate. What’s your fancy: typing, talking, or maybe both at the same time? Do you want to keep it private, talk to a group of people or let the whole world know about your thoughts?
Of course, we are all about having different options. And what goes hand in hand with options - decisions. Don’t you just hate those? So am I. And that’s why I am highly appreciative of the UC (Unified Communications) world and its capabilities. Suddenly, I am no longer obligated to make a choice.
I am taking part in a meeting, reading emails, chatting with my colleague, and reading a voicemail (yes – no mistake, reading!). All real, all true, all at the same time.
Sure after reading this yapping of mine, you jumped online in search of suitable UC solution for your company… Not surprisingly you chose the Lync Server. After all, your IT infrastructure is 90% Microsoft based platform. You are very familiar with the underlying technologies, such as: Active Directory, Exchange, and others. The learning curve is relatively easy, and in no time you’ve got your-self fully functional UC product. Your boss loves you, colleagues complement for the brilliant idea. The world is an awesome place to liveJ. If only, you could get rid of those old desk phones and that dusty PBX device you are afraid of touching (it just might die if you will).
Well, the good news, you can! Also, you don’t have to spend tons of money to do that and … very important, you can play and test as much as needed without risking your existing setup all at once. Oh, and remember those huge conferencing bills in your IT budget? How about cutting those by about 50%?
The answer is deploying a SIP trunk, connecting your Lync infrastructure with the big outside world of telephony.
And what is that magical thing called “SIP trunking”. In few words, SIP trunking is a cost effective alternative for connecting an IP based PBX (Private Branch Exchange) to PSTN (Public Switched Telephone Network) compared to traditional methods such as BRIs (Basic Rate Interfaces) or PRIs (Primary Rate Interfaces). SIP trunks are being used by different PBX platforms out there; Lync Server being one of them.
There are other ways of getting out there, though for the purpose of this discussion I will focus on the SIP trunk method.
I will not bore you will all the technical aspects and details of deploying the SIP trunk. You probably well aware of MS TechNet, it will provide with all the information you need and more. There are also tons of articles out there that simplify various deployment scenarios and supply with step-by-step instructions.
Instead, I would like to focus on choosing the right SIP trunk provider or ITSP (Internet Telephony Service Provider) aspect. After all, this is a huge decision. You are giving a third party vendor big portion of the control over your external voice capabilities. My advice is to make sure the vendor of choice answers to all technical and non-technical requirements of your organization before signing an agreement. In a way the situation is very similar to choosing an ISP.
There is an authorized vendor list published at http://technet.microsoft.com/en-us/lync/fp179863. I would say this is the right place to start the hunt.
So let’s cut to the chase. What are you looking for in an ITSP?
There is no simple answer to that question. What might work for one company could mean a disaster for another.
Recommendation number one is to compile a list of technical requirements for the SIP trunk:
- Number of channels (maximum concurrent calls)
- Number of DIDs (Direct Inward Dial)
- Monthly usage in minutes
- Type of calls and their breakdown (incoming, outgoing, local, long distance, international)
- Preferred connection method (VPN, SBC, NAT, MPLS)
- Business requirements (internal toll free numbers, geographical distribution, 911 service, etc.)
- SLA requirements (up time, high availability and redundancy)
Those will play a big role in your final decision. Additionally, you should be able to use gathered information to assess whether your own networking infrastructure has enough capacity to establish a SIP trunk.
Once you are well aware of the technical requirements you can start short listing potential candidates. These are the criteria’s to judge by:
- A. Connection method
Not all vendors support all types of connection. This should be one of the first questions to ask an ITSP. For example, you have decided to go with site-to-site VPN connection type for security reasons. If the vendor doesn’t support such connection method you can probably skip to the next one on your list.
- B. Redundancy and high availability
Different companies will have different requirements for high availability and level of tolerance for an outage will vary as well. In case, SIP trunk is being used as a supplementary way of communication, it might not be considered as critical service by some companies. While in other scenarios losing external voice functionality over SIP trunk could translate into loss of revenue and have serious impact on the business.
Things to look for from the provider:
- High availability capability when multiple Lync Mediation servers (pool) used within the same trunk – This will ensure continuous operation in case one of your Lync servers is down (of course you will need to have more than a single Lync server to begin with).
- Local redundancy at ITSP datacenter – Presence of backup firewall, router and other equipment to provide with minimal downtime in case of a physical device failure. You should also enquire if there is a proper disaster recovery plan in place, and when it was validated last time.
- Inter-site redundancy – Some ITSP’s will have a second site that will be activated in case of primary site failure.
- Number of carriers – ITSP’s use carrier/s to obtain physical access to PSTN, obviously vendor with single carrier configuration has higher chance of failures communicating to PSTN.
- C. Pricing
There is no getting away from the financial aspect of any technical decision. The chances are you will need to explain to company’s CFO why one provider makes more sense over the other; especially if you will pick the pricier option.
There is no magic ball here, and some financial assessment should be produced based on the technical requirements you previously gathered.
SIP trunk providers will have different plans and options. They will be based either on number of channels, number of users, or amount of minutes. Plans will come with various fees such as long distance calls, international calls, 911 service, toll free number, etc. Some of the fees might be one time only, while others will be reoccurring. You should account for that and have an idea on the initial cost and monthly cost for the trunk.
Using technical requirements you should be able to find the most appropriate plan that works best for your company.
- D. Support
With technical and financial points out of the way, we can now concentrate on more personal side of your ITSP search.
No matter which provider you have chosen it’s pretty much guaranteed there are will be some issues encountered either during the initial deployment or down the road. Some of those might be related to ITSP side setup and some might be caused by improper configuration internally. While no one can anticipate all possible scenarios, you should do a proper investigation of vendor’s support capabilities.
Here are the things to look for in an ITSP:
- Support Centre hours of operation – 365x24x7 support would get my vote.
- Ticket response time – This one is self-explanatory. When your phone system down, you need some-one to work with right now, not in 4 hours.
- Ability to provide with detailed information for each call placed through the trunk, such as packet trace – This could come very handy when troubleshooting an issue, and can be very frustrating to be unable to receive any information from the vendor.
- Level of expertise – It’s very important to have knowledgeable support engineer on the other end of the line when working on a production issue. My preference would go to support personnel who on top of voice/networking experience had sufficient exposure to OCS/Lync integration. This would probably make your life easier and will save you some time explaining things.