HDTenEightyP/NetNews huggingface dataset:
From: naddy@mips.ruessel.sub.org (Christian Weisgerber)
Newsgroups: comp.dcom.isdn
Subject: Re: Newbie Q
Date: 10 Jan 93 15:16:57 GMT
Reply-To: naddy@mips.ruessel.sub.org
Organization: My Individual Private Site
X-Software: HERMES GUS 1.10 Rev. Dec 18 1992
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

In <184809@pyramid.pyramid.com>, Lon Stowell writes:

>    o A telecom-specific term for vaporware

Can't be. I have an ISDN telephone sitting right beside me and it
actually works.

>    o A bunch of little islands of really neat features, none of
>      which can interoperate with each other.

Ask in comp.dcom.telecom how the phone network started out, you might be
surprised.
At least on this continent it doesn't look that bad at all.


bye
-- 
Christian "naddy" Weisgerber, Germany           naddy@mips.ruessel.sub.org
Newsgroups: comp.dcom.isdn
From: bob1@cos.com (Bob Blackshaw)
Subject: Re: ISDN - bridge - phone/TA
Organization: Corporation for Open Systems
Distribution: world 
Date: Mon, 11 Jan 1993 15:04:09 GMT

In <1993Jan10.054036.6393@hplabsz.hpl.hp.com> laubach@hpl.hp.com (Mark Laubach) writes:

>Superuser (sfrazier@norstan.com) wrote:
>: If you had a NT-1 installed on your newly installed 2B+D line in your
>: home and you decided that you wanted/needed a bridge to extend your
>: TCP/IP connection from your office, you installed one of the available
>: bridges.
>: 
>: Now the next question is, you need dialtone.....

>Well, the solution we're using (Combinet CB200 ISDN Ethernet bridge) gets
>the dialtone, I believe, off the D channel.  I ought to know more about
>this but haven't taken the time to look into it in depth.  The box takes
>care of doing all the dialing, so a phone is not needed to make a
>connection to work.  2B+D goes into NT1-200 goes into CB200.

>Hope this helps.

>Mark

Well, tones are a little different with ISDN. The D-channel is a
message based signaling channel, and as such does not carry analog
tones. In their place are message elements (SIGNAL) which tell the
ISDN set or TA which tones to generate and when.

However, there is a message element (PROGRESS, and sometimes it is
a message) which tells the CPE to cut through the B-channel when
one of those network generated audio messages is on the channel.

Bob.

Xref: sparky comp.dcom.isdn:1103 comp.protocols.ppp:1050
From: rees@pisa.citi.umich.edu (Jim Rees)
Newsgroups: comp.dcom.isdn,comp.protocols.ppp
Subject: Re: dp2.2 on Interactive V3.2 & ISDN
Date: 8 Jan 1993 16:20:31 GMT
Organization: University of Michigan CITI
Distribution: world
Reply-To: Jim.Rees@umich.edu
NNTP-Posting-Host: pisa.citi.umich.edu

In article <C0IIz4.8AB@sranhd.sra.co.jp>, nisimura@sran233.sra.co.jp (Tohru Nishimura) writes:

  Unfortunately, there is interoperability problem between implementations,
  as usual.  For example, different brand of integrated ISDN/IP cards would
  not talk each other.  No surprise, please....

There are two emerging "standards" for ip over isdn.  One is rfc 1294 frame
relay encapsulation, the other is ppp.  An rfc 1294 ip frame looks like
this:

         +-------------------------------+
         |        Q.922 Address          |
         +-------------------------------+
         |Control  0x03  |  NLPID  0xCC  |
         +-------------------------------+
         |          IP Datagram          |
         +-------------------------------+
         | FCS                           |
         +-------------------------------+

Unfortunately (or maybe fortunately), the mtu is undefined except that the
maximum frame size must be greater or equal to 262.

