About a year ago, Communications Convergence (then Computer Telephony Magazine) ran an article titled "SIP Rules!" which argued that the Session Initiation Protocol would change the way we think about telecommunications services in general, and Internet telephony in particular.

SIP, we then said, would win the so-called "protocol wars" over its main competitor, H.323. This is clearly happening. Regardless of what they're using to do VoIP today, no one, as Level 3's Jon Peterson quipped at a recent industry conference, has H.323 "on their long-term roadmap." Pundits who, not long ago, declared that H.323 and SIP would share the spotlight for years have almost unanimously changed their tune. Increasingly, H.323 is viewed as a legacy technology - good enough to keep using while we work the bugs out of the business models, but slated for replacement by SIP as soon as things pick up.

At the same time, development of and investment in SIP has blossomed over the past year, despite market reverses. Just in the past six months, two major U.S. carriers - Level 3 Communications and WorldCom - announced commercial availability of SIP-based VoIP services on their networks, and they have aggressive plans to expand their reach in months to come. To varying degrees, other providers, including telecom giant Qwest, are allocating near-term resources to the deployment of SIP infrastructure and SIP-based applications. In the vendor community, the protocol has seen a groundswell of support with Microsoft's announcement in late March that the upcoming release of its new operating system, Windows XP, will ship bundled with a SIP User Agent; and that its next generation of instant messaging clients will also be based on SIP. Microsoft's move will put the protocol right on the desktop of almost every Internet user in America, within the next two years.

All has not been rosy, of course. Competition in the telecom industry, particularly in the local access marketplace, seems to be grinding to a standstill. The balance of power has clearly shifted back in the direction of incumbents and the Regional Bell Operating Companies (RBOCs), while CLECs file for Chapter 11 daily and other upstart voice and data providers struggle to stay afloat. These CLECs, small next-gen carriers, and other competitive entities had looked to become big early adopters of SIP-based infrastructure. While we believe this will eventually happen, a renaissance of competitive telecom may wait on a general market upturn, on improvements at central offices to facilitate provisioning, on the emergence of reasonable telecom pricing paradigms, and it may hang on the FCC's and the courts' willingness to put some teeth in access rulings.

Still, there's no doubt that equipment vendors, service providers, and application developers are betting big on SIP. But this apparent victory may offer only transitory satisfaction, unless SIP is adopted wholeheartedly - not just as a connection protocol, per se, but as the basis for an entirely new way of thinking about telecommunications products, services, and applications.

SIP is simple, it's scalable, and it's built for the Internet environment. SIP was developed in the Internet Engineering Task Force (IETF) by engineers who took Internet standards like HTTP as their model. The result is a mechanism that is indeed easily adaptable to serve where other "call setup/teardown" protocols play, but goes far, far beyond that single application - enabling (either by itself or in combination with other simple protocols or rules): a host of negotiations relevant to communications (capabilities exchange, rerouting, proxying, etc.). SIP can do this, moreover, for virtually any kind of connection - voice, video data, or what-have-you - between or among any kind of entities or resources. Beyond even this, SIP can easily embrace concurrent Net-tech developments to enhance its power; for example, RDF (Resource Description Framework), which will form an important component of the "semantic Internet."

All of this demands that we consider SIP as more than a call setup protocol - that as we enter the era of the "service and application-driven network," we give as much rein as possible to SIP's potential for making this future real. Unfortunately, the balance-of-power shifts and economic reverses may inhibit or distort the vision. Even as SIP gains ground, there seems to be increasing reluctance, on the part of carriers, to let "SIP think" take hold. Instead, with renewed conservatism, many are crying for "evolution, not revolution" in developing and rolling out next-generation communications services; invoking the slogan to protect incumbent interests and defend legacy strategies.

We'd argue, at this point, that the biggest challenges facing SIP in the near future won't come in the form of rival standards, or buyer resistance to "innovative new technologies," per se. What proponents will have to guard against is the risk of SIP being co-opted at the same time as it's adopted - applied in old-fashioned ways to produce IP simulacra of old-fashioned services, because these services are seen as "tried and true." At risk in this endeavor is losing sight of the most fundamental benefits SIP promises to enable, cutting off users from service innovation and diversity, and inhibiting broader growth within the industry as a whole.

Return of the Monolith

Henry Sinnreich, Distinguished Member of Engineering for WorldCom (Clinton, MS - 601-460-5600), was one of SIP's earliest proponents, and has never been known to mince words. At a recent conference (Marcus Evans' "SIP Services and Applications"), Sinnreich opened his keynote remarks with a stern and vivid warning: "The PSTN," he said, "like most dangerous viruses, continues to spawn new mutations."

