Nice to see my mailbox overloaded on monday morning because a lot of
people have a lot of whishes :-)
Like most people I am already very happy with the current product.
I have worked with CUCM as well and SipX is much better structured
and much easier to set up and configure.
I therefore think there is not so much to simplify, it is almost
impossible to make the product as such easier.
But it can be extended in some areas of course.
4.2 seems to make a big step with web conferencing, XMPP and much, much
more.
What I would like to see is:
1) A "components and functions" section on the wiki explaining what they
do and how they all interwork.
For example, with 4.2 coming (XMPP) I am wondering how everything will
interact and what part of the software will be doing what.
SIP is to initiate/terminate a session between 2 or more devices and
transports SDP information.
It also transports presence information.
In 4.2 we will get XMPP. What does XMPP do? Will SipX be a "gateway"
between SIP and XMPP clients.
(I am a NOOB on XMPP)
2) A "best practice" section on the wiki describing what the best setup
would be for a 100, 500 and 1000+ user system.
What type of servers are needed and how should the different functions
(Voicemail etc) be distributed over them.
It would be nice to have real-life examples as well of some interesting
installations that people have made.
3) Better support for softphones like Bria Pro (currently no dial plan,
the webdav section is minimal etc)
I want to help here as well, but don't know how.
4) Extension of dial plan options (more people asked for this)
More specifically: I would like to create dialplans based on location
to support multiple sites from one SipX installation
(Remote Branch Office support in 4.2?)
and be able to modify the calling-number as well (remove sitecode if
intrasite call).
5) It is very difficult, but it would be nice if more information could
find its way from the mailing list to the wiki.
There is a lot in the wiki, more in the mailinglist and some
information is in other hands.
I am happy I found SipX. I learned a lot using SipX and reading the
mailing list.
That it may 'Live long and prosper'
Best regards / Mit freundlichen Grüßen / Sincères salutations
Paul Scheepens
[email protected] wrote on 22-01-2010 23:09:08:
> From:
>
> [email protected]
>
> To:
>
> [email protected]
>
> Date:
>
> 22-01-2010 23:09
>
> Subject:
>
> sipx-users Digest, Vol 71, Issue 192
>
> Sent by:
>
> [email protected]
>
> Send sipx-users mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://list.sipfoundry.org/mailman/listinfo/sipx-users
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of sipx-users digest..."
> Today's Topics:
>
> 1. Simplify, Simplify, Simplify (Scott Lawrence)
> 2. Re: Simplify, Simplify, Simplify (Michael Scheidell)
> 3. Re: Simplify, Simplify, Simplify (Online Systems)
> 4. Re: Simplify, Simplify, Simplify (Josh Patten)
>
> ----- Message from "Scott Lawrence" <[email protected]> on Fri,
> 22 Jan 2010 16:23:34 -0500 -----
>
> To:
>
> sipXecs users <[email protected]>
>
> Subject:
>
> [sipx-users] Simplify, Simplify, Simplify
>
> As we begin to home in on release 4.2, we're starting to formulate plans
> for what comes next...
>
> First, I want to reassure the community - Avaya is very much committed
> both to the SCS commercial product (see roadmap announcements made this
> week), and to leading, contributing to, and materially supporting the
> sipXecs open source project. There most assuredly will be versions
> beyond 4.2, and we're committed to making them better with every
> release.
>
> Which brings me to the Subject of this request for community input. One
> of the major strategic goals of the release after 4.2 is to make sipXecs
> simpler. Simpler to install, simpler to administer, simpler for end
> users to use. Nice goal, huh? Motherhood is good, Apple Pie is very
> good, and Simplicity is great - I'm glad we all agree :-)
>
> Now comes the challenging part - what is simplicity? We'd like to hear
> what the community thinks...
>
> 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!) ?
>
> This is not like those dumb Microsoft advertisements where one doofus
> after another takes credit for Windows 7 (really - would anyone actually
> want to take _credit_ for Windows?) - we really want to know.
>
> I'm going to suggest one more thing for this thread - that developers
> just read and not post. In particular, in this thread: don't explain
> that something our users think is hard is actually easy, or tell them
> why it's hard, or suggest how we might fix it, or chime in here and now
> with your ideas. We'll have our turns to process all this more actively
> later and elsewhere - this thread is about listening to our users pain.
> Hear, be inspired, and get motivated.
>
>
>
>
>
>
> ----- Message from Michael Scheidell <[email protected]> on Fri,
> 22 Jan 2010 16:30:13 -0500 -----
>
> To:
>
> [email protected]
>
> Subject:
>
> Re: [sipx-users] Simplify, Simplify, Simplify
>
> On 1/22/10 4:23 PM, Scott Lawrence wrote:
>
>
> Now comes the challenging part - what is simplicity? We'd like to hea
>
> what the community thinks...
>
>
> Groups, user groups. for stupid people who forget to CapItalIze the
> group when adding users, make it case insensitive, or if they put in
> a group that doesn't exist (sIncE it isn't capitalized the same way)
> ask confirmation before automagically creating a grOup we didn't
> think we wanted created.
>
> and, some intelligence on dial plans.
> (a 'dial plan trace' program: type in target phone, select time,
> select user, type in 'digits'. where will it TRY to outdial?)
> and if multiple groups, or multiple trunks. if one doesn't have
> permissions (trunk/gateway 5555 isn't in group x, but user is in
> group x and y, and group y has permission let it dial!)
>
> and, did I say dial plans?
>
> --
> Michael Scheidell, CTO
> Phone: 561-999-5000, x 1259
> > | SECNAP Network Security Corporation
> Certified SNORT Integrator
> 2008-9 Hot Company Award Winner, World Executive Alliance
> Five-Star Partner Program 2009, VARBusiness
> Best Anti-Spam Product 2008, Network Products Guide
> King of Spam Filters, SC Magazine 2008
>
> This email has been scanned and certified safe by SpammerTrap®.
> For Information please see http://www.secnap.com/products/spammertrap/
>
>
> ----- Message from Online Systems <[email protected]> on Fri, 22 Jan
> 2010 16:47:29 -0500 -----
>
> To:
>
> [email protected]
>
> Subject:
>
> Re: [sipx-users] Simplify, Simplify, Simplify
>
> Hello,
>
> Ability to use IP addresses instead of having to deal with domains at
> all, I can see the benefit of this approach but it becomes a serious
> obstacle to those who want to use SIPX on a small scale, and slows
> adoption of the platform compared to other solutions in my opinion.
>
> Thanks for all of your hard work.
>
>
> On 1/22/2010 4:23 PM, Scott Lawrence wrote:
> > As we begin to home in on release 4.2, we're starting to formulate
plans
> > for what comes next...
> >
> > First, I want to reassure the community - Avaya is very much committed
> > both to the SCS commercial product (see roadmap announcements made
this
> > week), and to leading, contributing to, and materially supporting the
> > sipXecs open source project. There most assuredly will be versions
> > beyond 4.2, and we're committed to making them better with every
> > release.
> >
> > Which brings me to the Subject of this request for community input.
One
> > of the major strategic goals of the release after 4.2 is to make
sipXecs
> > simpler. Simpler to install, simpler to administer, simpler for end
> > users to use. Nice goal, huh? Motherhood is good, Apple Pie is very
> > good, and Simplicity is great - I'm glad we all agree :-)
> >
> > Now comes the challenging part - what is simplicity? We'd like to
hear
> > what the community thinks...
> >
> > 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!) ?
> >
> > This is not like those dumb Microsoft advertisements where one doofus
> > after another takes credit for Windows 7 (really - would anyone
actually
> > want to take _credit_ for Windows?) - we really want to know.
> >
> > I'm going to suggest one more thing for this thread - that developers
> > just read and not post. In particular, in this thread: don't explain
> > that something our users think is hard is actually easy, or tell them
> > why it's hard, or suggest how we might fix it, or chime in here and
now
> > with your ideas. We'll have our turns to process all this more
actively
> > later and elsewhere - this thread is about listening to our users
pain.
> > Hear, be inspired, and get motivated.
> >
> >
> >
> >
> > _______________________________________________
> > 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/
> >
> >
> >
>
>
>
> ----- Message from Josh Patten <[email protected]> on Fri, 22
> Jan 2010 16:08:48 -0600 -----
>
> To:
>
> Scott Lawrence <[email protected]>
>
> cc:
>
> sipXecs users <[email protected]>
>
> Subject:
>
> Re: [sipx-users] Simplify, Simplify, Simplify
>
> Be ready for a mailing list flood :-P
>
> Here are a few things, and I'm sure some if not most are already in
> motion and some of them may not fall within your guideline, call me
> out on them if they're out of the scope of your request:
> Advanced audiocodes gateway configurations, such as manipulation tables.
> Better CDR's. Right now I'm having to get our on-staff programmer to
> write me out a parser to sift through all the CDR records to
> generate a comprehensive report.
> Voice notification of new voicemails, not just email. Some people
> don't have data or SMS on their phones.
> Auto Attendant Dial by name directory is currently just bad, namely
> due to the 10 second delay issue.
> make backup and restore a little more comprehensive, such as making
> sure all SSL certs are in order.
> Wildcard SSL certificates.
> Bring back the remote call forwarding restriction, sometimes there
> is a need to keep certain users from forwarding calls off-site.
> Hunt group pickup code shortcut. A speed dial has to be used for
> hunt group pickup because users can't remember the entire *78XXXX pickup
code.
> Call pickup/hunt group pickup permissions. It is somewhat unnerving
> that anyone can set up a presence monitor on any extension they want
> to and intercept their calls.
> Allow different alarms to be sent to different email addresses
> (sipXconfig) Allow more than 20 phones/users to be displayed at one
time.
> For end users: allow a different phonebook in the web portal than on
> the phone so the entire directory can be searched in the web portal
> but only a small departmental subset will be seen on the phone.
> Better dial plans. The current ones are a bit watered down.
> Transferring calls to park requires three button presses on Polycom
> handsets (transfer, blind, park button). Could this possibly be whittled
down?
> If a Jabra or Plantronics headset with EHS adapters is used on a
> phone with BLF then every time a BLF button shows a monitored
> extension to be ringing, the headset also rings. Polycom and Jabra
> have basically ignored me on this. I am almost 100% positive this
> has to do with the "alerting" state with enhanced BLF.
> I've had to write EFK's for Intercom, Group Page, Transfer To
> Voicemail, and Blind Transfer on Polycom phones. Perhaps these could
> be included by default and turned on/off at the group phone level?
> Allow for a pickup time shorter than 1 second for *78XXXX call
> pickup. Users are used to the call immediately being picked up on
> older systems. I have trained users to wait for the short "beep"
> sound but sometimes they forget :-(
> Voicemail quotas so the packrats will get rid of voicemails from 5
> years ago or archive them to their computer
> 64 bit CentOS installation ISO.
> Polycom config overrides upload. It's frustrating after a firmware
> update having annoyed users because their ringtone, background, etc.got
reset.
> Troubleshooting has got to become a bit easier. A scrolling CLI
> would definitely help.
> OK, that seems to be more than just a few. I'm sure there are more
> that I'm not thinking about right now. I'm really glad to hear Avaya
> is committed to the project.
> Josh Patten
> Assistant Network Administrator
> Brazos County IT Dept.
> (979) 361-4676
>
> On 1/22/2010 3:23 PM, Scott Lawrence wrote:
> As we begin to home in on release 4.2, we're starting to formulate plans
> for what comes next...
>
> First, I want to reassure the community - Avaya is very much committed
> both to the SCS commercial product (see roadmap announcements made this
> week), and to leading, contributing to, and materially supporting the
> sipXecs open source project. There most assuredly will be versions
> beyond 4.2, and we're committed to making them better with every
> release.
>
> Which brings me to the Subject of this request for community input. One
> of the major strategic goals of the release after 4.2 is to make sipXecs
> simpler. Simpler to install, simpler to administer, simpler for end
> users to use. Nice goal, huh? Motherhood is good, Apple Pie is very
> good, and Simplicity is great - I'm glad we all agree :-)
>
> Now comes the challenging part - what is simplicity? We'd like to hear
> what the community thinks...
>
> 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!) ?
>
> This is not like those dumb Microsoft advertisements where one doofus
> after another takes credit for Windows 7 (really - would anyone actually
> want to take _credit_ for Windows?) - we really want to know.
>
> I'm going to suggest one more thing for this thread - that developers
> just read and not post. In particular, in this thread: don't explain
> that something our users think is hard is actually easy, or tell them
> why it's hard, or suggest how we might fix it, or chime in here and now
> with your ideas. We'll have our turns to process all this more actively
> later and elsewhere - this thread is about listening to our users pain.
> Hear, be inspired, and get motivated.
>
>
>
>
> _______________________________________________
> 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/
> _______________________________________________
> 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/
_______________________________________________
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/
