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

---------------------------------------------------------------------- 
 (0101296) madrouter (reporter) - 2009-03-06 03:37
 http://bugs.digium.com/view.php?id=13205#c101296 
---------------------------------------------------------------------- 
I think the only driver that actually supports the sync_tick callback at
the moment is the XPP driver.  Essentially it provides a mechanism to
synchronise a device from the DAHDI clock.

For example - I have a live deployment (using my version of the patches,
plus biohumanoid's patches from bug 0012406) where I have a box with
Sangoma spans physically connected to the carrier.  It also has a number of
dahdi_dynamic_eth spans which connect to a variety of remote boxes.  The
remote boxes all have Xorcom XR0056s hanging off them which then attach to
local PABXs.

Clock configuration is that on the box connected to the carrier the
carrier provides clock to DAHDI (which then naturally clocks the dynamic
spans).  On the remote boxes I have the dynamic spans configured to provide
clock to DAHDI and then have /proc/xpp/sync set to DAHDI which tells the
Xorcom to get it's clock from DAHDI.  The remote PABXs are configured to
take clock from the Xorcom.

All that was done to make faxes work (and they do work perfectly) without
having to muck around with T.38 gateways and other such horrible things. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-06 03:37 madrouter      Note Added: 0101296                          
======================================================================