[asterisk-gui] Opinion, what do you want in the gui for users?
Brandon Kruse
bkruse at digium.com
Fri Apr 13 12:42:16 MST 2007
I totally agree,
If you guys want to start working on the GUI, go for it.
I would love to get more community members involved, this discussion
alone is priceless, slowly defining exactly what the user wants and
what would be awesome.
The provisioning stuff, we will see. Alot of things must be integrated
into asterisk as well, we will see.
I like where the discussion is going though, keep it up!
-brandon
Facundo Ameal wrote:
> Steven,
> It would be wonderful to have every feature you are talking about.
> I 'll try to help in improving the GUI. Count on me.
>
> Greets.
>
> On 4/13/07, Tzafrir Cohen <tzafrir.cohen at xorcom.com> wrote:
>> On Fri, Apr 13, 2007 at 11:28:03AM -0500, Steven Sokol wrote:
>> > 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:
>>
>> The idea with provisioning is automating. If it is not automatable
>> (scriptable), then it remains a non-useful GUI feature.
>>
>> >
>> > 1) scans the LAN and finds devices.
>>
>> How?
>>
>> For Cisco phones: using cdpr?
>>
>> What other method? scan UDP port 5060 over the LAN?
>>
>> > 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.
>>
>> Is there any decent "dynamic" tftp daemon?
>>
>> Be that by the way of proxying content to a nearby httpd.
>>
>> --
>> Tzafrir Cohen
>> icq#16849755 jabber:tzafrir at jabber.org
>> +972-50-7952406 mailto:tzafrir.cohen at xorcom.com
>> http://www.xorcom.com iax:guest at local.xorcom.com/tzafrir
>> _______________________________________________
>> --Bandwidth and Colocation provided by Easynews.com --
>>
>> asterisk-gui mailing list
>> To UNSUBSCRIBE or update options visit:
>> http://lists.digium.com/mailman/listinfo/asterisk-gui
>>
>
>
More information about the asterisk-gui
mailing list