I'm hoping we can not resort to name calling, Robert. I'm just
trying to have a serious conversation so I can stop messing around
with unsuccessful configs and get out and start selling.
Michael, I believe that you have multi-thousand-seat systems. Are
you using any ITSPs for sipXecs, or are those installations using
traditional TDM systems? If you are using ITSPs, which ones work
flawlessly with the system? Can you share screenshots of the config
pages or upload a valid snapshot or something? Are you only using
TDM access as opposed to SIP trunking?
I realize that you wrote the book, but there is more to it than
that, isn't there. The book covers the basics. There are lots of
holes that a person can fall into if they try various things that
aren't documented in your book.
Are you thinking of doing a second edition? I think that would be a
great idea, and I would buy it if it went significantly beyond what
the current one contains. But how do you handle the conflict between
making money on the book and providing free info in the sipXecs
wiki? I can see how it may be difficult to investing lots of time
updating the wiki since that would take away some of the value of
buying the book. I'm not sure how I would deal with that.
Thanks,
Tim Ingalls
Shared Communications, Inc.
801-618-2102 Office
On 02/17/2012 10:12 AM, Michael Picher wrote:
Ok... there are just some who can't get it... no worries.
Properly installed, with proper gear it works great. I have
many multi-thousand seat systems to point to. It's not
everybody's cup of tea but I respectfully disagree with you.
On Feb 17, 2012 12:03 PM, "Robert Durst"
< [email protected]>
wrote:
Picher,
No one was discussing hosted
solutions. We have deployed Asterisk switches at each
of our client locations. Simply, sipx is a mess, much
like it’s idiot supporters.
Rob
Durst
Santa Monica Systems, Inc.
310.395.5135
www.smsystems.com
To ensure perfect aim, shoot first and call
whatever you hit the target
From: Michael
Picher [mailto:[email protected]]
Sent: Friday, February 17, 2012 6:26 AM
To: Robert Durst
Cc: [email protected];
[email protected]
Subject: Re: [sipx-users] sipXecs Commercial
Feasibility
Now that's a troll... or at least a
vulture.
I think the other thing some folks
run into is that they try to use this as a hosted
/ tenanted system.... which it isn't. nor does it
pretend to be.
Mike
On Fri, Feb 17, 2012 at 9:12
AM, Robert Durst <[email protected]>
wrote:
Tim,
We receive most of
the sipx emails (now in my junk folder) as
we have previously tested sipx. After seeing
this, I thought I’d respond with a few of
our own experiences.
We are in a
similar situation, as we are relatively new
to the VOIP world. We currently manage over
400 DIDs, so we are still very small. But
there have been a couple of discoveries that
make our job much easier now. First, after
testing most of the voip apps, we settled
with Asterisk (you are already aware of the
myriad of problems with sipx). Second, after
employing Sonicwall routers at all clients,
we have now switched away for the voice
circuits. Most of the random problems have
disappeared (no more dropped calls leaving
VMs, no more one way audio loss, etc.) We
now use a $50 router (tp-link), which works
even in 100 phone deployments. And after two
years with Vitelity, we are now currently
porting out all our accounts. The underlying
carrier problems, the sbc problems, the
hacker attacks, etc. were just too much to
ask our clients to accept. VI has good
service (so far), few trouble tickets, and
good rates (originations .001)
For phones, we
have used Polycom, Aastra (my favorite),
Snom and Grandstream. All work OK
(Grandstream is OK now with latest firmware
update).
Hope some of this
is helpful.
Rob Durst
Santa Monica Systems, Inc.
310.395.5135
www.smsystems.com
To ensure perfect aim,
shoot first and call whatever you hit the
target
From:
[email protected]
[mailto:[email protected]]
On Behalf Of Becker, Jesse
Sent: Friday, February 17, 2012 5:14
AM
To: Discussion list for users of
sipXecs software
Subject: Re: [sipx-users] sipXecs
Commercial Feasibility
Tim,
No one has accused you
of being a troll and several of us have
provided advise regarding LAN, firewall
and PSTN setup. I would start with those
recommendations and report back with any
further issues to be addressed.
On Feb 17, 2012 6:21
AM, "Tony Graziano" <[email protected]>
wrote:
A familiar refrain
here is:
Use good phones. Use good switching gear
(and a vlan for voice). If
you are supporting trunking and/or
remote users have a thorough
understanding of your firewall to ensure
it is compatible or use a SBC
that can deliver the desired results.
Pick and choose your ITSP carefully too.
If trunking is too
porblmeatic, switch to PSTN service from
the local phone company, it
still works with sipx. I think unless
you are VERY well rounded in
telephony and SIP, reselling trunking
will get you in over your head
real fast.
Many of the problems you list are likely
related to LAN or firewall
configurations. Some of what you are
saying is strange to me (port
numbers), because unless you really need
to go outside the box you
don't really have to change those
things.
Don't let anyone tell you voip is easy.
Don't expect to start doing
this without a primer in telephony
functions too. Read the book.
On Fri, Feb 17, 2012 at 5:02 AM, Michael
Picher <[email protected]>
wrote:
> Tim,
>
> I think the message here from all
involved is that cutting corners gives
you
> the results you have experienced.
>
> A VoIP system will quickly point
out the problems with your network.
Good
> network switches, properly
configured are important to larger
installations.
>
> Cheap phones stink, my
recommendation for now is to use
Polycom. We're
> trying to get a few others to the
table but they aren't there yet with
their
> plugins.
>
> With tier 3 players for ITSP
connections, you get tier 3 service. If
you
> want top quality voice connections,
get a top quality ITSP on a dedicated
> link or get traditional service and
bring it in with a gateway.
>
> Thanks,
> Mike
>
> On Thu, Feb 16, 2012 at 9:02 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/
>
>
>
>
> --
> Michael Picher, Director of
Technical Services
> eZuce, Inc.
>
> 300 Brickstone Square
>
> Suite 201
>
> Andover, MA. 01810
>
> O.978-296-1005 X2015
> M.207-956-0262
> @mpicher <http://twitter.com/mpicher>
> www.ezuce.com
>
>
------------------------------------------------------------------------------------------------------------
> Hope to see you at the sipX CoLab!
http://www.sipfoundry.org/sipx-colab
> A gathering for - open source
users, eZuce customers & eZuce
partners
> Get the inside track on 4.6 and a
glimpse at the future of sipXecs!
>
>
>
_______________________________________________
> sipx-users mailing list
> [email protected]
> List Archive:
http://list.sipfoundry.org/archive/sipx-users/
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: [email protected]
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
Linked-In Profile:
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~
--
LAN/Telephony/Security and Control
Systems Helpdesk:
Telephone: 434.984.8426
sip: [email protected]
Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
[email protected]
List Archive:
http://list.sipfoundry.org/archive/sipx-users/
--
Michael Picher, Director of Technical Services
eZuce, Inc.
300 Brickstone Square
Suite 201
Andover, MA. 01810
------------------------------------------------------------------------------------------------------------
A gathering for - open source
users, eZuce customers & eZuce partners
Get the inside track on 4.6 and
a glimpse at the future of sipXecs!
|
