hangup not detected?

Home » Asterisk Users » hangup not detected?
Asterisk Users 4 Comments

On Fri, May 18, 2012 at 12:00 PM, Justin Killen <
jkillen@allamericanasphalt.com> wrote:

> I have and automated call-in dispatch system where hundreds of people
> call in daily for 2-3 minutes each. The extension is set up to get their
> information, then text-to-speech the dispatch information (via odbc). It
> then loops 5 times then ends the call. These calls are being handled by an
> 8 port analog digium card. ****
>
> ** **
>
> Sometimes though, I see calls via ‘core show channel dahdi/1-1’ that have
> a time of > 16 hours. I’m not sure if this is a result of dahdi missing
> the hangup, ODBC timing out, or TTS failing for some reason. When a
> channel gets in this state, the call doesn’t seem to progress through the
> dialplan, they always display the TTS line. Doing a ‘dahdi destroy channel
> 1-1’ doesn’t seem to be effective – the only way I’ve been able to clear
> the calls is to do a ‘dahdi restart’ and/or restart the asterisk service.*
> ***
>
> ** **
>
> For TTS I’m using cepstral with the Swift wrapper.****
>
> ** **
>
> Here is a snippet of my dialplan:****
>
> ** **
>
>
Can you post the CLI output of a call that gets “hung”? I’d like to see
where it’s hanging on.

Also, as a work-around to attempt to solve the symptom and not the
underlying issue, you could maybe setup a cron job that runs once every ten
minutes that checks for stale calls using AMI, and then hangs up any calls
up that are over 10 minutes long? Using the AMI Hangup command?

4 thoughts on - hangup not detected?

  • Okay, the next time it gets in this state I’ll gather that information.

    Justin Killen
    ________________________________
    Sent: Monday, May 21, 2012 1:22 PM

    I have and automated call-in dispatch system where hundreds of people call in daily for 2-3 minutes each. The extension is set up to get their information, then text-to-speech the dispatch information (via odbc). It then loops 5 times then ends the call. These calls are being handled by an 8 port analog digium card.

    Sometimes though, I see calls via ‘core show channel dahdi/1-1’ that have a time of > 16 hours. I’m not sure if this is a result of dahdi missing the hangup, ODBC timing out, or TTS failing for some reason. When a channel gets in this state, the call doesn’t seem to progress through the dialplan, they always display the TTS line. Doing a ‘dahdi destroy channel 1-1’ doesn’t seem to be effective – the only way I’ve been able to clear the calls is to do a ‘dahdi restart’ and/or restart the asterisk service.

    For TTS I’m using cepstral with the Swift wrapper.

    Here is a snippet of my dialplan:

    Can you post the CLI output of a call that gets “hung”? I’d like to see where it’s hanging on.

    Also, as a work-around to attempt to solve the symptom and not the underlying issue, you could maybe setup a cron job that runs once every ten minutes that checks for stale calls using AMI, and then hangs up any calls up that are over 10 minutes long? Using the AMI Hangup command?

  • Here is the output from the cli:

    dozer*CLI> core show channels
    Channel Location State Application(Data)
    DAHDI/5-1 s@DB_LOOKUP:24 Up Swift(“”Schedule for employee
    1 active channel
    1 active call
    1528 calls processed
    dozer*CLI> core show channel dahdi/5-1

  • Swift() is an asterisk wrapper around the text-to-speech engine cepstral. Looks like this is a dev issue – I’ll start a new thread on the dev mailing list.

    Justin Killen
    Senior Programmer / Analyst
    All American Asphalt
    951-736-7600 x 2060
    jkillen@allamericanasphalt.com
    ________________________________
    Sent: Thursday, May 24, 2012 4:41 PM

    Looks like Swift() (whatever that is) is not returning ?