dcsimg
Linux Today: Linux News On Internet Time.




More on LinuxToday


David Sugar: Community report from the ISC

Feb 07, 2001, 19:41 (0 Talkback[s])
(Other stories by David Sugar)

WEBINAR:
On-Demand

Re-Imagining Linux Platforms to Meet the Needs of Cloud Service Providers


[ Thanks to David Sugar for this link. ]

Six months ago, I was elected as the software communities representative to the International Softswitch Consortium. Recently (January 23rd-24th), the ISC held it's first semi-annual event, which I attended. This report has been filed and made available at several public news sites to provide some feedback to the community directly on what has been accomplished since my election to the ISC. But first, a disclaimer; the views expressed in here are my own and do not nessisarly represent the views held by officers or other members of the ISC in any manner.

First, it might help to define the ISC and why it should matter, both to those involved in telephony specifically, and the general free and open source developer community at large. The ISC is a vendor neutral organization of over 200 member companies chartered with suggesting and promoting interoperable standards for softswitches. Softswitches will be at the core of the next generation ip based telephone network.

While the ISC does not directly create or endorse standards, they do have working groups that evaluate and recommend standards, and many of these working groups share members with and directly influence related IETF working groups. Another service the ISC provides is interoperability testing and this will become more formalized with the introduction later this year of a dedicated interoperability lab.

In that the next generation telephone network will be IP based, many of the standards talked about within ISC working groups would be familiar to those working on diverse areas including multi-media streaming over the internet, quality of service, multi-media conferencing, and of course telephony related signaling and control protocols. These are all core issues that can effect a very broad range of developers.

While there are over 200 voting corporate seats in the ISC, there is one voting non-corporate seat, which I hold this year. This seat was sponsored by Vovida prior to it's purchase by Cisco systems, and Craig Southern, from the "openh323" project, held the seat in the year prior to me.

Within the ISC, there is much talk of what a standard or "reference" next generation ip based telephone network should look like. While the idea of softswitches started with the simple idea of VoIP gateways that could interconnect, this has expanded into the reference softswitch architecture we see discussed in the ISC today.

In this ideal architecture, we have "media gateways" which now simply interconnect between the traditional telephone network and the ip domain. There is of course what could be called a "softswitch" itself, which routes and directs ip calls between ip end point devices such as media gateways, ip telephones, and feature/application servers. There is also feature and application servers which provide programatic logic and application handling for ip phone sessions, and media servers, which provide media resources such as speech recognition, playback, and recording of audio prompts.

In an "ideal" ip central office of the future, these are all represented by separate servers that are interconnected over tcp/ip using commodity protocols like SIP and RTP running on commodity hardware, and each component can be supplied by and integrated from a different vendor. Clearly this means that free software can be written for any and all of these well defined components, and that free software can migrate into and liberate the next generation central office from the proprietary solutions of the past.

My own more immediate interest was initially with the Applications working group of the ISC. This group is tasked with, among other things, defining how application servers and media servers interoperate, and how a single application server can marshal the resources of multiple media servers in an effective manner.

Several solutions to this problem have been suggested, starting with MGCP, which provides a master/slave protocol for managing a media server from an application server. MGCP (Media Gateway Control Protocol) and similar solutions which decouple application logic from realtime media services over ip have proven less than effective in the real world, since the coordination of many media servers from a single application server tends to overload the application server, and near realtime response is not possible to achieve. To help solve this problem, more and more extensions were made into MGCP to push more and more application logic thru it to help overcome this limitation, and other protocols have been suggested.

I personally believe that the ideal of separating the application server from the media server is fundamentally flawed. Certainly the last presentation of the Application working group this past week brought this point home to me, where to solve this problem, an example was shown whereby the application server simply collects and pushes an entire VoiceXML application script to the media server to execute locally rather than on the application server itself. The media server then hence has obviously become a media processing application server unto itself.

While I am sure it's very much a minority view, I believe rather than trying to separate application and media processing into two distinct entities, they should be combined. I also personally believe work should instead be done on how separate "application processing" media servers could be coordinated with peer to peer procotols for distributed application execution rather than the master/slave topography favored today.

Another working group I "discovered" largely at the ISC meeting is the session management group. This group is trying to solve a hard and interesting problem; how to collect and process billing and connection information thru a multi-protocol softswitches, application servers, and gateways. In that calls may pass thru many protocols, and even gateways from ip to the traditional phone network, there must be a way to describe and log this traffic, and ultimately to bill for usage, to determine quality of service rendered, etc.

The session management group is a natural compliment to IPDR, which focuses on how IP detail records could be stored, organized, and retrieved. In the traditional telephone network, individual phone switches generate CDR records (call detail) which serves this purpose, and the session management group hopes to have an IETF draft protocol for how next generation IP equipment can also generate call detail.

One of the more difficult questions I faced as the communities representive to the ISC is the process by which members of the technical advisory committee and the board are selected, which is by election thru voting members, of which I qualify. The key question is what would be the best use of exercising my vote on behalf of the community. My conclusion was that it was best to do so by voting for those members who were from companies that understood and presumably favorably disposed to open source/free software solutions.

Another issue I had to consider is CALEA. Some may remember that the IETF choose to reject legal intercept in working drafts and as part of IETF sanctioned protocols. What is unfortunate is that they choose mearly to reject and ignore legal intercept rather than activily lobbying strongly for reversal of the legislation behind this.

Come August, it will become illegal to sell telecommunication equipment that does not include specific wiretapping capabilities as specified in CALEA, regardless of how the IETF may feel about it. Naturally, the ISC, being a vendor organization, simply has chosen to accept this as a legal requirement to be "in the business".

Personally, I would have favored the ISC coaxing these same vendors to take an active stance against this law. I also do not believe wiretapping and "secret evidence gathering" is a right that our govt should be permitted to constitutionally exercise, in that it interferes with due process, with what would otherwise be legally privileged communications, and with the right against self incrimination. Wiretapping powers can be used indiscrimentaly against innocent members of the public who's conversations are also overhead simply because they choose to speak with the target of an investigation.

What legisture like CALEA does is particularly insidious in that it helps put in place the infrastructure needed for the model police state. While I am certain that those who exercise wiretrap warrents today generally do so with ethical standards and intent, the very existance of this kind of infrastructure represents a potential future threat to our very liberties and the freedoms we enjoy today. I urge all those reading this to consider lobbying by whatever means are available against laws such as these.

One thing I did find is that I was able to understand and work within the ISC much more effectivily after the semi-annual meeting than before. I think it is unfortunate that the election of a community represenative currently occurs many months prior to their first ISC meeting rather than much more immediately before one. This is the one change I would suggest in the future.

Further general information about the ISC may be found at http://www.softswitch.org.

David

Related Stories: