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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > 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 > [email protected] > http://lists.gnu.org/mailman/listinfo/bayonne-devel > > > ------------------------------------------------------------------------ > > _______________________________________________ > Bayonne-devel mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/bayonne-devel
_______________________________________________ Bayonne-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bayonne-devel
