Hi,
Our product does most of this, and some things in a different way.
The only missing parts would be uploading MOH and speaking prompts through the phone, but these would be easily added.
Features: - multi tenanting - endusers have their own portal (stats, features, call history) - call recording - PPTP support for roving users (no more NAT problems) - automatically generates provisioning files for SNOM, Cisco, Polycom, and Grandstream phones. - Full Zaptel configuration, supports all Digium and the Junghanns card. - Add users and departments (for group pickup) - per company phonebook for fastdial and displaying a caller name on you phone (can import Excel sheets) - per enduser private phonebook. - upload you own sound prompts for IVR use. - configure IVR menus, configure queues. - companies can define trunks, and their incoming and outgoing dialplan - interfaces with [EMAIL PROTECTED] for small branches. - remote monitoring and configuration backups
And not to forget manuals, extensive english manuals for endusers that combine phone functions, and PBX functions into one comprehensive manual. Here's our list:
Astium Aastra480i Manual (beta) Astium Cisco 7940 7960 User Manual Astium Eyebeam User Manual Astium Grandstream Budgetone100 User Manual Astium Installation Manual Astium Operator Manual Astium Programmers Guide Astium SNOM 190 User Manual Astium SNOM 220 User Manual Astium SNOM 360 User Manual Astium Soundpoint300 User Manual Astium Soundpoint500 User Manual Astium Soundpoint600 User Manual Astium TAPI manual Astium Xten User Manual ISDN2GSM Gateway Installation Quad BRI Installation Manual Teleworker Installation Manual
The Astium is running on production sites in The Netherlands and Belgium.
Contact me offlist for more information, and see our website www.neonova.nl (click the english flag, and apologies if some texts are still in Dutch, we're working on that).
Regards, Ron Arts CEO NeoNova BV
C F wrote:
I'm looking for someone to develop an interface for Asterisk that will/can do the following:
1. Managing of extensions.conf 2. Managing of musiconhold.conf 3. Managing of sip.conf 4. Managing of voicemail.conf 5. Managing of Contexts within extensions.conf, sip.conf, and voicemail.conf
The basic Idea is to have a couple of macros to handle most of the bulk of the work, give each macro a description. Each macro will have arguments that make it work. The description will explain what each argument does, and if it is required or not. Then when adding an extension it will just ask what macro to use, and ask the user to fill in the arguments. Since it has to be context aware the idea is to have the interface allow the user to add a company, then to each company it will allow to add extensions, music on hold, voicemail, SIP devices, and IVRs. Each extensions will have to be part of a company (context). For DIDs there should be a way of allowing the user to add DIDs, change music on hold, and what each DID does, dump to a company's IVR, or dump to an extension. There should be a way to add IVRs for each company, the way it will work is that it will include the extensions context that belongs to each company. It ends up requiring the following for each company to function: A. context for DID's where they start and from there jump to any existing extension in the dialplan, setting musiconhold on the way. B. context for each company's' devices which will include the rest of the company's' contexts (outbound, extensions, and feature set). C. context for each company's' outbound dialing rules and routes. D. context for each company's' IVRs, mutiple IVRs for each company, open, closed, etc.
There should also be a context that is shared (or could be shared/disabled according to company) which will hold the feature set (like Call Forwarding etc).
The flow of such an interface will look something like this: 1. User adds company 2. User adds music on hold 3. User adds extensions to company, assigns the desired macros to each extension, and create the voicemail entry if requested, as well as allow to include the features context. 4. User adds outbound dialing rules 5. User adds IVRs to company 6. User adds DID to extensions/and IVRs
The interface will do the following corresponding to the above: 1. Adds a blank context 2. add the class in musiconhold.conf, as well as allow upload of mp3 files. 3. Will create an additional context for the devices that includes context from step one (perhaps the same name prefixed with something like d), The main feature context, Will create the same context in voicemail.conf, Will create sip accounts for each extension, and assign the music on hold setting from #2 and assign context d above. Will create an additional context (lets call it prefixed with ext) that will include the lines to dial the extensions, this context will be included in the main companys context (#1 above), Will create a line for that extension in extensions.conf that will call a macro that will actualy complete the call for this extension. Create Voicemail setting in voicemail.conf if selected to do so. 4. Add an outbound context (prefixed with outdial) for that company that is included in the devices context (context d above). 5. Will just create a context (going with the naming from before, will be prefix ivropen, ivrclosed, for ivrs that play when open and closed. For the options presented please see below. 6. Will just reference the DIDs (which will initially be dumped into one big context - lets call it from-pri) to jump to a context,extension,priority, but first it will set the music on hold class.
*IVR* For an IVR there is only a limited amount of functions that we need, each function (with the exception of the playback functions, that is just the first/few step/s in an IVR) can be assigned to one of 12 keys (0-9, *, and #). When a key is pressed it will just do what that key is assigned to do using the relevant command. The functions are: 1. Call (dial) devices 2. Go to another IVR (sub menu) 3. Play messages (always in the background, so users can select a choice) 4. Go to a voicemail box (context should be automatic, since we know which companys IVR it is) 5. Hangup 6. Repeat the current menu (same as #2)
The recordings will be done using a phone and a special extension that will be in the features context. The only thing selected in the interface regarding playback of messages will be the massage number.
*Features Context* The features context will just be a collection of extensions that will allow users extra functions to their phones, i.e. call forwarding, follow me, etc. This context does not have to be manageable, just has to be included in the main context that devices for each company use (d above).
*SIP Devices* Since not all sip devices are the same and some need different settings, and/or work only a certain way with asterisk, I implement sip devices using one of 2 ways: 1. Each phone gets one SIP account, and only that sip account is used thruout any dial command in the system. 2. Each phone gets multiple sip accounts (for multi line appearance phones, like the polycoms) which is named appended with 1 for the first one, 2 for the second and so on. For example when I add a Polycom IP500 which has 3 line appearances to my asterisk system, that will be called extension 101, then I add 3 accounts in sip.conf, 1011, 1012, and 1013, that way I can just dial it using Dial(${EXTEN}1........ and so on. Therefor the function in the interface that creaes sip accounts should also have an option of: either selecting with set (range) of sip devices to use, in which case the creation of sip accounts step will be ignored, because it will be assumed to have been created by other means (read below). Or it should ask the user how many accounts to append, and then append that amount, however only if the number to append is more than 0 should there be appended anything, otherwise it should be created as 101 with the example from above. I actually prefer that both methods are available. The dialing to such phones will be done thru macros. There should also be an extra interface for creating multiple sip phones and their contexts and music on hold settings (maybe import export function), that way both of above can be utilized.
*Others/Notes* *The macros do *NOT* have to be modifiable in any way thru the interface. *Although I used user throughout this email. The interface is meant *ONLY* for an admin of the whole system, and *NOT* for an admin/user of each company.
*Optionals* *An interface to allow the upload, creating, and editing of files to tftpboot directory, for Cisco, and Polycom phones. *An interface to allow to add buttons to FOP (www.asternic.org)
_____________________________ I think the above covers it all. If you think you can do it please contact me at shmaltz at gmail dot com, the time frame for completion is yesterday. _______________________________________________ Asterisk-Biz mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-biz
-- NeoNova BV, The Netherlands Professional internet and VoIP solutions
http://www.neonova.nl Kruislaan 419 1098 VA Amsterdam info: 020-5628292 servicedesk: 020-5628292 fax: 020-5628291
The following disclamer applies to this email: http://www.neonova.nl/maildisclaimer _______________________________________________ Asterisk-Biz mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-biz
