[asterisk-bugs] [Asterisk 0016070]: [patch] Seg Fault on Transfer with IAX/iLBC

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16070 
====================================================================== 
Reported By:                Ayth
Assigned To:                dvossel
====================================================================== 
Project:                    Asterisk
Issue ID:                   16070
Category:                   Channels/chan_iax2
Reproducibility:            always
Severity:                   block
Priority:                   normal
Status:                     assigned
Target Version:             1.4.27
Asterisk Version:           1.4.27-rc2 
JIRA:                       SWP-296 
Regression:                 Yes 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-10-14 12:18 CDT
Last Modified:              2009-11-05 09:29 CST
====================================================================== 
Summary:                    [patch] Seg Fault on Transfer with IAX/iLBC
Description: 
Hello,

We recently in our process of upgrading asterisk have run into serious
problems. Our environment is as follows:

Asterisk clusters spread across three countries. IAX trunking is done
between each office. Running CentOS 4.7 and Asterisk 1.4.26.

We have for the longest time used iLBC as the codec between the offices,
and wish to continue, however, we are experiencing seg faults with it. See
https://issues.asterisk.org/view.php?id=13116, as we are having the exact
same issues, but the patch in this post is already in our code.

When using jitter buffer, with iLBC and Mixmonitor we have seg faults when
a user tries to transfer the call to another party within the office. A
example call is as follows:

1. Call comes into our system in one office, and is trunked via IAX to
another office.
2. Call gets recorded using MixMonitor(with audiohook_inherit), and enters
a queue.
3. Call is answered by one of our staff. If the call is completed with
that one agent we are fine, however, if that agent needs to transfer it to
another person Asterisk seg faults and dumps it's core.

I have run gdb against the core, and am posting it here, also before
testing this I turned up SIP/IAX/Core debugging within the CLI. I've also
attached that output.

We normally use a RPM version of Asterisk that we package ourselves,
however, I'm able to reproduce this from source at will. If I remove the
option for jitterbuffer, or not record the call, or change the codec I
don't get the seg faults at all. However, we need them in place or else the
phone quality goes down the tubes.
====================================================================== 

---------------------------------------------------------------------- 
 (0113191) Ayth (reporter) - 2009-11-05 09:29
 https://issues.asterisk.org/view.php?id=16070#c113191 
---------------------------------------------------------------------- 
Ok, so I've installed 1.4.26.2(from source, to rule out any rpm stuff),
with the patch applied, and it doesn't crash, which is exactly what dvossel
said, but it also doesn't provide the output it should either. I turned the
verbosity way up and still nothing.

I then went back to pristine 1.4.26.2 sources, and it crashes perfectly(or
not perfectly depending on your thoughts). With no change of configuration
or anything if I switch between the two versions, I can crash on the
unpatched version. But it's kind of weird to not get the log message I was
expecting. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-11-05 09:29 Ayth           Note Added: 0113191                          
======================================================================