Re: FW: [Bayonne-devel] The GNU Telephony Roadmap

[David Sugar]

Well, while not directly in the roadmap, for very short term, starting
with release 1.5.6, Bayonne2 can now act as a SIP proxy/registrar for
external devices, receiving the dialed number in %session.dialed, so I
think with some scripting you could possibly make it operate as some
kind of gateway by loading the SIP with the existing voicetronix card
driver together.  There incidentally also exists a methodology for
creating Bayonne dialing plans.  With some further work, and a lot more
testing, it could be very possible to make Bayonne behave much more like
a complete and self-contained SIP phone system, although my original
focus and intent was on telecenter & ACD functionality.  Longer term,
however, I expect to have trollgw, a new and separate server, which will
be better at being a dedicated function and high capacity PSTN gateway.

Julien Chavanton wrote:
> Hi David,
> 
> I am not sure about something, are you planning Voip/Pstn gateway
> support? If so with what pstn interface are you planning to start?
> 
> Personally I still think this is a really important feature.
> 
> Julien
> 
> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden
> g] On Behalf Of David Sugar
> Sent: June 3, 2006 10:55 AM
> To: mailing_list_bayonne-devel
> Subject: [Bayonne-devel] The GNU Telephony Roadmap
> 
> I had been either sick, very busy, or away for parts of the past two
> weeks.  I have however recently made available a number of interesting
> releases from things that had actually been in development from a long
> time ago, and I will later this summer bring out some entirely new
> things.  I wish to explain how these releases relate to, and what is my
> overall roadmap for, GNU Telephony for the next several years.
> 
> * Bayonne XML and webservices
> 
> The last two point releases of Bayonne2 have focused on enabling Bayonne
> to be both a producer and consumer of XML documents.  This included the
> re-introducing of BayonneXML to allow GNU Bayonne servers to query and
> process call sessions under the control of web served documents.  I see
> XML documents as the way to enable common publishing and presentation of
> documents, whether on the web for browsers in xhtml, for editing through
> odt, for the visually impaired in daisy, and voicexml and/or BayonneXML
> for presentation to telephone callers.  Produce once and distribute
> everywhere.
> 
> Bayonne server bindings offered new opportunities for introducing new
> application service with Bayonne.  Now that we are working with
> BayonneXML again, I also wish to introduce Bayonne Daisy as a server
> binding for the GNU Alexandria project.  There also remains a lot of
> work to make BayonneXML more fully consistent with CCXML/CallXML.
> 
> Bayonne2 web services provide a model both for system management and for
> integrating Bayonne with other application services.  Initially I have
> introduced several .html status pages which automatically refresh, and
> hence can be used to monitor the server, and a new XML dialect,
> serverResponse, which allows one to send a GET request to known uri's,
> with optional query arguments, and retrieve a XML response document
> which is simpler than the POST driven XMLRPC reply system.  In the
> future I will also be adding XMLRPC to Bayonne web services.  The
> existing web service also needs support for authentication.
> 
> Bayonne web services makes it possible to telephony enable existing
> applications, either from other web services, or by using common
> scripting languages.  Along with the existing Bayonne::Libexec.pm
> module, and similar modules for Python, Java, C#, and php that also
> exist, I will be writing a Bayonne::Webservice.pm (and
> Bayonne::xmlrpc.pm) module for different scripting languages to future
> Bayonne distributions to make it easier to write such applications that
> integrate with Bayonne.
> 
> * On frameworks and platforms
> 
> There has been some effort being made in an entirely new sub-project,
> GNU Telephony Open Embedded.  This work is focused on making the core
> GNU Telephony frameworks available for two uses; for those developing
> softphone applications handheld devices, potentially using GPE, OPIE, or
> QTOPIA; and for deploying embedded servers (including things like GNU
> Bayonne) on appliances.
> 
> With regard to our framework libraries, there are specific goals for
> each.  These goals are consistent both with features that have been
> missing but deemed vital to add, and with addressing needs suggested by
> other goals.
> 
> In GNU Common C++, there will be work on introducing SSLStream (and
> later SSLSocket) in the ccext2 library, using openssl.  The existing
> URLStream class will then be rewritten to support SSLStream and to
> support SSL web sites.  From the perspective of GNU Bayonne, binders
> like BayonneXML which consume web sites will eventually be rewritten to
> use URLStream rather than depend on external libexec based xml-fetch, to
> increase performance.  Other uses will include support for creation of
> services which depend on secure communications, and hence support for
> things like key management and encryption will also be added to the GNU
> Common C++ framework directly.
> 
> In GNU ccAudio2, some work has been completed on improving plugin
> support for codecs, including those which have irregular packet sizes.
> This work will be used to modify the AudioStream class with methods that
> allow a codec to pull data and synchronize I/O to packet boundaries.  An
> example of this will be found in the interaction of the future mpg audio
> codec plugin with the audio file streaming class.
> 
> GNU ccAudio2 now includes primitive resample support.  This allows
> audiotool to do basic "rate conversion".  This needs to integrated with
> a smart resampler algorithm.  In addition, I will be adding support for
> generating false audio positioning in ccAudio2's existing capability to
> convert mono to stereo audio.  This will be very useful in future
> telephony softphone client work.  There are many gaps remaining in
> ccAudio2, including fsk/fax decoding, which still need to be addressed.
> 
> In GNU ccRTP, I am going to look at how we can simplify templates, so
> that we do not have to have entirely separate templates for IPV4, IPV6,
> etc.  I may also look at introducing some hard coded classes for certain
> common RTP profiles.  However, we do not have any large issues in GNU
> ccRTP, that I see, only those that will either make the library easier
> to use, or better suited for embedded applications.
> 
> On the Microsoft Windows platform, I recently re-organized CAPE, and
> broke compatibility with past releases of CAPE dependent software in the
> process.  This was done to standardize the naming convention we used for
> DLL's so that versioning of API's would be better represented.  I also
> used it as an opportunity to introduce a bunch of additional libraries
> as part of CAPE for building GNU ccAudio2 codec support, including
> Speex, and a stand-alone GSM audio DLL.  The existing .dsp project
> files for GNU Bayonne can be made to work with the new CAPE releases by
> adjusting the link library names.
> 
> * Migration of past services
> 
> Recently I did a partial rewrite of the globalcall driver stack to try
> and eliminate issues with call failure states.  This became 1.2.16,
> which still has one open issue with handling of disconnect on outbound
> calls, and included the new snmp module.  I intend to resolve that issue
> this or next weekend, and then have a new release (1.2.17).  Afterward,
> I will be focusing on migrating dialogic driver support to Bayonne2.
> 
> * Introduction of new services
> 
> Many new areas of development are still in my workshop, and so have not
> yet made it into software I have released.  However, I am very shortly
> going to introduce the first of what will become several new free
> software generic Internet media servers through GNU Telephony.  None of
> these break new ground directly, although they are engineered to my
> expectations, and are meant to be used for experimentation in
> convergence of telephony, Internet radio, IMS, and IPTV, over the next
> several years.  Free media requires freedom in the tools which propagate
> it, as well as freedom in the formats it is encoded in, and the
> infrastructure it is carried on.
> 
> The first of these new servers will be the Nijmegen audio, video, and
> internet radio streaming server, which implements the icecast protocol,
> and supports plugins as media sources.  Initial releases will be
> available sometime on or before August 1st, when I will demonstrate this
> new server during ClueCon in Chicago.  Later this year I am introducing
> a RTSP based generic streaming media server.
> 
> Because it is vital to our enterprise vision for GNU Telephony, a third
> effort will be made to introduce Troll gateways, and this time again as
> a stand-alone server.  This will focus on the idea of tightly coupling
> the RTP stack to the telephony device for optimal gateway I/O
> performance.  The other advantage this offers is being able to offload
> transcoding to the telephony card, and presenting those codecs which the
> device nativily supports.  This is from our vision of optimizing system
> load and maximizing system capacity.  There are already other gateways
> that support such functionality through extensive transcoding.
> 
> Part of this enterprise vision focuses on separating telephony into
> three parts; a gateway for when dealing with PSTN/ISDN trunking
> services, an application/media server (Bayonne), and a call
> control/session manager/registrar/call server.  For H.323 networks,
> GNUGK is already an excellent resource.  For SIP there are things like
> SIPX and Vocal, although each breaks up the functionality into separate
> micro services.  I have thought about introducing a new kind of SIP
> proxy/registrar that focuses on peer-to-peer audio while managing SIP
> sessions, call state, call groups, etc.
> 
> Another important consideration has been in developing applications with
> GNU Telephony.  Part of this will be addressed in several long term
> applications that are currently being developed, including a model
> Bayonne-based SIP telecenter.  Other applications we will look at is
> large scale Bayonne hosted voice mail and ACD systems.  Some of these
> projects have waited on the introduction of Bayonne web services.
> 
> * Our long term vision of the future of VOIP
> 
> There are several areas I consider important to the future of telephony
> and collaborative communications including the question of the telephone
> handset, an instrument traditionally of low quality audio reception.
> The interest in GNU Telephony Open Embedded, and in migrating client
> softphone development to embedded devices in general is related to our
> goal of eliminating the traditional handset altogether.
> 
> Part of this idea involves re-thinking audio as it relates to telephony.
> While some have focused on questions like narrow-band vs wide-band, and
> hence overall quality of audio at the expense of bandwidth, I have
> chosen to focus on something different; how we can treat audio as a
> "spacial" environment for the listener, and so I have been experimenting
> with false spacial positioning through regenerated and artificially time
> shifted stereo.
> 
> The real value of this comes into play when considering audio mixing for
> audio conferencing.  The traditional way to do this is to route all the
> participants audio into a common conference server, mixing the audio
> together, and feeding each user the mixed result, minus their own audio.
> 
> By maintaining multiple peer connections at the VOIP (Voice Over IP
> networks) client (VOIP telephone phone devices), it is possible to mix
> audio at the end point rather than at the server.  This means each
> connection can also be given a separate and distinct false spacial
> position in the resulting false stereo audio that you then hear.  It is
> far easier and more natural to have a multiparty conference without
> confusion when each speaker "appears" to be in a different spacial
> location then when you mix their signals together at some central point.
> 
> This also relates to the question of latency, which, particularly for
> VOIP, is a very important question.  In current VOIP networks, latency
> can often approach 1/4 of a second, which is enough to be disturbing and
> ineffective.  Each hop through a server, such as for mixing, or
> spoke-wheel configured centralized networks, adds significantly to
> latency, especially on poorly designed software, and hence even further
> reduces the quality of the call.  Peer to peer calling, besides offering
> greater privacy, also reduces latency by removing intermediary servers.
> 
> Other areas I have been exploring include ways to provide better
> security and privacy in VOIP, and not just by securing the audio channel
> with encryption.  Given recent events, I have come to consider it vital
> to hide even basic signaling and call session information.  In this
> area, I have looked at ideas like forward publishing and caching SIP
> location information through peer-to-peer networks for direct calling
> when trying to locate people, rather than depending on traditional SIP
> registrars and proxies which introduces signaling information at central
> control and intercept points.  My long term goal in VOIP is to introduce
> massively scalable and secure peer-to-peer calling services with a focus
> on endpoint development and which have no centralized control points.
> 
> * Legal issues & infrastructure
> 
> Of course, much of our vision for private, secure, and anonymous VOIP
> calling, including anonymous PSTN gateways, are things which I happen to
> consider a basic human right to privacy, and which fall well outside the
> scope of what will be permitted under new surveillance mandates such as
> those driven by CALEA.  This is one reason we are locating some specific
> VOIP work outside of the U.S.  We may need to do the same with current
> and future work in media servers should future digital restrictions
> mandates also appear, such as the broadcast flags.
> 
> I also have recently been able to consolidate much of our separate web
> resources into one place, under the new wiki.  This has made it much
> easier to consolidate project management overall.  As part of this
> process, I do plan to setup a bugzilla site to consolidate bug tracking.
> 
> Which particular area of the roadmap gets attention will depend on where
> we happen to find time, funding, and resources.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Bayonne-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bayonne-devel
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Bayonne-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bayonne-devel