Asterisk Simply Stops Call Processing

Home » Asterisk Users » Asterisk Simply Stops Call Processing
Asterisk Users 3 Comments

Hi.

I have a strange problem and I’m looking for suggestions on how to investigate it.

I have a dialplan which is processing a call, and Asterisk simply stops doing anything for that call.

I have verbose and debug logging turned on.

There are two steps at a particular point in the dialplan:

Set(UserCredit=${ODBC_GENERIC(select Credit(‘${DDI}’))})

Verbose(6,Current credit level for user ${DDI} is ${UserCredit} pence)

Everything gets processed up to and including the first line – the verbose log file shows me:

pbx.c:2946 in pbx_extension_helper: Executing [0044xxxx509903@DialBleg:46]
Set(“SIP/TrunkTwo-00001184”, “UserCredit=999”) in new stack

(Phone number obscured here for anonymity).

Then, that is it. Nothing further happens with call processing (until one of the parties hangs up) and the second dialplan command above never appears in the verbose log file. I have several other Verbose(6,…..) commands preceding this, and they all output into the log file as expected.

If another call arrives on the same server, Asterisk quite happily starts processing it and records what it’s doing in the log files.

Can anyone suggest how I can investigate what Asterisk is doing at the point where it “gets stuck”, and how to find out why it simply stops processing the call and doesn’t continue with the dialplan commands?

Thanks,

Antony.


“The future is already here. It’s just not evenly distributed yet.”

– William Gibson

Please reply to the list;
please *don’t* CC me.

3 thoughts on - Asterisk Simply Stops Call Processing

  • If there are multiple connections that the utilize the same driver, try putting:

    Threading = 2

    in the appropriate driver section of
    /etc/odbcinst.ini

    …this would be a possibility if the problem is intermittent.

    Also can you successfully execute the same SQL from the cli?

    By the way, what driver is asterisk using?

  • I’ll give that a go, however I doubt that it is the problem, since I see the correct result from the ODBC query recorded in the assignment verbose log output, therefore the query is done and the result has been used by the time Asterisk freezes.

    It’s actually extremely repeatable – I have not seen call processing proiceed beyond this stage once so far.

    Yes, and as I say, they query is working fine and Asterisk is correctly using the returned value in the assignment.

    The further detail which I think I added in a later post is that this is actually in a context which gets called using a Gosub() from two different places in the dialplan.

    From one, it works fine; from the other, it gets stuck. Completely consistent.

    You mean ODBC? That’s connected to MariaDB.


    Why are they called “The Rocky Mountains”?
    What are other mountains made of?

    Please reply to the list;
    please *don’t* CC me.

  • I’ve been having a related problem. I have Asterisk with some call processing accessing Maria (hosted on the phone server, running Ubuntu) via func_odbc. That same odbc driver is used to write cdr records on a different server. I had never noticed a problem (and no threading attribute defined) until after I did a system update several months ago.

    Now if the ethernet cable is disconnected to the cdr server, call processing then hangs when func_odbc trys to access the locally hosted
    (same machine as asterisk) call process database. The zombied channels then accumulate.

    In my research, I read that the default threading value was changed in unixodbc to assume that threading would be handled by the individual odbc-drivers – rather than the odbc framework. Also, I read that unixodbc has to be compiled with a threading directive set to yes for the odbcinst.ini key-value to have any effect.

    Anyway I am suspecting that the ubuntu unixodbc package is now compiled without threading enabled.

    This is happening on a production machine, so I am somewhat limited in when
    & how much experimentation I can do.