[asterisk-gui] Opinion, what do you want in the gui for users?

Steven Sokol ssokol at sokol-associates.com
Fri Apr 13 09:28:03 MST 2007


On 4/13/07, Andrew Latham <lathama at lathama.com> wrote:
> Would a provisioning middle-ware be the better option. A system described below.
>
> Stations = MAC address
> Extensions = Stations
>
> 1. Station starts up and asks for DHCP
> 2. DHCP gives TFTP or CONFIG server per MAC (lots of work here)
> 3. TFTP or HTTP configs to the phones with correct settings (magic)
> 3.1 TFTP or HTTP system ask the manager interface for info for extension
> 3.2 TFTP or HTTP configs created and sent to Stations
> 4. Station registers
>

Possibly, but here's my goal in narrative form:

A user downloads/builds (or buys) an Asterisk with the GUI.  The
README tells him to go and install all of his phones (Polycom, Snom,
Linksys, Cisco, Grandstream, etc.), then run the discovery wizard.
The discovery tool does the following:

1) scans the LAN and finds devices.
2) Identifies them by either a SIP options response (using the User
Agent value) or simply by a MAC that fits within a known range for a
given manufacturer (is this data available?)
3) adds the devices to a list (conf file, database, etc.) of known endpoints.

The system then builds a "guest" account for each of the newly
discovered devices.  The device uses the MAC address to craft a config
file for the phone (to be downloaded via HTTP or TFTP) or uses
something like CURL to post a basic config to the phone.  The system
also creates a PEER entry in Asterisk (using users.conf?) that points
to a [guest] or [unknown] context.

This basic configuration allows the phone to dial 911, dial inside
extensions and to access the provisioning extension: the administrator
can dial an extension, log in using an ID and PIN and feed Asterisk
the new extension number for the phone via DTMF.

In a VERY simple system that's really all that needs to happen.
Asterisk will update the users.conf entry for the device and move it
to the [inside] or [users] or [default] context and that's that.  But
wait, that's not all....

In a truly integrated system the user would be able to log into an
AJAM-powered portal that allows them to control their system features
(i.e. features configured on Asterisk using the AstDB, etc.) but they
would ALSO be able to manage the buttons on their phone from the same
GUI.  They could set busy-lamp fields (BLFs), configure phone
features, etc. all from their portal page.

One thing that I would like to try to overcome is the dependence on
the DHCP->TFPT->HTTP chain.  In some cases the PBX administrator
simply won't be able to control the DHCP options system in order to
configure the TFTP option to point to the Asterisk system.  If we can
build a basic "push" system that can update the TFTP and/or HTTP
provisioning address on the most common brands of phone, we can avoid
having to manage the DHCP process or server.

Yes -- this may be a big pain.  However, we're trying to build
something that competes with the big telecom players and, in the next
few months, MicroSoft.  We need to make this as powerful and as easy
as possible.

-- 
Steven Sokol
CEO
Sokol & Associates, Inc.

Asterisk Training:  http://www.sokol-associates.com/
AstriCon 2007: http://www.astricon.net/


More information about the asterisk-gui mailing list