[Asterisk-Users] Asterisk - fax - spandsp

[Steve Underwood]

Rich Adamson wrote:

>>>What is in the bug tracker helps make things clearer to people who know 
>>>what they are doing. What we need is something that makes things clear 
>>>to laymen. Saying internally and externally clocked doesn't cut it. It 
>>>needs to be made clear to laymen that clocking internally is rarely 
>>>right; that slaving to a PBX, when there is also a PSTN connection is 
>>>almost never right; that the PSTN is the grand master of the telecoms 
>>>universe, and all Asterisk boxes should be its slave.
>>>
>>>      
>>>
>>Maybe the confusion is because some pieces of the explanation are being 
>>left out.  If you look at the leads on a synchronous RS232 interface it 
>>is very clear:  Rx clock and Tx clock, and people understand that.  It's 
>>not as clear-cut with T1/E1.
>>
>>I'm not the person to explain this, but someone (Rich Adamson perhaps, 
>>or a Digium engineer) needs to explain phase-locked loops and the 
>>recovery of the timing signal from the data stream.  Perhaps 
>>understanding that the timing comes from the data stream itself might 
>>lead to better understanding.
>>    
>>
>
>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?
>  
>
Not bad, but not ideal. This primary, secondary thing is not clear to 
laymen. It sounds more like something concurrent, than a priority list. 
It needs to say something like first choice, second choice if the first 
port stops working, etc. Also talking about the port, rather than the 
far end kit connected to the port, as the source of timing confuses 
people. How about:

# span=<span num>,<timing source>,<line build out (LBO)>,<framing>,<coding>[,yellow]
# 
# All T1/E1 spans generate a clock signal on their transmit side. The          
# <timing source> parameter determines whether the clock signal from the far
# end of the T1/E1 is used as the master source of clock timing. If it is, our
# own clock will synchronise to it. T1/E1's connected directly or indirectly to
# a PSTN provider (telco) should generally be the first choice to sync to. The
# PSTN will never be a slave to you. You must be a slave to it.
#
# Chose 1 to make the equipment at the far end of the E1/T1 link the preferred
# source of the master clock. Chose 2 to make it the second choice for the master
# clock, if the first choice port fails (the far end dies, a cable breaks, or
# whatever). Chose 3 to make a port the third choice, and so on. If you have, say,
# 2 ports connected to the PSTN, mark those as 1 and 2. The number used for each
# port should be different.
#
# If you choose 0, the port will never be used as a source of timing. This is
# appropriate when you know the far end should awlways be a slave to you. If the
# port is connected to a channel bank, for example, you should always be its
# master. Any number of ports can be marked as 0.
# 
# Incorrect timing sync may cause clicks/noise in the audio, poor quality or failed
# faxes, unreliable modem operation, and is a general all round bad thing.


Regards,
Steve