[asterisk-bugs] [Asterisk 0014877]: pri_resolve_span assumes span's channels have consecutive numbers

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=14877 
====================================================================== 
Reported By:                tzafrir
Assigned To:                jpeeler
====================================================================== 
Project:                    Asterisk
Issue ID:                   14877
Category:                   Channels/chan_dahdi
Reproducibility:            have not tried
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           SVN 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 187963 
Request Review:              
====================================================================== 
Date Submitted:             2009-04-11 09:01 CDT
Last Modified:              2009-10-05 16:52 CDT
====================================================================== 
Summary:                    pri_resolve_span assumes span's channels have
consecutive numbers
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.
====================================================================== 

---------------------------------------------------------------------- 
 (0111880) jpeeler (administrator) - 2009-10-05 16:52
 https://issues.asterisk.org/view.php?id=14877#c111880 
---------------------------------------------------------------------- 
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? 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-10-05 16:52 jpeeler        Note Added: 0111880                          
======================================================================