On 29/04/11 11:51 AM, Ernie Dunbar wrote:
On 29/04/11 5:06 AM, Ira wrote:
At 05:56 AM 4/28/2011, you wrote:
If I can install 1.8 and
know that I can "turn off" things to get to 1.4 "solidness", then I
don't
have a problem with this kettle of fish. BTW, where does 1.10 fit into
this
conversation?
Personally, 1.8 has never lasted more than 12 hours on my box without
dying and once I figured out how it dies, every beta and every release
will fail within moments if I followed the same very short test script.
I did put up a bug report on the problem once and was told within
moments it wasn't a bug, but I'm not smart enough to understand what I'm
supposed to do to troubleshoot and the same configuration has always run
on 1.2, 1.6 and 1.10 so from my perspective, it's a bug.
What's the URL to the bug you submitted?
I'm running 1.8 here 24/7 with no problems other than the ones that Alec
Davis fixed. I've got it running in I think 4 installations and we're
not getting any core dumping or anything - obviously I'm only using a
subset of the full functionality and most modules are not included.
What features do you have disabled? It would be helpful to know this for
future 1.8 implementation, although right now we can't quite use it yet.
The opposite of what we're using :-)
We've been reworking our GUI software to work on embedded systems as
well as larger so we use:
AGI for all outbound calling logic - our licensing code sets up routes
for the customers (i.e. which providers they're using etc) and then they
chose order (i.e. VoIP followed by Analogue etc). If a destination
can't be matched via an outbound route then the call is passed back to
the dialplan.
Applications/Functions we use:
Macro, Dial, VoiceMail, VoiceMailMain, Goto, GotoIf, GotoIfTime, Hangup,
UserEvent, Answer, Playback, Record
Some others:
* Pickup application with PICKUPMARK
* DB Functions
* We don't use Asterisk Realtime for these systems
* Call transfers etc are all done by the phones themselves
* DAHDI for timing - even if it's just DAHDI_dummy
* MeetMe (we haven't started using confbridge yet)
* Set application for variables
* hints
* SIPAddHeader or Set(__SIPADDHEADER=
* Outbound calling via IAX2, DAHDI and SIP - depending on the customer
* RFC2833 or Inband DTMF (depending on issues)
And that's it.
We don't use any of the imap voicemail stuff, don't usually use Google
Talk or anything. Don't usually use Jabber. Try to stay away from Local
channels wherever possible. Restart Asterisk in the middle of the night
in case there are any memory leaks.
If we ever have any problems we try to track it down to the exact
revision that caused the problem, read the commit and try and submit a
bug entry with as much detail as possible. It's pretty unusual for you
to be the only person experiencing a bug so normally if you come across
something you'll see other people with the same problem. If you don't
it's because you're doing something different to the majority of users
or it's a very new bug. So you first look at what you're doing that's
different (we use chan_lcr occasionally as BRI isn't working for us with
DAHDI - LCR has caused some issues). If it is caused by doing something
in a way that is different then see if you can do it how most people
would. If it still causes an issue, either fix it or submit a ticket.
You can usually work around most things.
For example we had a problem last week where an incoming call to a DDI
had a 302 redirect from the phone to another number - i.e. the person
was out of the office so they redirected to their cell. When the call
went back to Asterisk it used the local channel and made an outbound
call to the cellphone. After 2 seconds of ringing it would hangup and
head back to the desk phone - that would redirect it back to the
cellphone etc etc.
It turned out that for whatever reason the LCR channel wasn't happy with
the redirection - when tested with the incoming call coming from IAX
instead of LCR it worked fine. We then thought that maybe it was
because the LCR channel hadn't been answered. We added an Answer()
before sending the call to the phone and it resolved the problem.
This was not a crash and was caused by the fact that we were doing
something that most people aren't (using chan_lcr in Asterisk 1.8). If
everyone's calls did this when they saw a 302 redirect it certainly
would have shown up on the issue tracker.
--
Cheers,
Matt Riddell
_______________________________________________
http://www.venturevoip.com/news.php (Daily Asterisk News)
http://www.venturevoip.com/exchange.php (Full ITSP Solution)
http://www.venturevoip.com/cc.php (Call Centre Solutions)
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
