SIP and Web-Based Applications

Doug Tucker, CTO Americas, Ubiquity Software
By Tim Scannel, Internetnews.com

Since its founding in 1993, Ubiquity Software has pretty much lived up to its moniker of developing applications and services that are available anywhere and everywhere.

In 1999, the company revamped its strategy to produce software based on the Session Initiation Protocol, or SIP. The technology was originally designed to be a framework for the development of converged voice, video and data services over IP networks, and has since become a key element in telecom-class communications services today.

The market for such services, based on SIP, is expected to reach $4.7 billion by 2009, according to market researcher Yankee Group, as a range of new applications and products is deployed that make use of enhanced IP services. These also include VoIP, Web conferencing, instant messaging and gaming applications.

In January, the UK-based Ubiquity agreed to be acquired by Avaya, a move that gave this company an edge over Nortel, Cisco and other competitors. And just this month, Avaya agreed to an $8.2 billion acquisition deal put on the table by private-equity firms Silver Lake and TPG Capital, which effectively makes it a private corporation.

Ubiquity has emerged as a key element in Avaya's plans to expand its IP-based telephony footprint and spearhead the development of converged voice and data applications and services -- especially those offered by the wireless carriers.

Recently, internetnews.com talked with Doug Tucker, CTO of Ubiquity's Americas operations, about its evolving SIP platform and how the technology will play a key role in the IP-based applications landscape.

Q: Why is SIP important to current and future Web-based applications?

You can think of SIP as a generic interconnect mechanism for communications sessions. It's not limited to voice or IP telephony. In fact, IP telephony is an application kind of superimposed on top of the SIP interconnects. It is a way to establish sessions between communications participants and then negotiating different ways communications sessions run on top of it.

Q: Are sessions of this type possible without a SIP protocol or architecture?

There are other protocols you could use, like H.323, which has been the predominate protocol that enterprises have used in the past for voice and video conferencing and collaboration. Actually H.323 and T.120 have been the predominant ones.

These are now migrating to a SIP infrastructure. There are still H.323 products in use today, but clearly the future is moving towards SIP.

Q: What is the problem with H.323 as compared to SIP?

H.323 is a very constrained infrastructure. It was designed for very specific deployment architecture and specific uses, while SIP is a much more open protocol that allows the applications to define the usage and the topology that SIP is applied to.

Q: So would the problem with H.323 and others be that they were essentially developed before the development and growth of mobile devices and advanced Internet applications?

I was actually on the committee that created H.323 10 or 12 years ago. It was really targeted as an IP-modeling of the PSDM (perceptual speech distortion metric) infrastructure, and was strictly designed for point-to-point multi-point video and voice communications.

It wasn't viewed as a general applications infrastructure, where SIP was really built around the Internet protocols and a very distributed deployment model and also a very open usage model. It's much better suited to today's view of where applications are going, which are rapidly breaking down the notion of vertical applications and approaching more of a horizontal services capability that are more dynamically grouped into point applications for the enterprise.

Q: Are there various types and iterations of SIP, much like there are different types of Unix, Java and other platforms?

There is one SIP set of standards that people adhere to, but it's a very flexible base. On top of that you layer in what I call your "service topology," and that's how you make use of SIP to make the connection session and to define what the sessions are. And those service definitions are what changes from deployment to deployment.

Q: Ubiquity's SIP is a Java-based platform. Does this make a big difference as compared with something that may be based on Brew, or does Brew have a comparable platform?

First of all, there is the SIP infrastructure, and on top of that you need to layer an environment that allows you to write programs and make use of it. The Ubiquity SIP platform uses Java, and more specifically a SIP server container that is equivalent to a Web server container. So, the programming model on top of that matches Web developers who are creating Web portals or Internet-style applications.

Something like Brew is a more closed environment that is really built around the notion of a monolithic vertical application development, and it has its own programming environment. As a result, you would have to retrain your redevelopment community around that infrastructure.

Q: One trend in mobile applications development today is to put more code and operational rules on the server side and less programming on the mobile device itself. This not only conserves real estate on the device, but provides more security should the device be lost. What is your opinion on this approach?

There is a development model that I support of not putting a lot of intelligence on the endpoint. It is definitely a growing trend in the industry.

When you look at how applications are built, both carriers and enterprises are looking toward an SOA-based hosting and development model. And in that model, the endpoint participation is evolving to the point where the endpoint itself can host its services into the SOA environment.

But those services aren't necessarily a part of the application, but they may be elements that the application can attach to and make use of in the context of the subscriber session with that application.

Q: Are most carriers up to speed on using SIP, or is there a ways to go before it is firmly implanted and used as a matter of course?

I think SIP has clearly won the mindshare in terms of when people are implementing IP as part of their telephony infrastructure. It's just assumed that it's SIP.

The latest evolution in thinking is now modeling the call model and operational model of a network more closely to how SIP operates as opposed to how they were operating as a PDM infrastructure.

Q: A couple of years ago CERT questioned the security of SIP as an infrastructure because it made use of the IP architecture. Has that situation changed today?

I think we are well on our way to solving the security issues. The issues are understood, and it's not just related to the protocol. The protocol itself doesn't take care of security. It's really edge devices that have to be in the frontline of security in the service network.

Q: Does this mean that applications developers using SIP must be very aware of its characteristics and what it can and cannot do in terms of security as they build applications for service networks?

Not anymore. The growing trend is that applications developers really work at the applications layer, which is well buffered from the service network. They may not even see SIP at all. And security is a layer underneath the SIP layer.

As everything moves closer to a Web services and a service-oriented architecture approach, applications developers will be able to be highly abstracted from the service definitions underneath the application and the endpoints as well as any of the issues around security.

Q: What do you view as he biggest roadblock to the continued drive toward SIP and the development of SIP-enabled applications?

I think the next evolution has to be at the applications layer. Service-oriented architectures are going to be the new arena over the next couple of years, and SIP and HTTP are underlying access technologies and transports for applications sessions that are being defined at a very high level through SOA techniques.

It's not necessarily SIP itself that is going to evolve significantly, but the number of rich applications is going to grow and drive more utilization of SIP.