In this blog article I will provide some best practices for deployment planning that our UC platform will need, to work as expected.
When a new UC system is installed, users will need to spend a considerable amount of time and resources learning how it works. It is crucial to reduce the impact of adopting any new technologies by avoiding user problems.
The most common issues I have witnessed are “regressions” in how the system works, particularly when compared to the previous system. Some examples include:
- Missing features (especially telephonic ones)
- Poor audio quality
- Fax machines not working reliably
- PoS connections not working reliably
What follows is an incomplete list of leading vendors who are using the main protocols described in one of the previous blog articles: SIP and XMPP. This list is based on my personal knowledge. I apologize in advance for any exclusions.
The goal is to provide material for further analysis by the reader.
Cisco was one of the first to embrace the potential of Unified Communication systems and open standards.
Cisco historically selected MGCP and H.323 as VoIP protocols. SIP was later introduced, first on endpoints and then on servers.
Jabber, Inc., is a provider of presence and messaging software. It’s important to note that Cisco has acquired this company not the open standard Jabber (jabber.org). Jabber, by that point, had already been renamed to XMPP.
In this blog article I will describe some essential characteristics that should be taken into consideration to evaluate UC platform.
Some UC solutions are still developed and managed without foreseeing a need for backwards compatibility. So, after a major upgrade of the platform, features might be removed.
A product should strive to protect the investment made by those people using the product, especially to minimize the work needed to maintain the product. After any major or minor upgrade, the old features should remain functional.
This logic must also be extended to hardware components (such as phones). For example, when the UC server platform is upgraded, support for existing hardware should continue.
It is acceptable for any IT solution to put an end-of-life date on a part of the system, but this information must be clearly published.
Whether you want to build a UC platform or choose one, pay particular attention to backward compatibility.
In the following article I will present a list of requirements that should help you in understanding which platform is better suited to an organization’s needs.
Number and Location of Sites
The quality of the connectivity is crucial for good voice and video service. Offices located in different countries or continents will most likely need separate local or managed UC servers.
What’s the size of each site? If the site is large and most communications are done within the site, a local UC server is often the winning solution.
A Unified Communication solution can be deployed either in an environment controlled by the customer, as a corporate data center, or in a third-party data center. Let’s review such deployment scenarios in more detail.
In most scenarios, a solution deployed in a cloud environment (such as Amazon AWS) offers the best overall conditions including easy redundancy, by relying on different physical data centers, and better connectivity, by providing worldwide data centers.
However, there are scenarios where an in-house UC platform can offer advantages over a cloud solution. When the UC services are accessed mostly by local users and using local PSTN trunking, a local deployment is the best solution. Another scenario might be a site with poor Internet connectivity where phone services must be provided.