[asterisk-users] Fax from FXS to PRI

[Kevin P. Fleming]

On 09/20/2011 09:57 PM, Jeff LaCoursiere wrote:

> Like most faxing issues, at it's root it is a timing problem IMO.
> Sangoma makes a special timing cable to link their cards so you can do
> exactly what you are asking to do.  I've never purchased it, but last I
> looked into the issue, that is what they suggested.

Digium sells such cables as well, but they cannot resolve this problem 
completely. They solve a related, but different, problem.

There are really two issues at work here: the first is that the nominal 
8kHz clock used on all TDM telephony boards is just that... 'nominal'. 
Every board has its own clock, and digital boards can be configured to 
derive a clock from the spans they are connected to. All of these clocks 
are built with varying degrees of accuracy and tolerance; PSTN-derived 
clocks will generally be of greater accuracy than anything you'd be able 
to afford putting into a PC, so that's why they are always the preferred 
option when they are available.

If two ports in a system are using clocks that differ slightly in 
frequency, then over time they will 'drift'; one port will be producing 
(and consuming) data a slightly higher rate than the other port. The 
percentage of frequency difference will determine how often there will 
be a 'slip'; a 1% difference in an 8kHz clock is 80Hz. With that 
difference, one port will produce/consume data at a rate of 80 samples 
per second faster than the other port; at that rate, slips will occur 
fairly often. When slips occur, data will be lost, or will be replaced 
with silence... this is unavoidable.

Timing cables are designed to reduce the drift/slippage problem; when a 
timing cable is connected between two cards, and at most one of those 
cards is connected to an external connection that provides a clock, then 
a single clock can be distributed between the cards. This produces a 
'clock domain', and the ports will produce and consume data at the same 
rate.

Timing cables do *not*, though, transfer data between the cards; even 
though a timing cable will result in the clocks on the cards being in 
sync, the data from one card still needs to be transferred to the other 
card *on time*. If the data arrives late, silence (or noise) will be 
sent in its place. This means that the entire system (hardware and 
software) must be able to reliably transfer the data between the two 
cards without it ever arriving late. Software running on a CPU, with 
other software operating at the same time, is subject to CPU scheduling 
delays and lots of other potential reasons why it might fail to deliver 
the data on time. The only way to guarantee that the data will not ever 
be late is to directly connect the TDM busses on the cards, or failing 
that, to run a single application on the host CPU with appropriate 
real-time scheduling so that it will *always* have access to CPU time 
slices when they are needed.

Traditional PBXes avoided this problem (because users would not have 
been willing to accept it) by having direct TDM connectivity between all 
of their ports, and having the software only control the connections, 
not transfer the data. This, of course, produces significantly more 
expensive hardware, and this sort of connectivity isn't possible with 
packet networks. As the world has moved to lower-cost solutions and 
Voice-over-IP, some of these long-standing 'problems' have reappeared. 
For voice calls, most users are willing to accept them in return for 
lower costs, increased flexibility and other benefits... but modems and 
FAX machines can't tolerate these problems without help (which is where 
T.38 and V.150 enter the picture).

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org