[asterisk-bugs] [JIRA] (ASTERISK-25498) Asterisk crashes when negotiating g729 without that module installed
Jonathan Rose (JIRA)
noreply at issues.asterisk.org
Mon Nov 23 17:49:32 CST 2015
[ https://issues.asterisk.org/jira/browse/ASTERISK-25498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=228439#comment-228439 ]
Jonathan Rose edited comment on ASTERISK-25498 at 11/23/15 5:47 PM:
--------------------------------------------------------------------
I've got a patch for this issue that I want to try out, but I've been having a lot of trouble reproducing the issue. I usually end up in a situation where an audiohook will simply not execute on frames when the codec has no translation path to ulaw, but here the audiohook attempts to translate even after this check is (or would normally be) made.
I'd like to get some more information if you could... the following to be specific:
1. all log messages from the start of the call to the end of the call that triggers this crash
2. All extensions involved with the call. If the call is to stasis, all Stasis commands ran in order.
3. Configuration for the endpoints involved with the call. I think you are using chan_sip, so the endpoints used in sip.conf... not including sensitive information like passwords and IP addresses. Codec order would be a good one to have in particular. If the endpoints are defined via realtime, the CLI output for 'sip show peer <peername> load' works fine too.
was (Author: jrose):
I've got a patch for this issue that I want to try out, but I've been having a lot of trouble reproducing the issue. I usually end up in a situation where an audiohook will simply not execute on frames when the codec has no translation path to ulaw, but here the audiohook attempts to translate even after this check is (or would normally be) made.
I'd like to get some more information if you could... the following to be specific:
1. all log messages from the start of the call to the end of the call that triggers this crash
2. All extensions involved with the call. If the call is to stasis, all Stasis commands ran in order.
3. Configuration for the endpoints involved with the call. I think you are using chan_sip, so the endpoints used in sip.conf... not including sensitive information like passwords and IP addresses. Codec order would be a good one to have in particular.
> Asterisk crashes when negotiating g729 without that module installed
> --------------------------------------------------------------------
>
> Key: ASTERISK-25498
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-25498
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Codecs/General
> Affects Versions: 13.4.0
> Environment: $ lscpu
> Architecture: x86_64
> CPU op-mode(s): 32-bit, 64-bit
> Byte Order: Little Endian
> CPU(s): 8
> On-line CPU(s) list: 0-7
> Thread(s) per core: 1
> Core(s) per socket: 4
> Socket(s): 2
> NUMA node(s): 1
> Vendor ID: GenuineIntel
> CPU family: 6
> Model: 45
> Stepping: 2
> CPU MHz: 2300.000
> BogoMIPS: 4600.00
> Hypervisor vendor: VMware
> Virtualization type: full
> L1d cache: 32K
> L1i cache: 32K
> L2 cache: 256K
> L3 cache: 20480K
> NUMA node0 CPU(s): 0-7
> $ free -m
> total used free shared buffers cached
> Mem: 12010 11670 339 0 174 8262
> -/+ buffers/cache: 3233 8777
> Swap: 4092 26 4066
> $ uname -mrs
> Linux 3.13.0-62-generic x86_64
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description: Ubuntu 14.04.3 LTS
> Release: 14.04
> Codename: trusty
> Reporter: Ben Langfeld
> Assignee: Jonathan Rose
> Attachments: backtrace-asterisk-13.6.0.txt, backtrace.txt
>
>
> Regularly the following log lines are followed by Asterisk crashing (backtrace attached):
> ```
> [Oct 19 11:17:43] WARNING[15022][C-0001f68d] translate.c: No translator path: (starting codec is not valid)
> [Oct 19 11:17:43] WARNING[15051][C-0001f68d] channel.c: Unable to find a codec translation path: (g729) -> (ulaw)
> ```
> I do not see any relevant changes between 13.4.0 and 13.6.0, but I am in the process of upgrading anyway to confirm this issue is still present.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list