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!