One area this is happening is in the domain of the softswitch. Ike Elliott, who managed Level 3's implementation of SIP and serves as president and chairman of the International Softswitch Consortium, says a softswitch is simply "software that's used to control a communications network." By this definition, a SIP proxy server fits the bill. It's possible to harness a SIP proxy server to create a general-purpose call-switching resource in IP space, extending this capability to the PSTN through media gateways and controllers. Some SIP proponents are building "softswitch" products that fit this description.

Many softswitch consortium members, however, view softswitches in a different way - as something characteristically bound to the network edge. There's history behind this portrayal: The softswitch market has, thus far, revolved mainly around Class 5 switch replacement. Here, the softswitch, together with a media gateway for connecting to circuit switched services, acts as a cheaper and more "open" version of the telephony switches found in today's central office. While most Class 5 switch replacement products incorporate SIP signaling, few are engineered with SIP entities at core. Instead, they tend to focus energy on feature support (after all, these are "replacement" products), and treat SIP as "just another connection protocol," coexisting with legacy technology like SS7, as well as legacy IP control protocols such as MGCP/Megaco.

This, in itself, is not a problem. Even the most strident advocates of SIP acknowledge that the PSTN will be around for some time to come. So there's continued need for network elements that replace legacy hardware while preserving important features, perform protocol and signaling mediation, and let IP-side services exploit PSTN facilities, and the reverse. In theory, there's not much practical reason for the SIP community and the softswitch community to butt heads.

Philosophically, however, there are real issues at stake. Lacking SIP entities at core, Class 5 replacement products can't serve double-duty - answering today's market demands while claiming a CO beachhead for new network vision and functionality. Meanwhile, SIP itself wasn't designed for feature equivalence with PSTN infrastructure. Rather, the model of "Class 5 equivalent" softswitches, and its absence from the SIP architecture, only highlights the fact that SIP rejects the notion of a one-to-one equivalence with PSTN switching and signaling. A SIP proxy server is emphatically not a software-based telephony switch. Instead, proxies presume a protocol architecture in which signaling intelligence is distributed across endpoints in the network, and in which centralized call control is therefore not necessary. Features and applications in this architecture remain aggressively independent from the plane of signaling and message transport. Their integration is horizontal, at the level of peer communication, as opposed to vertical, where regardless of the interface used they are still essentially tied to a single call control platform.

The tension between these models, Sinnreich points out, is one that's been encountered in other aspects of the Internet's buildout. The problem, he says, is that "people who are trying to make money fast will misuse the Internet to serve their own narrow purposes. In the mobile industry, the Wireless Application Protocol (WAP) is a good example. WAP is really a perversion, not an extension, of the world wide web. Many companies feel a temptation to use the Internet 'my way, so that only I can make money.' But if you do that, then you're losing the fundamental advantages of the Internet, which are based on global connectivity."

The authors of SIP clearly had a globally connected, universally accessible Internet environment in mind when they created the protocol. But how that notion will be translated into practice remains an open question.

Getting Real

For a lot of equipment vendors, service providers, and software developers, SIP is still part of a future plan, rather than a current product release. On today's public networks, the number of VoIP minutes that are switched by H.323 gateways and gatekeepers easily edges out those generated by SIP-based endpoints and proxy servers. But with SIP poised to serve as the standard not just for any new VoIP service development, but also for both corporate and consumer instant messaging systems (not to mention the entire signaling architecture for third-generation wireless networks), the "installed base" of other protocols could quickly become irrelevant.

A number of major carriers are already moving ahead with SIP-based services that represent significant progress from what's been offered in the IP telephony market until now. Level 3 Communications (Broomfield, CO - 720-888-1000), for example, was one of the first U.S. carriers to declare its support of SIP, and has since activated a commercially available SIP-based packet telephony service. 3 Voice Exchange IP, which went live last month, combines a hierarchy of SIP proxy servers with softswitches and media gateways to offer IP-based call switching and termination services on a wholesale basis.

Level 3's service targets retail providers like CLECs, communications ASPs, and ISPs who may or may not own their own telephony infrastructure. Two prime examples are GoBeam and TalkingNets, each of which hosts its own SIP-compatible softswitches and application servers to sell IP Centrex-style services to businesses. To access their business customers, these comm ASPs partner with various broadband local loop providers, while using Level 3's IP backbone to switch long-distance traffic and to terminate calls whenever necessary onto the PSTN.

