[asterisk-dev] MASTER CLOCK selection for ZAP/DAHDI span does not work (always 1st active span...)

[Oron Peled]

On Tuesday, 25 בNovember 2008, Anton VG wrote:
> 2008/11/25 Tzafrir Cohen <tzafrir.cohen at xorcom.com>:
> > On Tue, Nov 25, 2008 at 11:23:50AM +0500, Anton wrote:
> >> On Monday 24 November 2008 23:20, Tzafrir Cohen wrote:
> >> >
> >> > What did you expect here to happen?
> >>
> >> Hm, I'm not sure what you mean. But shouldn't zaptel dahdi
> >> select the proper device to be a master clock instead first
> >> available?

Yes, but... see below

> > How would you define "proper"?
>
> Tzafrir,
> 
> If you have ever used over than a single E1 span link, what you surely
> did, you must know that one of the links becomes a master clock for
> asterisk through zaptel, what you also surely do.

The catch is that, zaptel/DAHDI only select this master span
on two events:
 - During registration of a new span (when the result also
   depends on the second parameter to zt_register).
 - Iff the current master gets an alarm.

So if you simply change your priorities in the config data and run
ztcfg/dahdi_cfg, nothing happens.

The truth is that this code badly need a rewrite (IMO):
 - Refactor the master selection code (it's roughly duplicated
   in two different places in zaptel-base). This is a good
   opportunity to rename span->master to something else (e.g:
   span->timing_master), since there's also chan->master which
   "helps" a lot when you search for the word 'master'...

 - Save in the zt_span the timing priority passed in the SPANCONFIG ioctl.
   Currently this information is gone after the call, which means that
   an alarm on the master would cause the first working span to be
   selected (regardless of priority). Even if the alarm is later cleaned
   we stay on the wrong master.

 - Call master selection during SPANCONFIG (before or after driver specific
   spanconfig() subroutine -- should invest more time to decide what is
   better).

> ..., and it's YOUR code (written by you), which actually shows what
> device is an actual MASTER for the system.

We added this trivial change in our lab, long time ago when we got
tired of second-guessing what zaptel decided to do (that's when I
saw all the problems aforementioned). We didn't want to send a very
intrusive patch so the other "master-related" items were never implemented.
Than Tzafrir committed it to zaptel/DAHDI as we normally do -- don't
blame him for this ;-)

Cheers,

-- 
Oron Peled                             Voice/Fax: +972-4-8228492
oron at actcom.co.il                  http://www.actcom.co.il/~oron
... Complex problems have simple, easy to understand wrong answers.