[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-02-08 06:40 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0099672) tzafrir (manager) - 2009-02-08 06:40
 http://bugs.digium.com/view.php?id=13205#c99672 
---------------------------------------------------------------------- 
Suppose we want to have a single select_sync_master() function[1]. How
could DAHDI choose better?

Here is the general order I'd like:

1. Digital spans synched from an external source
  * Order among them: choose manually?
  * PRefer PRI to BRI?
2. Other spans from a hardware device (that provides clock)
  * Order among them: manual.
3. dahdi_dummy
4. Spans that provide no timing at all.

Cases of spans that provide no timing:
* Dynamic (dahdi_dynamic) spans that are timing providers (to the remote
side).
* Astribank (xpp) span in a NOTOPEN alarm.

At the moment DAHDI has no way of getting manual preference order from the
user. The "timing" parameter of the span line seems useful, but has a few
problems:

* It already overloads two separate selections:
  1. Is the timing on this span set from here or from the remote side?
  2. What is the priority among different spans in the current device?
For instance, I'd like to give a dynamic span that is a timing provider a
different priority than such span from a card. But both get timing=0.

* DAHDI does not know its value. THe real value is never saved anywhere.
We could save the value after a successful call to the span_config method
of the span. But we can't be sure if the span didn't change it (see
wct4xxp).


[1] 'master' on its own has other meanings in the code, which is why I
prefer 'sync_master' 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-02-08 06:40 tzafrir        Note Added: 0099672                          
======================================================================