<br><br><div><span class="gmail_quote">On 4/15/06, <b class="gmail_sendername">Steve Underwood</b> <<a href="mailto:steveu@coppice.org">steveu@coppice.org</a>> wrote:</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think you might be a little confused. The primary goal of Asterisk<br>development is to make the patches in Mantis rot, until their developers<br>finally get tired of updating them and cease all contributions to<br>Asterisk. I thought everyone here knew that.
<br><br>Regards,<br>Steve</blockquote><div><br>Up until the switch to svn at the beginning of the year the situation with getting patches into asterisk was unbearable. <br><br>Now, at least, with olle's test-this-branch, there's something of a linux-mm thing happening, which has broken some but not all of the bottlenecks. I would love to see asterisk get on a 6-8 week development cycle similar to that of the one of the kernel, with some sort of explicit contract to the frustrated developers - "OK, your patch is going into the mainline on the next cycle, be ready")
<br><br>so (and with a little competition from projects like freeswitch) - it's getting better, but is still way too painful (unless you are already used to the pain of trying to get a arm patch into glibc, for example). There are a bunch of out of tree modules that are effectively unowned now (format_mp3, chan_bluetooth) and a few worthy ones (like steve's fax work) that need some love from asterisk central and more testers...
<br><br>At the same time, when there are major architectural changes happening (like the changes to the loader), it's hard to keep everything working without maximum breakage. I did take a look at the roadmap laid down at last year's astricon and felt a lot better about things (see
<a href="http://www.sineapps.com/news.php?rssid=139">http://www.sineapps.com/news.php?rssid=139</a> for details).... perhaps a review of where all this is at is in order:<br><br><font face="ARIAL" size="2"><font size="2">
<b>== Mark's Roadmap for Post 1.0 ==<br></b>
<br>
1. Restructure Caller*ID<br>
2. IAX2 Registration Stuff - <br>
3. SQLite instead of db1 - <br>
4. IAX2 Encryption - <br>
5. Voicemail Storage API - <br>
6. Unified audio pipe structure for translation, generator, monitor, spying, etc. ?<br>
7. Database standardization<br>
8. Common User Configuration<br>
9. Do something about the number of variables per channel<br>
10. Unify features where possible<br>
11. Generic Asterisk hash w/ multi-view structure for storing important info<br>
12. GTK-Like reference counts (ref/un-ref)<br>
13. Move jitter buffer out of IAX2, optionally to Zap.<br>
</font></font><font face="ARIAL" size="2"><font size="2"><b>== Brainstorm Session Ideas ==</b><br>
<br>
1) Scripting & Testing features for lab testing of large
installations without forcing the customers to become "beta customers".<br>
<br>
2) Better manager API with web services and additional control.<br>
<br>
3) Load balancing solutions for IVR.<br>
<br>
4) Decouple RTP from Chan SIP, Chan H323. Abstraction layer.<br>
<br>
5) Module system for Asterisk. Configuration system separated from the
main workings of the system. Replace the configuration processor with a
new modular setup.<br>
<br>
6) Enum channel improvements to support better interconnection from
VoIP to PSTN. Avoids the peering issue. Helps the conversion from one
tech to another.<br>
<br>
7) Standardized status manager. Smaller than SOAP. XML-RPC. (Addendum: .92 version w/o schemas)<br>
<br>
8) Pluggable modules for manager to integrate Jabber and other technologies.<br>
<br>
9) Close integration of Asterisk w/ Festival and Voice Recognition technologies.<br>
<br>
10) IBM's open-source speech recognition software<br>
<br>
11) Intel's soft-DSP chips for some advanced management of media streams.<br>
<br>
12) Dynamic routing protocol - ARP (Asterisk Routing Protocol). Dynamic extension - (ENUM).<br>
<br>
13) Voice frame size available in chunk sizes beyond 20ms.<br>
<br>
14) Redundancy and registration in IAX2 protocol<br>
<br>
15) Certification program for Asterisk - hardware and software. Additional approvals in other markets.<br>
<br>
16) IAX2 standards track - RFC submission<br>
<br>
17) Assembler coding of codec handlers for improved performance.<br>
<br>
18) Asterisk in the ISP community (transition from dialup to TSP service)<br>
<br>
19) More consideration of Euro ISDN in the libpri. Also Caller*ID for other nations.<br>
<br>
20) A language syntax module and API.<br>
<br>
21) Improvements to the ACD to improve call-center operations. Especially outbound functions.<br>
<br>
22) QSIG - Help people migrate to Asterisk. (Q931 can help cover some additional channel functions).<br>
<br>
23) Extensions to SIP for business applications (BLF, etc).<br>
<br>
24) Database integration of Asterisk.<br>
<br>
25) Additional error codes in IAX2.<br>
<br>
26) Submit internal documentation to the *Docs project.<br>
<br>
27) Update the docs with each patch and change.<br>
<br>
28) Extended absence greeting for Voicemail. (Russell from AdTran has this).<br>
<br>
29) No documentation on the APIs (for the Zaptel channel?) and no QSIG. Scalability issues for multi-chassis operation.<br>
<br>
30) Operator console for Asterisk. SIP has holes that make operator
console difficult to configuration. DSP Guy - Tampa telecom provider.<br>
<br>
31) Greg Boehnlein - Load balancing of IAX2 across w/ Monkey? Also the astwind guy.<br>
<br>
32) Support for additional SIP headers (auto answer, ring tone, etc.)<br>
<br>
33) Multiple national ring-back options. Pluggable internationalization of ringtones.<br>
<br>
34) Additional video codecs. More than H261, H263.<br>
<br>
35) SS7 Support for Asterisk. Malcolm will set up a mailing list. A new development group is forming. Email: <a href="mailto:asterisk-ss7@flanet.net">asterisk-ss7 [at] flanet [dot] [net]</a><br>
<br>
36) Fault tolerance and failover technologies.<br>
<br>
37) R2 Integration (along with SS7 and QSIG).<br>
<br>
38) HFC cards for doing BRI. Low cost BRI cards.<br>
<br>
39) Move from GLIB C to MicroLib C for better support of embedded systems.<br>
<br>
40) T.38 fax support over Asterisk (pass-through).<br>
<br>
41) What happened to SpanDSP? Steve Underwood. Had to drop the project. May pick it back up again.<br>
<br>
42) Steve Underwood may be working on R2? Working on Class 1 and 2
support in his Span DSP. He is looking for support (financial and/or
technical).<br>
<br>
43) MOH from other source - not just MP3.<br>
<br>
44) Auto-Execution of "@" values in the dial-plan.<br>
<br>
45) Labels in the dial plan.<br>
<br>
<b>== Suggestions from AsterLink Page ==</b><br>
<br>
1) Build a translation matrix <br>
a virtual codec translation CPU<br>
to abstract the codec translation<br>
tasks to 1 place that is optimized.<br>
<br>
2) Make Extensions a public object <br>
and allow independant creation/execution<br>
eg build an ext ext = ast_ext_new();<br>
add/remove priority etc ast_ext_add_pri(ext,1,"Dial(Zap/1)"<br>
execute the extension. ast_ext_execute(ext);<br>
<br>
3) Destroy manager and make an internal eventing system then rebuild it
using this system. Also allow chan obj to have bindable event handlers
chan->onHangup chanonDtmf<br>
<br>
4) Redo the way a bridge is done so it doesn't live in res_features.
Extend the bridge_config obj to go down into native bridge and utilize
#3's eventing system more.<br>
<br>
5) Make modules stackable so you can load a new copy of the same module
and send new requests to the highest version on the stack. so you can
replace code without restarting.<br>
<br>
6) Make 100% of applications loadable -- to make #5 more effective.<br>
<br>
7) Introduce thread/memory/channel Pools all 3 are used way to much to keep alloc/dealloc'ing them <br>
<br>
8) Abstract the stream obj from the channel so you can build and open streams to homemade objs not just channels<br>
<br>
9) Extend IAX to allow a registration to send back a specific IP to
place new calls that can be different from the registration server and
perhaps round robin host= entries to allow calls to a specific iax peer
to rotate several ip's<br>
<br>
10) find everything in common between voip channels and implement it as a seperate object as a sort of pbx-wide "account"<br>
<br>
11) chan_prioip for Local area network ferry of pri w/o disturbing the protocol. (TDMOE?)<br>
<br>
12) Start 1.2 and 2.0 at the same time (today) so some drastic changes
can be made now and not have any dependency on legacy issues...\<br>
<br>
<b>== Dial Plan/AGI Session ==</b><br>
<br>
Auto execute stuff.<br>
<br>
Global options to the "default ending" extension. A default to hangup?<br>
<br>
Addition of a label <br>
<br>
Addition of ability to execute macros in the middle of a call (during a call nailed up by Dial).<br>
<br>
Renumbering dial plans - (10, 20, 30 instead of 1,2,3 only).<br>
<br>
Matt has a hunk of code to allow macros to be executed when a keystroke
interrupts the Dial application. Can this be used to start/stop the
Monitor application?<br>
<br>
AGI over TCP - AGI://localhost/script or AGI://some.server.com/script (Port 4573) to run remote AGI sessions. FastAGI.<br>
<br>
AGI debugging is a huge pain in the ass. Can we build a better debugger
for AGI? AGI debug option to make all communication print.<br>
<br>
Call progress information made available to the AGI interface (very hard to do because the system is synchronous).<br>
<br>
<br>
<b>== Managing Asterisk - Manager API, XML Web Services, Etc. == </b><br>
<br>
Manager Proxy and/or broker. Somebody from Rhodes university has done some of this.<br>
<br>
Flash operator console uses a similar daemon. Perl-based system. A start. AsterNic?<br>
<br>
Some data is lost when information is returned across the manager (when executing CLI commands).<br>
<br>
Adding logging and more to the manager interface so that the debugging
information so that debugging can be sent across the wire to a remote
box.<br>
<br>
SNMP support for Asterisk.<br>
<br>
Voice quality monitoring?<br>
<br>
Frame slip warnings and more across SNMP. Essentially alarm forwarding as SNMP.<br>
<br>
Web services for manager API.<br>
<br>
<b>== The Asterisk User - A Missing Concept ==</b><br>
<br>
Common users concepts can be done today using a number of techniques. <br>
<br>
Check out the IAX2 Provisioning stuff.</font></font><br><br></div><br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">_______________________________________________
<br>--Bandwidth and Colocation provided by <a href="http://Easynews.com">Easynews.com</a> --<br><br>asterisk-dev mailing list<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">
http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br>Mike Taht<br>PostCards From the Bleeding Edge<br><a href="http://the-edge.blogspot.com">http://the-edge.blogspot.com
</a>