Thanks for the great comments. I agree that QOS is difficult and
PSTN connections typically just work. But I'm trying to leverage the
cost savings of using SIP trunking with an ITSP in order to help
customers justify switching their phone system. In this tough
economy, saving a customer 50% of their monthly phone bill can make
the difference between selling a system and not selling one.
I have a few questions, below:
Thanks,
Tim Ingalls
Shared Communications, Inc.
801-618-2102 Office
On 02/16/2012 09:19 PM, Becker, Jesse wrote:
I would have to agree with Tim and state that most of
your issues are most likely ISTP related and/or network related. I
am not one of the developers, so I am not defensive, however, I
will say that I have using and testing SipX on and off since 2004
(going back to the Pingtel days). The one thing I can say is that
all of my deployments and labs have utilized physical PSTN
connections (PRI and or Copper). Keep in mind there is no QOS on
the internet. With proper engineering you can control level of QOS
on your network and to QoS going to your firewall, however,
everything after that is hope and pray.
That's a good point. What PSTN gateway(s) are you using? Are there
any tricks to configuring it to work with sipXecs?
I have a carrier I plan to use (Airespring) that uses MPLS to deploy
their SIP trunking. With that system, QOS across to the ITSP should
not be a problem.
I am currently using SipX in my IT department and so far it
performs ways better then the 400K Cisco phone system that the
college implemented five years ago. We currently are using SIP
trunking between the two systems allow interop of calling
between Cisco and SipX users. We are currently planning on
replacing the Cisco system and going with a 3-server redundant
system campus wide.
A couple of suggestions/points I can offer
1. Make sure your ITSP is sending your inbound calls to 5080
and not 5060. This is required to use the building SBC of SipX
2. Let your SipX server take care of all your NAT
transversal. Turn off any built in VoIP transversal setting that
may be build into your firewall
Does that suggestion include not using any port forwarding rules
(5080 and 5060)? I briefly switched off my port forwarding rules for
5060 and 5080 and everything kept working. I put it back just to be
safe.
3. Configure your firewall so that only your ITSP's gateways
can communicate with you. Leaving yourself exposed allow you to
be DOS attacked by others on the internet who use robotos to
exploit you for toll fraud. It is possible that their denial of
service attempts could cause issues to your proxy and registar
service.
I assume doing that on my Tomato Firmware router would mean either
using custom firewall rules or implementing port forwarding while
identifying the source IP address. My issue with that is that I
wonder if the same IP address will always be initiating the session
from the ITSP. If they have several servers, wouldn't it be possible
that the packets will come from multiple IP addresses?
4. If you have the capability, give your SIP traffic and RTP
traffic priority or guarantee on firewall. Heavy regular
internet use could cause delay or loss of your call traffic if
you do not have QOS on your network and firewall.
I used to use QOS settings, but I discontinued that practice after I
switched to a 20Mbps connection from Comcast. Inbound QOS doesn't
really work that well anyway when prioritizing from the WAN side. If
you have a specific solution for that, I'm all ears.
Switch to a PRI or copper lines if you don't want to deal
with QoS etc.
I have installed and used various telecom systems over the
last 14 years. I will not stand on a soup box and say that SipX
is 100% bug free, however, I will take SipX over any other
open-source or commercial product any day. I will also say that
I have given and received better support on this list that I
every received from a 25,000 dollar Cisco smartnet contract.
I know of a local network of community college campuses that have
been trying to implement Cisco call manager for the past 3 years
without success. The guy who runs the IT shop is certified in Cisco,
so that's what he wants to use.
Just my 2 cents.
I truly appreciate your insight, Jes.
Jes
On Thu, Feb 16, 2012 at 9:58 PM, Todd
Hodgen <thod...@frontier.com>
wrote:
Tim, This type of email is
disappointing for me. They highlight negative
experiences that are experienced by a user, and do
nothing to help this project. I’m sure you are
being open and honest, but all that it shows is that
you are struggling with the system, in your
deployment, and it gives a black eye to a very well
design platform that a lot of dedicated individuals
have poured their heart and soul into.
I can tell you that I have many
commercial customers that use sipXecs daily, and I
have ZERO issues to deal with on a daily basis.
But, how did I get to this point – many years of
experience with telephony, understanding the
components that are required for engineering a great
solution, and time and patience in a lab environment
to understand what is commercially viable for my
customers.
This is a great solution, but it
is not for everyone. I also have two other
commercial solutions available for my customers,
which I use when sipXecs is not a perfect fit.
However, that is rare. In general, the majority of
the issues I have ever had are related to ITSP
reliability, QOS related to the Network, occasional
software issues with Telephones, and the occasion
bug in sipXecs, like any other software platform.
The sipXecs issues have never been a show stopper
for any of my customers. I can’t be any more honest
or direct about my experience.
There are resources available for
a fee that can help your learning curve, or the
eZuce platform may be a better fit for you. I can
say with certainty, this is a great product, that I
have no fear in offering to a commercial customer,
and know they will be 100% satisfied when the
project is done. Most of my business is referrals
from very happy customers. It really is that good!
My advice is understand the
product, invest in excellent equipment, and chose
the network design and the ITSP or Telco
carefully. Mindful that this is an open source
platform, it would be very rare for me to deploy a
new software release until it has been vetted in the
field for at least a few months or more. I am right
now updating 4.2.1 customers to 4.4, although I
started deploying 4.4 in the August timeframe for
new customers.
Not everyone is a good fit for
offering open source products as a commercial
option, that is why there are so many options out
there, and I would sincerely consider eZuce as one
of them, with the right design, the right
components, and the right technical expertise to
offer it to a commercial customer.
Quite frankly, the trace process
for sipXecs, along with features of Wireshark, and
other applications commercially available on the
market seem to work well for isolationing issues.
Is it perfect, not by a long shot. But I have seen
less in much more expensive products on the market
today.
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
sipx-users@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
![]()
Jesse Becker | Technical Manager
Network+ |
Linux+ Certified Professional
DATATEL+SGHE @
SUNY Ulster
491 Cottekill
Road, Stone Ridge, NY 12484
Tel 845-687-5064 |
Fax 845-687-5105
beck...@sunyulster.edu | www.sunyulster.edu
Check out our knowledge base: http://kb.sunyulster.edu
_______________________________________________
sipx-users mailing list
sipx-users@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/
|