Frame relay may become important if anyone ever gets around to offering the
service.  For point-to-point links, which are the most common for ip today,
the main advantage of frame relay is that you don't need a state machine to
implement it.  The disadvantage is that you have to configure everything
manually, whereas with ppp you only need to configure one end manually.
Newsgroups: comp.dcom.isdn
From: bob1@cos.com (Bob Blackshaw)
Subject: Re: V.42bis over V.120? (was Re: Can V.32bis or V.42bis be 'faked' by
Organization: Corporation for Open Systems
Distribution: world 
Date: Wed, 6 Jan 1993 14:39:31 GMT

In <1993Jan5.170810.13055@kei.is.s.u-tokyo.ac.jp> jeff@is.s.u-tokyo.ac.jp (Jeff McAffer) writes:

>In article <bob1.726244213@cos> bob1@cos.com (Bob Blackshaw) writes:

> >In their demo at TRIP'92, France Telecom showed me a compression
> >algorithm (or at least the effects of one) over ISDN. When I asked
> >if it was V.42bis, they said no. According to the person I was
> >speaking with, they found V.42bis too processor intensive for a
> >64 kbit/s line and it actually slowed throughput. They claimed to
> >be achieving throughput in excess of 110 kbit/s on a 64 kbit/s
> >line. I didn't have a stopwatch with me, but it certainly looked
> >impressive. Hopefully, they will submit it to CCITT.

>I am not sure that I understand the compression problem.  There are
>several schemes available that do on the fly compression on data to
>disk.  The data rates are significantly higher and they actually make
>the disk interaction faster.  That is, the amount of time saved
>reading bytes is greater than the extra required to de/compress.
>Given that 64kbits/s is at least a couple orders of magnitude less, I
>would have thought that this would not be an issue.  How are the cases
>different?

Good point, programs like Stacker compress to the hard disk and even my
old Rodime has about 500,000 byte throughput. Hey, it was late in the
day and I was tired, so I didn't ask the guy. Had e-mail from a chap at
Gandalf who wondered what processor they were using. I guess it might
have been the NIH factor at work, since everyone and his brother has
a different compression scheme. The whole point is that given any
good scheme we should be able to effectively double the bandwidth.

>--
>ato de, |m        -- Death by stereo!

Bob.
From: h198@hosp.med.umich.edu  (Gene Mangum)
Newsgroups: comp.dcom.isdn
Subject: Re: IDSN wanna-be questions
Date: Fri, 08 Jan 1993  15:30 EDT
Organization: Univ of Michigan Hospitals
Distribution: world
NNTP-Posting-Host: condor.hosp.med.umich.edu
X-Newsreader: FTPNuz (DOS) v1.0

In Article <1993Jan8.192642.5383@gandalf.ca> "cstorry@gandalf.ca (Chuck Storry)" says:
> In <19930108092137.h198@hosp.med.umich.edu> h198@hosp.med.umich.edu  (Gene Mangum) writes:
> 
> >Hello ISDN experts,
> > 
> >I have two questions.   First, does anyone know of a good review of IDSN
> >cards for IBM PCs.   Something like PC Magazine would be good for my 
> >level (know nothing).   And second, does anyone have comments on the
> >compatibility of the serial interface on the Teleos IDSN card for the
> >PC.   I understand that it has a 16550 UART.   Does it run with regular
> >serial port software well, or is it flaky/incompatible?
> 
> Just a quick question from a vendor who makes ISDN TAs but not PC cards.
> 
> Why do you want the card in your pc ?
 
  I'm looking for the *fastest* possible connection from my home in the
  pseudo-country (too far for an ethernet, to close for cows :-)   My
  modems give 19200.   They could go to 38400 except that none of the
  devices I'm dialing into allow above 19200.   I've heard that there's
  some sort of dial-into-ethernet facility, but I don't have an ethernet
  network at work, just a Token Ring.
> If you use the serial port (or better yet the ethernet port) that likely
> came with your pc or was subsequently added compatibility and software
> problems disappear (assuming the hardware/software worked before ISDN
> was brought into the picture). I've always looked at this issue as the
> same for modems (internal or external). The cost difference doesn't
> usually justify the added "questionability" of the internal hardware.
 
  [.sigs deleted]
 
  I recently got some software for OS/2 (which I run at home and work;
  try it you'll like it!) which provides an NDIS MAC interface to OS/2
  which looks like a Token Ring driver, but really talks to a serial
  port.   I would use this at home.   Then at work, I'd use this in
  conjunction with its other component which bridges between the
  async driver and a real Token Ring.   This provides LAN connectivity
  for multiple protocols over a dial-up line.   If the serial port
  on the ISDN card acts like a true serial port, I should get 57.6K.
 
  In summary, I'm looking for *speed* at home.

  Gene Mangum
  Univ of Michigan Hospitals
From: rogue@ucrengr.ucr.edu (ed zeamba)
Newsgroups: comp.dcom.isdn
Subject: Newbie Q
Date: 5 Jan 93 09:26:32 GMT
Organization: University of California, Riverside

Ahhh.. if you can excuse an ignorant but enthusiactic student of
dcom asking a dumb question... :)

What exactly is ISDN?

simple enough eh?

-- 
     /                                                                \
@###I===============> "Know me as GORD of GREYHAWK..." <===============I###@ 
     \		                                                      /
rogue@ucrengr.ucr.edu		UC Riverside -- home of the Guildsman
From: lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
Newsgroups: comp.dcom.isdn
Subject: Re: Newbie Q
Date: 6 Jan 93 21:00:56 GMT
Reply-To: lstowell@pyrnova.pyramid.com.pyramid.com (Lon Stowell)
Organization: Pyramid Technology Corporation

In article <24677@galaxy.ucr.edu> rogue@ucrengr.ucr.edu (ed zeamba) writes:
>Ahhh.. if you can excuse an ignorant but enthusiactic student of
>dcom asking a dumb question... :)
>
>What exactly is ISDN?
>
   
   o A telecom-specific term for vaporware

   o Yesterday's technology proposed as tomorrow's solutions

   o Technology obsolete before implementation

   o A triumph of politics over technology

   o A bunch of little islands of really neat features, none of
     which can interoperate with each other.

   o An obfuscation designed to produce enough smoke to avoid
     implementation of a REAL [fibre-based] communications
     infrastructure.  


