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.