Whoa Corporate Rat! I still cannot seem to resist a good ol’ geek talk! One more of the year, OK? It is just plain hard-work when you are trying to join a communications club that is several decades old with multiple generations of engineers developing distinct applications and services. What is happening in the VOIP world is nothing new. Standardization is inherently complex. It becomes doubly more complex when you consider voice communication is of vital interest to multiple societies. It becomes triply more complex when the infrastructure being replaced is the most used and the most stable in the world! Discussing your arguments: 1. Text based Protocol: Yes, SIP could have been XML based but THANK GOD it is not ASN.1. 2. Refusal to standardize services: I don’t know why the IETF should do this? Do you really think we could get two carriers to agree that Call Forwarding RNA should terminate in an intercept or ring forever? Or that Music On Hold is an “expected” feature in business applications all over the world? I think the push for standardizing services has more to do with carriers being apprehensive that they will be locked into a proprietary solution. Industry

(Read More…)

VOIP is a giant leap forward in dragging us “Call Processing” types out of the dark ages to the modern world. SIP is the motivation. While SIP improved the interoperability between systems, it did not take away the inherent complexity of developing voice applications. Many of us VOIP application vendors basically built proprietary constructs from scratch (a HUGE benefit) that helped develop applications rapidly. The net result is that voice applications continue to be developed by a select few. Don’t get me wrong. We all use the latest and greatest available today: Object oriented design patterns for vastly improved software quality, SOAP for remote data access, CPL or equivalent for simple routing, VXML and MSML/MOML for media control, and a services oriented model for application delivery. However, they continue to be proprietary to the application vendor. The best we can do is claim SOAP or SIP as the “API” for developing applications. Want to integrate a cool conferencing application as a “converged” application? Sorry, besides SIP “interop”, no can do! Carriers are wising up to this. They are demanding an open environment that doesn’t lock them into a particular vendor. Initiatives like IMS are forcing vendors to rethink and offer

(Read More…)