Scott Lawrence wrote: > Having just helped a large customer to work through a bunch of dial > plan issues, I have a set of suggestions for how we display them. I > share them below to stimulate discussion... > > Here's a screen shot > <http://sipx-wiki.calivia.com/images/f/fd/DialPlan.png> (posted to the > wiki because it's too big for the list) taken from an HTML mockup I did > (the colors are a bit odd due to interactions between my personal color > preferences and the stylesheet): > > The improvements I'm suggesting are: > > 1. The internal and external rules are separated and ordered > independently. This reflects how the rules really work - all > rules that do not route to a gateway go in mappingrules.xml, and > all that do route to a gateway go in fallbackrules.xml; each file > is searched in order, mappingrules first - and fallbackrules is > not used unless no other source of routing information (including > aliases, registrations, mappingrules, etc) found a way to route > the request.
Makes sense - there should be 2 tables there. > 2. I removed the Type column. Mostly, I did this to make room, but I > also think that it has little value in helping to read and > understand an existing dial plan. > 3. I moved Schedule next to Enabled/Disabled because it reads more > naturally that way than having it widely separated. > 4. I added annotations to the Enabled column (could be somewhere else > or a column by itself) whenever an earlier rule masks (matches) > all or part of the same pattern: > > ⇑ when some numbers matched by this rule would be matched by > an earlier rule > ∅ when all numbers matched by this rule would be matched by an > earlier rule (making this rule a no-op) > > with tooltips when you hover over those annotations that tell you > which earlier rule(s) overlap. > > > 5. I replaced Description (which says what the administrator thought > the rule did) with three columns that display what it actually does: > > Match > > Displays any fixed digits and the number of variable digits > matched by the rule. > > Send > > Displays how the user part (phone number, usually) is modified > by the rule on output. > > To > > Displays what gateway (for external) or service (for internal) > the rule sends the request to. > > The existing Descriptions are probably valuable, but I'd move them > to a tooltip that displays if you hover over the Name, or something > along that line. > I like it. This is the oldest screen in sipXconfig at the moment. And the changes that you are proposing would be quite easy to implement. I am actually not sure what exactly can be shown in Match and Send columns since the real examples are way more complicated than what you have in the table, but anything is better that what we have now. Add the issue... D. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
