Asterisk stalls call when setting CDR variable, until timeout

Asterisk Asterisk Support
1

hello,

some initial details

  • using Asterisk 13.23.1 in Production (5 instances) and Asterisk 13.38.2 in DEV (3 instances); both environments are virtualized
  • each VM have 3 network interfaces: eth0, eth1, eth2; SIP and audio are managed by eth1; DB traffic by eth2;
  • DB cluster is also virtualized and includes 3 Mariadb 10.6.x nodes using Galera for clustering; DB is accessed using a Virtual IP address that currently points to Node #1
  • Asterisk uses CDR Odbc and CDR table has many extended fields
  • Dialplan uses some func_odbc functions

Problem description:
The following issue happens in both environments, and in any VM.
The dialplan makes use of some Set(CDR(key)=value) before executing the Dial command.
Example:

same => n,Set(CDR(fromRoute)=${CHANNEL(accountcode)})
same => n,Goto(${context},${EXTEN},1)
same => n,Set(CDR(fromIP)=${SIPPEER(${peername},ip)})

The issue is that, from time to time, the Set(CDR(x)=y) command stops the dialplan for up to 30 seconds. It is like if the Set(CDR(x)=y) stalls the dialplan process and, after some kind of timeout, it continues executing normally.
In the above lines, if the first Set(CDR(fromRoute)…) stalls the dialplan process for 30 seconds, it will recover and continue to the next line. And the second Set(CDR(fromIP)…) will be executed normally, without any issue, until the dialplan is fully executed.
The end result is the call will have a very high PDD (A Leg makes a call request, diaplans stalls at Set(CDR(x)…), dialplan recovers, dial command is set to call B Leg) and most of the time, A Leg will cancel the call request prior to be redirected to B Leg.

I think this behaviour is related to how Asterisk’s DB connection/processing is managed, In fact, if the DB cluster is unavailable for some reason, the behaviour is very similar but without the timeout: the calls gets stuck in the first Set(CDR(x)…) command and won’t proceed.
I would expect that is DB cluster is unreachable, then the call would be processed normally and CDR saved on standard .CSV file (which is enabled).

These are the current CDR status:
CLI> cdr show status

Call Detail Record (CDR) settings

Logging: Enabled
Mode: Simple
Log unanswered calls: Yes
Log congestion: Yes

  • Registered Backends

    mysql
    Adaptive ODBC
    cdr_manager
    cdr-custom
    csv

Does anyone have had similar issue? Any clue?

1 Like
2

If you are using databases, you should update one on the same machine as Asterisk, and then replicate that to the final destination.

On the other hand I would be surprised if anything was written to the database until the CDR was closed.

You will need to reproduce this on a supported version of Asterisk before anyone is likely to look at it in depth.

3

Agreed. Your are working those CDRs hard!

You could try switching from CDR simple mode to batch mode.

Or you might want to look into adjusting thread pool settings in the Stasis configuration:

And check on your taskprocessors:

1 Like
4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.