X2 DOVBS over long distance

X2 DOVBS over long distance

Post by Jeffrey Rhode » Thu, 15 Apr 1999 04:00:00





> >How 'bout answering the question about 56K DOVBS long distance? I am aware
> >that this will fail if echo cancelling circuits are not disabled, if any
> >digital padding is mistakenly present, and if for some reason there is still
> >an analog trunk out there in the PSTN/ISDN, but other than that, have you
> >ever known 56K DOVBS to fail?

> This was addressed to David, but I will answer.  The answer is YES!!!
> I don't claim to know what goes on at the GTE/Bellsouth boundary here in
> the Research Triangle, but it sure is flakey.

Note that I did not say it was IMPOSSIBLE for 56K DOVBS to fail, I
simply state that is has NEVER failed to work for me when calling within
the US, except when I fail to enable the echo cancelling "fake modem
tone". When I knock down AT&T True Voice echo cancellers, they stay
down, while I am transferring normal data and idle 56K flags. I predict
that idle 64K flags will not keep echo cancellers disabled, hence the
need for single zero idle 64K flags are needed to present the same
equivalent energy as 56K idle flags. GET IT?

Quote:> I was doing some testing (for Hernan Silva, I think) to see which of the
> local ISPs accepts DOVBS.  I don't need it because my grandfathered
> contract with Bellsouth gives me true unlimited local data and voice.  But
> he's a few miles away in GTE-land where data's measured and voice isn't.
> So I was asked to test which ISPs would accept DOV calls.  I called the
> Raleigh (free) POPs of the local ones he asked me to try, and traced PPP
> login attempts with user=guest, password=guest.  Negotiations were
> successful at several POPs.

> Hernan then asked me to try the Durham numbers that he would use.  These
> were 10 cents a call for me.  And what I found was that calling a different
> POP of the same ISP was that the call was answered, but the raw trace was
> gibberish.  (Any ~ character looks like the start of an async-PPP frame, so
> any time there's a ~ in the data stream, you see the next junk.  It looked
> like !~LKD)ASID-0asd8asyd78asd--just completely meaningless.)

> I wouldn't have thought much about this, but the GTE-Bellsouth boundary has
> a notorious history of weirdities like this.  When USR had released its
> V.90 code for the Total Control Hub, the Research Triangle Park POP was the
> only one in IBM Global Networking (IBM.net and other services) that didn't
> work for calls into the GTE area from Bellsouth.  Operation was so strange
> that they eventually sent some engineers here to study the problem.

The other night when I was talking to you on my cellphone to your POTS
phone, I was getting ready to explain why I think the GTE-Bellsouth
Triangle Park mysteries pervade your thinking, but you we're more
interested in not missing dinner and hung up on me.

Quote:> And there's the caller-ID saga.  Calls from GTE to Bellsouth had caller-ID
> for 13 months.  Then they stopped.  A trouble call to Bellsouth led to a
> trouble ticket to GTE. The switch tech there said, "You got caller-ID from
> us?  You're not supposed to.  We'll make sure it stays off."  I gave up on
> that when my son moved from Durham, although my wife would still like to
> have it when I call from work.

I believe that an explanation for the problems you report are due to
compression. I believe the compressed portion of the "talkpath" between
GTE and Bellsouth is NOT using common channel signaling, hence the CgPN
information is lost. Maybe compression is only for the overflow traffic,
have you confirmed the lack of Caller ID during the dead of night? Note
that I am not CLAIMING to know for sure, I am merely HINTING that this
may be a problem for you and IBM Research Park Triangle V.90 testers!

Quote:> >Also, do you think that one channel of 64K X2 DOVBS (like when I call AT&T
> >Worldnet in Seattle from my lab in Seattle) that includes V42bis compression
> >is doing better thruput than two channels of 112K DOVBS without compression?
> >I kinda think so but I haven't done extensive testing. Bidirectional 64K X2
> >DOVBS using the Courier I-modem and USR Total Connect servers is no fantasy.

> All depends on the data.  64K with V.42bis would be better on newsgroup
> headers, 112K without would be better on GIF files.

