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

Alvaro Oliver alvaro.oliver at gmail.com
Fri Apr 13 13:38:36 MST 2007


How about setting profiles?
An admin account may have access to every single tab in the GUI, while an
user account can just access some selected (by http.conf?) tabs.

-- 
Alvaro Oliver

2007/4/13, Brandon Kruse <bkruse at digium.com>:
>
>
> 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
> >>
> >
> >
>
> _______________________________________________
> --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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-gui/attachments/20070413/45744f64/attachment.htm


More information about the asterisk-gui mailing list