Martin,
Thanks,
Tim Ingalls
Shared Communications, Inc.
801-618-2102 Office
On 02/17/2012 08:30 PM, Martin Steinmann wrote:
Tim – we really appreciate the
feedback. The following might help add some additional
perspective:
- We need the community’s help to keep improving
the open source edition, especially as it relates to
documentation on our Wiki and elsewhere, but also for
specific features important to the community. We will
make every effort to incorporate contributions timely and
properly
- The UI can and should be improved
- Our commercial edition, openUC, is positioned
for larger enterprise and not SMB. This is the reason why
certain features and design considerations are not
optimized for the SMB market
- SIP trunking is one of these features. Large
enterprise will always use a commercial SBC and not
sipXbridge. They also do not use voip.ms
- We think the SMB market moves into the cloud
and away from on-premises installations. The requirements
for technology needed to build large scale cloud based
systems is very different from on-premises installed SMB
systems. Our engineering effort is focused on where the
market is headed
95% of my market in Utah is small businesses. In 2008, Gartner
analyzed the offerings for small businesses, and they found that
not many had deployed it because of a lack of understanding and
economics. I think that making VOIP easy for small businesses to
adopt is a winning idea. I do not agree that SMBs will
overwhelmingly go to hosted services. The monthly per-seat costs
are too high unless you are talking about a company with only 3 or
4 people. Otherwise, they save a lot more money by having an
on-premise phone system. I've created hundreds of sales proposals
and analyzed thousands of phone bills. I know this is true.
Your marketing directions seem to be disconnected from the sales
world that I am in. Come cold calling with me to SMBs, and you'll
get a different viewpoint of what is really happening--not what
you and the tech media think should be happening.
- We think that this industry transitions to IT
and away from legacy systems and also away from the
traditional VAR model. Most VARs, especially the many
small ones, are in trouble already. We can help VARs
transition and we work with partners to develop managed
services offerings
VARs struggle to the extent that they do not stop offering
proprietary systems. When they start offering open systems, they
will be successful.
Small VARs will never disappear. Small companies need them too
much for them to disappear. The problem is simply that they cannot
afford to have an IT person on staff to make sense of everything.
I think it would be great for VARs to become telecom resellers,
but I doubt the transition will be made for very many of them. It
is too complicated to run a successful reseller business if you
are a small VAR. I have experience in that.
In time, if ISPs start to offer QOS for their Internet access
products, nobody will need a voice carrier. Everything will go via
ENUM lookups directly to the destination as a data service. Hosted
VOIP carriers are a temporary phenomenon. I give them 20-30 years
at the most before they are unneeded. (The hosted VOIP carriers
I've talked to are getting squeezed on pricing from both large and
small customers.) Carrier billing systems will be irrelevant.
Eventually, you will only need a data carrier and a small SIP
proxy server.
So if you really want to be strategic, focus on helping small
businesses and SOHOs get to that future by making adopting VOIP
easy. Then you will be the one they go to for their solutions
instead of being a temporary bump in the road they have to get
over in order to let their VOIP run free (as in free root beer).
- We think that clients move into the Web with
html5 and browsers / mobile apps capable to do real-time
comms
- Training and docs as well as support are
available very similar to e.g. Cisco as mentioned below,
but as part of the commercial edition
OK. But consider the fact that organic growth can be fueled by the
open-source version. You will never get certain customers, because
they don't need you. But in great numbers, they can provide market
assurance that your solution rocks. The closer you get to mass
adoption, the greater the perception that your commercial
offerings rock. But you won't get to mass adoption (like Asterisk
and it's variants have achieved) if nerdy-but-not-that-nerdy
people like me can't understand quickly how to deploy sipXecs with
ITSP SIP trunking. So it furthers your goals to make all of that
documentation public. Great documentation = great mindshare.
Open source and commercial
editions go hand in hand; they both need each other to
exist. Every customer or reseller has a choice to work
with either edition and there are benefits to both, but it
often helps to clearly understand the two models. Our
goal is to establish the undisputed leading and open UC
solution in this new market that unfolds on the IT side.
We have proven our viability even in very large
deployments, our customers have saved substantial amounts,
our users are happy, our support is highly regarded, and
our partners (VARs and resellers) have built a business.
--martin
I appreciate your feedback. You're right.
Being specific is helpful. However, I was trying to not be
totally specific, because I'm bringing up a few main general
points:
1. Learning and deploying sipXecs correctly is very complex.
The learning curve is very steep compared to some other
open-source projects, including Trixbox. Part of the
complexity is the way the user interface is laid out
(multiple places to configure similar things, etc.), part of
it is due to bugs and incompatibility w/ specific ITSPs, and
part of it is due to the technology itself. What I liked
about Trixbox is that it pretty much just worked w/ most of
the ITSPs without a bunch of headaches. So although the user
interface (FreePBX) isn't as nice as sipXecs, you don't have
to worry about tweaking the internals as much since it
usually just works.
I am trying to sell SIP trunking to small businesses who
want to save money on their monthly bills. I'm not
necessarily planning to resell SIP trunking at the
beginning. I'm more the marketing type and am looking for
someone who is great with the technical stuff, but I'm
starting off by myself, so I'm looking for a system that can
be deployed with only a medium amount of experience with
interop w/ ITSPs.
2. The book is great, but it doesn't cover everything. For
example, it doesn't tell you that if you are connecting to
Voip.ms that you have to choose the same server to register
to as you have set in the DID's POP setting in the Voip.ms
portal. You can't register using the same DID to one
sub-account at one server and another sub-account at another
server so that you have server redundancy. You also cannot
register two sub-accounts to the same server or you start
seeing registration rejections and one-way audio on outbound
calls. It also doesn't tell you that Voip.ms has a secret
NAT keepalive setting they can set both on your main account
AND on the sub-accounts, and that it can stop the problem of
getting registration and call rejections for outbound calls.
The book goes over the basics. Not the technical details.
For the technical details, you have to read every post in
this mailing list every day. You also have to read every
page of the wiki. You also have to ask questions on this
list. Some of us have too much going on to be able to do
that. But the same questions pop up here over and over. Why?
Because they aren't documented in an excellent way. I think
that maybe we are subconsciously using "Read the book" as a
crutch to not have to document things properly.
The fact is, the lack of documentation for both how to
configure sipXecs, and how NOT to configure it, even though
it is possible to do so (because that feature isn't
available or there is a bug, etc.) is a big problem with
getting more people, including technical people, to adopt
this as a platform.
If you want to learn to deploy Cisco gear, there are classes
you can take, books you can read, and certifications you can
take. If you want to learn to deploy Avaya, Nortel, Alcatel,
etc., there are similar programs. You learn the stuff, and
then you know what to do. With sipXecs, the knowledge about
how everything works is very diffuse. Even if I hire techs
to do my installs, I imagine they would be struggling to
learn how to deploy the system. The lack of documentation
prevents a wide reach for the project.
3. I'm suggesting that we need some simplified recipes for
deploying a fool-proof system. I'd like to cite the Drupal
installation profiles as an example. Drupal is complicated.
It has lots of documentation spread across several books,
tons of articles on the Drupal site, and lots of third-party
Web sites with info on it. But they also have installation
profiles you can just install and everything works. Want an
e-commerce site with PayPal as the back-end? There's an
installation profile for it. An installation profile
contains all of the optional modules you'll need without
having to download and configure each one.
We could do that for sipXecs. It would make it more
accessible. I think if you study the rise of Asterisk and
Trixbox, one of the keys for spreading their popularity was
that they are accessible to moderately technical
do-it-yourself types like myself. If the sipXecs project
wants to get more traction, its proponents should pay more
attention to making it easier to adopt.
4. You and others have suggested adding knowledge to the
wiki. The problem I face in doing that is that I don't feel
like I am an expert enough to definitively state how to do
very many things that aren't already on the wiki. I don't
want to give out bad information, especially since it seems
that just when I think I have figured out sipXecs, something
else breaks. I don't feel qualified to put much into the
wiki.
I've seen you give out some great information. But it gets
buried under a pile of other posts in this mailing list.
===========================
By the way, here is my setup:
1 Polycom IP 670
1 Polycom IP 450
1 Grandstream HT386 ATA
1 Sipura SPA-2002
ISP was Qwest for DSL and Xmission for the ISP service. I
used to have 5 static IPs. My ISP is now Comcast 20Mbps
residential service. Comcast doesn't sell static IPs for
residential customers.
1 Linksys WRT54GL running Tomato Firmware. I used to use the
QOS prioritization feature w/ Qwest, but don't use it any
more since I have way more bandwidth than I can use and I
don't have any troubles with QOS issues. The firewall
currently has TCP/UDP ports 5060 and 5080 forwarded to
symmetrical ports on my sipXecs server. No ports are
forwarded for the RTP stream. When I connect to both
Vitelity and Voip.ms, the SIP port is verified as registered
to 5080.
I also temporarily deployed pfSense on a mini computer (AMD
PIC) to see if some of my issues were from my firewall
setup, but there was no change, so I switched back to the
Linksys router.
My sipXecs server is running on a Pentium 4 3.2 GHz w/ 2GB
RAM and 250GB SATA hard drive and 1Gbps Ethernet. Although
it is a bit under-powered for a large company, for my home
office it works fine.
I am using a Cisco Catalyst 2924 10/100Mbps switch without
implementing VLANs. There is no LAN QOS. But I don't think I
need it. My problem is not call quality. It is flaky
connections w/ ITSPs and other problems w/ CID, internal
sipXecs services, etc.
I use zoneedit.com as my DNS host. I also have port 53
forwarded at my firewall to the sipXecs machine, and I have
all of my local machines listed at the end of the zone file
so I can use sipXecs as my local DNS server. I don't know if
my DNS setup is actually working well for requests from the
outside world into specific machines on my network, but
that's OK. I don't really want that to happen. I just port
forward to my Web server, etc.
The only mildly annoying thing related to latency is that
the first micro-second of phrases I hear from the voicemail
system get cut off or slurred when listened to on a Polycom
phone, but I chalk that up to the slow CPU on my server.
I've experimented with various firmware versions on my
Polycom phones, but to no avail. I'm hopeful that a real
server wouldn't have that issue.
=================
But again, I think what I'm trying to accomplish here is to
find out what specific configurations people are using that
actually work. What ITSPs do you use? What configs work with
them and which ones don't?
I'm not looking to just dump on sipXecs. I really like the
platform. I really really want it to work out. My only issue
is that it keeps me up at night worrying that if I deploy it
to any customers I'll be in deep doo-doo.
Thanks,
Tim Ingalls
Shared Communications, Inc.
801-618-2102 Office
On 02/17/2012 06:34 PM, Tony Graziano wrote:
The book was written based on an earlier version of sipx
but the concept is no different. I have heard a lot of
positive feedback from people who have ready the book.
If you stop being vague and ask questions while providing
detail I'm sure you will get the answers you seek, if you
are actively looking for answers.
An example would be:
I use phone model "a" with firmware version "1" and my
calls are sometimes connected with one way audio using
trunks from so and so and a firewall from blankety blank.
Here is my sip trace.
If you have a little mystery it takes a little digging and
problem solving to find out why. Dig in and see what's
wrong. If you want to resell siptrunking (no matter the
platform and provider) you had best be able to do this any
given day anyway.
Good luck.
On Feb 17, 2012 8:16 PM, "Tim Ingalls"
<[email protected]>
wrote:
I did read the book. There are lots
of important technical details that are not in the book.
Thanks,
Tim Ingalls
Shared Communications, Inc.
801-618-2102 Office
On 02/16/2012 07:29 PM, Tony Graziano wrote:
You should read the book.
On Feb 16, 2012 9:03 PM, "Tim
Ingalls" <[email protected]>
wrote:
Hi
Everyone. I promise I am not trying to be a troll.
I have some serious questions that I hope I can
ask honestly and get some honest feedback about
using the free version of sipXecs as a commercial
product.
I implemented sipXecs about a year ago. My hope
was to find something more reliable than
Asterisk/Trixbox/FreePBX and easier to deploy. My
purpose was to start selling phone systems and SIP
trunking to businesses as a VAR. So far, after
testing the system day in and day out as my
home/home-office phone system, I haven't found it
stable enough to feel comfortable selling it to
customers.
I have had a host of issues with sipXecs, and
every time I think I've got the platform stable,
something else fails and I get one of those
barely-descriptive error messages in my email
inbox. I've followed the instructions from the
book, the wiki, and this forum, but still have
issues every month. Some of the issues are as
follows:
- Routing inbound
calls to an auto-attendant worked great for a
long time and then just stopped working one day.
After connecting the call, visitors were greeted
with no sound at all. I decided after hours of
trying everything to just skip the
auto-attendant and deactivate it.
- With both Vitelity
and Voip.ms, I have problems where periodically
an authentication request is rejected. Instead
of re-trying immediately, sipXecs waits a full
10 minutes to try to connect again.
- Nuances about how
certain ITSPs (e.g., Vitelity and Voip.ms) work,
and how you can and cannot connect to them
without getting strange behavior like inbound
audio not working, rejected authentication
requests, etc., take days and weeks to isolate
sometimes. These are not very well tested nor
documented. I think that a serious effort at
interop testing and certification should be
undertaken with detailed results --warts and
all-- posted so that someone can make an
educated decision when selecting an ITSP to use
with sipXecs.
- Just a few days
ago, calls that were transfered to voicemail
resulted in the call failing and the ITSP
routing the call to my failover phone number (my
cell phone) -- this is after the call initially
rang correctly. Rebooting the system fixed it
for some reason. Why?
- Periodically,
(perhaps due to a sipviscious attack) certain
services just stop working. Sometimes it is the
proxy service. Sometimes it is the registrar
service. Sometimes it is the NAT traversal
feature as a result of temporarily not being
able to reach the STUN server assigned (since
there is no back-up STUN server setting). Why
should these services just fail and require
human intervention to restart them? Can't they
just time out for a certain short period and
then fix themselves?
- CID doesn't work
reliably. I change all of the settings as I'm
told in the wiki, but it still doesn't get
transmitted correctly (or at all). For some of
my users, it works flawlessly, and for others it
doesn't work at all.
- Doing a SIP trace
to isolate an issue is a pain in the neck. In
Asterisk, all you have to do is type "asterisk
-rvv" and you can see a dialog stream which you
can read quickly. With sipXecs, you have to run
a series of research tasks to find the call in
question, convert the time to UTC, grep for the
time stamp in a big list of calls, then create a
merged XML file, then load it into SIPViewer,
and then find what you are looking for. The
process takes at least 5 minutes if you are an
expert.
Those are just a few examples.
I'm always wondering what is going to go wrong
next. It drives me (and my wife and kids) crazy. I
never had this many problems with Trixbox. I'm not
saying that sipXecs doesn't have its good points.
I'm just saying that over the last year+ since I
started using 4.2 and then 4.4, it has been
anything but reliable. Reliability is the number
one need for commercial clients.
Yes, I'll admit that it could all be my fault. It
probably is. But there are so many options, so
many opinions, so many sources of information,
(there are even so many places to set port numbers
for various things) that it seems you have to do
only sipXecs development for a living to be able
to deploy it correctly. It is far from simple. And
that complexity is part of the problem.
I know that some of you have deployed many of
these systems in a commercial setting, so I have
to ask you, how do you do it? I'm too afraid that
if I deploy sipXecs in an actual customer's
location that they'll hate me within a few months
and ask for their money back. How do you set
everything up (selection of ITSP, etc.) so that
the system is rock-solid reliable? Can we collect
some rock-solid fool-proof (as much as possible)
recipes that are known to work reliably every
time? This seems to be something that should be
placed on the wiki. I know that there are 100+
ways to configure the system (SIP trunking gateway
configs, various hardware, ITSP settings, dial
rules, etc.). I'm looking for just the recipes
that make the system reliable. I also know that
there are various conflicting opinions on this
forum about what works and what doesn't. I'm
looking for PROVEN opinions.
This is my final shot before I give up on the
platform. I'd even be willing to partner with
someone who has a near-flawless system implemented
and pay you to do the technical part if you can
prove your solution is stable. Until I find the
answer to this problem, I can't use sipXecs as the
cornerstone of my business plan and will have to
move on. If I can solve this issue, I'd be willing
to pay for further development out of my profits.
I know someone will suggest that I should just
sell Ezuce's commercial products. Based on what
I've experienced so far, I don't think I'd feel
confident in relying on Ezuce to be the partner in
question. If the open-source version has these
problems, what's to say that the commercial
version is any better?
Does anyone else experience the same reliability
issues?
Also, is anyone willing to have a phone
conversation about this and impart some wisdom or
have a partnership conversation?
--
Thanks,
Tim Ingalls
Shared Communications, Inc.
801-618-2102 Office
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/
LAN/Telephony/Security and Control
Systems Helpdesk:
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/
LAN/Telephony/Security and Control
Systems Helpdesk:
|
