[Home]

Summary:ASTERISK-14199: IAX trunk only comes up as trunk in one direction only, unless you unload and load chan_iax
Reporter:Alec Davis (alecdavis)Labels:
Date Opened:2009-05-26 05:31:54Date Closed:2009-06-09 11:34:21
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_iax2
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:running asterisk -vvvvvc we find the line:
[May 26 21:43:44] WARNING[24802]: chan_iax2.c:10819 build_peer: Unable to support trunking on peer 'ald' without a timing interface

We have a DADHI timing source in all installations.
*CLI> timing test
Attempting to test a timer with 50 ticks per second.
Using the 'DAHDI' timing module for this test.
It has been 1019 milliseconds, and we got 51 timer ticks

*CLI> iax2 show peers
Name/Username    Host                 Mask             Port          Status
ald/ald          200.201.202.203 (S)  255.255.255.255  4569          OK (64 ms)

*CLI> module load chan_iax2.so
*CLI> iax2 show peers
Name/Username    Host                 Mask             Port          Status
ald/ald          200.201.202.203 (S)  255.255.255.255  4569 (T)      OK (59 ms)


*CLI> iax2 show peer aldhome


 * Name       : ald
 Secret       : <Set>
 Context      :
 Parking lot  :
 Mailbox      :
 Dynamic      : No
 Trunk        : Yes
 Encryption   : No
 Callerid     : "" <>
 Expire       : -1
 ACL          : No
 Addr->IP     : 200.201.202.203 Port 4569
 Defaddr->IP  : 0.0.0.0 Port 0
 Username     : ald
 Codecs       : 0x70f (g723|gsm|ulaw|alaw|g729|speex|ilbc)
 Codec Order  : (alaw|ulaw|gsm)
 Status       : OK (46 ms)
 Qualify      : every 60000ms when OK, every 2000ms when UNREACHABLE (sample smoothing On)


****** ADDITIONAL INFORMATION ******

We have multiple servers, at various 1.6.x versions, most exhibit the same problem.

SVN-trunk-r181371M, requires reload of chan_iax.

SVN-trunk-r178919M, requires reload of chan_iax, and patch below.

SVN-trunk-r178446M this our oldest version doesn't. Every time IAX trunks come up as TRUNKS. Did require patch mentioned below.

WARNING: older versions may require this patch first before unloading chan_iax, Asterisk may SEGFAULT.
http://lists.digium.com/pipermail/svn-commits/2009-March/044686.html



Comments:By: Alec Davis (alecdavis) 2009-05-26 06:15:51

The IAX setup we have is a hub (our older box) and spoke, the hub seems to bring up it's end of each IAX trunk in trunk mode. But the spokes end being newer versions, won't come up in trunk mode, they read a reload.

If I upgraded this box, which I can't, as it's in production, then neither end probably would be in trunk mode.
By: Leif Madsen (lmadsen) 2009-05-26 08:30:13

Is there any particular versions where this works fine? I'm trying to determine if there is a regression here that could be tracked down and refined to cause this to work across all versions.
By: Alec Davis (alecdavis) 2009-05-26 13:38:37

Regression happened I suspect somewhere after r178446M but before r178919M.

We don't have 2 systems at r178446m.
By: David Vossel (dvossel) 2009-05-27 12:02:48

[May 27 11:45:04] NOTICE[20284]: loader.c:864 load_modules: LOADING:chan_iax2.so
[May 27 11:45:04] NOTICE[20284]: loader.c:864 load_modules: LOADING:codec_lpc10.so
[May 27 11:45:04] NOTICE[20284]: loader.c:864 load_modules: LOADING:func_module.so
[May 27 11:45:04] NOTICE[20284]: loader.c:864 load_modules: LOADING:chan_oss.so
[May 27 11:45:04] NOTICE[20284]: loader.c:864 load_modules: LOADING:app_userevent.so
[May 27 11:45:04] NOTICE[20284]: loader.c:864 load_modules: LOADING:func_redirecting.so
[May 27 11:45:04] NOTICE[20284]: loader.c:864 load_modules: LOADING:app_softhangup.so
[May 27 11:45:04] NOTICE[20284]: loader.c:864 load_modules: LOADING:res_timing_timerfd.so

Here's the problem, the timer is never opened in chan_iax because the timer module isn't loaded until after chan_iax.  This why doing a reload works.
By: Jonathan Thurman (jthurman) 2009-05-29 10:44:23

Adding the timing source as a preload in modules.conf works around this issue (tested on 1.6.1.0).  Shouldn't the timing module be loaded early in the process by default?
By: Digium Subversion (svnbot) 2009-06-09 11:22:05

Repository: asterisk
Revision: 199743

