The Future of Communications, Part 3: SIP Federati

For a while now, setting up SIP for voice to the outside world through these amazing SRV records has been kinda like being the first person in the world that owned a fax machine:  They probably did not get very many faxes, since there weren’t any other machines out there to send them anything.  

The idea of communicating to an organization outside of your own is called “federation”, which is defined as the joining of two distinctly different networked systems.  The need to connect one domain to another first arose because of the desire to share Instant Messaging services between organizations.  From this, we are seeing two divergent philosophies around federation.  The first is the idea that not just anyone should be able to federate with my domain.  A user in my domain should make a request for the federation, and the systems administrators can work with the systems administrations of the other domain to set the relationship up at the server level.  The second is the idea that my domain is open to anyone that wants to send me an instant message, voice, or video call.  

The open federation model is more along the same philosophical lines as email and SMTP, but creates the possibilities of voice or video spam, unwanted calls by telemarketing fir...wait a minute, we already have these things on the PSTN!  Can you imagine if early within SMTP’s infancy we had adopted the “manual federation” mentality? That protocol would have been worthless if it couldn’t have scaled with the growth of the internet.  Sure, we got spam out of it, but there are always going to be people who abuse the system that’s in place. Our world has been transformed by email and instant communication worldwide, the same way that the world was transformed by the telephone back in the late 1800’s.  It’s only logical that we take voice communication to the same level that we have email and video conferencing, ubiquitous B2B voice calls over SIP.

Another reason to take B2B SIP voice seriously is that we aren’t going to have the PSTN forever, at least not in its analog and TDM forms.  Efforts are underway to establish what the next phase of the PSTN should look like, and by all accounts SIP and direct IP-to-IP communications are the forerunners in the options race.  There have been a lot of dates thrown out for this “refreshing” of the PSTN, some as early as 2015, some as late as 10 years from now.   One thing's for certain, the carriers will try to push for a solution that is going to maximize their profits and burgeoning monopolies (good article here).

I believe it’s up to IT departments everywhere to move the companies that they support into the new age of voice communications with SIP.  This doesn’t necessarily mean ripping and replacing existing infrastructure, as SIP can be added to existing PBXs through IP-to-TDM gateways that do the protocol and medium conversions, all while preserving the dial-plans in place.  This can be taken further and setup in your DMZ to enable SIP calls to your organization by using the directory number @ domain name notation.  This of course, is a one-way solution, since legacy PBX phones can’t dial SIP URI’s, but it’s a start, and it keeps the phone companies out of at least some of your voice calls.  The ideal solution would utilize a modern IP PBX like Cisco’s Unified Communications Manager or Microsoft Lync, both of which can federate with outside organizations. Beware though, Microsoft Lync philosophy to the core is vendor lock in, so the use of standards based protocols are few and far between.  

We are at a crucial time for the evolution of communications worldwide.  I believe the pieces are there to make rich media voice, video, and text communications operate just like email, in a decentralized, highly effective network of individually controlled servers and appliances.  Whatever solution you are considering, make sure that the manufacturer actively supports B2B SIP or at least has it on a near-term roadmap, and operates in the realm of Internet standards.  Proprietary solutions may work better in one or two silo areas, but overall, the vendor lock-in will restrict your flexibility and interoperability to the outside world.   If you want some help wading through the options available to you, talk to your local trusted VAR that specializes in Unified Communications, or find a good freelance consultant that knows this stuff.  Thanks for reading!

The Future of Communications, Part 2: Can you see me now?

This is a continuation from Part 1 of my series, The Future of Communications.

Let’s shift gears away from voice for a bit, and talk about video (don’t worry, we’ll come back to voice).  Video Teleconferencing or VTC has been around since the 1980’s in practical form, utilizing the ISDN networks built by the carriers in anticipation of the “digital age” of communication.  When data networking became prevalent in the 1990’s video teleconferencing was one of the first communications methods to utilize the technology.  At the time, video conferencing over ISDN was extremely expensive, and required dedicated ISDN circuits to communicate with outside organizations.  It turned out that the Internet was a lot cheaper to use, which by then most larger businesses were connected to.  In the early 2000’s, H.323, a protocol born out of the ITU, was used by VTC manufacturers to connect disparate video units together.  The challenges with H.323 were many, chiefly among them the complexity of the protocol meant implementing it was not for the faint of heart.  The shift to SIP started to happen in the mid-2000’s, when video teleconference manufacturers started including SIP software support in their endpoints and infrastructure components.  

The ability to scale SIP the same way that SMTP had been scaled is what set the SIP protocol fire ablaze.  SIP was developed with the expectation that DNS would be used, specifically service, or SRV, records in order to provide a dynamic way to establish sessions to known internet domains, and subsequently, servers owned by those domains.  Here’s what a sample SRV record for SIP looks like:  

_sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com.

In this example, an initiating SIP server or proxy would make a DNS query for the example.com domain looking for what server and port to send a SIP INVITE message.  In this case the server is sipserver.example.com on TCP port 5060 (the standard unsecured SIP port).  Using this method VTC manufacturers could scale multiple VTC units inside an organization, without having to assign a public IP to every single unit.  A simple Uniform Resource Identifier, or URI, could be used to identify individual endpoints.  Much like an email address, a URI consists of a username, the @ symbol, and the domain name.  For example, a screen in the boardroom of Example.com might be named boardroom@example.com, and could be called using this simple, easy to remember URI.  

