How do we get to a shared global communications infrastructure where the basic forms of communication (voice, video, messaging, and maybe presence?) can be expected?
First: where are we today?
Business incentives
Each enterprise or service provider has the freedom to implement any kind of rich communication service (mostly based on SIP with non-standardized extensions like Multiway that I mentioned in an earlier post). The problem is that the moment you get to the edge of the organizational boundary (another enterprise or provider), you need to get down to the least common denominator as the same functionality may be implemented differently. Currently, there is no real incentive for large providers “owning” enterprises to do rich SIP peering: they want to keep their current business models in peering as there are real financial benefits. And there is a lack of a market for peering where rich SIP-based functionality can generate revenue. As an example, XConnect started out as a “VoIP peering fabric” and attracted smaller VoIP players challenging the incumbents. Interestingly, they have moved more and more towards using their technology to enable private federations, and have introduced ways of tailoring the terms and policies related to the peering hoping to attract more traditional telco players.
Technology status
On the technology-level, there has been a gradual shift from TDM/SS7 peering towards also SIP-based peering. Partially, this is a cost-reduction measure where carriers move to all-integrated TCP/IP networks and partially it is a result of new voice entrants like cable operators and pure VoIP players. Most often, these peering relationships are protected by Session Border Controllers (SBC) and if you look at what is supported by the SBC vendors, the latest software upgrades are starting to allow flexibility on codecs, as well as making it increasingly easier to pass rich SIP functionality through. This is, however, very dependent on each provider’s policies and a very strictly configured SBC will stop any unknown SIP signalling or codecs from going through. Also, the versions running in production are likely a bit behind.
Technical sidenote (skip below to Standardization if not interesting):
Another interesting development is peer to peer SIP (P2PSIP). For quite some time it has been an esoteric activity with little real, commercial adoption (more sort of a Skype me-too). However, Cisco recently announced the Intercompany Media Engine (IME). Well, the main positioning is the IME as a device to securely bypass your PSTN trunk and instead send traffic over SIP. The second positioning is that by discovering a SIP path to another rich SIP client, you can do video and other rich SIP functionality. (Of course, this is only relevant if you are stuck in the old world and the only way you can address your video systems is to use a public e.164/PSTN phone number.)
However, more interestingly, the IME creates a global Cisco P2PSIP search cloud where the IME registers all the SIP URI addresses in the cloud. From a PSTN bypass point of view, this is good, you bypass ENUM lookups that don’t really scale in this scenario. However, from a SIP point of view, the only thing you have done is to replace DNS lookups (which is an address hierarchy where a given domain @example.com needs a home server common to all @example.com addresses) with a flat address space where addresses can be served from any server in the global search cloud.
What does this do for peering? Well, you might imagine two or more companies creating their private search cloud, or providers using IMEs to create private peering clouds, or maybe that Cisco opens the IME P2PSIP search cloud for other products competing with the IME, thus de facto creating an open Skype…
Standardization
The SIPConnect standardization effort is focused on standardizing the interface between a corporate PBX (Private Branch eXchange) and the provider, i.e. a SIP trunk, simplifying buying SIP trunks from providers . This effort has seen quite a lot of adoption and v1.1 is in the works. Still, video, presence and other rich SIP functionality is out of scope.
The IETF SPEERMINT working group has SIP Service Providers and SIP trunking, as well as peer to peer peering within scope. However, the concern is that the output will be too generic and thus not help too much in establishing true interoperability for core rich SIP functionality.
Of course, IMS/TISPAN must also be mentioned as these frameworks allow inter-domain exchanges. The dream for some service providers was that also enterprises would connect to the rich SIP-based networks using IMS/TISPAN. However, it seems that getting any type of application-layer functionality to fly is difficult enough within a network, and crossing organizational boundaries seems not to be the priority.
Finally, there are other standardization efforts like OSP, the Open Settlement Protocol, which is focused on the practical exchanges needed to authenticate and authorize usage (not only SIP-based) across provider domains.
Where to go from here?
Tandberg, as an example of a vendor of rich, SIP-based communication functionality, would greatly benefit from a market for connecting companies (and consumers) to each other with far richer functionality than you have on the old PSTN and current SIP-based peering arrangements. It is my belief that there is an absolute need to make new (and old) business models work in the market of connecting companies and individuals to each other. I am also convinced that there is real money to find in this market. Incumbent service providers have an opportunity, exchanges enabling private enterprise and provider peering have an opportunity, and finally, there is huge potential market in providing rich SIP-enabled services in cross-sections between organizations.
Who knows? Video to companies and to individuals has really started to roll and may turn out to be the key customer desire that will kick-start the market of rich SIP peering!
RSS - Posts