U   trunk/include/asterisk/module.h
U   trunk/main/loader.c
U   trunk/res/res_timing_dahdi.c
U   trunk/res/res_timing_pthread.c
U   trunk/res/res_timing_timerfd.c

------------------------------------------------------------------------
r199743 | dvossel | 2009-06-09 11:22:04 -0500 (Tue, 09 Jun 2009) | 11 lines

module load priority

This patch adds the option to give a module a load priority. The value represents the order in which a module's load() function is initialized.  The lower the value, the higher the priority.  The value is only checked if the AST_MODFLAG_LOAD_ORDER flag is set.  If the AST_MODFLAG_LOAD_ORDER flag is not set, the value will never be read and the module will be given the lowest possible priority
on load.  Since some modules are reliant on a timing interface, the timing modules have been given a high load priorty.

(closes issue ASTERISK-14199)
Reported by: alecdavis
Tested by: dvossel

Review: https://reviewboard.asterisk.org/r/262/

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=199743
By: Digium Subversion (svnbot) 2009-06-09 11:28:50

Repository: asterisk
Revision: 199744

_U  branches/1.6.2/
U   branches/1.6.2/include/asterisk/module.h
U   branches/1.6.2/main/loader.c
U   branches/1.6.2/res/res_timing_dahdi.c
U   branches/1.6.2/res/res_timing_pthread.c
U   branches/1.6.2/res/res_timing_timerfd.c

------------------------------------------------------------------------
r199744 | dvossel | 2009-06-09 11:28:50 -0500 (Tue, 09 Jun 2009) | 18 lines

Merged revisions 199743 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r199743 | dvossel | 2009-06-09 11:22:04 -0500 (Tue, 09 Jun 2009) | 11 lines
 
 module load priority
 
 This patch adds the option to give a module a load priority. The value represents the order in which a module's load() function is initialized.  The lower the value, the higher the priority.  The value is only checked if the AST_MODFLAG_LOAD_ORDER flag is set.  If the AST_MODFLAG_LOAD_ORDER flag is not set, the value will never be read and the module will be given the lowest possible priority
 on load.  Since some modules are reliant on a timing interface, the timing modules have been given a high load priorty.
 
 (closes issue ASTERISK-14199)
 Reported by: alecdavis
 Tested by: dvossel
 
 Review: https://reviewboard.asterisk.org/r/262/
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=199744
By: Digium Subversion (svnbot) 2009-06-09 11:33:32

Repository: asterisk
Revision: 199745

_U  branches/1.6.1/
U   branches/1.6.1/include/asterisk/module.h
U   branches/1.6.1/main/loader.c
U   branches/1.6.1/res/res_timing_dahdi.c
U   branches/1.6.1/res/res_timing_pthread.c

------------------------------------------------------------------------
r199745 | dvossel | 2009-06-09 11:33:32 -0500 (Tue, 09 Jun 2009) | 18 lines

Merged revisions 199743 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r199743 | dvossel | 2009-06-09 11:22:04 -0500 (Tue, 09 Jun 2009) | 11 lines
 
 module load priority
 
 This patch adds the option to give a module a load priority. The value represents the order in which a module's load() function is initialized.  The lower the value, the higher the priority.  The value is only checked if the AST_MODFLAG_LOAD_ORDER flag is set.  If the AST_MODFLAG_LOAD_ORDER flag is not set, the value will never be read and the module will be given the lowest possible priority
 on load.  Since some modules are reliant on a timing interface, the timing modules have been given a high load priorty.
 
 (closes issue ASTERISK-14199)
 Reported by: alecdavis
 Tested by: dvossel
 
 Review: https://reviewboard.asterisk.org/r/262/
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=199745
By: Digium Subversion (svnbot) 2009-06-09 11:34:20

Repository: asterisk
Revision: 199746

_U  branches/1.6.0/

------------------------------------------------------------------------
r199746 | dvossel | 2009-06-09 11:34:19 -0500 (Tue, 09 Jun 2009) | 17 lines

Blocked revisions 199743 via svnmerge

........
 r199743 | dvossel | 2009-06-09 11:22:04 -0500 (Tue, 09 Jun 2009) | 11 lines
 
 module load priority
 
 This patch adds the option to give a module a load priority. The value represents the order in which a module's load() function is initialized.  The lower the value, the higher the priority.  The value is only checked if the AST_MODFLAG_LOAD_ORDER flag is set.  If the AST_MODFLAG_LOAD_ORDER flag is not set, the value will never be read and the module will be given the lowest possible priority
 on load.  Since some modules are reliant on a timing interface, the timing modules have been given a high load priorty.
 
 (closes issue ASTERISK-14199)
 Reported by: alecdavis
 Tested by: dvossel
 
 Review: https://reviewboard.asterisk.org/r/262/
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=199746