[asterisk-dev] code-cleanup concerns

[Mike Taht]

On 4/15/06, Steve Underwood <steveu at coppice.org> wrote:

> I think you might be a little confused. The primary goal of Asterisk
> development is to make the patches in Mantis rot, until their developers
> finally get tired of updating them and cease all contributions to
> Asterisk. I thought everyone here knew that.
>
> Regards,
> Steve


Up until the switch to svn at the beginning of the year the situation with
getting patches into asterisk was unbearable.

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")

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...

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
http://www.sineapps.com/news.php?rssid=139 for details).... perhaps a review
of where all this is at is in order:

*== Mark's Roadmap for Post 1.0 ==
*
1. Restructure Caller*ID
2. IAX2 Registration Stuff -
3. SQLite instead of db1 -
4. IAX2 Encryption -
5. Voicemail Storage API -
6. Unified audio pipe structure for translation, generator, monitor, spying,
etc. ?
7. Database standardization
8. Common User Configuration
9. Do something about the number of variables per channel
10. Unify features where possible
11. Generic Asterisk hash w/ multi-view structure for storing important info
12. GTK-Like reference counts (ref/un-ref)
13. Move jitter buffer out of IAX2, optionally to Zap.
*== Brainstorm Session Ideas ==*

1) Scripting & Testing features for lab testing of large installations
without forcing the customers to become "beta customers".

2) Better manager API with web services and additional control.

3) Load balancing solutions for IVR.

4) Decouple RTP from Chan SIP, Chan H323. Abstraction layer.

5) Module system for Asterisk. Configuration system separated from the main
workings of the system. Replace the configuration processor with a new
modular setup.

6) Enum channel improvements to support better interconnection from VoIP to
PSTN. Avoids the peering issue. Helps the conversion from one tech to
another.

7) Standardized status manager. Smaller than SOAP. XML-RPC. (Addendum: .92
version w/o schemas)

8) Pluggable modules for manager to integrate Jabber and other technologies.

9) Close integration of Asterisk w/ Festival and Voice Recognition
technologies.

10) IBM's open-source speech recognition software

11) Intel's soft-DSP chips for some advanced management of media streams.

12) Dynamic routing protocol - ARP (Asterisk Routing Protocol). Dynamic
extension - (ENUM).

13) Voice frame size available in chunk sizes beyond 20ms.

14) Redundancy and registration in IAX2 protocol

15) Certification program for Asterisk - hardware and software. Additional
approvals in other markets.

16) IAX2 standards track - RFC submission

17) Assembler coding of codec handlers for improved performance.

18) Asterisk in the ISP community (transition from dialup to TSP service)

19) More consideration of Euro ISDN in the libpri. Also Caller*ID for other
nations.

20) A language syntax module and API.

21) Improvements to the ACD to improve call-center operations. Especially
outbound functions.

22) QSIG - Help people migrate to Asterisk. (Q931 can help cover some
additional channel functions).

23) Extensions to SIP for business applications (BLF, etc).

24) Database integration of Asterisk.

25) Additional error codes in IAX2.

26) Submit internal documentation to the *Docs project.

27) Update the docs with each patch and change.

28) Extended absence greeting for Voicemail. (Russell from AdTran has this).

29) No documentation on the APIs (for the Zaptel channel?) and no QSIG.
Scalability issues for multi-chassis operation.

30) Operator console for Asterisk. SIP has holes that make operator console
difficult to configuration. DSP Guy - Tampa telecom provider.

31) Greg Boehnlein - Load balancing of IAX2 across w/ Monkey? Also the
astwind guy.

32) Support for additional SIP headers (auto answer, ring tone, etc.)

33) Multiple national ring-back options. Pluggable internationalization of
ringtones.

34) Additional video codecs. More than H261, H263.

35) SS7 Support for Asterisk. Malcolm will set up a mailing list. A new
development group is forming. Email: asterisk-ss7 [at] flanet [dot]
[net]<asterisk-ss7 at flanet.net>

36) Fault tolerance and failover technologies.

37) R2 Integration (along with SS7 and QSIG).

38) HFC cards for doing BRI. Low cost BRI cards.

39) Move from GLIB C to MicroLib C for better support of embedded systems.

40) T.38 fax support over Asterisk (pass-through).

41) What happened to SpanDSP? Steve Underwood. Had to drop the project. May
pick it back up again.

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).

43) MOH from other source - not just MP3.

44) Auto-Execution of "@" values in the dial-plan.

45) Labels in the dial plan.

*== Suggestions from AsterLink Page ==*

1) Build a translation matrix
a virtual codec translation CPU
to abstract the codec translation
tasks to 1 place that is optimized.

2) Make Extensions a public object
and allow independant creation/execution
eg build an ext ext = ast_ext_new();
add/remove priority etc ast_ext_add_pri(ext,1,"Dial(Zap/1)"
execute the extension. ast_ext_execute(ext);

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

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.

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.

6) Make 100% of applications loadable -- to make #5 more effective.

7) Introduce thread/memory/channel Pools all 3 are used way to much to keep
alloc/dealloc'ing them

8) Abstract the stream obj from the channel so you can build and open
streams to homemade objs not just channels

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

10) find everything in common between voip channels and implement it as a
seperate object as a sort of pbx-wide "account"

11) chan_prioip for Local area network ferry of pri w/o disturbing the
protocol. (TDMOE?)

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...\

*== Dial Plan/AGI Session ==*

Auto execute stuff.

Global options to the "default ending" extension. A default to hangup?

Addition of a label

Addition of ability to execute macros in the middle of a call (during a call
nailed up by Dial).

Renumbering dial plans - (10, 20, 30 instead of 1,2,3 only).

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?

AGI over TCP - AGI://localhost/script or AGI://some.server.com/script (Port
4573) to run remote AGI sessions. FastAGI.

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.

Call progress information made available to the AGI interface (very hard to
do because the system is synchronous).


*== Managing Asterisk - Manager API, XML Web Services, Etc. == *

Manager Proxy and/or broker. Somebody from Rhodes university has done some
of this.

Flash operator console uses a similar daemon. Perl-based system. A start.
AsterNic?

Some data is lost when information is returned across the manager (when
executing CLI commands).

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.

SNMP support for Asterisk.

Voice quality monitoring?

Frame slip warnings and more across SNMP. Essentially alarm forwarding as
SNMP.

Web services for manager API.

*== The Asterisk User - A Missing Concept ==*

Common users concepts can be done today using a number of techniques.

Check out the IAX2 Provisioning stuff.



_______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>



--
Mike Taht
PostCards From the Bleeding Edge
http://the-edge.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20060415/178db700/attachment.htm