[asterisk-bugs] [DAHDI-linux 0013205]: [patch] bad master selection

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13205 
====================================================================== 
Reported By:                biohumanoid
Assigned To:                kpfleming
====================================================================== 
Project:                    DAHDI-linux
Issue ID:                   13205
Category:                   dahdi (the module)
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
====================================================================== 
Date Submitted:             2008-07-31 00:11 CDT
Last Modified:              2009-03-06 16:10 CST
====================================================================== 
Summary:                    [patch] bad master selection
Description: 
Current dahdi master handling work in the following way:
The first SPAN become a master
If a new registered !!! SPAN is preferred , it is the new master
If a span is unregistered - the new master is the first available span
If master SPAN is in alarm state - the new master is the first non in
alarm state SPAN

So
1. dahdi-dummy once loaded will be the master forever.
2. even not-running SPAN can be a master
3. master implementation is ugly...
====================================================================== 

---------------------------------------------------------------------- 
 (0101322) sruffell (administrator) - 2009-03-06 16:10
 http://bugs.digium.com/view.php?id=13205#c101322 
---------------------------------------------------------------------- 
Just so I understand, how would an automatic timing source in dahdi-base
cause problems with your test environment?  If on the machine that is
receiving timing from the dynamic span suffers a loss of network
connection, you would not want dahdi to be able to generate it's own timing
internally in order to continue to process any meetme conferences that may
be running on pseudo channels?

As long as that dynamic span doesn't try and start to provide timing to
the upstream device, what would break?  And if a dynamic_span is configured
to take timing from the network, it doesn't seem like it should ever then
switch to provide timing (just like ISDN spans, etc..) 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-06 16:10 sruffell       Note Added: 0101322                          
======================================================================