> > How about this... > > > > Replace the old text in /usr/src/zaptel/zaptel.conf.sample: > > # span=<span num>,<timing>,<line build out > > (LBO)>,<framing>,<coding>[,yellow] > > # > > # The timing parameter determines the selection of primary, secondary, and > > # so on sync sources. If this span should be considered a primary sync > > # source, then give it a value of "1". For a secondary, use "2", and so > > on. > > # To not use this as a sync source, just use "0" > > > > with this text: > > # span=<span num>,<timing>,<line build out > > (LBO)>,<framing>,<coding>[,yellow] > > # > > # All T1/E1 spans generate a clocking signal on the transmit side. The > > > > # timing parameter determines whether the clocking signal from the opposite > > # end of the T1/E1 is used to sync our clock. For T1/E1's connected to a > > # pstn provider (telco), chose 1 for using this T1 as the primary clock, > > # 2 for a secondary (if multiple T1/E1's are in use and the second T1 is > > # to be used for clock sync should the primary fail), or 3 for the next > > # T1, etc. If the T1/E1 is connected to a channel bank or if the T1/E1 > > # is not to be used for clock sync, then specify the timing as 0. (A quad > > # T1/E1 card should only have a single T1/E1 specified as timing = 1, or > > # primary clock sync. Incorrect timing sync may cause clicks/noise in > > # the audio, poor quality faxes, or fax failures, etc.) > > > > If this is helpful, I'll submit a bug for the text. Thoughts anyone? > > > Very good. Now I'll try to muddy the waters with my own ignorance on > this subject. > > Where is the clock source that the T1/E1 board, with "0" for timing, > uses to generate the tx data stream? Is there a PLL on each board? Or > is some central source used?
Each T1/E1 card has a clock on board and most use a crystal in the circuity. However, the frequency of that clock is not always "right on" and may drift by a few cycles/second or more. Regardless of how the clock is implemented on the card, its important to "sync" that clock to the telco so that "your T1/E1 transmit" data is sent to the telco at the same rate as what they are sending data to you. (The telco engineers understand this very very well, and have been syncing their clocks to higher-level switching offices for years.) If you don't sync your on- card clock to theirs, then you will be transmitting pcm data to their site at some rate they aren't expecting which will cause "some" errors to occur depending upon how far off your clock happens to be. Of coarse, "they" are the only ones that will "see" those errors (since it is on their "receive" side), and the telcos won't call you to tell you that is actually happening. For the most part, they don't even monitor the incoming errors unless asked to. If your T1's don't connect to a telco (pstn line), then the clock sync is less of an issue. You just have to decide which end of the T1 is going to be the master clock, and make all attached devices subservant to it. (The subservant devices would then have timing=1, as an example.) > For example, I have one system with two separate T100P cards--one for a > telco T-1 (#1) and the other for a channel bank (#2). For timing, #1 > (telco) is set to "1" and #2 (channel bank) is set to "0". How does > card #2 get its timing to generate its tx stream? Does card #1 > interrupt the CPU based on the retrieved clock stream, and the CPU drive > the other boards based on #1's interrupts? It doesn't make any difference. The pcm data that arrives from the telco is buffered in the zaptel and/or asterisk code, and sent out the second T1 card as soon as it can. That buffering reduces (or eliminates) the need to sync one T1 card to another. However, if the clock on the second card were "way off" frequency, there could be a missed pcm frame from time to time. The missed frame would not even be noticed by users in most cases. (There was some discussion about how great of an impact that really has several months ago. Personal opinion plus experience says its a non-issue other then on some very extreme cases where a clock is way off frequency. That tends not to happen with today's electronics.) If you think about the variable delays that occur because of contention for the pci bus, interrupt latency, etc, there are likely larger swings in dropped packets resulting from that then there would be from multiple T1 cards not having the exact same clock frequency. The bigger issue with multiple T1's occurs with the Quad T1 cards, where a single on-card clock is used with all four T1's. Syncing that clock "to the pstn" is the only correct way (timing=1), making all other downstream T1's (eg, channel banks, pbx's, other * boxes) subservant to it (timing=0). If you had multiple asterisk boxes located in several cities, and each of those asterisk boxes had a pstn T1, then you better read and understand T1 clock syncing very well as it will make a signifcant difference how each box obtains clock sync since there is a potential for a circular timing loop if one doesn't think that process through very carefully. Hope that helps... Rich _______________________________________________ Asterisk-Users mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
