.titleBar { margin-bottom: 5px!important; }

[Asterisk-dev]-Mailingliste: Was kommt nach 1.0?

Dieses Thema im Forum "Asterisk Allgemein" wurde erstellt von rajo, 29 Sep. 2004.

  1. rajo

    rajo Admin-Team

    Registriert seit:
    31 März 2004
    Beiträge:
    1,958
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Moin,

    grade auf asterisk-dev gelesen (weiss ja nicht, wer da alles mitliest), u.U. interessiert es ja den ein oder anderen:

    Es geht um die neuen Ideen die auf der astricon zusammengetragen wurden, die man so (oder ähnlich) in die nächste Asterisk-Generation aufnehmen kann.

    From: Steven Sokol <>
    To: asterisk-dev@lists.digium.com
    Subject: [Asterisk-Dev] Wish List / Brain Storm from AstriCon
    Date: Tue, 28 Sep 2004 13:56:11 -0500

    Below is a set of notes I took at the show. If anybody else took detailed notes, please post them. Please pardon if I butchered any thoughts you may have voiced -- I did my best to keep up with the flow of ideas.

    Thanks,

    Steve



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



    _______________________________________________
    Asterisk-Dev mailing list
    Asterisk-Dev@lists.digium.com
    http://lists.digium.com/mailman/listinfo/asterisk-dev
    To UNSUBSCRIBE or update options visit:
    http://lists.digium.com/mailman/listinfo/asterisk-dev