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 (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.
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.
_______________________________________________
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/
