On 02/17/2012 07:12 AM, Robert Durst 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)
Who is VI? Do you have a Web site for them?
One problem I found with Vitelity is that you pretty much can only
use one account per static IP. If you change your IP address, you
have to go and add it to their site or they will stop sending or
accepting calls from you. So if you have two accounts, you can't
use the same IP address for both of them. And if you simply delete
the IP address, they'll still keep it somewhere in their system
and prevent your calls if they don't come from that IP
address--even if you are not using IP routing. You have to
actually change the IP address in their portal every time your IP
address changes. So using dynamic IPs with their system is
useless.
Oh, and their techs just pretend to actually solve your problem.
They just blame it on sipXecs or your setup. When you prove to
them that it is their system, they just say "sorry about that" and
don't fix it.
Thanks for your feedback.
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/
|
