[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:33 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0101323) sruffell (administrator) - 2009-03-06 16:33
 http://bugs.digium.com/view.php?id=13205#c101323 
---------------------------------------------------------------------- 
Why might it be better to have asterisk load dahdi_dummy?  If the logic is
such that dahdi should have an optional timing source at all times, then it
doesn't seem like getting asterisk involved gets us anything, other than a
little bit less code loaded up that may be unused much of the time. 

Also, one of the cases that kpfleming brought up is this:  Someone has a
single span connected to a provider and are conferencing a group of sip
channels together in meetme.  If the span goes down, the conference will
become intelligible since there is not timing source to use to conference
the channels together.  If asterisk is responsible for loading dahdi_dummy,
then the window of time to switch over would be greater and it involves
more components in the process of getting the alternate timing up or
supporting kernels in the future that do not want to use loadable modules
but instead want everything compiled in by default. 

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