Summary:	ASTERISK-13938: pri_resolve_span assumes span's channels have consecutive numbers
Reporter:	Tzafrir Cohen (tzafrir)	Labels:
Date Opened:	2009-04-11 09:01:11	Date Closed:	2009-11-10 08:51:58.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_dahdi
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	pri_resolve-span assumes that the the D channel of a span is at channel number <base> + 16 / 24 / 3 (for E1/ T1/J1 / BRI, respectively). This is normalyl the case. But does not apply if channels of the span do not have consecutive numbers. Which is something that can happen with the right order of modules loading / unloading sequence in a multi-device system. Furthermore, when the function is called it is called with the following value for the parameter 'offset':  channel - p.chanpos Thus making this assumption again.
Comments:	By: Jeff Peeler (jpeeler) 2009-10-02 13:08:38 Can you provide a chan_dahdi.conf sample (and system.conf if necessary) to demonstrate this issue? It seems to me that any surprises from module load order would be found when running dahdi_cfg, which enforces consecutive channel order. By: Tzafrir Cohen (tzafrir) 2009-10-03 01:02:18 It's not a matter of configurations. You basically need to have a "hole" of channels in use. A simple example: a system with a certain single-span E1/T1 card and another card. You configure the E1/T1 card as T1, load its module and the module of the other card. Now unload the module of the E1/T1 card, configure it to load as E1, and load it. Channels 25-31 of the span will be positioned after the channels of the first card. By: Jeff Peeler (jpeeler) 2009-10-05 16:52:10 Even with a span configured with a "hole" in it, chan_dahdi handled it appropriately for me as long as the dchannel is in the position assumed as you stated above. I started a branch to actually find the dchannel instead of assuming, but it seemed to provide little benefit since both sides were still going to have to use the same time slot for the dchannels. I guess there would have to be some mapping for each side's bchannels for the dchannels to not be using the same time slot. Is this worth pursuing further or have I missed something? By: Jeff Peeler (jpeeler) 2009-10-07 18:13:59 I loaded a quad-span as T1 and then loaded another card. I then unloaded the T1 module, reloaded as E1, reconfigured chan_dahdi with the new channel numberings, and everything seemed to work fine. Tzafrir: Have you been able to find a problem with chan_dahdi configured with the nonconsecutive channels? By: Leif Madsen (lmadsen) 2009-11-10 08:51:58.000-0600 I'm closing this as unable to reproduce, however feel free to reopen this issue should you have any further comments. Thanks!