[asterisk-bugs] [Asterisk 0010342]: On Mac OS X PowerPC, Asterisk 1.4.x stops bridging new calls shortly after start

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10342 
====================================================================== 
Reported By:                jcovert
Assigned To:                putnopvut
====================================================================== 
Project:                    Asterisk
Issue ID:                   10342
Category:                   Core/Portability
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     ready for testing
Asterisk Version:           1.6.0-beta8 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             07-31-2007 09:10 CDT
Last Modified:              05-09-2008 08:35 CDT
====================================================================== 
Summary:                    On Mac OS X PowerPC, Asterisk 1.4.x stops bridging
new calls shortly after start
Description: 
I have unsuccessfully tried to get every 1.4.x version of Asterisk to work
on Mac OS X PowerPC, most recently Asterisk 1.4.9 on Mac OS X 10.4.10.

Asterisk starts up fine, and works for a short while.  But after about the
third or fourth bridged call (local sip soft client, SJphone, or locally
connected SIP ATAs Cisco ATA 186), RTP read too short errors start
ocurring, or other dead call problems.  It is still possible to connect to
IVRs within asterisk, and inbound IAX2 calls from a 1.2.22 version of
Asterisk to the 1.4.9 version still work, but originating SIP devices are
unable to reliably make outbound calls.
====================================================================== 

---------------------------------------------------------------------- 
 jcovert - 05-09-08 08:35  
---------------------------------------------------------------------- 
Hi snuffy.  conftest.c is dynamically created for each of the various
possible configuration items; it's expected to fail when an item isn't
present; that's how the determination is made.  As each item is tested, the
successful compile (and link if appropriate) of conftest.c is used to add
lines like
#define HAVE_RES_NINIT 1
to the file confdefs.h.  If the compile/link fails, the line is not
added.

To see if the failure to detect res_ninit was really the problem, I forced
the lines
#define HAVE_RES_NINIT 1
#define HAVE_RES_NDESTROY 1
into the file even though the test for res_ninit failed.  (If the test for
res_ninit fails, configure doesn't even bother to look for res_ndestroy.)

This made the resulting configuration behave as though res_init and
res_ndestroy were present as far as configure were concerned.  If this
really is related to the problem, even if configure had properly detected
them, something else is still failing to use them, i.e. the successful
definition of the two symbols by configure isn't sufficient to solve the
problem.

/john 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
05-09-08 08:35  jcovert        Note Added: 0086659                          
======================================================================