HDTenEightyP/NetNews huggingface dataset:
From: ariel@world.std.com (Robert L Ullmann)
Newsgroups: comp.dcom.isdn
Subject: Re: The D channel: how is it used & billed?
Date: 23 Jul 92 23:50:19 GMT
Organization: The World in Boston

etxorst@eos.ericsson.se (Torsten Lif) writes:
>     The data rate is VERY low but you still want it transmitted in
>     fairly small packages and presumably over a long time. Since
>     there's no time charge to a D-channel connection, you can keep it
>     open as long as you want and only pay for the actual data. With a
>     B-channel connection you'd need to accumulate data over a longer
>     time to build up a package sufficiently large to merit a full
>     setup-transmit-disconnect cycle. (I had to strain myself to come up
>     with this one. I doubt if there is any real traffic situation that
>     fits the bill.)

Most email (short messages) fits this model perfectly. Sending a 1KB
mail message will take about 30 packets. At the NYNEX rate of US$.60/Kpacket
this is about US$0.01 vs the B channel cost minimum of .05 to .15
typical. (a penny for a message? Shades of the Victorian age,
and the penny black ... But a penny is worth a lot less than
it was then. :-)

Once you pick up hundreds or thousands of packets, you set up a B
call, _then_ drop the D channel call. I watched a demo of this at
the NYNEX customer presentation center a couple of months ago; they
know what this is about.

And if you can pass X.244 user/user data in the Q.931 setup (which
you normally can for a packet call), you can run RFC1090, and save
even more packets.

Rob
--
Robert Ullmann		Ariel@World.STD.COM	+1 508 879 6994 x226
Quand Maigret poussa la porte du Tabac Fontaine, vers une heure et demie,
le patron du bar, qui venait de se lever, descendait lentement un escalier
en colima gon qui s'amor gait dans l'arri hre-salle. ... Arriv i derri hre le
comptoir, il repousa le gar gon d'un geste n igligent de la main, saisit
une bouteille de vin blanc, un verre, m ilangea au vin d l'eau min irale et,
la t jte renvers ie en arri hre, se gargarisa.  -- Simenon
From: m@crito.Stanford.EDU (M Carling)
Subject: Re: ISDN support for NeXT computers
Organization: DSO, Stanford University
Date: Tue, 28 Jul 92 00:13:24 GMT

In article <5a214421.1bc5b@pisa.citi.umich.edu> rees@pisa.citi.umich.edu  
(Jim Rees) writes:
> What does the DSP have to do with ISDN?  Is it used to produce digitized
> voice that could then be heard by someone with voice bearer service?  Or  
is
> it just a convenient way to get 128 kbps out of the box?

That's right, it is a convenient way to get 128Kbps out.

M Carling
Director, Bay Area NeXT Group
--
Bill Clinton lied to his wife. How can his country trust him?
George Bush lied to his country. How can his wife trust him?
Newsgroups: comp.dcom.isdn
From: rees@pisa.citi.umich.edu (Jim Rees)
Subject: Re: The D channel: how is it used & billed?
Reply-To: Jim.Rees@umich.edu
Organization: University of Michigan IFS Project
Date: Fri, 24 Jul 1992 21:05:36 GMT

In article <jhhm2+f.nagle@netcom.com>, nagle@netcom.com (John Nagle) writes:

        15-20 seconds for call setup?  All this digital computer-controlled
  switch technology and we have call setup times that would be high for
  a #5 crossbar.  If that's ISDN, I want to go back to electromechanical
  switching.

I think he had his numbers wrong.  We're seeing setup times that are lower
than the tcp retransmission time, on the order of tens of milliseconds, I
think.  Certainly less than a second.  This is within a 5ESS switch, which
is the only way we can run isdn at the moment.  We do setup on demand when
there's a packet ready to go, and we don't time out.

        Thought for today: if the original '60s Picturephone had been implemented,
  using 1MHz analog signals switched through a modified #5 crossbar, we'd
  have a great infrastructure for data.  Modern modem technology could
  squeeze near-Ethernet rates through a Picturephone channel.  Would
  have been good.

As I recall, Picturephone was somewhat less than 1 MHz, and there was a fair
amount of phase distortion due to the massive equalization on the line (have
you ever seen the electronics package installed at the CO?).  Still, I'm
sure modern modem technology could push at least a megabit through one of
those channels.  By the way, I'm in the market for an original Picturephone,
if anyone's got any leads.
From: sklower@diva.Berkeley.EDU (Keith Sklower)
Newsgroups: comp.dcom.isdn
Subject: Re: Why buy D channel Bits?
Date: 23 Jul 92 23:47:37 GMT
Organization: /etc/organizaton