> Laurence V. Marks
> IBM Corp. - Research Triangle Park, NC

Laurence,

I hope I have not insulted you the way you have insulted me in your last
couple of response postings to me ;-(. What is V.42 compressing, is the
entire PPP packet compressed, or is just the data inside a PPP packet
compressed? Last weekend I experimented with a German ISDN V.l20 64K
data call that was reportedly using V.42bis compression. We noticed that
a 1 MEG file that contained a single character repeated 1 million times
does not really transfer any faster than about 7000 characters per
second on average. I'd have thought V.42bis would transfer this file in
less than a second, no? <wink> Yes, our COM ports we're at 230000 bps
sender and 115000 bps receiver.

Thanks for your antlike persistence, but I do not believe you are
reading my postings correctly. I think you suffer from "not invented
here" IBM syndrome and you cannot accept the idea that I MAY BE correct
about 64000 bits/second V.91 potentials. HTH.

Regards, Jeffrey

 
 
 

X2 DOVBS over long distance

Post by Jeffrey Rhode » Sat, 17 Apr 1999 04:00:00



> There's more to it than 'fake modem tone', Jeffrey.  In addition to ANS,
> the 2100 Hz answer tone (1500 milliseconds?), the modems are required to
> send continuous speech energy (in some band at some amplitude which I
> forget).  Speech is more than 50 % pauses, so if an echo cancellor were
> mistakenly turned off due to speech that looked like ANS, it would come
> right back on.

> Not all data patterns (even scrambled) will have the right characteristic.

If the data is truely random, like it will be when packets are
compressed (and/or encrypted), then I disagree. Again, why have I had so
much success with Bitsurfer to Bitsurfer V.120 56K DOVBS long distance?
As I recall, either end can set %A96=E to Enable echo cancelling
disabling (how's that for department of redundancy department and even
when the other end is %A96=D to Disable echo cancelling disabling), then
the DOVBS call stays up and transfers data flawlessly, albeit at
56K-only. If I could just FORCE the Bitsurfers to TRY 64K DOVBS, I
wonder how flawless that connection, via AT&T long distance, would be? I
kind of think that idle HDLC flags of 01111110 at 64K will not present
enough enery to keep echo cancellers disabled, but idle flags of single
zero delimited repetitions of 1111110 WILL present the same energy as
rate adapted idle flags of 01111110.

Quote:> Take a look at the V.25 recommendation.  While you are at it, have a look
> at V.8, for the really interesting way they extended V.25 for V.34 modems.

> Laurence V. Marks
> IBM Corp. - Research Triangle Park, NC

I would look at those documents, Laurence, but IMO, they are written by
analog modem vendors who (like you) see digital impairments that do not
exist in a correctly operating ISDN!!! I believe that persuing an
auto-adjusting algorithm for end-to-end ISDN digital-only connections is
a better approach, since I believe that I can resolve whether, or not,
digital impairments exist in the LSBs of transmitted octets in about
20000 received bits (or so). If impairments do not exist in the LSBs of
an end-to-end ISDN digital-only connection, then the connection can be
assumed to be on clear channels that are 64k-worthy. So I believe that
V.25 and V.8 need to first consider my auto-adjusting algorithm after
answer indication is given, before "negotiating" anything else that is
that is needed for low grade and misconfigured voice circuits.

I notice that the Courier I-modem is able to "negotiate" X2 symmetric
proprietary DOVBS using somekind of V.8 answer modem tone, yet this
algorithm seems to give up too easily and settle for V.34 data rates on
long distance, when I know that DOVBS data rates like 56000 bps are
possible on the same connection. Also, I am getting CONNECT
64000/ARQ/x2/LAPM/V42BIS connections within the city of Seattle (like
from a US WEST BRI to an AT&T POP for Worldnet) yet calls to other
cities like Tacoma or Olympia only resolve to 56K, and calls beyond that
ALWAYS resolve to 33600 bps or less V.34 analog speeds.

X2 Symmetric is not WORTHY of the ITU's so-called "V.91", in my opinion.
I'd like to help USR get this fixed but it seems the almost year old
external I-modem firmware is "fixed" as good as it will get???

regards, jcr