🚀 go-pugleaf

The problem is purely telco (at least from a technical 
perspective).  We are doing nothing special, the phone company
is simply using glass fiber rather than copper wire to bring the 
phone lines from the Central Office to our site - we have something
like 2000 lines in here, so this makes some sense.  The problem is 
that the equipment that they are using to convert from copper to 
fiber (at the CO) and then from fiber to copper (at our office) is
not passing the entire bandwidth of the "normal" telephone call,
and is losing the top couple of Khz.

This means that instead of 28.8k, you can only get 26k or so through
the phone line.

Doug


>This isn't quite right, either.  The original complaint dealt with...
>
>>As background, traffic from the Baltimore area to the Beltsville
>>site is routed down high capacity circuits known as the SLC 96 or 
>>"slicks".  These trunks handle traffic in the 200 Hz to 3300 Hz
>>range.  Modems operate at the high end of  this range, and 28.8 Kbps
>>modems negotiate at a frequency of 3750 Hz.  The "slicks," in  
>>other words, cannot support a 28.8 Kbps connection over the phone
>>network.  Therefore, DIGEX cannot guarantee 28.8 Kbps access to its 
>>customers at this time.  The "slicks" are guaranteed by the 
>>manufacturer to support 19.2 Kbps connects, but they are only part of the 
>>total connection from the customer site to DIGEX.  
>
>So, what I gather Digex is doing is (to use the old terminology I'm
>comfortable with) acquiring calls at local numbers remote from their site,
>and using BA-provided equipment to multiplex or otherwise channel those
>calls to their central location.
>
>If the problem /is/ occurring before the call reaches the Digex number at
>the remote location, then of course Digex isn't responsible for the
>handshake only taking place at lower speeds.  However, if the user's modem
>can connect with the Digex modem at (say) 28.8, but equipment which Digex
>contracted for to take that data to another location is throttling the
>speed down significantly, then it /is/ Digex's fault.  More expensive lines
>can be acquired (or higher-speed lines multiplexed), and it is /not/ the
>user's or the universe's fault that Digex elected a transmission path that
>couldn't handle the load -- it's Digex's fault.  (And as others have made
>clear, it's not TPC's fault, either -- they're providing what they were
>paid to provide.)
>
>
>