So, can we set a date? I'd really like to see this happen. One thing I would like to learn about, is how to connect an office to a co-located server the right way, and who the best ITSP's are, cheers, Mark. ----- Original Message ----- From: "Philip Mullis" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, May 29, 2006 8:20 PM Subject: **SPAM: Re: [on-asterisk] Asterisk Horror Stories
Cool I think thats a great idea id be will to talk on things partaining to asterisk disasters and solutions and proactive testing and resolution methodologies. As well as on some key OPEN SOURCE solutions for doing connectivity debuging and testing to assess traffic capabilites of dsl/cable home users etc line quailty yadda. Lets step the knowledge up on the Taug community :) _*For the people who still read the how to's or want to do itps or use asterisk for the companies read below *_Asterisk makes great for a PBX but unless your knowledable on C code, Networking, Telephoney and Linux aswell as asterisk basics, making serious production boxes is something to be avoided and probably recommended against from a business perspective (there are lots of sip servers with voicemail etc.. for less than 2k such as the allworx gear(sip appliances , non asterisk)) _* Problems/ tips/ considerations for the itsp/business or end user*_ *From the itsp or box builders perspective* 1) line quailty based issues echo,pops and drops... due to impromper hardware mating (not prevalant in sangoma but digium.. oh yeah some of you know what im talking about hehehee) 2) Long distance and other asterisk peers, in this case some people are to far away in ms travel time has an effect on g729 codec audio quailty ulaw stands up the best but really you dont want peers that are high in latenct. 3) Scaling, for redundancy and scalign sakes in large operations asterisk does not usually make the best choice for a bridgehead server, it runs much better as a backend. 4) Poor Server bandwidth (some itps believe it or not hose out of pod offices with very limited bandwidth) Anything hosted at core colos tends to be the way to go :) 5) Purchased bandwidth from cogeco (beware bandwidth is over sold so traffic is not premium grade) (itsps in toronto core only) 6) Routing .. routign to end points is key if your at a colo learn about BGP routing :) for the win and learn such routing softs as Zebra or Quagga(baesd on Zebra) 7) Linux/Unix setup, if your makign an asterisk box.. make it an asterisk box.. not an xwindows box.. most people tend to run into all sorts of additional trouble this way. 8) Take asterisk from BRANCHES NOT TRUNK (all thos [EMAIL PROTECTED] users ... your update script takes from trunk!) trunk is stuff in development not stable 9) Monitoring tools, have scripts that will monitor your process and restart ones that go amuk if the case may be, also have them inform you of issues that may have occured... its always nice to not have to log into a box just have things sent to cellphone test message alerting you of things like system goign into unusually high cpu cycles. *From the end users (people connecting to central servers/itsps) * 1) Firewall Issues 2) Nat Traversal issues (1&2 , can interfear with call transfers) 3) You believe your 5meg dsl is the bomb until you realize you only have about 400kbps upstream which is good for 3 simultanous ulaw calls (technically 4 but we knock on down due to spikes) 4) Poor network control/qos ... most people blame the core internet for qos :) it tends not to be the issue ever really its all to do with how your controlling your traffic going out (in house qos devices recommended , if you are on dsl or cable do a ping/traceroute to your itsp to see where they are in relativity before you sign up if your less (< 100ms it will be good) (<50ms excellent) around 150ms..hello cellphone quailty >150 chooe a differnt itsp ) 5) customer support .. is it any good .. for instance i tried some other itsp for custoemr response some are good some are horrid 1week+ 6) Highspeed quailty , similar to 3 but partaining to packet drops, does your highspeed connection drop packets? does it suffer speed differences at peak times of the day? these are some important questions to get answered 7) 911 , yes it is possible on voip , so usually you want to find out if you still need to keep a cell phoen in case of heart attach or be ok with your net phone. for those with no asterisk experince and no linux skill (aka the [EMAIL PROTECTED] candidate)- Asterisk supports just about every feature you can think of from a traditional telephony standpoint, when you get it dont expect all those features to work, you actuall have to configure them all :) its not a windows based software good to go out of the box.. learn how to use google, IRC, and the voip wiki and you will be well on your way to getting everything working you need to get working just be patient and the open source community will gladly help you. :) Regards, Philip Mullis Mark Palser wrote: >Not even mistakes, sometimes things just don't work, it's people ingenuity >I'm interested in. You're right though, I think most of us are almost >beyond >the how to's , now for the dirt. Frankly I'd rather learn from other >peoples >trials and tribulations than experience them first hand, Mark. >----- Original Message ----- >From: "Shidan" <[EMAIL PROTECTED]> >To: "Mark Palser" <[EMAIL PROTECTED]> >Cc: <[email protected]> >Sent: Monday, May 29, 2006 4:54 PM >Subject: [>>> SPAM <<<] - Re: [on-asterisk] Asterisk Horror Stories - Email >found in subject > > >Mark I agree with you on this, it sounds like a very good topic, a day to >learn >from our mistakes. Who here has made some serious mistakes who would >like to talk? > >I think coming with a set of Asterisk Anti-Recipes is probably even more >useful >at this point with so much info out there than talking about more how to's. > >On 5/29/06, Mark Palser <[EMAIL PROTECTED]> wrote: > > >>I think you hit the nail on the head there, a lot of the problems are pure >>ignorance, but can we really be blamed, as there is little to no >>documentation and what tidbits you can find make huge assumptions of their >>own. I think as a group we have such a wealth of experience, form the >>smallest annoyance to major obstacles overcome and some real characters in >>our midst, it would make for an interesting meeting, Mark. >>----- Original Message ----- >>From: "Andrew Kohlsmith" <[EMAIL PROTECTED]> >>To: <[email protected]> >>Sent: Monday, May 29, 2006 4:30 PM >>Subject: [>>> SPAM <<<] - Re: [on-asterisk] Asterisk Horror Stories - >>Email >>found in subject >> >> >>On Monday 29 May 2006 16:10, Mark Palser wrote: >> >> >>>Not wanting to put Asterisk in a bad light, but this technology is still >>>so >>>new and raw, I think we all have some stories where things didn't quite >>>go >>>as planned. I really think it would benefit us all if one meeting could >>>be >>>put aside to share some of these "experiences", we could then discuss >>>what >>>went wrong and possible solutions, Mark. >>> >>> >>I am willing to bet that almost all of them will be rooted in poor >>assumptions >>or basic lack of knowledge about this new technology, including: >> >>1) business lines from a VOIP provider that didn't work >>a) because we assumed that the internet was able to provide QoS >>b) because we assumed that the provider'd never go tits-up >> >>2) runaway costs >>a) because we didn't understand the nature of computer telephony >>b) because we learned the hard way about echo cancellation >>c) because legacy vendors have DECADES of experience in customer lock-in >> >>3) lack of features >>a) because we assumed Asterisk had feature 'x' >>b) because feature 'x' seems simple in theory >> >>I have personally been bitten by #2 and #3. Anyone else? :-) >> >>-A. >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
