[ 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