This exact same capability exists for voice calls, however the implementation of SIP in the enterprise has been focused on the station (phone) and trunk (carrier) side, rather than the Business-to-Business (B2B) possibilities.  I’d say that I blame carriers for this, but in the end, we all know what their motivations are, and shouldn't be surprised by their greedy natures.  Carriers hate the idea of losing out on revenue streams, and while these same carriers can also provide data services to run SIP calls over, currently they charge for both.  The same can be said for carriers that also have a cellular business, as voice plans still cost more than data plans (don’t even get me started on texting).  If B2B SIP calls were more common, carriers would start to lose out on these revenue streams, because SIP calls are run best over more reliable (typically) higher bandwidth WiFi networks.  At the end of the day, the advancement of B2B SIP falls squarely on the shoulders of the corporate world, or the users of the equipment that could enable this capability.  If we complacently continue to accept what options we are given, instead of demanding that we want change in the way our communications work then this situation with the carriers is going to continue, and the “communications mafia” is going to keep collecting their monthly check from you.

Part 3 coming soon!

The Future of Communications, Part 1: In the beginning was the phone, and the phone was without dial-tone.

One could argue that the telephone paved the way for modern society as we know it, connecting friends, relatives, co-workers, employers, and employees in ways never before seen in human history.  We've all essentially grown up on the telephone, talking to our distant relatives when we were kids, or as teens sneaking to stay up late talking to the opposite sex.  In the last 10 years, we've witnessed the explosion that has been the cellular telephone industry, and coupled with that, the improvement in the technology of the handsets themselves, marrying telecommunications and computing capabilities.  The times, they are a-changin'.

Much of the hoopla (technical term) over the past few years in the telecom industry has been over the concept of Unified Communications, which is essentially just the idea of running voice services over a data (or Internet Protocol) network.  While the carriers have been doing it for years, this more recent push for Voice over IP (VoIP) has been typically seen as something done within an organization, utilizing a company’s already in-place routing and switching infrastructure, and even extending voice and IM services to those über intelligent mobile handsets.  Voice services to the outside world have always been provided by the archaic, limited in function, soon to be obsolete Public Switched Telephone Network (PSTN).

Modern phone companies can trace their roots all the way back to the invention of the telephone in 1875 by Alexander Graham Bell.  The technology has evolved, but the basics remain the same.  You pick up the receiver, and you end up talking to someone on the other end.  The modern PSTN utilizes a numbering plan that allows for regional phone companies to facilitate easy, operator-less calls between parties.  This includes the intra-country dial-plan, as well as allowing for interoperating with outside countries via country codes.  For example, in the US our international dialing prefix is 011, which we follow with the country code, followed by that country’s dial-plan.  For instance, for me to call the office of the City of Melbourne, Australia, I would dial 011 61 3 9658 9658.  There will be some pricey international charges for that call, as the phone companies bill customers back for long distance and international calls.  This has led a lot of businesses to restrict who has access to dialing internationally from their PBX.

What if I wanted to send an email to a friend that lives in Australia?  Well when I click "send", my mail server fires up a request to the local Domain Name System (DNS) server to see what Mail eXchange (MX) record exists for the domain name used in my friend’s email address.  Once my mail server knows the address, it sends the email to the Simple Mail Transfer Protocol (SMTP) service running on port 25 on the destination server, and voila! the email is delivered.  Have you ever stopped to ask yourself why we don’t pay for international email charges?  Quite simply, the internet was designed as a foundation for whatever services and protocols that clever, inventive computer scientists could dream up.  Email just happens to be one of them.

As it turns out, there’s another protocol out there capable of doing the exact same thing that email does, but for voice communication.  Session Initiation Protocol (SIP) was designed to mimic that same decentralized session establishment that SMTP utilizes, but for any type of interactive session.  This has led to the use of SIP for myriad of different services, such as video, Instant Messaging, and especially voice communication, since voice is one of those legacy technologies that was due for some market disruption.  SIP was created back in 1996, and ratified in its current iteration in 2002.  SIP came out of the Internet Engineering Task Force (IETF), as opposed to the normal batch of telecommunications protocols, which are controlled by the International Telecommunications Union (ITU).  This highlights a very key point in our story, which is that SIP came out of the standards body responsible for the protocols that run the Internet, not the one made up of all the world’s phone companies.  Thus, the focus, intent, and application of SIP has typically come from companies like Cisco, who at their very core are Internet Protocol dependent.

One of the biggest challenges with SIP early on was that the original standards documents (called RFCs, or Requests for Comments) left a lot of room for interpretation in implementing certain features.  I called SIP the Subject to Interpretation Protocol for years, having seen first hand all the challenges with interoperability of various products and services.  With SIP coming into its prime in the last 5 years and telecom manufacturers developing very effective methods for accounting for operability, telcos have started offering SIP-based trunking services to businesses all over the world.  This is a great thing for the enterprise, the small and medium business, and especially the phone companies.  They get to remain the voice clearinghouse, charging for access fees, international calling, and of course, benefiting from those pesky billing mistakes that always manage to sneak past accounts payable departments everywhere.  

Part 2 coming soon!