Session initiation protocol (SIP) trunking is an oxymoronic catch-all phrase used to describe a set of services that is rapidly growing in market demand in the commercial services sector. A trunk is known in telecom parlance as a single circuit between two telecom devices. SIP supports one-to-one, one-to-many, and many-to-any connection with no limits to how many individual sessions can be established within an individual connection.
That clarification aside, there are implementations that work well to replace legacy trunk services for small to medium businesses (SMBs), defined as fewer than 100 users, as well as large enterprises with distributed geographies. In this discussion, we will address the range of things collectively known as SIP trunking and break them down into their functional classes.
The first application to be discussed for SIP trunking is one that is utilized by carriers and generally not sold as an end-user service. I will refer to this use as route proxy. Within carrier networks, large volumes of voice traffic can be more efficiently transported through the network by using time division multiplexing (TDM)-SIP gateways to bypass the public switched telephone network (PSTN). (See Figure 1.) Cost efficiency is achieved by minimizing the use of carrier-to-carrier TDM handoffs and transport over expensive TDM transport. Telecom technologists predict that over time, Internet protocol (IP)-to-IP interconnection will surpass and eventually replace TDM interconnection.
A derivative of the route proxy is a peering arrangement. (See Figure 2.) Carriers may agree to exchange traffic or services at the voice over IP (VoIP) level, again avoiding the PSTN.
The SMB revenue opportunity for cable operators lies in the domain of SIP trunking for end users. Generally speaking, there are four distinct variants of this opportunity: hosted voice, primary rate interface (PRI) circuit replacement (or T-1 over HFC), IP Centrex, and SIP trunking to IP-PBX (private branch exchange).
Beginning with hosted voice, the business application is a PSTN telephone line replacement service with a user telephony feature set similar to PacketCable 1.5. It also provides Web-based service management capabilities normally only available to businesses that possess a PBX. Many of the service management capabilities available are superior to what exists on legacy PBXs. The customer premises device is an embedded digital voice adapter (EDVA), more commonly referred to as a SIP embedded multimedia terminal adapter (EMTA). PacketCable Multimedia (PCMM) dynamic quality of service (DQoS) is used in this configuration. The delivered voice capability is an analog phone line, and traditional telephone handsets can be used. (See Figure 3.) Cox initially investigated delivering this service type with a DOCSIS cable modem and standalone ATA, but found the QoS and device management challenges too difficult to overcome.
ArrayT-1 over HFC
The second area of strong demand is for T-1 over HFC or PRIs to serve legacy PBXs. In this case, the customer premises device is a DOCSIS cable modem and an integrated access device (IAD). The delivered service is the PRI. (See Figure 4.) PRIs are traditionally expensive offerings from carriers. Cable operators can leverage their HFC reach to provide this type of telecom service for a greatly reduced cost as opposed to a dedicated four-wire copper or fiber interface. It also requires no changes to the customer-owned PBX.
The IAD itself can be equipped with user side interfaces besides just PRI, such as FXS analog lines, if the customer has that need. The IAD has layer three capabilities that can be leveraged for IP traffic management including security and QoS. One challenge for cable operators providing this service is that more DOCSIS throughput is consumed for voice than in normal residential applications, so careful planning and allocation of cable modem termination system (CMTS) resources are required.
The third application, IP Centrex, does away with analog lines and TDM circuits altogether. The customer premises devices are VoIP handsets (SIP phones) and potentially SIP clients running on other devices such as PCs and PDAs. This service type offers all of the capabilities of traditional digital Centrex and many additional services as well. Delivery can be via DOCSIS or Ethernet. (See Figure 5.)
Implementations can be complex, however, because this service rides the customer local area network (LAN) and invites all of the security and traffic management issues that arise in that case. At Cox, we are still defining the standard edge network strategy by comparing network-based edge management via a session border controller (SBC) or a customer premises equipment (CPE) stack that includes a router/firewall and session control security features.
The last application in which SIP trunking can be deployed is SIP trunking to IP PBX. IP PBX has become the dominant telephony apparatus being purchased by medium to large enterprise customers. Shipments of IP PBX overtook legacy TDM PBX several years ago, and the trend will only continue. For this type of customer, the majority of voice and voice integrated features is provided by the IP PBX itself. The carrier is basically providing connectivity, PSTN routing, business continuity and telephone numbers.
The range of service complexity for customers of this type can be very broad. A simple version involves a single IP pipe with an edge demarcation device to a single IP PBX geographical location. Since there are numerous vendors of these devices, interoperability between the service provider’s network devices and the IP PBX in question becomes mandatory. Cox is currently validating the ability to support interoperability with the top five IP PBX vendors.
Some enterprise customers will have complex legacy situations to deal with. (See Figure 6.) They may have multiple vendor devices spread out in multiple locations. Ultimately, they will seek seamless unification of these discrete devices, and building the holistic communication capability becomes a tremendous integration challenge for the service provider. As we have learned at Cox, it’s not for the faint-hearted.
Large enterprises may also request special capabilities, such as seamless integration of telephone services with customer business applications or multi-level precedence pre-emption (MLPP). Often these are legacy circuit-switched functions not widely supported by IP devices or newly emerging Web-based capabilities that are vendor specific. In those cases, the operator may have to make difficult decisions such as raw feature development or expensive legacy integration to win the SIP trunking business.
In summary, SIP is becoming the dominant protocol for next generation voice services. The protocol and its extensions have the capability to eventually displace all legacy PSTN mechanisms for providing voice services. SIP trunking is a great opportunity for cable operators to harvest new revenue in the commercial space, but requires new thinking to leverage the capabilities to provide greater value in communication services to the customers.
For those just starting down this path, first know where your real market opportunity is, design the most standard implementation you can, and don’t scrimp on quality or reliability. Conventional wisdom says that the mobile phone experience has de-sensitized the public to lower voice quality. Since commercial customers rely on voice services to run their business and make money, Cox has learned some very hard lessons about how little tolerance there is for anything less than "carrier class" in the commercial market.
Bruce McLeod is executive director, voice technology and engineering, for Cox Communications.
Sidebar: SIP Background
Interestingly, while SIP is commonly thought of as a voice over Internet protocol (VoIP), its original inventors – Mark Handley, Henning Schulzrinne and their academic teams – conceived a realtime media communication capability for a flat network where voice was just one service element and not the primary purpose. This concept was initially described in an Internet draft as the session announcement protocol (SAP) in 1996 and evolved into RFC 2543, session initiation protocol, and was the cornerstone deliverable of the Multi-Party Multimedia Session Control working group, whose prior work included the real time streaming protocol (RTSP). MMUSIC is still the keeper of SIP today.
The basic SIP document was refined, and the now widely adopted version is documented in RFC 3261. The desirable traits of SIP as a VoIP protocol boil down to simplicity and flexibility. SIP itself has only a few commands, making it simple, but uses session description protocol and numerous extensions to RFC 3261 that allow for great flexibility.