[asterisk-users] Discussion: Are we ready to leave 1.4 behind?

[Matt Riddell]

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)