[Asterisk-Users] Interfacing T100P with Definity PBX

[Andrew Kohlsmith]

On November 27, 2004 10:26 am, Rich Adamson wrote:
> > If span 1 is the telco you want sync to be '1' not 0 -- you want the span
> > to take clock from the PSTN.  span 2 with sync '0' is right 99% of the
> > time -- most PBXes and KSUs don't have an option to be the sync source so
> > they'll be trying to sync from *, which should have it span sync set to
> > '0' to achieve this.
>
> Andrew, I think the words came out a little different in your response
> from what you were actually thinking in the last sentence above.

... I think I got it right.

> T1/E1 spans are really four wires; two transmit and two receive. The two
> transmit wires (regardless of whether they come from a pstn, pbx, KSU,
> or whatever) always has embedded clocking within the pcm stream. There
> is no way to turn that off, so its always a possible "source". What you
> probably meant was the clock (in a KSU as an example) has no options
> other then to sync _from_ the receive side of the span (as it doesn't make
> any sense generally to turn that off). It considers itself the end node,
> not the kingpin in the sync hierarchy. Your "span 2 with sync 0" is still
> correct, its just the wording of the sentence.

I understand the physical level of T1 (I used to design this stuff many moons 
ago) -- I understand that regardless of what it is, it's embedding clock in 
its transmit stream.  

Where does this clock come from?  You have several options, but I'll say 
there's two: an internal clock or an external clock.  Now technically it 
always comes from an internal clock but that clock is either self-timed or it 
is phase-locked to an external clock.

This is what the span sync is doing, it is setting up the internal clock to 
either free-run or sync to a recovered clock from a datastream the card is 
connected to.

With span sync set to 0, the zaptel driver does not try to synchronize the 
internal clock to the received clock from that span.   With a span sync set 
to non-zero, it will attempt to lock the internal clock to the recovered 
clock from the span.  You usually use a value of 1 but higher numbers just 
define a priority -- a span sync of '2' will use the recovered clock from 
this span if the span with a span sync of '1' is down.  

So yes -- that is what I meant -- KSU/PBX/Channel Banks typically assume they 
are syncing their transmit clock to the recovered clock from the other side, 
which is why when you're connecting to these things with Digium hardware you 
typically set your span sync to '0' so the two sides aren't "chasing each 
other's clocks", so to speak.  :-)

-A.