Somebody's gonna try to tell you it means "Integrated Services
Digital Network" which is gonna solve ALL of your communications
problems forever.   Give this roughly the same credibility as a 
campaign promise or used-car salesman statement.


Oh yeah, as if it were needed... >:-)
Newsgroups: comp.dcom.isdn
From: scott@labtam.labtam.oz.au (Scott Colwell)
Subject: V.42bis for a B Channel, was Re: V.42bis over V.120? (was Re: Can etc
Organization: Labtam Australia Pty. Ltd., Melbourne, Australia
Date: Tue, 5 Jan 1993 23:28:21 GMT

bob1@cos.com (Bob Blackshaw) writes:
>In their demo at TRIP'92, France Telecom showed me a compression
>algorithm (or at least the effects of one) over ISDN. When I asked
>if it was V.42bis, they said no. According to the person I was
>speaking with, they found V.42bis too processor intensive for a
>64 kbit/s line and it actually slowed throughput.

This statement from France Telecom is somewhat misleading .  Current modems
providing V.42bis achieve >2400 characters per sec with only a lowly Z80
for a processor.  Given that a Z80 is a marginal choice for a processor in
a terminal adapter (since it only has a 64k address space), and most people
are using things like a 80c188 to handle the call control protocols, it would
not be unreasonable to build a terminal adapter that can run V.42bis on a B
channel at around 16000 cps.

A more long sighted choice might be to use something like an 80960SA (which
is priced at only a few percent higher than an 80c188 but provides hell of
a lot more processing power (~5 VAX 11/780 MIPS sustained if you believe
Intel.)

>They claimed to
>be achieving throughput in excess of 110 kbit/s on a 64 kbit/s
>line. I didn't have a stopwatch with me, but it certainly looked
>impressive. Hopefully, they will submit it to CCITT.

Cost of things like Z80s is not dropping anywhere near fast enough to stay
ahead of new much more powerful cpus that are on a much steeper price curve.
I believe that V.42bis ought to be extended to allow some more compression
algorithms to increase compression factors, rather than to decrease the
processing requirements.  (I would prefer not to have yet another compression
standard.  Sorry.)

As far as compression over ISDN is concerned, it seems to me that the correct
place for compression is higher up the protocol stack.  A one size fits all
compression algorithm is fine for text/executables etc but does not fit well
with using a B channel for a point to point network connection.  Xremote from
NCD uses different schemes to compress different things (e.g an image will
compress much better using an algorithm designed for images rather than
V.42bis).  This requires that the compression is done by the code that knows
what the data represents.  It is probable that you would turn any compression
on the modem/terminal-adapter etc off with this type of link.

Scott
-- 
Scott Colwell				Labtam Australia Pty. Ltd.
net:	scott@labtam.labtam.oz.au	41 Malcolm Rd., Braeside
phone:	+61-3-587-1444			Melbourne, Australia  3195
Newsgroups: comp.dcom.isdn
From: picone@trdc001.trdc.ti.com (Joe Picone)
Subject: end-to-end digital on ISDN -- the real application
Organization: Tsukuba Research and Development Center
Date: Thu, 7 Jan 1993 08:50:01 GMT

Thanks for all the helpful responses.

The answers to my previous messages were that *no one* can guarantee
end-to-end digital connections.

Perhaps I should explain our real application and let you ISDN wizards
out there solve the problems...

I am interested in collecting large speech databases that represent
good samples of the variation of speakers, telephones, channels, and
the ambient conditions found in the "normal telephone network"
(whatever that means these days).  Of course, we cannot sample all
dimensions of the problem (collect data in every city, from every
carrier , etc.).

Two scenarios we have used in the past are the following (vendors
names are used just for informational and historical purposes - let's
leave marketing issues out of this):

1. Voice Across America

  Callers, randomly selected throughout the US, dial an 800 number
  supplied by AT&T. These callers call from any phone they want (home
  phone, office phones, analog, digital, etc.) any time of the day or
  night.

  Our computer system, in Dallas, is connected to the local switch via
  an analog telephone interface (a Gentner TC-100).  It answers the
  phone, prompts the subjects for things to say, and digitizes the
  incoming calls with a high quality A/D.

  Note that the data collected under this scheme has been very
  valuable for speech recognition research - even with all its obvious
  deficiencies.

2. Switchboard

  The scenario is comparable to that above with major changes in the
  hardware. A T1 line is terminated in our lab. We connect an
  Intervoice RobotOperator to the T1. Users call from all over the
  country using a toll-free number. The numbers, I believe, have
  been registered with MCI (or maybe Bellcore) to provide end-to-end
  digital transmission (within the MCI network at least - again I
  don't know the details of what MCI actually promised).


Case 1 suffers from the fact that at the receiving site there is a fixed 
analog line from the local office to the data collection machine.
This does impose an additional and unnecessary A/D conversion.

Case 2 suffers from the fact that the data collection system is a PC
and T1s are unmanageable for us novices.

So, now that Sun Sparcstation 10s have ISDN interfaces built in,
we can replace Case 2 with an ISDN interface. Sounds too good to
be true...

The question was raised: how does the data collected in such a manner
compare to the T1 connection in Case 2. My instinct is that doing this
type of data collection with ISDN will be as good, certainly no worse, 
than the T1 case, and definitely better than Case 1.

Others have raised concerns that there might be, on the average,
more re-conversions performed.

ISDN gurus please comment...


-Joe
Newsgroups: comp.dcom.isdn
From: ketil@edb.tih.no (Ketil Albertsen,TIH)
Subject: Re: IDSN wanna-be questions
Organization: T I H / T I S I P 
Posting-Front-End: Winix Conference v 92.05.15  1.20 (running under MS-Windows)
Date: Tue, 12 Jan 1993 08:00:40 GMT

In article <5d81b394.1bc5b@pisa.citi.umich.edu>, rees@pisa.citi.umich.edu (Jim 
Rees) writes:

>In article <1993Jan10.135914.12321W@lumina.edb.tih.no>, ketil@edb.tih.no 
(Ketil Albertsen,TIH) writes:
>
>  I want my PC to present the name of the caller on the screen, if known, 
>  before I lift the receiver...
>
>Caller-id returns the number of the phone used to place the call.  This does
>not necessarily imply anything about the name of the person making the call.
>You should be aware of the limitations of caller-id before implementing
>this kind of screening.

Sure (there has recently been an extensive debate of this in rec.electronics),
but still knowing who is *responsible* for the phone that makes the call is
a lot more than nothing. Anyway, I wouldn't expect all the world's phonebooks
to be available and inverted on the phone number in, on my PCs desk. 

My intended primary use would be to give some *well known* caller IDs special
treatment (the ability to break through when all other calls are ignored).
Sort of the opposite philosophy of giving someone *poorer* service (rejection)
because I know who they are, or thought I did from the ID. 

All the ones I do not know for sure about, I wouldn't know the name of
either, and they would, for the naming part, be treated as if the caller 
ID was not available at all.

Obviously, any caller ID can be used for the negative "poorer service"
purpose. But even though I may be nasty to people I dislike, this is no
reason for not being nice to the people I like. Even if I actually choose 
*not* to be nasty to those I dislike...

K.A.


Newsgroups: comp.dcom.isdn
From: cstorry@gandalf.ca (Chuck Storry)
Subject: Re: IDSN wanna-be questions
Organization: Gandalf Data Ltd.
Date: Fri, 8 Jan 1993 19:26:42 GMT

In <19930108092137.h198@hosp.med.umich.edu> h198@hosp.med.umich.edu  (Gene Mangum) writes:

>Hello ISDN experts,
> 
>I have two questions.   First, does anyone know of a good review of IDSN
>cards for IBM PCs.   Something like PC Magazine would be good for my 
>level (know nothing).   And second, does anyone have comments on the
>compatibility of the serial interface on the Teleos IDSN card for the
>PC.   I understand that it has a 16550 UART.   Does it run with regular
>serial port software well, or is it flaky/incompatible?

Just a quick question from a vendor who makes ISDN TAs but not PC cards.

Why do you want the card in your pc ?

If you use the serial port (or better yet the ethernet port) that likely
came with your pc or was subsequently added compatibility and software
problems disappear (assuming the hardware/software worked before ISDN
was brought into the picture). I've always looked at this issue as the
same for modems (internal or external). The cost difference doesn't
usually justify the added "questionability" of the internal hardware.

> 
>Thanks for any info,

>  Gene Mangum
>  Univ of Michigan Hospitals
-- 
Chuck Storry, Principal Designer      CAnet: cstorry@gandalf.ca
Gandalf Data Ltd.                     Voice: (613) 723-6500
130 Colonnade Rd So, Nepean, Ontario  Fax: (613) 226-1717
Canada  K2E 7M4
From: wadswort@babss.UUCP (John H. Wadsworth)
Newsgroups: comp.dcom.isdn
Subject: Re: Newbie Q
Date: 6 Jan 93 13:42:51 GMT
Followup-To: comp.dcom.isdn
Distribution: world
Organization: Bell Atlantic Business Systems Service Branford, Ct.

In article <bob1.726244625@cos> bob1@cos.com (Bob Blackshaw) writes:
>In <24677@galaxy.ucr.edu> rogue@ucrengr.ucr.edu (ed zeamba) writes:
>>What exactly is ISDN?
>
>To put ISDN in very simple terms, it does two basic things. Firstly,
>it extends digital transmission right out to the user over the local
>loop - in one interface (Basic Rate I/F or BRI), the user gets two
>64 kbit/s lines. In the second interface (Primary Rate I/F or PRI),
>the user gets 23 64 kbit/s lines or 30 64 kbit/s lines - depends
>on the carrier system used.
>

Thanks. Now on with more simple but needed questions....
What kind of equipment is needed at my place to use ISDN?
Once I have this equipment, is there any use for it besides
a point-to-point connection say from a local office to headquarters.

I've been lurking here for a while in the hopes of getting more
familiar with isdn and wan connections in general but many of the
posts seem to be over my head. Does anyone have a beginners guide
they could post? Could you write a quick intro to ISDN? I've seen
lots of press explaining the who and what of it but not the why and
how.
Thanks!

John H. Wadsworth            BABSS           wadswort%babss.UUCP@cs.yale.edu
(800) 677-8549 voice    (203)481-0276 fax      {uunet,yale}!babss!wadswort
Newsgroups: comp.dcom.isdn,comp.protocols.ppp
From: nisimura@sran233.sra.co.jp (Tohru Nishimura)
Newsgroups: comp.dcom.isdn,comp.protocols.ppp
Subject: Re: dp2.2 on Interactive V3.2 & ISDN
Date: 8 Jan 93 02:01:36 GMT
Organization: Software Research Associates, Inc., Japan

In article <413@se.alcbel.be> Gratien D'haese wrotes;

> Dear ppp-ers,
> 
> I am following the comp.dcom.isdn and comp.protocols.ppp newsgroups for a
> while now. It seems to me that some people do actually use ISDN instead of
> a common phone line + modems.
> 
> Could someone tell me how a  working configuration with ISDN looks like
> (ISDN+TA+modem or ISDN-card plugged in a PC?).

We have been ISDN customer over past two years, and using ISDN/IP links
for daily company work.  There are many many ISDN products in Japan.
Here is a product list of what comp.protocol.ppp/comp.dcom.isdn people
would like;

	ISDN bridge
	ISDN router
	integrated ISDN card for UNIX WS makes WS an ISDN/IP router
	integrated ISDN card for PC gives tranparent 64K sync link to PC
	ISDN TA with RS232C interfaces or V.35/RS.449 interfaces
	etc, ...

Unfortunately, there is interoperability problem between implementations,
as usual.  For example, different brand of integrated ISDN/IP cards would
not talk each other.  No surprise, please....

Tohru Nishimura
Software Research Associates, Inc. Tokyo Japan
nisimura@sra.co.jp
Newsgroups: comp.dcom.isdn
Subject: Re: IDSN wanna-be questions
From: <JDB6@psuvm.psu.edu>
Date: Mon, 11 Jan 1993 08:59:13 EST
Organization: Penn State University

In article <1993Jan10.135914.12321W@lumina.edb.tih.no>, ketil@edb.tih.no (Ketil
Albertsen,TIH) says:
>
>In article <1993Jan8.192642.5383@gandalf.ca>, cstorry@gandalf.ca (Chuck
>Storry) writes:
>
>>Just a quick question from a vendor who makes ISDN TAs but not PC cards.
>>
>>Why do you want the card in your pc ?
>
>What *I* want (but that may be different from what the original poster
>wants!) is to have my PC control the phone. Essentially, I must have
>access to the D channel:
> [... lots of good stuff deleted for brevity ...]
>I want a nice, Windows-based interface for setting up and organizing a
>multiple party connection (phone conference). Doing that with the numeric
>keys on your phone is not exactly user friendly.
>
>I want the option to be able to digitally manipulate the speech signal
>before transmission or after reception. (I didn't say 'encryption' - at
>least not very loudly.)

Hear, Hear!

When you get any of these goodies, PLEASE let us all know here on the list.

Nice post, BTW.

John Balogh, Data Engineer, Penn State, Office of Telecom, JDB@OTC.PSU.EDU
Date: Mon, 11 Jan 93 10:18:02 PST
From: John_David_Galt@cup.portal.com
Newsgroups: comp.dcom.telecom
Subject: Re: 976 Fraud in Toronto
Organization: TELECOM Digest
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 13, Issue 20, Message 10 of 17

I have an idea that would make us more secure against this type of
fraud.  I wonder if any of the telcos would be willing to implement
it.

What I'd like to do is get my phone blocked so that direct-dialed
calls to a 900, 976, ... number won't go through, but calling-card
calls will.  That way if I really want to try one of these services, I
can get through, but a visitor can't (unless he uses his own card, and
then he pays).


John David Galt