My suggestions are all in the 'preparing to deploy' category as I haven't 
successfully gotten further in the last 3 months. I'm 100% in the newbie 
category so some of this is likely to sound pretty dumb. These are things that 
looking back over the last months have burned the most time or were most 
confusing coming in from the cold.

1)

Portable configuration export/import. I've re-entered the configuration for a 
group of 10 or so phones, users, bridge, etc so many times while testing I can 
see the entries on my retina when I close my eyes. I'm not looking forward to 
ever upgrading again once I get this working.

As a user this would be a fantastic aid to keeping up with new releases as it 
would take a huge hurdle from transitioning from a test server to a production 
server. It would even be very useful if only some subset was generically 
exportable with an 'error' if you used a feature that isn't easily portable to 
a new release. I really want to take my production environment and copy over to 
a test server in a sandbox, play with it, then go back once its all working.

2)

UI supported debugging of call progress (or lack thereof).  It would make life 
much simpler while getting things working to be able to merge the logs then 
select from the calls that occurred and get a nice (even static/graphvis style) 
display of the action right after an attempt. Especially WRT setting up SIP 
trunking. Its not too hard once you've been indoctrinated to run merge-logs 
then sipviewer over X but its a fairly long climb and is cumbersome enough that 
you *really* have to need to look before you do it (and waste lots of time 
trying alternatives instead of just looking at what really happened).

3)

This is less of a product feature and more of a 'support' feature: A clear and 
maintained definition of 'known to work' hardware and provider info. In the 
last 3 months I've been working with sipxecs this has been the #1 time sink 
(trying and failing due to various issues with differing gateway and telephone 
hardware).

4)

Clarify the phone groups vs individual phone configuration. I've gotten jammed 
up several times by spraying settings between 2 groups and each phones config. 
Once you enter phone settings into a group they're sort of 'lost' if you don't 
independently keep track of things. Its also confusing that groups can contain 
phones of different models then when you go to change settings you get a menu 
that shows all the models -- I sure expected that each model within the group 
would be separated then was surprised when 335 specific settings ended up on 
650's (thus pushing me to use multiple groups, Polycom, Polycom 335s, Polycom 
650s, etc).

This was easily the most confusing aspect as a complete virgin user (and likely 
I still don't fully understand the intent of the design and how to use it as 
intended).

5)

Allow some persistent level of override/control of the phone configuration for 
Polycoms. Its great to tell people they should just update the velocity 
templates but that's really a developer thing and no management/backup is 
available if you go there (its also hard to target specific phones). As a 
newbie not knowing any better I read about how to fix some feature on the phone 
(for instance the changeable line/function keys on the new IP 335's) and 
there's no support in the templates; I just want to put the damn setting from 
the polycom manual in somewhere and get it over with. The Polycom root level 
config files support this easily but since sipxecs just *has* to own every 
aspect of the phone config and not allow a 'user' config file that comes first 
it really gets in the way. Tieing a sipxchange release to a specific phone 
firmware version (which may no longer be available) is also problematic; an 
override system that let you work around minor issues until real support was a
 vailable would be greatly appreciated.

-Eric

> Specifically, what are your top 5 suggestions for how to simplify
> sipXecs?  For this thread, we are _not_ asking for what your favorite
> missing power telephony features are (we'll do some of those too) - we
> want to know how to make the features we've got easier to understand and
> use.  What are the things that you have to jump through hoops to do
> (especially if you have to do them more than once)?  What are the things
> you constantly have to explain to users?  What are the things you know
> how to do but it's just a little irritating ever time you have to do
> them?  Try to think back to your first experiences - what was hard
> before you knew what you were doing (newbies - this is your chance to
> jump in and contribute even before you know what you're doing!) ?  
_______________________________________________
sipx-users mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
sipXecs IP PBX -- http://www.sipfoundry.org/

Reply via email to