[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-09 10:51 CDT
====================================================================== 
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...
====================================================================== 

---------------------------------------------------------------------- 
 (0101386) madrouter (reporter) - 2009-03-09 10:51
 http://bugs.digium.com/view.php?id=13205#c101386 
---------------------------------------------------------------------- 
Using the timing value from the span line was exactly what I had in mind
when I wrote the patch.  This gives the behaviour as documented in the
sample system.conf file.  If you want a span never to be a clock source
just set it's timing value to 0.

Not sure I see the need for any weighting of PRI/BRI/Analog cards as sync
source.  If a user has more than one card, chances are they have some idea
what they're doing (as opposed to someone who's just experimenting with a
couple of SIP phones and maybe an analog trunk or two) and so should be
setting their clocking.

The other thing is - if they've got two different cards in the system
they're already in trouble unless they're using Xorcoms because unless
you've got some ugly solution like a sync cable there's no way the two
cards are going to be in sync.  I don't think any of the other hardware
manufacturers have any way of letting DAHDI clock the card rather than the
other way around. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-09 10:51 madrouter      Note Added: 0101386                          
======================================================================