SIP Trunking is not the answer
You might be wondering what the question was. Whatever question you can think of in unified communications (UC), [except for maybe “How can I get a cheaper PSTN connection?”], SIP Trunking is not the answer. It is certainly not the answer to inter-company communication with UC systems. Let’s take a quick look at SIP Trunking to see why.
The concept of SIP Trunking has been around for 6+ years as a mechanism for connecting a UC system to the PSTN. The notion back then was that, unless a UC system is connected to the PSTN it (UC) would only ever be an internal communications system, since there was no UC connectivity outside the enterprise (what we now know as ‘Federation’). And that was true…then. However, the options for PSTN connectivity now include the SIP to PSTN gateways, such as those offered by NET, Dialogic, AudioCodes, Cisco etc. which provide PSTN connectivity (and much more) with far less hassle. But what is this hassle that I speak of?
First of all, there are no standards for SIP Trunking. There is the SIPconnect v 1.1 document from the SIP Forum, but those familiar with that document will know that only 2 service providers (Skype and CableLabs) participated in the creation of that document: most of the contributors were UC vendors. Telephony Service Providers declined to participate in SIPconnect because they had no interest in creating a SIP Trunking standard. To this day, they all implement SIP Trunking in a different way, clearly creating an impediment to adoption. This is because Service Providers view SIP Trunking as cannibalizing their PRI revenues and adding to their costs: in effect, they are providing a PRI discount while providing the SIP-PSTN gateway at their network edge. Furthermore, any company that is looking for a SIP Trunk service has the option of connecting to any of a range of new service providers over the Internet. Since the Internet obviates the need for geographic proximity and ownership of the ‘last mile’ network, these services are instant commodities. The net result is that your traditional telephony service provider may grudgingly provide you with a SIP Trunk, but it will likely be unencrypted and insecure; and the proprietary implementation will require you to deploy a SIP-SIP gateway in any case to intermediate the signaling and media. That is the hassle I speak of.
If you just wanted to make a traditional phone call (which is what you are doing over a SIP Trunk) then you wouldn’t have deployed UC, you would have stuck with your PBX. However, you were excited by the vision of presence driven communications; of instant collaboration; of desktop video conferencing; all of these things from the location of your choice. That experience works ‘out of the box’ among your UC enabled colleagues on your corporate LAN – and you eagerly anticipate the day when it will work with your business associates in other companies over the WAN. However, if you are expecting that service to be provided by your traditional PSTN carrier, you are going to have a long wait. They tried, 10 years ago, to define an infrastructure for SIP-based multi-media communications in an architecture called IMS (IP Multi-media Sub-system) but it has failed and the telephony carriers are investing all their capital in mobile networks. The best they are willing to do to enable inter-enterprise UC is to convert SIP and RTP to a standard telephone experience and, per above, they are often unwilling to do that.
So, if you are interested in inter-company UC communications (and why wouldn’t you be after reading ‘How did we ever get by without Federated Presence’ or ‘Thousands of parts flying in close formation’) then you are probably seeking a different kind of service provider. Maybe you should take a look at NextPlane.