[asterisk-dev] [svn-commits at lists.digium.com: [svn-commits] dhubbard: branch 1.4 r112689 - /branches/1.4/main/asterisk.c]

[John Todd]

At 8:30 PM -0500 2008/4/7, Kevin P. Fleming wrote:
>Steve Edwards wrote:
>
>>  Is a "green" T1 required before a Zaptel card will serve as a timing
>>  source? I've been putting cards in boxes that will never even have T1s
>>  connected based on advice from this list. Have I been mis-informed?
>
>No, that should *not* be necessary. All that should be required for
>Zaptel to provide timing to Asterisk is for *any* span that can provide
>timing to do so. If the T1/E1 card drivers do not provide timing off
>their internal clock when their spans are in alarm, I would consider
>that to be a bug.
>
>It is *not* a bug that an unconfigured card does not provide timing, but
>when the card has been configured it should *always* provide timing,
>even with no spans plugged in. Plugging in spans may cause the timing
>source to change, but this is already true for multi-span cards with the
>spans set to different 'timing source' priorities.
>
>John Todd: if the drivers behave the way I just described, would that
>ease your concerns about Asterisk starting up in the way it has been
>changed? The goal was for it to keep Asterisk from starting on systems
>that were improperly configured, not those that just happen to be unable
>to find any functional digital spans at that moment.

[sorry for late reply - missed this the first time around]

Kevin -
   Yes, I think that would be a reasonable method of startup, if that 
is the way it works now (if not, then if it were to change to that 
method it would be suitable.)  That addresses my primary concern of 
Asterisk unexpectedly not starting based on external problems (span 
outages.)  If the card is configured correctly, even with no spans 
attached or spans down, Asterisk will still start up and provide 
timing from the card.

   If zaptel is misconfigured (regardless of span state) then throwing 
an error and not starting is acceptable, since then the failure mode 
is consistent and predictable regardless of external circumstances 
(span outages.)

JT