Interoperability remains a wild card, but session initiation protocol (SIP) – now gaining traction in business telephony circles – has an elegant simplicity that will become even more appealing as IP networks mature.
The advent of Internet protocol (IP)-based networks capable of delivering a host of services is nudging SIP closer to center stage.
A transport-agnostic means of signaling between two or more endpoints in an IP network, SIP has more than a decade of history (see sidebar 1) but is gaining traction today, especially in networks carrying services to the enterprise sector.
Recent deployment news surrounding SIP has emanated from business-customer focused "IP solutions providers" such as Global Crossing and Cbeyond, but the SIP trend involves cable operators as well. CableLabs incorporated SIP into PacketCable 2.0 three years ago, but more to the point, cable operators of various sizes are embracing this protocol itself.
Over the past year, for instance, these pages have carried a SIP business voice case study from two executives at Atlantic Broadband (July) and a survey of business telephony (April) in which a Cox executive memorably called SIP trunking "the biggest no-brainer in the history of mankind."
The takeaway is that SIP is becoming a fixture in today’s telecommunications landscape. "SIP is part of the convergence to IP-based networks, and all the cable companies are looking at bundling services, with VoIP (voice over IP) becoming more pervasive," said Rick Sizemore, chief strategy and business development officer for the research group, MediaIntelligence.
What makes SIP such a good fit? "(It’s) a more elegant solution for enterprises to deliver VoIP and anything packetized," Sizemore said. "It’s easier to manage, takes less time to implement and reduces the cost of ownership. It’s definitely a solution for enterprises."
It’s built for the Internet age, insisted Marc Robins, president of the SIP Forum. "SIP is a communications protocol and enables features like true rich media applications, and it is Web-compatible, so telephony services will look the same on your desktop or other devices. That’s the key, the injection of real time communications in everyday PC applications and the Internet experience. SIP is at the core of that and is easily adoptable within a Web-based framework."
Questions There are some lingering questions, however. Given the mind-numbing number of requests for comments (RFCs) that comprise the standard, SIP Forum President Robbins said interoperability is a leading concern.
"Today, SIP has been widely adopted. Now our job is to solve the interoperability problems. There are 150 RFCs that make up the standard, so it’s pretty complicated. The challenge for developers is picking the right RFC option, and trunking is the main area. If the product hasn’t been engineered for the right option, there can be interoperability questions," Robins said.
SIPConnect, he noted, is a new "robust set of guidelines" for SIP trunking that addresses the problem. "It’s basically a best practices guide when doing trunking, since SIP is a communications session and not just a call," Robbins explained.
The work of the SIP Forum has not gone unnoticed. In May, the non-profit association announced that CableLabs had joined its ranks. In June, Cox Business hopped aboard.
The protocol itself, of course, is the main draw. "There’s a growing interest in SIP based on cross-industries," said Glenn Russell, director of business services for CableLabs. "You get some economies of scale, and there’s interest in delivering IP-based services to enterprises based on SIP standards. It’s more flexible than just voice and a smarter protocol, and easy to develop to."
Smart enough too for service providers such as Cbeyond, a Cisco network-based voice and broadband Internet provider to small businesses, to place a large bet on the SIP standard.
"Our biggest growth area is in connecting customers through IP networks and on the trunking side with services like fax-to-mail applications. (SIP) was a logical choice for us because we built our network from the ground up to be Internet-friendly and co-exist with other Internet components and peer-to-peer designs," said Cbeyond VP and CTO Chris Gatch.
Cbeyond, Gatch said, expects to see strong growth in SIP-enabled feature sets such as HD phones, video phones and products complementing them. "We expect to see those customers expand. But our immediate focus is on SIP trunking." Service-agnostic SIP promoter Alcatel-Lucent touts its service-agnostic role, especially within the IP Multimedia Subsystem (IMS) framework.
"The telephony industry saw that it needed to move to a new world of more video, voice and data in both wireless and wireline and formed a standard body for an IMS (IP multimedia subsystem) framework, said Mike Cooper, vice president of marketing and strategy for Alcatel-Lucent’s multi-core division. "SIP sits in the middle of that architecture."
Cooper said the telephony industry wanted a "protocol not tied to just any one function in the network." But SIP’s role appears to shift for other industries.
"For cable, it’s a unifier and enabler," Cooper said.
The ability of SIP to reduce complexity also has played into its appeal for cable. For instance, server-based requirements posed challenges to cable operators in the context of then-emerging CableLabs VoIP specifications, said Chris Koehler, senior director of engineering for broadband solutions at Motorola.
"SIP became a simpler, more attractive way for cable to set up other streaming applications like video conferencing and beyond voice," Koehler said. "It’s easier to manage and more robust for services like streaming media."
Yet with that robustness come some tricky challenges with SIP, he admitted. "There are lots of suppliers that have introduced different versions of SIP, so interoperability issues exist. That’s a challenge we face, and there are still infrastructure components you must bridge to other parts of the network. But SIP enables more features, and that’s what is motivating operators to roll it out."
And just why is SIP becoming more appealing? "SIP doesn’t care if it’s a voice or video stream. It treats them the same. And we’re seeing more SIP activity in 3G and WiMAX and those types of architectures. We value SIP a lot, and it’s in every Motorola voice product and many gateway products," Koehler said. Non-voice apps SIP is also showing up in other feature sets, many of the non-voice variety. "SIP isn’t wedded to voice," said Steven Johnson, president of Ingate Systems, a provider of SIP-capable firewalls.
"It’s the protocol to connect, like video to the desktop, and can collaborate on a presentation. It has many applications, and industries like cable can benefit from adopting it to expanding business services," Johnson said.
That includes mobile devices, Johnson added. Not a surprising addition, given SIP’s role within the IMS framework.
Traditional telecom players such as Cisco, Nortel and others are getting the SIP message as well. "They have finally started adopting SIP for call managers," said Tom Fisher, systems engineering director for unified IP communications solutions provider Interactive Intelligence.
"(SIP) can set up chats on PCs, voice and video sessions, and it doesn’t care what it’s being used for. It’s open, flexible and evolutionary. Interoperability is still a challenge, but the right people are listening now," Fisher said.
One of them is the legacy Scientific Atlanta side of Cisco. According to Bill Wall, technical director for Cisco’s service provider video technology group, the company is looking at SIP for its set-top boxes.
"There are some areas in SIP that haven’t been completely defined, and it is just one of a suite of IP protocols, so it’s not a magical protocol. But there is some call for adding SIP to our set-top boxes for caller ID on the TV. SIP is a natural for that. It also has the ability to initiate video conferencing from desktops and will be included in software stacks in future set-tops," Wall explained. Keeping it simple Going forward, SIP will likely embrace even more applications. "We’re still growing the scope of SIP trunking services to include added features like disaster recovery and better failure scenarios," said Cbeyond’s Gatch.
As far as real deployments go, however, that association with "new" and "better" is a double-edged sword.
Writing in these pages in August, Rob McCann, president of IP and voice network services consultancy ClearCable Networks, acknowledged that demand for both SIP trunks and hosted IP private branch exchanges (PBXs) is expected to accelerate. But he argued that success in the small-to-medium business (SMB) segment today is a function of meeting basic needs. And that means keeping emerging IP solutions in the sales case and leading instead with basics, such as analog line or trunk replacement products.
As the SMB market itself matures, however, so will its demand for technology. Interoperability remains a wild card, but the ultimate value of SIP may be that it promises to enable a scaling up of services while keeping complexity to a minimum.
"Simplicity tends to win in the end, and SIP does that," Gatch said.
Craig Kuhl is a contributor to Communications Technology. Reach him at firstname.lastname@example.org. Sidebar 1: SIP History Academics drafted what became known as SIP in 1996 as a way to issue invitations to large-scale, multipoint conferences on the Internet. The original drafts included just one request type, a call setup request.
Three years and 11 versions later, that draft became recognizable as SIP.
Subsumed within the request for comment (RFC) standards process of the Internet Engineering Task Force in 1999, SIP was accepted as a Third Generation Partnership Project signaling protocol in 2000 and became part of the IMS architecture.
Although some 150 RFCs define SIP, experts commonly reference RFC 3261, dated 2002, as a core specification. CableLabs incorporated SIP within PacketCable 2.0 in 2005.
A signaling protocol used to set up and tear down multimedia communications sessions between two or more intelligent endpoints within an IP network, SIP has to date become a sort of extensible network glue enabling everything from over-the-top residential or dedicated business telephony to email on a PDA to the latest applications on an iPhone.
It’s a protocol with a bright future. Sidebar 2: Ask the expert: Q&A with Chris Busch Chris Busch, VP broadband technologies for Incognito Software, is an expert on SIP. Here are his answers to some common SIP questions.
What is the state of play on the client side of SIP-based technology?
SIP VoIP terminals such as IP Phones, MTAs and EMTAs have come a long way in the past two years.
Various standards bodies have all placed concerted effort to the obstacles preventing SIP VoIP devices from entering mainstream service deployments. These include the IETF, Broadband Forum and CableLabs. IETF has been active in geo-location RFCs for SIP VoIP devices, which has been picked up by both Broadband Forum and CableLabs in PacketCable 2.0. See draft-ietf-geopriv-dhcp-civil-09 for the use of DHCP with SIP devices extending location information for first responders.
All three standards bodies have also been active in device provisioning, arguably one of the single largest obstacles to service adoption. Until very recently, each vendor of a SIP VoIP device implemented its own device configuration, which included its own firmware control and remote management practice. Broadband Forum has arguably the best technical approach to standards-based provisioning, common firmware management and ongoing operations management and surveillance through a combination of Technical Requirements documents.
For EMTA devices attached to the cable plant, PacketCable 2.0 intends to deliver SIP line appearances within EMTA devices, compliant to the 3GPP IMS Core standards for public user identity service subscriptions. This standards approach has the obvious benefit of control plane and QoS reservations that cable has come to expect in its delivery of native VoIP service delivery.
So is it interoperability that poses obstacles to moving to mass market?
Interoperability comes in a couple of flavors within this conversation. First, we have the current state of proprietary vendor device implementations. These are the SIP VoIP terminals that follow no standard, which include what I would call pre-PacketCable 2.0 EMTAs with vendor-specific firmware enabling SIP line appearances.
For all of these flavors of SIP endpoint, verification of line features such as message waiting indicator, digit map processing, feature code provisioning, and so forth differ not only between the configuration of those parameters within each of the varying devices; they also differ often in their performance with call platforms in the headend.
This brings us to the second concern. Legacy Class 5 call platforms, which for PacketCable are termed CMS or simply softswitch elements, will have varying line features supported. Depending on the service you intend to offer, residential or commercial, what line features are supported by the call platform, and of those, which features can be shown to work well with which vendor-specific implementations of SIP VoIP terminal?
Thankfully, IETF, Broadband Forum and PacketCable recognize this obstacle. As those standards enter the device manufacturer, we will finally remove these roadblocks and enable any residential or commercial VoIP service product with integrated provisioning, standard device management, and assured service features.
What about on the network side? Call servers are integrating SIP. Anything else?
VoIP interconnection has been and continues to evolve between operators. SIP-T (SIP trunking) plays a large role in preserving the legacy call setup and completion signals the PSTN prefers. Supporting SS-7 interfaces, session border controllers sit at the edge of an operator’s network on the SIP packet side and speak natively to the PSTN on the SS-7 side. Another driver of SIP is trunking inside the cable operator network, which is in addition to what we often hear about in terms of VoIP peering between operators. This has the advantage of bypassing the legacy SS-7 PSTN entirely for operators who choose to directly exchange call routing information.
We’ve mentioned PacketCable 2.0. I’ve used the term legacy Class 5 softswitches. There’s a connection there. Current CMS softswitch investments are effectively a packet-based version of a traditional PSTN voice core. You have the concept of lines and trunks rated to a platform capacity and fixed to a service location such as a headend or central office.
With PacketCable 2.0, which is an extension of the IMS standards from 3GPP, we separate the service from the subscription. What that means is your SIP VoIP registration need not be fixed to a single call-processing platform. In fact, a SIP line in an IMS design will be directed to its serving call platform known as a serving call session control function (CSCF) after having been registered and authenticated via a proxy CSCF by the home subscriber server (HSS) core, which stores every user identity, including the subscribed services of the user.
The services themselves are another topic, where we’re no longer pinned to traditional voice offers such as phone and voice mail. Services now include IP video voice mail, location-based call routing, presence-enable applications that span multiple devices from the mobile phone to the softclient phone to the cable set-top box – all enabled by an application core systems relying on SIP for signaling and endpoint communication, making the entire process transparent to the end consumer.
Is it true that deployments of IP-PBXs within cable depend to some extent upon the capabilities of PacketCable Multimedia (PCMM) regarding support for QoS?
Yes and no. If the IP-PBX is the only service on the Ethernet side of the cable modem, then you could dedicate your cable modem provisioning to map traffic into a high priority QoS service flow and simply maintain the same QoS through the network to the terminating softswitch.
Where we come to need PCMM is when it isn’t just VoIP in the data from behind the cable modem. Many IP-PBX platforms are SOHO/SMB (small-office home-office; small-to-medium business) platforms where in addition to call routing and terminating VoIP phone lines, data services including firewall, Internet access, VPN connectivity and so forth are converged to the premises via the IP-PBX.
In this scenario, we want the PCMM application manager to work for us in recognizing the SIP VoIP traffic from the rest of the data, consulting the policy server for a decision on QoS for VoIP on a per flow basis. This also gives us the benefit of assuring the delivery of VPN services, for example, into another classification over the network. PCMM really comes into its own when we need to make decisions about multiple types of traffic originating behind a cable modem from a converged service box.