Some of the advantages of SIP might not be as immediately apparent in Level 3's implementation, since they aren't the ones developing and rolling out services and applications to the end user. But that fact in itself is crucial. One of the key benefits that SIP offers to carriers is precisely the ability to deploy cross-provider services in an open, efficient, and scalable manner. Level 3's value proposition depends on having a backbone network and signaling architecture that makes it as easy as possible for customers to develop services at the edge, without Level 3's direct intervention.

In this respect, Level 3's Ike Elliott comments that the choice to base the 3 Voice infrastructure on SIP was a natural one. SIP enables virtually any type of features and applications to be developed on top of it, from standard Class 5 capabilities to integrated IP services, without overburdening the protocol itself with all these features and allowing for very simple implementations at the core. "SIP assumes that endpoints have computing power in them, and that software can be written in those endpoints to make their own decisions about how to implement features," says Elliott. "The H.323 series, on the other hand, has made a lot of assumptions about the IP network's capabilities at the core, and does not allow the same degree of innovation to take place at the edge. ... SIP is essentially about free enterprise, where older telephony protocols were about control."

Aside from fitting in with Level 3's basic business model in its approach to implementing features, other characteristics of SIP's design are well suited to the kind of networks that backbone carriers like Level 3 are building. One particular focus in the 3 Voice architecture has been scalability - an issue Level 3 in conjunction with dynamicsoft, its main supplier of SIP infrastructure, has addressed by distributing the functionality of its proxy servers across a series of logical domains in the network. Elliott compares the distribution of SIP proxy servers in Level 3's private IP network to that of domain name servers on the public Internet.

In the DNS (Domain Name System), HTTP requests for a route or destination IP address are escalated through a hierarchy of servers that administer to a series of top-level domains and sub-domains, working together to create a distributed and decentralized database. In the same way, SIP proxies can be outfitted to perform tasks relevant to the particular part of the network in which they reside - the capabilities of a proxy interfacing to end-user applications at the edge of the network, for example, might be different from those of a proxy responsible mainly for routing requests across the core. Proxies communicate with one another to accomplish what's required for a given session.

In Level 3's installation, dynamicsoft supplies at least three different levels of proxy server, designed to address different requirements for the edge of the network, the core, and for firewall control. In addition, a fourth level of proxy might be used to interface to the access network, hosted either by Level 3 or by one of its customers.

By implementing firewall control in its network, Level 3 has taken a pioneering role. One area of ongoing development within the SIP protocol has been to ensure compatibility of SIP traffic (usually traveling in the form of RTP-over-UDP) with firewalls, which are usually configured to block incoming traffic of this sort and don't always have the capability to respond to it on a dynamic basis. For Level 3 this is a significant issue, since the carrier needs a secure way to regulate the traffic coming onto its IP network from customers, and to block against unauthorized users and denial of service attacks.

Using a system co-developed by dynamicsoft and firewall vendor Aravox, Level 3 has been able to deploy SIP-aware firewalls at the edge, along with specialized proxy servers that can control the opening and closing of ports on the firewall via SIP-based signaling messages. While this system protects sufficiently against denial of service attacks, and provides the necessary interoperability to work with Level 3's partners' and customers' implementations of SIP, Elliott notes that some challenges still remain. Cost is one, he points out, stating that the price of such solutions needs to drop considerably before they come in line with Level 3's target networking operating costs. The other is to deploy similar solutions in the enterprise.

Aravox, however, has not yet announced an enterprise version of its product, and the major firewall vendors who do target enterprise networks have yet to announce support of SIP. Though much of the technical work is done, education, negotiation, and consultation with enterprise IT managers must follow. Nobody yet well understands what their requirements and fears may be about letting even secured SIP traffic traverse their networks.

Proof that these issues aren't necessarily slowing down the rollout of SIP to enterprise customers, however, can be found in the example of WorldCom's recently announced IP Communications service - a fully SIP-based retail offering of hosted business communications apps. In its first appearance, IP Communications looks something like an IP Centrex service, and could be thought of as a PBX replacement option. But it would be wrong to limit the service to this relatively narrow idea, in light of WorldCom's long-term plans.

With Henry Sinnreich guiding much of the engineering initiative that laid the groundwork for IP Communications, it's no surprise that WorldCom chose SIP as the basis for its service. But in discussing the project with Sinnreich and Teresa Hastings, WorldCom's director of IP Communications engineering, it's clear that a distinct business plan, not just a series of technical considerations, has also motivated the company's moves. These two intertwined motivations equally represent some major shifts in telecom carriers' thinking.

At one level, WorldCom's overall approach to service delivery appears more vertically integrated, and in that sense more traditional than Level 3's. The difference, of course, is that WorldCom - historically a facilities-based carrier - both owns and operates the network and sells services directly to customers. A closer look at the kind of architecture being put in place for IP Communications, however, reveals some important differences from the conventional PSTN environment, as well as from first-generation VoIP offerings.

In its first stage, WorldCom's service will target midsize and large enterprise customers with IP-based voice and data termination based on a converged broadband access connection, and will let customers add PBX-style telephony features with no customer premise equipment (other than IP phones and routers). The company has discussed plans to offer intelligent SIP phones from a variety of vendors, including Cisco and Pingtel, which will in turn interact with SIP proxy servers and application servers in the network. WorldCom's main supplier of SIP server infrastructure is CommWorks, formerly 3Com's carrier division.

Again, this service might appear on the surface as just an IP version of traditional Centrex offerings. But when you consider the capabilities that WorldCom is actually putting in the hands of customers, it becomes clear that many of the fundamental assumptions on which Centrex and other Class 5 services relied are in fact being undermined. In the initial phases, WorldCom will develop its own services, and implement third-party applications on top of its infrastructure. But that infrastructure is built in such a way that it can be extended almost infinitely to third-party providers, as well. To reach a WorldCom customer, in other words, an application wouldn't have to reside in WorldCom's network.

"From a technical perspective," comments Sinnreich, "nothing should be easier than to join WorldCom, and that applies to both our corporate customers and to our partners. The less we have to rely on engineering meetings and proprietary APIs in the development of new services, the better. Basically, all you should really need to add services to the network are access to URLs and a common set of XML data representations. The less protocols and data representations you have in the network, the easier it will be to create third-party services."

For IP-centric engineers, and those third parties developing network services - independent software vendors, ASPs, etc. - this reasoning makes sense. But for a telecom carrier, especially one in the business of selling local access, it's unprecedented. Still, WorldCom is betting that in the long run the Internet model will win, and that the winning carriers will be the ones who accept this sooner rather than later.

"There may indeed be a time," Hastings adds, "when customers will be able to choose between different providers of open, parallel services on a per-application basis, just like the web works today. We recognize that in the web world you simply cannot keep people from doing that."

That, of course, is the kind of environment that telecom deregulation was supposed to create. But for many carriers, it may in practice prove a difficult pill to swallow.

Still, even some of the largest telcos in the U.S. share a similarly aggressive point of view. Qwest Communications (Denver, CO - 303-992-1400), for example, which last year bought incumbent U.S. West, is already moving forward with deployment of SIP in its network, and sees significant opportunities on the horizon for the kinds of services that infrastructure will enable. For now, Qwest's primary focus is on building out the right capabilities in its network to enable its own organization as well as third parties to more easily develop and deliver new applications. According to Timothy Jasionowski, director of IP product incubation and strategy, development of SIP-based services will occur in parallel with the operation of Qwest's IN and SS7 infrastructure - the goal being not to replace existing PSTN services initially, but to target new applications and new service delivery models that were never possible within the older environment. In this regard, a model of working with third-party developers and application providers goes hand in hand with the technical model that SIP puts forth.

"In the Intelligent Network arena," says Jasionowski, "innovation was motivated by carriers because the signaling and applications infrastructure was fundamentally closed; whereas in the Internet model, third-party providers can use the infrastructure that carriers provide to add new features and create new businesses."

By implementing SIP, Qwest is able to build an infrastructure that's not just open to developers and other service providers, but also loosens certain boundaries that have traditionally existed in the telecom network between a carrier and its customers.

The key idea, Jasionowski adds, is that "we're not trying to make the Internet look more like the PSTN, we're trying to make the PSTN look more like the Internet. That means that we need to stop drawing the same hierarchical distinctions we had in the telephone network - between local, national, and international calls, for example - and start thinking of the network on more of a flattened-out model."

To simply reproduce old PSTN services in a new IP domain, while keeping the same hierarchical layers (like Class 4 and Class 5 switching) in place, would, Jasionowski says, be taking a step backwards.

Exploding Applications

Even among engineers and those who are implementing the SIP protocol, there's been debate as to what it really means to build an "open" application infrastructure. In some ways, the application server is the most vaguely defined element of the overall SIP architecture - partly because its functions cannot, by nature, be specified in the same way as a SIP proxy, and partly because it is more a fluid, logical entity than an easily circumscribed physical one.

