GSoC Ideas
This page is for drafting ideas. The official ideas page is here: http://adhearsion.com/gsoc. Pull requests welcome.
Possible projects:
Support for internationalisation built in to the framework as a first class feature, ensuring that applications are built internationalisation-ready by default with little effort. Should include both prompt files and TTS, and allow for a variety of methods for adding languages to an application, including a UI.
Create new Adhearsion CallController methods for collecting and interpreting speech, and renovating the existing input methods to handle prompt barge-in correctly.
Many applications which implement IVR functionality have to create a state machine for dialogs by hand, and write tests for them. Baking in support for a declarative IVR DSL to standardise this and centralise the implementation and testing burden would simplify many of these applications and make them faster to write and cheaper to maintain, as well as more understandable.
Adhearsion currently has no support for audio mixing. Adhearsion needs to be able to track state for mixers, including participant details, simple joining and management, seamlessly moving collections of calls into a mixer, etc. This would include adding support for mixers on Asterisk based on ConfBridge.
- Allow hotdesking (login via user ID + PIN)
- Select from multiple distribution methods (round-robin, least-recently-used, ring-all)
- Configure multiple queues
- Handle agents logging in and out of individual queues
- Visualization for agents logged-in, calls waiting in queue
Depends on first class mixer support
Short list of possible features:
- Enable PIN-based conference logins
- Creation of conference rooms via web UI
- Invite/Kick/Mute/Unmute individual call legs via web UI
- Create separate listen-only PINs and speaker PINs for the same room
- Add support for missing TwiML syntax
- Add unit tests
- Create example apps
Often, after creating an Adhearsion application, we need to test it at scale. This usually means hand-crafting a SIPp profile and associated pcap-formatted audio file to test the application. It's a time-consuming process, and much of it could be automated. The idea is to be able to specify the load test actions in a simple format, likely YAML, and have a program convert that YAML to XML and a PCAP file. A prototype (not using SIPp) can be seen in ahn_loadbot.
The features:
- Take a YAML with simplified syntax and use it to generate an XML file and a PCAP audio file suitable for use with SIPp
- Ability to quickly set DTMF playtimes during the call (after pickup, wait 10 seconds, then 1-2-3..), play media, automate run-throughs of full stack components
- Use queuing mechanism to allow for high concurrency.
- Create a browser-accessible live dashboard showing the number of active calls, the number of completed calls, and the number of calls resulting in error