> >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.
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?
The other night when I was talking to you on my cellphone to your POTSQuote:> 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.
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.
I believe that an explanation for the problems you report are due toQuote:> 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.
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!
Laurence,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
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.