Although SIP Trunking is a growth business, the impetus to create SIP Trunking standards appears quite low and the rate of compliance with the standards that exist is equally low.

As regular readers of NoJitter know well, SIP Trunking has become a boom business for emerging service providers looking for a way to monetize the deployment of UC systems in the enterprise. For the incumbent service providers, the adoption has been somewhat lukewarm, as they tend to view SIP Trunking as:

* Cannibalizing their PRI Trunking business;
* Adding to costs by requiring them to host the PSTN to SIP/RTP gateway at the edge of their network;
* Creating competition that reduces margins because new market entrants can offer SIP Trunking service over the public Internet, thereby eliminating the advantage of the ownership of the "last mile network".

(To the last point, it could be said that the new entrants are getting a free ride on the networks of their incumbent competitors, but we will leave that "Net Neutrality" topic for another day.)

The State of SIP Trunking Standards
I last posted on NoJitter the topic of SIP Trunking interoperability last May, with an article on the ratification of the SIPconnect v1.1 technical recommendation from the SIP Forum. In that document, I outlined the pros and cons of this interoperability profile, specifically:

Pros:
* It was a comprehensive profile that addressed the needs of service providers and enterprise communications vendors alike.
* It tackled the thorny issue of preferred SIP transports (i.e. UDP, TCP and TLS) in an equitable manner that addressed the needs of all stakeholders while providing a clear direction for future standards and implementations.

Cons
* It left some important areas open as future work items, e.g. voicemail, E911, IPv6 support and FAX support.
* The service providers (other than CableLabs and Skype) had declined to participate in the standards process and were thereby "voting with their feet" on the result.

The original intent of the SIP Forum was that SIPconnect would be supported by the "SIPconnect compliant" self-certification process. However, in subsequent discussions with the vendor community and with the UCIF, the consensus is that a tested verification process is required to give customers confidence, and this is currently being developed by the SIP Forum. This conclusion is supported by the results of a SIP Forum survey on SIPconnect compliance, which is quite informative. Key points from that survey include:

* Of the 26 respondents to the survey, only 6 are service providers, the remainder being SIP equipment and software vendors.

* IETF RFC compliance was, on average:
--67% compliant
--9% substantially compliant
--12% not compliant
--13% "not applicable"

* Overall compliance was, on average:
--59% compliant
--9% not compliant
--32% "not applicable"

The glaring non-compliance areas included:

* Only 23% compliance with STUN RFCs, which enable media (i.e. voice codecs) to traverse NATs and firewalls; with 54% of respondents claiming that the standards did not apply to them.

* An average of 23% non-compliance with TLS as a SIP transport, which means that those noncompliant respondents are unable to support encrypted SIP traffic.

* 27% non-compliance with P-Asserted Identity (i.e. hiding internal extension numbers from external callers).

* 23% non-compliance on T.38 FAX support.

* 8% non-compliance on hold/unhold support.

* 12% non-compliance with DiffServ (prioritization of media packets).

Considering that the participants in this survey are the ones who are seeking SIPconnect self-certification (and therefore, we assume, are primarily compliant) these statistics indicate an overall lack of interoperability in SIP Trunking implementations.

IPv6 Support
In general, support of IPv6 from North American SIP Trunking service providers is low; whereas Asian service providers are forging ahead on IPv6 implementations. I currently only have anecdotal data on this: but intuitively it makes sense, as North America is the least challenged in terms of IPv4 address allocation. Asia, on the other hand, has only 18% of the IPv4 blocks assigned to it to accommodate 53% of the world's population. In terms of the rate of growth of Internet usage, Asia is probably the most in need of IPv6: indeed, the Asia Pacific region of IANA depleted its allocation of IPv4 addresses in April 2011.

Impediments to SIP Trunking Standards Adoption
In general, I believe that there is an inherent resistance to the establishment of interoperability in emerging technologies such as UC (see my No Jitter posting on "The Economics of Interoperability"). That being said, SIP Trunking is a special case in point since it appears to the customer as a "hub and spoke" network. However, the "hub" of the network is not the SIP Trunk service provider, it is actually the PSTN. Using the PSTN as the "lingua franca" for incompatible SIP Trunk implementations removes the requirement for "any-to-any" interoperability. When viewed in that light, the SIP Trunk "network" turns out to be just a series of "one-to-one" connections.

Of course, UC customers have to be able to make that "one-to-one" connection, but this turns out to be not only fairly easy to implement, it is actually a stand-alone boom business for a number of vendors:

* The service providers themselves (particularly the incumbents) who often require their own network element to be hosted at the edge of the customer network and charge for the usage of that element.

* SIP to SIP gateway vendors (typically the vendors of SBCs and Integrated Services Routers) who provide the network edge elements to those service providers or to customers who connect to service providers who do not require an edge element.

* Systems integrators and consultants who are hired to configure these edge elements.

Summary
Although SIP Trunking is a growth business, the impetus to create SIP Trunking standards appears to be quite low and the rate of compliance with the standards that exist is equally low. There are good economic reasons for this: particularly the lower margins that are gained by the incumbent service providers, combined with the loss of utility (see the survey and summary stats above).

The main driver for the adoption of SIP Trunking is clearly the discount that UC customers can get over PRI trunks, and this is driven only by the entrance of new competitors into the market.

At Enterprise Connect 2012 in Orlando, I will be presenting a session on "SIP Trunking Interoperability" (Wednesday, 3/28 at 3:45pm) where I hope to have more stats and further updates to report. If you are in Orlando, I would be happy to engage with you on this topic.