One effort that has gone a long way toward clarifying what application servers look like is a recently published IETF draft, titled "An Application Server Component Architecture for SIP," co-authored by two of the protocol's original authors, Henning Schulzrinne and Jonathan Rosenberg, along with Peter Mataga. The paper (available at this site) describes a generalized decomposition of SIP-based application servers into multiple component pieces, each of which provides one or more discrete software building blocks that can be used as resources in a particular application, but which are generic enough to be reused in other applications. The basic idea of component architecture is common in modern software engineering. But this draft addresses a specific challenge to a very different architectural model, found in traditional telephony service creation and currently taking root in IP communications as well.

The crucial feature of the server "components" here proposed is that they interact on a peer-to-peer basis. This idea, in line with the way SIP in general distributes intelligence throughout the network, extends both to the feature "logic" of a given application, including signaling and call control elements, and to the processing resources - hardware or software - that handle media associated with that application. The division between these two pieces, categorized as application servers and media servers, is already widely accepted. But the most common model to describe that division has been a master/slave relationship, rather than one that occurs on a peer level. In terms of protocols, this has lead to the early adoption of MGCP and Megaco, where SIP is now being proposed as an alternative.

The Application Server Component (ASC) proposal, however, doesn't only or even primarily deal with the interface between media servers and application servers. Its focus is on the application server itself, which the authors suggest has until now been thought of too much as a self-contained element. Breaking up what is today a tightly coupled, vertically integrated model into more loosely associated, horizontal components doesn't just have a technical motivation, either - though good arguments can be made for why the latter is more scalable, more extensible, and more rapidly deployable than the former. Beyond, or at least in addition to, all the technical reasons, the draft itself states: "One of the key concepts here is that components can be provided by separate service providers."

A model that centralizes all of the intelligence for an application in a single server component, and uses a low-level control protocol like MGCP or Megaco to communicate that intelligence to other elements in the network - endpoints, media servers, or anything else involved in the course of a session - doesn't allow for such flexibility in how the service gets delivered. SIP, on the other hand, calls for session state to be distributed among components, so that each - for example, a text-to-speech server or a VoiceXML interpreter - has enough information about a particular session to execute its specific function without having to know everything about what its counterparts are doing.

The idea here isn't decomposition for its own sake, or that every component piece in an application needs to live on a dedicated server. But one can imagine a number of discrete functions - TTS, speech rec, conference mixing, presence notification - that, if isolated and integrated across a common signaling plane, could easily serve as the core resources for a whole range of highly differentiated applications. The goal is to abstract what is generic, the building-block components, from what is unique and adds value, the end-user focused application component. In the case of a large telecom carrier, the same entity might "own" all of these. But it also becomes possible to let third parties plug in other components to the network - targeting vertical markets, for example, that the carrier might not be pursuing on its own - with far less cost and integration work than was ever required in the past. With SIP as the mechanism for call setup and signaling, and VoiceXML as the primary media interface, the interactions between servers become literally as simple as sending an HTTP "post" or "get" message.

"In my view," says Jonathan Rosenberg, chief scientist for dynamicsoft, "the fundamental definition of an application server is that it establishes the infrastructure necessary for third parties to be able to write and drop applications into it. ... Many application servers claim to be open just because they have a box with an API. But there's a lot more to having someone else write an application than just exposing the API. There are all the issues around how that application gets deployed, who can execute it and when, and so forth. ... If I need to recompile my code to include that information, then it's not really a third-party application service."

With systems that Rosenberg helped to architect, dynamicsoft is trying precisely to buck this trend, and they are joined by a number of other software startups who have adopted a similar model, using SIP as the basis for open applications infrastructure components. These players include Ubiquity, Longboard, and Indigo Software, to name just a few. In most cases, these companies build certain components (presence servers are among the most common) on their own. They may or may not also supply the core SIP signaling infrastructure, including proxy servers and User Agents, that leverages this application framework. But all of them have adopted the guiding philosophy that their products should make it as easy as possible for third-party developers to add on other applications, without undertaking the redundant work of implementing resources that other components already supply.

Enterprise SIP

Until now, SIP activity has remained almost wholly focused on carriers and service providers. But there isn't any strong technical or economic reason why this should be the case. Increasingly, the industry seems to be exploring opportunities for SIP deployment in the enterprise and for blending enterprise and carrier deployments.

To be sure, Henning Schulzrinne isn't your average business communications customer. Associate Professor of Computer Science and Electrical Engineering at Columbia University, Schulzrinne co-authored the original documents that became the IETF's SIP RFCs. But as he describes the challenges faced by his department in upgrading their telephony infrastructure, he could be voicing the concerns of almost any enterprise IT or telecom manager today.