In article <nkrqajs@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
}In article <1992Jul22.195218.9871@nntpd.lkg.dec.com>, goldstein@carafe.enet.dec.com (Fred R. Goldstein) writes:
}> ...
}> >Q. How is D channel traffic billed?  Is it per-byte or per minute?
}> 
}> (There) is a trivial (2 cents, I think) charge for call setup, there is no
}> connection time element.  Packets are charged at 60 cents per 
}> kilosegment
}
}
}Do I understand this right? $0.60/(1000*128Bytes)  Or $8*.6 = $4.80/MByte?
} ....
}I've been told you can get switched-56 to connect your B channels at
}the same rates as long distance.... about ....  $0.11/minute
}So a long distance B channel is about 17 times as cheap as a D-channel.
}
}What have I computed wrong?  Why is anyone even slightly interested in
}buying D-channel bits?

There is also a minimum charge for a phone call (one minutes worth),
So, if you are only receiving E-mail overnight, say,
where the median message is 1K bytes, which arrive only at extended
intervals, then it would cost you 2 + .40 cents via X.25/D channel instead of
11 cents for the minimum phone call.

You have to transfer at least 22.5 = ((11 - 2) /.4)K bytes to make
the B channel transfer cheaper!
Xref: sparky comp.dcom.servers:54 comp.dcom.lans.ethernet:1453
From: art@acc.com (Art Berggreen)
Newsgroups: comp.dcom.servers,comp.dcom.lans.ethernet
Subject: Re: Microcom B-Routers (TCP/IP)
Date: 23 Jul 92 17:29:32 GMT
Article-I.D.: acc.1992Jul23.172932.5072
Organization: ACC, Advanced Computer Communications

In article <1992Jul23.124525.917@gandalf.ca> dcarr@gandalf.ca (Dave Carr) writes:
>We make a COMPRESSION BRIDGE.  We don't max out at 4:1.  That's the
>typical performance however.  Dual 64K links, and soon 256K or 384K.
>Currently requires our bridge at remote, but PPP interoperability
>in the works. 

I just want to point out to folks not familiar with compression technology
that "typical" compression ratios are highly dependent on the data stream.
When we added compression to our bridge/router we tested several compression
algorithms and many different types of data.  Data that is already
compressed often expands unless the algorithm can quickly switch into
a "transparent" mode and back.  Binary computer data often only gets
about 2:1 compression.  Ascii text can range from 2:1 to 4:1 or better
depending on the nature of the text.  Contrived sample data that can
really exploit the compression algorithm can give 25:1, 50:1, or better
(depending on several factors).  I don't want to say that 4:1 compression
won't be typical for some networks,  just don't expect it until you try
it on your net or have some idea about the compressibility of your network
data.

Also, interoperability requires compatible algorithms at both ends.
Due to the rapid evolution of compression technology and the state of
standarization, it might be a while before you can expect general
interoperability.

Art
Newsgroups: comp.dcom.servers,comp.dcom.lans.ethernet
From: dcarr@gandalf.ca (Dave Carr)
Subject: Re: Microcom B-Routers (TCP/IP)
Organization: Gandalf Data Ltd.
Date: Thu, 23 Jul 1992 12:45:25 GMT

In <1992Jul21.222325.27762@greco-prog.fr> simon@geocub.greco-prog.fr writes:

>Microcom (the guys who did MNP 4,5 etc.) make a router consisting of a
>PC, LAN cards, WAN cards and software.

>Up until recently they only routed IPX, and bridged everything else.
>A new version of the software now routes TCP/IP also.

>The interesting part of this package is that it will do 4:1 (max) data
>compression before sending data out through the WAN link. Of course to
>be able to do this, you have to have a Microcom router on the other end.

>Is anyone who has used this product willing to comment on :

>- reliability,
>- performance
>- bugs?
>- security features (filtering addresses, ports...)
>- interoperability with routers from other vendors

>As far as I know this is the only router which does compression on
>the whole packet, others only do TCP/IP header compression. If there are
>any other alternatives I would like to hear about them.

We make a COMPRESSION BRIDGE.  We don't max out at 4:1.  That's the
typical performance however.  Dual 64K links, and soon 256K or 384K.
Currently requires our bridge at remote, but PPP interoperability
in the works. 
-- 
Dave Carr               | dcarr@gandalf.ca       | It's what you learn, 
Principal Designer      | TEL (613) 723-6500     | after you know it all,
Gandalf Data Limited    | FAX (613) 226-1717     | that counts. 
Newsgroups: comp.dcom.servers
From: ppan@nobeltech.se (Per Andersson)
Subject: Re: 'Reverse Telnet' problem with VCP-1000
Organization: NobelTech AB
Date: Tue, 28 Jul 1992 22:51:20 GMT

