[Asterisk-biz] GUI for Managing Asterisk.

[Ron Arts]

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 asterisk at home 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
> Asterisk-Biz at lists.digium.com
> 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