Columbia's "old" PBX, a large-scale Nortel Meridian, was maxed out in terms of capacity. The university wasn't ready to replace it altogether, but they couldn't add many more new lines under their current configuration, and did not want to invest any more money in circuit-switched technology to expand it. Interestingly, the Computer Science department's choice wasn't to install an IP PBX either, at least not the sort that's generally sold under that name.

Using technology developed by graduate students working in Professor Schulzrinne's Internet Realtime (IRT) Laboratory, what Columbia did choose to install was a SIP proxy and redirect server, along with a SIP-compatible Cisco gateway linking back to the PBX and commercial SIP desktop phones from a variety of vendors. The SIP phones, two of which sit on Schulzrinne's desk, communicate over RTP to the proxy, which is responsible for routing calls between endpoints attached to the department's LAN. Calls from and destined for the PSTN traverse the Cisco gateway, and are switched by the Nortel PBX across standard ISDN lines.

Enhanced features like voicemail and conferencing are supplied in part by the SIP phones themselves, as well as a series of application servers also developed by Schulzrinne's students. Capabilities include an MCU for multiparty conferencing, RTSP-based media processing, unified messaging, instant messaging, point-to-point videoconferencing, and even SIP-to-H.323 conversion, all of which run as standards-based applications on open-server platforms and interface with endpoints via the SIP proxy server.

Sure, the average American business probably doesn't have a team of full-time Ph.D students dedicated to solving its communications needs. But the really impressive part about what Columbia has implemented isn't that it's on the cutting edge of technical development. Rather, in comparison with the vast majority of today's PBX architectures, including those that are IP-based, Columbia's SIP implementation is incredibly simple.

