If your looking for  support sipx community is not thr place, its a geat 
product - but when it breaks   your 
  ----- Original Message ----- 
  From: Tim Ingalls 
  To: sipx-users list 
  Sent: Saturday, February 18, 2012 11:59 AM
  Subject: Re: [sipx-users] sipXecs Commercial Feasibility


  Didn't see your email. My emails are sorted by thread. It probably wouldn't 
have mattered, though. Your private response was very rude/unintelligible. I 
posted it publicly because that was my original purpose and I just forgot to 
hit "reply to all." 

  Let's just stick to the topic and be positive shall we? You made this 
personal and rude from the very beginning without me wanting to offend anyone. 
You are turning every little thing into an imagined insult. If you have any 
specific ideas regarding the original post, please share. If you are just 
itching for a flame war, I'll pass. I didn't come here for a war or to be 
attacked by people. I came here for answers.


Thanks,

Tim Ingalls
Shared Communications, Inc.
801-618-2102 Office


  On 02/18/2012 12:13 AM, Todd Hodgen wrote: 
    Now that is class.  You email someone in private, you get a private 
response and you post it publicly.   You prove yourself well.



    From: Tim Ingalls [mailto:t...@sharedcom.net] 
    Sent: Friday, February 17, 2012 10:34 PM
    To: Todd Hodgen; sipx-users list
    Subject: Re: [sipx-users] sipXecs Commercial Feasibility



    Todd,

    This user list is for USERS. It's even in the name of the list: sipx-users. 
Maybe you should start a new list called sipx-prospects so that you can protect 
your people from seeing any negatives in sipXecs. If this isn't the forum for 
detailing problems and asking for help, please point me to the forum that would 
do that. Otherwise, I think you are blowing this way out of proportion. People 
post problems on here all the time. And they don't always get solutions. And 
they get frustrated. And they don't come back. Or they do come back, but they 
make clear that they have deep disagreements on what sipXecs can and cannot do. 
If your prospect can read my post, I'm quite sure they can read all of the 
others. Are you going to start tearing down all of the other users who post 
problems because they are pointing out faults with your favorite money maker?

    Just because someone doesn't have the same perspective as you, it doesn't 
follow that they are wrong. Are you seriously saying that nothing I said has 
merit? I pointed out actual problems, not fake ones I was using to discredit 
sipXecs. 

    I don't think you should worry too much about your prospect. There is 
nothing that has happened to your customer's point of view that can't be 
countered by good sales skills. Please allow me to suggest a few ways to 
overcome those objections. 

    1. Explain to your customer that the person who wrote that stuff (me) 
doesn't have as much experience and knowledge as you. That's a very effective 
way to overcome that objection. Point to your certifications. Point to your 
experience and to my relative lack of experience. I'll even post right here in 
the forum that I'm a dummy. 

    I AM A DUMMY!!

    There, that should help.

    2. Why can't you provide them with references to call? A good testimonial 
goes a long way in overcoming Fear Uncertainty and Doubt.

    3. If I have listed issues (that truly do exist), then tell your prospect 
why they don't have anything to do with how you will implement your system. 
Show them why I have had these problems and why they won't have those same 
problems. These are basic sales skills and can be learned by anyone.

    The great thing is that if your customer reads this post, it doesn't take 
anything away from your power to overcome his concerns, because this is all 
true. You DO perform a great job for your customers. I'm sure they would all 
say that. You DO have lots more experience in technical things than I do (but 
not so much in sales). You WILL deploy a system that avoids the pitfalls I have 
so clumsily fallen into. 

    Oh, and if you land the sale with my help, please consider throwing some 
free advice my way.

    I was not being mean-spirited to look for solutions to my problem. Nor was 
I inappropriate to suggest how complicated it is for someone new to the project 
to learn all of its ins and outs. I will not accept that I can't raise concerns 
about the project in an effort to make it better. I think that most other 
people who have responded have had the attitude that suggesting ways to improve 
sipXecs is a good thing, and they accept that I am sincere in not trying to 
just complain. And finally, I see nothing wrong with trying to use sipXecs to 
make money and ask for help in doing so. I'm hoping that I can hire some people 
who would otherwise be jobless, train them how to do this stuff, and see them 
succeed. 

    And finally, finally, if you have your system down so well, can you recall 
that I said that I'm interested in paying someone to do the technical stuff for 
me? This is an opportunity for you if you see it that way. 

    Happy birthday.




Thanks, Tim IngallsShared Communications, Inc.801-618-2102 Office 
    On 02/17/2012 09:25 PM, Todd Hodgen wrote: 

    See comments below.



    From: Tim Ingalls [mailto:t...@sharedcom.net] 
    Sent: Friday, February 17, 2012 7:12 PM
    To: Todd Hodgen
    Subject: Re: [sipx-users] sipXecs Commercial Feasibility



    Todd,

    I'm sorry my post disappointed you. But it is what it is - from your 
