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