A key reason for its simplicity: Aside from the Nortel switch - which is now reduced to the status of peripheral - there's no "PBX" in this network. Just a clutch of interoperating but decoupled entities, talking SIP. SIP proxies and presence servers maintain a dynamic map of where everybody and everything is. "Phone system features" live various places, depending on what's most rational - hold, transfer, three-way calling, and other simple features, for example, are sponsored largely by the phones themselves; while "voicemail" is expressed as a server-based SIP endpoint process (to which calls are redirected by proxy when your phone is busy or you're out), coupled to a message database, some servlets, and some web pages permitting message retrieval - all easily modifiable if somebody wants to add a cute feature. Interoperability happens in standardized channels, through resources, and according to strategies that everybody knows about: SIP CGI, SIP servlets, SIP third-party call control.

Nobody had to "integrate the voicemail to the PBX." Nobody had to provision the voicemail and the PBX in parallel. There's no "there" there. This is very different - and should be much more interesting to any application-maker - than IP PBX architectures that keep the "there" firmly in place, put it in a box, and surround it by proprietary APIs. While such devices certainly answer to market needs, they also conform to legacy expectations and bring along legacy baggage. Like Class 5 switch replacements, they risk becoming "just a sleeker, cheaper way of doing the same old thing."

By comparison, the SIP route is more liberating. But it's also scary. It means (among other things) that the "phone system" - long and still a monolithic device aggregating enormous value, expressing a complex feature-set, sold and supported by a specialized vendor chain - is exploded into a cloud of readily commoditized standard components and standard software. Differentiation at the level of features or applications occurs either in the endpoints or in separate server software components, neither of which are locked into the infrastructure in any unbreakable way.

How near is this vision? Can a SIP server combined with an intelligent phone or soft client today match the features of a mature PBX? The simple answer is no - especially if what you're looking for are all the same features that proprietary PBXs provide, implemented in exactly the same way. But is that even the right standard for comparison?

Schulzrinne says he agrees that "Right now, you're looking more at replacing basic business phone systems. ... In general, though, when people talk about features it's useful to distinguish between what's been motivated by old technology, and what's actually visible and relevant to the user. With my existing phone, I would have to dig through the documentation to figure out how to do most of the more specialized features anyway."

It's not a lack of features, according to Schulzrinne, that has kept his department from implementing SIP-based phone extensions more widely. The only major barrier at the present time, he says, is the cost of the phones themselves, which still range for the most part from around $350 to $600 per set, retail. In the next year or two, however, that price is likely to come down significantly, as vendors start to reduce the number of discreet components they use through developments in ASIC technology and systems-on-a-chip, and take measures to improve the cost of LCD displays.

The other element that's missing from today's environment, but could come into play soon to make SIP-based communications in the enterprise significantly more compelling, is a complementary set of carrier services. Most of the activity to date on the public network side has focused on offerings like IP Centrex; the distinction between enterprise and remotely hosted IP communications has been an either/or proposition, of exactly the same sort that pitted PBXs against traditional Centrex. This is part of the reason why enterprise vendors haven't had much motivation to implement standards, since IP PBX deployments have pertained mainly to closed groups of users on a private network. But forward-thinking businesses and service providers alike are starting to see good reasons for breaking down these traditional barriers.

One reason Columbia hasn't moved even further with its implementation of SIP and begun to bypass the legacy PBX altogether, for example, is that no carrier has yet been able to offer them a viable way of extending IP connectivity from the converged voice and data network in the enterprise across the local loop.

"If someone came to us today with an offer that combined local-number portability with IP termination, we would get rid of our voice T1 lines in no time flat," Schulzrinne says. "But without both those elements in place, an IP trunking solution isn't viable because we'd basically be trying to sell all our faculty and staff on changing their phone numbers, and that obviously isn't going to happen."

As carriers like WorldCom and Level 3 continue to build out their SIP networks, there's no doubt we'll start to see service offerings like this start to emerge. Even beyond just basic IP call termination, other synergies between enterprise and carrier communications networks will undoubtedly appear. With a fully distributed application server component model, for instance, there's no reason why certain applications shouldn't reside in the enterprise itself, while it might make more sense to deploy others simultaneously in a hosted environment.

The key is that it's no longer a choice of either/or between enterprises and carriers, but both working together on a peer-to-peer basis across the network. The kinds of applications that this model enables will in turn increase pressure on both carriers and enterprise product vendors to build products and services on open, standard implementations of SIP.

The Microsoft Effect

No single industry development in the past year will likely have a greater impact on SIP's future, and certainly on its place in the enterprise, than Microsoft's (Redmond, WA - 425-882-8080) decision to back the protocol. At last September's Voice on the Net (VON) conference, Microsoft announced that it would support SIP as the basis for real-time communications and development under the ".NET" architecture. At Spring VON just this March, the software giant got more specific: Every copy of Microsoft's next-generation operating system, Windows XP, will ship bundled with a SIP protocol stack.

Even prior to the release of the OS itself, Microsoft gave a sneak preview of what it hopes to do using SIP; announcing - in conjunction with Reuters - deployment of a secure instant messaging system used to exchange financial information within and among enterprises. The application, which Microsoft designed specifically for Reuters and its financial service customers, is built entirely around standards-compliant SIP proxy servers and User Agents. Instant messaging, both in the enterprise and in consumer markets, is clearly one of the first application areas Microsoft plans to target, and at some point in the near future we will see its currently proprietary IM implementations - in both MSN Messenger and Exchange Server 2000 - adopt the IETF's proposed SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) standard.

Presence, too - today viewed as "an aspect of IM," but in reality, a separate concept which IM is just the first application to leverage - is essential to Microsoft's vision for SIP. SIP includes presence as part of its core capabilities, routing session initiation requests around the network based on dynamically updated information about a user's location and availability, and letting entities subscribe to this information. This capability can be extended into any number of different real-time communications contexts; instant messaging and voice calls (particularly in the wireless domain) are just the most obvious.

"What we've observed," says Microsoft's David Gurle, product manager for Windows Real Time Communications, is the convergence of many different communications scenarios - including instant messaging, telephony, conferencing, whiteboarding, gaming, and others - around what we call 'multimodal session management.'... For us, SIP satisfied all of our requirements for integrating into a single session management model all these different modes of communication, and enabling them to take advantage of presence." Gurle has helped to lead the adoption of SIP within Microsoft and the Windows platform, and is eager in espousing both the technical advantages of the protocol and its role in facilitating real-world business applications.

While the company has yet to disclose details about the actual products and applications that will come with Windows XP, particularly on the server side, the potential effects of its plans have already started taking shape. For one thing, Microsoft has made it clear that every future Windows desktop will include a SIP User Agent, serving as the client interface to several different modes of multimedia communication. At a certain level, this strategy solves in one fell swoop the issue of having ubiquitous SIP endpoints, and is likely to drive demand for the deployment of SIP server infrastructure, both in the enterprise and on the public network.

Equally important is the potential for Microsoft to extend the influence it already asserts in the software development community to SIP-based networking and communications. The User Agent, for example, will include a set of COM-based APIs that allow developers to build applications on top of the protocol's basic capabilities, using familiar programming languages and development tools. Microsoft has also made enhancements to the RTP stack that's included with Windows, and added new features like acoustic echo cancellation, forward error correction, jitter management, and on-the-fly codec negotiation for both audio and video media streams. The servers will similarly include open APIs, designed to enable application development within the enterprise itself, as well as by independent software vendors. A Design Review, in which Microsoft developers will get to see an advanced release of the SIP software and APIs, is scheduled for the middle of this month.

Windows XP's integration of SIP won't be Microsoft's first foray into voice application development, or even its first attempt to bundle a real-time communications client with the operating system. But the forces that have gathered around deployment of SIP in the industry at large, along with the entrenchment of instant messaging as a new means of communications for both business users and consumers, have created a situation in which Microsoft could have as big an impact on the communications industry as it has had on desktop computing.

Gurle's choice of analogy to describe this potential does not seem fortuitous. "The combination of features supported by SIP," he comments, "can create a model as powerful as the web browser did in 1995, using HTTP. We believe that through the idea of presence-based multi-modal session management, the same phenomenon will occur in the real-time communications market as occurred in the Internet."

The thought of Microsoft controlling the user interface to real-time communications, in the same way as its browser controlled the interface to the web, begs the question of what effect its entry into the SIP market will have on competition. But other vendors in the industry seem overwhelmingly positive about the announcement, not worried. For those who are focused on carriers, Microsoft's move into the enterprise space helps validate their offerings and, hopefully, stimulate demand among users for SIP-based services. For those involved in enterprise IP communications - Cisco might be one to watch, in particular - Microsoft's position as a supplier of SIP client and server infrastructure adds another layer to the value chain, and may lead to further specialization in the development of applications for businesses.

SIP-ing Into the Future

Now that central issues of the protocol have been worked out in the IETF (a couple of enhanced features, like supervised call transfer and NAT traversal, are among the remaining challenges), the future of SIP will be about implementation. Trial deployments and initial rollouts already abound in the VoIP market. But the realization of SIP's true potential hinges on going beyond what is, on the grand scale of things, still a niche market for VoIP.

A few factors are likely to propel adoption of SIP in this direction, onward and upward. The first, and presently most prominent, is instant messaging. Yes, the general concept of presence or buddy lists - which allows other users to view and act upon real-time information about your status in the network - has other, arguably more interesting, applications. But IM is already well along the adoption curve. Within the next year, adoption of SIP-based standards could play a crucial role in deciding the much-hyped battle for IM subscribers between AOL and Microsoft. Undoubtedly, the instant messaging architectures currently being designed around SIP will gain significant ground in the enterprise environment, in which IM has thrived but also left enormous untapped potential.

Second, a bit further out on the horizon, is the adoption of SIP by the third-generation wireless community. Late last year, the Third Generation Partnership Project (3GPP), the organization responsible for developing technical specifications related to global 3G wireless standards, agreed upon SIP as the basis for signaling in all future, IP-based wireless networks. This means that as 3G rolls out we will see handset manufacturers starting to embed SIP User Agents in every mobile phone and most PDA devices as well (some of this activity is already starting to happen for wireless data apps), and a single SIP-based server infrastructure in the public network that's capable of supporting both wireless and wireline. Add to that the potential for SIP to serve as the standard for real-time communications across local-area networks as well, plus synergies between Bluetooth, 802.l1b, and 3G public network standards, and all of a sudden wireless communications doesn't seem like such a separate domain from either the Internet or wireline telephony. Core application enablers like presence, built on top of SIP, will extend naturally across these infrastructures.

Finally, the PacketCable group within CableLabs, which has defined standards for carrying IP-based voice and data over a common cable access network, is backing a SIP-based specification called Distributed Call Signaling (DCS) as an alternative to its currently implemented Network Call Signaling, based on MGCP. Two-way real-time communications in the cable market really haven't gotten underway yet, at least not in any volume, but with the near-total collapse of any competitive market for DSL services, cable stands as one of the last remaining channels for competitive carriers to gain access to residential subscribers without using the RBOC infrastructure. While the MGCP proposal provides a way of emulating existing telephony services over cable pipes, SIP-based DCS is a much more likely candidate for future success, since it will allow cable operators to creatively combine voice with other Internet-based multimedia applications they already plan to offer to subscribers.

It may take some time, whether it's a few months or a few years, before some of the most interesting and innovative business models that SIP enables start to materialize. In the meantime, a more conservative approach to services, especially among the larger carriers, may well account for the majority of deployments. But the potential of SIP to change the status quo is too big to be confined to the traditional paradigms. The ability to extend a common protocol set across disparate networks and media types will drive new applications that are built precisely on the convergence of these diverse characteristics. Those applications, in turn, could help to stimulate new models for the delivery of services that cut across conventional boundaries like enterprise and carrier, or facilities-based and non-facilities service providers.

SIP is laying the technical groundwork for all of this to happen today. When, and to what extent, the innovation will take place is still up for grabs.