Communication Modernization: Migration to SIP Endpoints

Continuing our discussion of Communication Modernization from my last post, I want to talk about migrating to SIP endpoints. What about SIP trunks, you ask? I’m not sure I’d consider SIP trunks a “modernization” thing anymore. Many made that switch a LONG time ago—it’s a complete no-brainer for most customers that I deal with. Reduce hardware, decrease cost, increase flexibility, easier redundancy… what’s not to love? No, instead I’m talking about hardphones and softphones. Using SIP as the signaling protocol is almost always the right answer. Let’s talk about why.

Seamless Mobility

From a user experience perspective, that mobile-first, always-on, always-available, no-matter-where-I-am experience is something that every end user wants. They don’t want to have to think about the technology in order to make it work. The idea of having to launch a VPN client to enable access for communication applications (or any application, for that matter) is a very old-school way of thinking. No one ever approaches this like, “You know, I think Linda is going to call me, I better launch my VPN client.”

Moving from device-based security to application-based security is the way to accomplish this type of seamless mobility. It plays directly into the Zero-Trust model that so many organizations and vendors are adopting. Trust no one. Trust nothing. Assume worst case. Administratively, it’s actually very liberating. I no longer have to care where a user is. I no longer have to care what client or device they happen to be using. I can adopt a company-issued-device model or a Bring-Your-Own-Device model. It just doesn’t matter. SIP is designed for this approach. H.323, or any of its proprietary variants, is not.

End-to-End Encryption

While this item is one of the technical enablers of my first topic above on Seamless Mobility, I want to call it out specifically because it’s a big deal. And it’s a topic that gets brought up a lot in my conversations with customers. Besides client-based VPNs being a pain for end users, they aren’t nearly as secure as people think. Don’t get me wrong, the VPN tunnel itself is very secure. But it’s only the VPN that’s secure. The traffic that entered the VPN tunnel and the traffic that exits the VPN tunnel is not secure. That’s pretty much how VPNs became popular to begin with. They let you put a band-aid on legacy applications that don’t know how to encrypt themselves over the network. With a VPN, you can just send those unencrypted packets to the virtual network interface of the device, where the client will encrypt that traffic and send it to the VPN concentrator at the enterprise. At the VPN Concentrator, it decrypts the packets and lets it loose on the network. This means that the traffic is unencrypted everywhere else besides the VPN tunnel.

Sure, it’s possible that the traffic entering the VPN tunnel was already encrypted before it hit the VPN—but that’s got its own set of issues. You’re encrypting encrypted traffic, adding overhead, and completely obscuring details of the packets, making it completely impossible to do any type of inspection for routing, prioritization, or security purposes. In fact, a common issue for voice buried in a VPN tunnel, is the obscuring the QOS tags contained in the packets themselves. Sure, you might have correctly tagged your voice packets with a DiffServ value of 46, but your routers will never know that, because they’re buried inside of a VPN tunnel that the router isn’t able to inspect. SIP uses TLS, the tried-and-true method of encrypting traffic over unsecured networks, like the internet. Encrypting packets with TLS is the responsibility of the originating and terminating applications (client/server) that created the packets to begin with. These packets are born encrypted. This gives us true end-to-end encryption all the way through.

Multi-Device Access

Here’s another great techy topic that has HUGE benefits for end users. For mobile UC applications, end users don’t want to have to log out of one client/device in order to log into another. This concept even applies to users that aren’t considered mobile in the traditional sense. Almost all users aren’t sitting in one spot all day long. Even getting up from your desk to get a refill on your coffee makes you a mobile user. To know that you’ll have access to your communications, without having to reconfigure something, is also very liberating.

Again, if a user has to think about what it takes to enable their communications, or be responsible for making changes in order to stay connected everywhere, they won’t do it. They need all of their devices to be connected all the time. In an H.323 world (or TDM, for that matter), none of that is possible. SIP is a very different story. The SIP standard, as defined by IETF RFC 3261, has inherent capability for vendors to implement support for “parallel forking.” If implemented, this lets users leverage multiple devices simultaneously. They can place and receive calls on any of those devices and can move calls between devices as needed. Once you use MDA, you’ll wonder how you ever survived without it.

Active-Active Registration

This is another topic that an end user would never think of as a “feature,” but it enables what they absolutely demand, which is reliability. They want the system to work all of the time, with no down-time, no matter what. H.323 can’t deliver on that the same way that SIP can.

H.323 uses a concept known as Gatekeepers and Alternate Gatekeepers. It’s the registration and signaling connection point. An H.323 device is ONLY registered to a single gatekeeper, with a list of Alternate Gatekeepers that can be used as backup. But failing over from your connected gatekeeper to an Alternate Gatekeeper isn’t instantaneous. It’s generally a failover measured in tens of seconds, unless of course the outage is significant enough where I have to let other components failover first, before those Alternate Gatekeepers even become available.

Admittedly, we tend to brush it off as, “Even based on traditional Erlang theory, it is statistically unlikely you’d even notice it.” Active calls generally aren’t affected by a failed gatekeeper, since gatekeepers and media resources are usually two very different components. Gatekeepers are for signaling ONLY. The actual voice is handled by a separate media service. BUT, if you do happen to need to make a call (or change an existing in-progress call), it’s not going to work if it hasn’t finished failing over to the alternate gatekeeper. SIP, on the other hand, supports full simultaneous registration to multiple Registration/Proxy servers (think of those as the SIP version of Gatekeeper). Failover is much more seamless and gives your users the reliability they expect.

Vendor R&D Investments

Most vendors are focusing the majority of their R&D efforts on SIP. SIP gives so many more options simply due to the flexibility and extensibility of the protocol itself. So, when the protocol becomes the obvious step forward, it becomes the de-facto standard platform upon which to add new features. Some of those new features simply aren’t possible with older protocols like H.323, but a lot of the features would work on both H.323 or SIP, but vendors have started ignoring H.323 completely. They are only adding the new features to the “going forward” protocol. We’re seeing that a LOT with the vendors we work with.

No, I’m not seeing H.323 going away, or being unsupported in the near future, but it’s obvious most of the new innovation we’re seeing is only functional with SIP endpoints. Most vendors’ H.323 endpoints haven’t seen new features in years. H.323-based clients and devices are looking pretty stale when compared to the great stuff that has been added when using SIP. In addition to the devices/clients themselves, we’re also seeing significant changes in core architecture associated with the clustering and load-balancing of services needed for resilient enterprise, private, and public clouds. And those things are ONLY available when used with SIP endpoints. H.323 endpoints/clients, while still supported, will not be able to leverage the benefits of these new architectures.

As you can see, there are a lot of reasons to migrate to SIP. At ConvergeOne, when we did our internal Consolidation, Modernization, and Automation project for our own communications infrastructure, migrating everyone to SIP was a critical component to achieving the business requirements and end-user experience goals we had established.

When you consider a modernization initiative, you really need to think about moving to SIP-based endpoints. ConvergeOne is not only living this model ourselves, but we’re REALLY good at helping you live that model, as well.

[WORKSHOP] CREATE YOUR PATH TO MODERNIZATION

Understanding your unique business goals is the first step in outlining the right path to modernization. With ConvergeOne's team of experts, we'll use our best practices to ensure you have a vision and strategy to execute your modernization journey.