perspective.  I certainly don't agree with your perspective.  You are entitled 
to your opinion, and equal rights on the user group, no doubt there.  But bear 
in mind that there are many on the list that invite our customers there to 
learn, that spend a lot of time working to improving things, etc.  It is my own 
opinion that your comments were damaging to this project, and for me almost 
seeme mean spirited - my opinion.. This is really what's going on from the 
perspective of a moderately-technical guy who has used Linux for the past 10 
years and has sold telecom services for 16 years. Tim, I don't see what selling 
telecom services has to do with building a commercial telephone platform, as 
one has nothing to do whith the other.  And being moderately technical I don't 
believe is enough to take an open source product to a commercial product.  A 
moderately technical guy should start with a commercial product to learn from 
first.   I offer two commercial products, besides sipXecs, because there are 
limitations in it just like ALL products, and one round peg does not fit in all 
of the holes.  Don't you think that honesty is really what we need to improve 
the project? If sipXecs is really this complicated to make it work correctly 
with an ITSP You miss the point here completely.  Let me give you an example.   
Broadvox is a national carrier.  Their legacy platform works well with sipXecs 
- configure it works, and well.  Their new platform does not work with 
sipexecs.  But I don't blam sipXecs because they are compliant with the 
standards and Broadvox refuses to accecpt invites without SDP.  Their failure 
to meet the minimum requirements of the RFC does not mean that sipXecs is at 
issue, in fact quite to the contrary.  The fact that VOIP.ms loses its 
connectivity in some of their switches, and not in others is their issue, not 
sipXecs.  They have some great switches that are underutilized, and some old 
switches that are overutilized., then it deserves that reputation  Again - in 
your less than experienced view. Your and others' heart and soul is greatly 
appreciated. But being rigorous with testing and documentation and detailing 
the flaws of the system are just as important for the success of the project. 
Making the system easy to implement for moderately technical do-it-yourself 
types like myself is critical for the project to progress. I think I am the 
demographic that sipXecs needs, and this is my perspective.  I don't agree with 
your assumption here.

    As an example, how many people do you know who deploy Freeswitch without a 
GUI? None.  I wouldn't deploy freeswitch because it's not designed for 
deployment by itself.  Probably just the really really technical people who can 
program in Java, XML, etc. Even though I have heard it is technically superior 
to Asterisk, it isn't as frequently deployed because it is too difficult for 
guys like me to understand without being programmers.  It's simply not designed 
for people like you, or for me for that matter.  It works well behind the gui 
for sipXecs as a media server.  It works well with Cudatel and their gui.   
That is the type of view of a product a company deploying commercial products 
takes when they evaluate products.

    I am overjoyed to hear that you have many commercial customers that you 
have zero issues with. That gives me hope that I could do it too. You're 
exactly the person I want to learn from. How did you do it? Do you use ITSPs? 
If so, which ones? What configurations work, and which don't? Instead of 
sipXbridge, if you use an external SIP gateway, what do you use? How do you 
configure it? What would you charge per hour to consult on the technical setup 
for my customers?

    You mentioned that if you use the right design, the right ITSP, and the 
right equipment, but you don't say what they are. What?  We are supposed to 
teach network design on this user group that is about sipXecs?  What networking 
gear (router, POE switch, firewall, etc.) do you use? Which ones would cause 
problems? Please be specific. I'm trying to learn what tricks and tips you have 
learned over the years. I know that some of this is in the wiki, but lots of 
specifics are missing.  Tim, I give advice freely to people all the time. But, 
you ever see someone pick their nose in a restaurant?  It kinds of spoils your 
appetite.  In view personal view, your email was inappropriate, and I could not 
in good conscience help you.  I believe it was damaging to the project, and I 
won't reward behavior like that.

    Finally, you mentioned Ezuce. I thought about registering as a partner, but 
I didn't want to spend $500 just to sign up with yet another vendor. I agree.  
I don't sell eZuce, and that is one of the reasons.  I am an agent for several 
carriers and I have never had to pay money for the opportunity to sell 
something for them. I was especially hesitant because I have had so many issues 
with my sipXecs deployment. If you know of some other organizations you would 
suggest that I partner with, please tell me who they are. 



    Tim, I have sold Millions of telecom equipment over the past 35 years.  In 
fact $22 Million to one customer in one sale over 10 years ago.  I do this 
because I enjoy it.  I do it because it is rewarding to me personally, not 
financially.  My customers love what I deliver, it helps them save money, in 
many cases it is what puts them in the black when they are bleeding.   I feel 
confident in what I deliver.  But when a customer forwards your email to me and 
starts questioning what I have talked them into, I get frustrated.  That email 
from them, which caused me to read your email, came at the end of a wonderful 
birthday spent with my wife, children and friends.  It put me over the top, and 
was very disappointing to read at the end of a otherwise beautiful day.



    This is all I have on the subject.  I hope you put more thoughts into your 
emails to this list in the future, as I don't believe you helped yourself much. 
 Otherwise, you might want to consider Trixbox, or Asterisk, or other 
commercial applications for building your business around.



    Regards,



    Todd Hodgen








Thanks, Tim IngallsShared Communications, Inc.801-618-2102 Office 
    On 02/16/2012 07:58 PM, Todd Hodgen 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.



    From: sipx-users-boun...@list.sipfoundry.org 
[mailto:sipx-users-boun...@list.sipfoundry.org] On Behalf Of Tim Ingalls
    Sent: Thursday, February 16, 2012 6:03 PM
    To: sipx-users list
    Subject: [sipx-users] sipXecs Commercial Feasibility



    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:

      a.. 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. 
      b.. 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. 
      c.. 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. 
      d.. 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? 
      e.. 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? 
      f.. 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. 
      g.. 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 IngallsShared Communications, Inc.801-618-2102 Office  

------------------------------------------------------------------------------


  _______________________________________________
  sipx-users mailing list
  sipx-users@list.sipfoundry.org
  List Archive: http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________
sipx-users mailing list
sipx-users@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Reply via email to