maybe you should start with this book instead:
http://www.amazon.com/gp/aw/d/1451612575/ref=mp_s_a_3?qid=1329577567&sr=8-3
<http://www.amazon.com/gp/aw/d/1451612575/ref=mp_s_a_3?qid=1329577567&sr=8-3>
On Feb 18, 2012 9:51 AM, "Tony Graziano" <tgrazi...@myitdepartment.net
<mailto:tgrazi...@myitdepartment.net>> wrote:
I think you need to apologize for your cross attitude with Martin
and eZuce. It was rude, unprofessional, uncalled for and plain old
disdainful.
I look forward to your public apology.
On Feb 17, 2012 9:52 PM, "Tim Ingalls" <t...@sharedcom.net
<mailto:t...@sharedcom.net>> wrote:
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 <http://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" <t...@sharedcom.net
<mailto:t...@sharedcom.net>> 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"
<t...@sharedcom.net <mailto:t...@sharedcom.net>> 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
sipx-users@list.sipfoundry.org
<mailto:sipx-users@list.sipfoundry.org>
List Archive:
http://list.sipfoundry.org/archive/sipx-users/
LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: helpd...@voice.myitdepartment.net
<mailto:helpd...@voice.myitdepartment.net>
Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
sipx-users@list.sipfoundry.org
<mailto:sipx-users@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/
LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: helpd...@voice.myitdepartment.net
<mailto:helpd...@voice.myitdepartment.net>
Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
sipx-users@list.sipfoundry.org
<mailto:sipx-users@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/
LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: helpd...@voice.myitdepartment.net
<mailto:helpd...@voice.myitdepartment.net>
Helpdesk Customers: http://myhelp.myitdepartment.net
<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
sipx-users@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/
