Enterprise Connect is a just a month away, and I am in the process of putting the final touches on my Understanding and Leveraging SIP for your Enterprise presentation. With me, it's always a balancing act between down-in-the-weeds protocol geekiness and enterprise solutions. While I admit to favoring the former, I realize that technology without practical applications is purely academic. So, as much as I would love to spend the full hour and forty five minutes of my session talking about SIP headers and the mathematics behind audio codecs, I am certain that I would drive away 95% of my potential audience.
In my third pre-session teaser, I want to spend some time on a subject that straddles the line between solution and technology. This will allow me to write about some very important high-level SIP components while still getting my protocol fix.
Every enterprise-grade SIP solution consists of a number of servers and their associated services. It's not enough that an endpoint knows how to format, parse, send, and receive SIP messages. A true solution requires external components in order to validate user authenticity, apply call admission control policies, encrypt and decrypt signaling and media, route messages, enforce security, and a host of other network services.
If you were to read through the SIP specification, you will find many references to proxy servers, redirect servers, SIP registrars, and back-to-back user agents. With the possible exception of the redirect server, these are the main network components that appear in every enterprise SIP solution. Without them, you have endpoints that don't know how to communicate with other endpoints and huge gaps in security that would undoubtedly be exploited by hackers and thieves.
While vendors will apply their own product-specific names to these services, functional instances can be found holistically by vendors such as Avaya, or they can be assembled from various manufacturers to create complete solutions. While single vendor solutions have their attractions, best-of-breed approaches are extremely common and often the right course of action.
As it is with all things digital, these SIP services are being delivered as appliances and through virtual instances. While the appliance version of a particular service may be necessary to ensure the correct feature set and scalability, its virtual counterpart can often deliver the same functionality in a form more suited to a datacenter architecture.
The SIP proxy may be the most important of all the network services. Simply put, its job is to move SIP messages from one place to another. It might make adjustments to those messages along the way and act as an application server as well as a SIP router, but that's not a requirement. As a proxy, moving those messages around is its primary raison d'être.
Proxies typically enforce authentication by challenging users to prove they are who they say they are. This is done by rejecting a SIP message with a "407 Proxy Authentication Required" response. Upon receipt of a 407, a client will resend the original message with a WWW-Authenticate header containing the proper credentials. These credentials are typically a user's ID and encrypted password.
In nearly every case, a SIP Proxy is only concerned with signaling messages. Media flows around a proxy. This allows proxies to be fast and highly scalable.
An example of a SIP proxy is the Avaya Aura Session Manager.
The SIP Registrar associates a SIP Address of Record (AOR) with an IP address. This identification tuple is stored by the registrar and made available to SIP proxies as they route messages. With this mapping, my SIP name, SIP:[email protected], is reachable without the caller having to know my IP address. In fact, requiring people to know my address is not only cumbersome, but a security problem. Some things need to be kept private.
All registrations have a shelf life, so it's necessary for endpoints to periodically refresh theirs. Registration and re-registration are both accomplished through the SIP request, REGISTER. Similar to what I described earlier in this article, every REGISTER message will be authenticated to ensure the identity of the sender.
It's not uncommon for SIP proxies to implement registrar functionality, but the SIP specification allows registration to exist as a separate service. The previously mentioned Avaya Aura Session Manager is an example of a proxy/registrar combination.
Commonly shortened to B2BUA, the Back-to-Back User Agent is similar to a proxy, but rather than simply forwarding messages along, the messages are completely regenerated before sending them to the next hop. This enables functionality such as deep packet inspection, network address translation, topology hiding, call admission control, and service building.
The most common instance of a B2BUA is the Session Border Controller (SBC). An SBC sits between private and public IP address spaces. It acts as a SIP traffic cop by only permitting authorized and appropriately modified SIP messages in and out of an enterprise's network.
The last major SIP component is the redirect server. A redirect server is similar to a proxy in that its job is to route SIP messages, but it goes about it in a completely different fashion. Rather than sending messages on to the next hop, a redirect server returns routing instructions back to the message senders. These instructions, in the form of a SIP Contact header, allow the sender to do the actual routing.
The beauty of a redirect server is that it can process a message, return the routing instruction, and then forget about it. This statelessness allows redirect servers to handle large amounts of traffic in the least amount of time.
A redirect server uses the SIP responses "301 Moved Permanently" and "302 Moved Temporarily" to implement message routing. Both of these responses will contain a Contact header that contains the address information of the next hop.
A common use for a redirect server is that of a centralized network dial plan server.
Despite the fact that SIP began its life at the University of Columbia as an academic exercise, it quickly evolved into enterprise and carrier-grade architectures and the services highlighted in this article exist in both places. In my mind, this proves the highly adaptable nature of SIP and ensures its role in communications for a long time to come.
See Andrew Prokop at Enterprise Connect 2016, coming March 7 to 10, in Orlando, Fla. View the conference program here, and register now using the code NJPOST to receive $200 off the current conference price.
Andrew Prokop writes about all things unified communications on his popular blog, SIP Adventures.
Follow Andrew Prokop on Twitter and LinkedIn!
@ajprokop
Andrew Prokop on LinkedIn
Tags:
Articles You Might Like