In article <1992Jul21.015619.11073@trl.oz.au> d.kirkham@trl.oz.au writes:
>
>The most annoying problem is that the tail end of some jobs are chopped 
>off, usually within the last 100 or 200 bytes.

Check your manual for a parameter called IO_FLUSH, and change the value to 
the opposite. I'm not sure why it exists, and a real Decserver doesn't have
it, but the VCP-1000 doesn't seem to work correctly without it.

/Per
-- 
-----------------------------------------------------------------------------
Per Andersson - ppan@nobeltech.se (perand@stacken.kth.se on free time)
Managing networks at, but not speaking for Nobeltech AB, J{rf{lla, Sweden
-----------------------------------------------------------------------------
Newsgroups: comp.dcom.servers,comp.dcom.lans.ethernet
From: jkight@au-ns.american.edu (Jeff Kight)
Subject: Dialin Servers - Recommendations et al
Followup-To: comp.dcom.servers
Reply-To: jkight@american.edu
Organization: The American University Computing Center
Date: Fri, 31 Jul 1992 15:33:19 GMT

Here at American University, we are doing an evaluation of dialin
servers.  People have mentioned that there are pretty much 2 big
players...Xyplex and Xylogics.

What I am looking for is impressions / recommendations not only
for people who have used these 2, but also any others you have
come across.  Email me and I will summarize.

I am esp. interested in hearing from people who have had a chance
to firsthand compare the offerings...

Thanks.

Jeff
-- 
Jeff Kight                                           jkight@american.edu
The American University Computing Center                  (202) 885-2281
Washington DC  20016-8019 USA                         Fax (202) 885-2224
Xref: sparky comp.dcom.servers:51 comp.dcom.lans.ethernet:1420
From: simon@geocub.greco-prog.fr
Newsgroups: comp.dcom.servers,comp.dcom.lans.ethernet
Subject: Microcom B-Routers (TCP/IP)
Date: 21 Jul 92 22:23:25 GMT
Organization: Greco Programmation du CNRS

Microcom (the guys who did MNP 4,5 etc.) make a router consisting of a
PC, LAN cards, WAN cards and software.

Up until recently they only routed IPX, and bridged everything else.
A new version of the software now routes TCP/IP also.

The interesting part of this package is that it will do 4:1 (max) data
compression before sending data out through the WAN link. Of course to
be able to do this, you have to have a Microcom router on the other end.

Is anyone who has used this product willing to comment on :

- reliability,
- performance
- bugs?
- security features (filtering addresses, ports...)
- interoperability with routers from other vendors

As far as I know this is the only router which does compression on
the whole packet, others only do TCP/IP header compression. If there are
any other alternatives I would like to hear about them.
Newsgroups: comp.dcom.lans.misc;,comp.dcom.servers
From: ken@pluto.dss.com (Ken Adler)
Subject: Datability Internet E-mail address
Organization: Datability, Carlstadt, NJ
Date: Wed, 29 Jul 1992 14:39:49 GMT

A few people recently posted requesting Datability's e-mail addresses.

Below are a few:

      Tech Support:        support@dss.com
      Sales/Marketing:     info@dss.com
     International:        ken@dss.com

messages sent to support@dss.com are handled by our 24-hour-a-day Tech
support team.
Date: Wed, 29 Jul 1992 22:52:23 GMT
From: caadams@atlas.cs.upei.ca (Kenny Adams)
Newsgroups: comp.dcom.telecom
Subject: Re: Panel Still in Use?
Organization: University of Prince Edward Island
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 12, Issue 595, Message 1 of 14

	In New Brunswick, Nova Scotia and Prince Edward Island the
normal situation is to replace the crossbar and other slightly newer
offices with digital ones (usually DMS100).  Most of the step by step
offices are still in use although new customers are usually put on the
DMS. I guess the step offices are more reliable than the middle aged
technology and require less maintenance.


Regards,

kenny adams    caadams@atlas.cs.upei.ca  these ramblings are my own......
Date: Thu, 23 Jul 1992 20:00:59 GMT
From: prall968@Armstrong.EDU
Newsgroups: comp.dcom.telecom
Subject: Concord 224 Modem
Organization: Armstrong State College, Savannah, GA
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 12, Issue 581, Message 10 of 12

Does anyone have any information about Concord Data System? I need an
address, email address or a phone number.

I have a Concord 224 modem, and I need some info on it ... like
everything.


Gene Prall    prall968@pirates.armstrong.edu
Date: Mon, 20 Jul 1992 13:39:21 GMT
From: robin@ruc.dk (Robin Cheesman)
Newsgroups: comp.dcom.telecom
Subject: Trying to Connect With URUPAC, Uruguay
Organization: Roskilde Universitetscenter, Danmark
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 12, Issue 577, Message 10 of 13

I am trying to connect to the Uruguayan PAD/PSI service URUPAC, but
cannot find the country code. In the list I have at hand is e.g.
Argentina with 7222, and plenty of other Latin American countries --
but not Uruguay. Can anyone help?


Robin Cheesman                                Communication Studies
Roskilde University  *  PO Box 260  *  DK-4000 Roskilde  *  Denmark
Phone: +45 46757711    Fax: +45 46755313    Internet:  robin@ruc.dk


[Moderator's Note: I assume you are asking about data network country
codes, NOT telephone country codes.   PAT]
Date: Mon, 27 Jul 92 13:21:48 GMT
From: vixen!jadams@uunet.UU.NET (26070-adams)
Newsgroups: comp.dcom.telecom
Subject: Re: Cordless Phone Not Charging
Organization: Bellcore, Livingston, NJ
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 12, Issue 590, Message 2 of 6

In article <telecom12.583.6@eecs.nwu.edu>, konstan@elmer-fudd.cs.
berkeley.edu (Joe Konstan) writes:

> In TELECOM Digest V12 #578, Ang Peng Hwa writes:

> > My AT&T cordless phone is not charging and I'd appreciate any input.

> The most common problem I have with AT&T cordless phones (love my
> 5500) is that the contacts on the phone and charger get dirty.  If the
> model you have has a "Charging" light, check to see if it stays on
> when the phone is in the base.  If not, get steel wool (can use other
> scrubbers, but steel wool works best) and clean off all of the
> contacts.      ^^^^^^^^^^^^^^^^^^^^^^ 8^{  NOT!

General rule around all types of electrical equipment ...do not use
steel wool or emery cloth for cleaning contacts...The residue
(slivers, shiners, call them what you will) are conductive and might
cause more damage than they fix!  One of the cheapest (and most
readily available contact cleaners known to man is the common pencil
top eraser. No shorts, no contamination and it does a yeoman job of
removing films and light corrosion.


Jack (John) Adams	   Bellcore RRC 4B-259 (Until 9/1)
(908) 699-3447 {Voice}	   (908) 336-2871 {Facsimile}
jadams@vixen.bellcore.com  kahuna@attmail.com
Date: Wed, 29 Jul 1992 16:12:35 GMT
From: william1@drill.me.utoronto.ca (Robert Williams)
Newsgroups: comp.dcom.telecom
Subject: Help Needed With Development of a Gateways Fee Scheme
Organization: UofT Mechanical Engineering
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 12, Issue 596, Message 6 of 13

A friend of mine has been asked to develop a fee structure for
accessors of a companies information resources.  She writes as
follows,

I need help on the following: I need to know how certain organizations
charge for use of their network gateways (gateways join two
systems/networks together, usually at the midrange or mainframe level
e.g. at the Front-end Processor). For instance, do they charge by the
number of sessions a client signs up for, by the number of sessions
the client actually used, do they have a one-time membership fee with
a smaller monthly maintenance fee which allows users a large but
undefined number of sessions, do they not charge at all and if so then
what is their justification? All these questions ask: HOW is the
gateway charged. But I also need to know, if possible, WHAT the charge
is based on: what cost items do they include in maintenance of the
gateway and what percentage of these cost items is used. Cost items
include: human resources, CPU time, memory, software development, and
other overhead items.

Any ideas from anyone who is familiar with this area would be
appreciated.  Any information on books or papers covering this topic,
or firms doing similar work, would also be appreciated.

Please send all responses to the email address below.  If there is
enough interest, I will post a summary on the net.


Thanks in advance.

Robert Williams    U of T, CIMLab   Toronto, Canada
Email: william1@drill.me.utoronto.ca
Date: Mon, 20 Jul 1992 05:17:57 GMT
From: mts@wam.umd.edu
Newsgroups: comp.dcom.telecom
Subject: Help Identifying Bell Systems Ringer
Organization: University of Maryland at College Park
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 12, Issue 578, Message 9 of 15

I have a phone ringer, model R-1-A and I was hoping someone can tell
me anything about it.  It is riveted shut, so I was wondering if it
was made to be explosive proof or anything of the sort.  I also have a
filter model number 720 and was wondering the same of it.


Thanks,

Dave
From: Bob_Frankston@frankston.com
Newsgroups: comp.dcom.telecom
Subject: Re: Beating Hotel Calling-Card Surcharges
Date: 23 Jul 92 15:57:00 GMT
Organization: TELECOM Digest
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 12, Issue 582, Message 7 of 13

I just stayed at a Regency Hyatt.  It is nice to know that 800 number
surcharges are going away.  But the hotel does make a special case of
800 numbers used to access LD carriers.
From: floyd@denali.ims.alaska.edu (Floyd Davidson)
Newsgroups: comp.dcom.telecom
Subject: Re: FCC Modem Tax Rumor on Compu$erve
Date: 23 Jul 92 12:08:02 GMT
Organization: University of Alaska Institute of Marine Science
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 12, Issue 582, Message 5 of 13

In article <telecom12.580.6@eecs.nwu.edu> yarvin@CS.YALE.EDU (Norman
Yarvin) writes:

> I don't know whether or not a modem tax is planned by the telcos'
> highest decision making level.  I do know that one current research
> project at Bellcore is a circuit to automatically distinguish modem
> sounds from voice sounds.  It uses neural networks, and is apparently
> quite reliable.

While such development might seem to obviously have applications in
billing decisions ... and all the horrors that involves, I doubt the
two are actually related.

One of the more significant developing technologies is real time data
compression for, among other things, telco digital transmission
systems.  But one really serious problem is that compressing a bit
stream being used by a modem causes serious degrading of the
modem-to-modem data link.  Hence the research to distinguish non-voice
sounds is very much needed in order to provide compression equipment
that will still work for modem users (by switching off the compression
for non-voice users).


Floyd
Date: Thu, 30 Jul 1992 04:00:49 GMT
From: dave@appi.iis.u-tokyo.ac.jp (David Wuertele)
Newsgroups: comp.dcom.telecom
Subject: Information Wanted About Radish Communications Systems
Organization: Institute of Industrial Science, University of tokyo.
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 12, Issue 596, Message 11 of 13

Has anyone heard of Radish Communications Systems and what they do?


David Wuertele, Yasuda Lab, Electronic Engineering, 
Institute of Industrial Science, University of Tokyo.
dave@windsor.iis.u-tokyo.ac.jp
Date: Tue, 21 Jul 1992 03:57:16 GMT
From: helfman@aero.org (Robert S. Helfman)
Newsgroups: comp.dcom.telecom
Subject: Giving a PAT Answer to Questions 
Organization: The Aerospace Corporation, El Segundo, CA
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 12, Issue 578, Message 15 of 15

In article <telecom12.574.4@eecs.nwu.edu> varney@ihlpf.att.com (Alan L
Varney) writes:

> In article <telecom12.562.5@eecs.nwu.edu> ggw@wolves.durham.nc.us
> writes:

>> Saying that Caller-ID is the way to go is just to much of a "pat"
>> answer.

>   Eeeuww, a PUN in c.d.t!  Doesn't PJN have a copyright on them???

> [Moderator's Note: Nope, I hold the copyright on this. I license it to
> PJN and other moderators who pay my requested fee annually.  PAT]

Sure, PAT. 

My colleague, Samuel Goldstein, says that he now holds the rights to
the Patented Look and Feel of Shit. Thus, everyone will now have to
pay him royalties to look in the mirror each morning!

By now, I must owe him bigtime.


[PAT's Answer and Last Word on the Subject:  Me too! Or should I say
'I also'?  :) PAT]
Date: 27 Jul 92 23:32:27 GMT
From: mtxinu!sybase!pokey!nealg@ucbvax.Berkeley.EDU (Neal Goldsmith)
Newsgroups: comp.dcom.telecom
Subject: Pac*Bell CLASS Features
Organization: TELECOM Digest
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 12, Issue 587, Message 2 of 11

I ordered the three new features (Repeat Dialing, Select Call
Forwarding, and Priority Ringing). The features only work within my
LATA.

I can understand them not working for numbers that are not on SS7
equiped switches, but isn't the CLASS information passed on even
through toll switches? If not will it ever be?

I would like to add numbers in LA to my Priority Ringing list.

Also it seems that repeat dialing works by attempting to retry the
call every 45 seconds. I would think that this should work even
through toll switches.

When I asked about CLID I was told that Pac*Bell didn't have the
technology yet. I didn't have the time or desire to explain to the
person at Pac*Bell that it's the same stuff and they are already ready
to provide it, they just don't want to right now.


Neal E. Goldsmith                                Sybase, Inc.  
nealg@sybase.com                                 1650 65th Street
What I sez is my opinion and not my employers.   Emeryville, CA  94608
                                                 (510) 596-3338