HDTenEightyP/NetNews huggingface dataset:
From: deand@bmerh404.BNR.CA (Dean Dillabough)
Newsgroups: comp.dcom.isdn
Subject: Re: ISDN and voice response systems
Date: 14 Oct 92 22:04:39 GMT
Reply-To: deand@bmerh404.BNR.CA (Dean Dillabough)
Distribution: na
Organization: Bell-Northern Research Ltd.

In article <13328@bnr-rsc.UUCP>, eswara@bnr.ca (Srinivas Eswara) writes:
|>In article <1992Oct8.204328.18112@atlastele.com>, bcapps@atlastele.com
(Brent Capps) writes:
|>>|> Since ISDN doesn't use DTMF, does anyone know how ISDN is supposed to
|>>|> interact with voice response systems that require input from touch-tone
|>>|> phones?  Can ISDN sets typically generate DTMF tones?
|>
|>>All of the BRI sets that I have seen will generate DTMF from the keypad when
|>>a call is answered. This is also the case for other sets such MBS or EBS
|>>which use a proprietary digital interface.
|>
|>>-- 
|>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|>>|Michael Babineau           | BITNET: babineau@BNR.CA                    |
|>>|Bell Northern Research Ltd.| UUCP  : ..!uunet!bnrgate!bmerh812!babineau |
|>>|Ottawa, ON. CANADA         |         ..!psuvax!BNR.CA.bitnet!babineau   |
|>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|>
|>The problem that I have seen is that some ISDN sets do not sustain the
|>DTMF tone, causing problems for systems which expect the tone to be held for
|>any length of time greater approx 1/2 a second. Of course, this is also
|>a problem for a POTS set which cannot sustain the DTMF tone even if you
|>keep the button pressed down.
|>
|>Srinivas Eswara
|>Bell Northern Research Ltd.
|>Ottawa, On. Canada
 
 No DTMF was the problem I had with my ISDN phone. Real frustrating when you're
 put into those "Press 1 to get info on xxx, press 2 to talk to a sales-droid"
 phone systems. I finally gave up and used another guy's phone. He hadn't been
 blessed with an ISDN set yet... he may end up getting mine (remember
this Seenu??)

 ISDN = Instant Strowger Dialling Now
 BRI  = Beautiful Ringing Instantly 
 (From a follow up to the NT Strowger world announcement)


                   Dean Dillabough (No shoes, no shirt, no sig)
                        
Newsgroups: comp.dcom.isdn
From: cmv@looney.att.com (Craig M. Votava)
Subject: Digiboard IMAC Ethernet-ISDN Bridge
Organization: AT&T Bell Laboratories
Date: Wed, 14 Oct 1992 22:32:09 GMT

I just got some information on the Digiboard IMAC product, and am interested
in any experiences that anyone may be able to share about it.

For those of you who don't know about it, this is an Ethernet to ISDN Bridge.
That is to say that if you have 2 physically seperate Ethernet networks (like
an X-windows workstation at home, and your building ethernet at work), you
can use 2 of these devices to form a bridge between the 2 networks over ISDN.

This particular product claims that it not sensitive to any particular vendors
switch or software version, and that it can use both B channels (128Kbps), no
matter what they are configured for (i.e. voice or data). It also claims that
you can use each B channel to connect to two different networks at 64Kbps.

Since it acts like an intelligent ethernet bridge, it learns what devices are
on the other end, and only sends the packets down the line that are destined
for those devices. It does a bunch of other "bridge" type stuff that I don't
understand.

The box has an on/off switch, a power connector, a thick and thin ethernet
connection, 2-RJ45 ISDN S/T Basic Rate connectors, and an RS-232 serial port
connector (for configuration and control), all for a list price of $2100.00.

I'd like to know if anybody has any experiences with this product, and if there
are any competing products available that I should look into.

Thanks

-Craig

	()_()	Craig Votava
	 (_)	AT&T Bell Labs, Naperville IL
		cmv@looney.att.com
Xref: sparky comp.dcom.isdn:655 comp.sys.sun.hardware:4891
From: dclunie@sirius.ucs.adelaide.edu.au (David Clunie)
Newsgroups: comp.dcom.isdn,comp.sys.sun.hardware
Subject: ISDN for non-10 Sun SS
Date: 10 Oct 92 02:38:23 GMT
Organization: Her Master's Voice
NNTP-Posting-Host: sirius.itd.adelaide.edu.au


Does anyone have any knowledge or experience concerning the ISDN
SBUS card that sun is supposed to be bringing out using the same
chip(s) as in the SS10 ? It was supposed to become available in
November but there seems to have been a deathly quiet concerning
its release.

Furthermore I gather that though drivers maybe available, kernel
integration of TCP/IP over these ISDN cards will only be
available in Solaris 2X not Solaris 1X, and won't be until mid or
late next year.

I really wish Sun would provide all these INR/PTP/X25 and so on as
part of the OS ... there is no way I can afford the cost of these
additional bits of software and the upgrade contracts associated
with them. If Sun wants to push connectivity then give us the
software to do it with. Everything I use is freely available stuff
that someone has generously donated (cslip, dial-up ppp and so
on).

I hope that the ISDN stuff really will be integerated. The card is
supposed to be cheap ... let's hope we can afford the software to
make it useable.

david
-- 
David Clunie (dclunie@itd.adelaide.edu.au)
Newsgroups: comp.dcom.isdn
From: "Bob Larribeau" <p00136@psilink.com>
Subject: IP encapsulation
Organization: Performance Systems Int'l
Date: Fri, 9 Oct 1992 13:38:04 GMT
X-Mailer: PSILink (3.2)

Is there any reason why existing serial line IP protocols, such as PPP 
or even SLIP will not be adequate for transmitting IP over ISDN circuit 
mode data links?  Since a circuit mode data link provides a transparent 
path, it does not seem like there would be any problems, except possibly 
for the ability to support higher data rates.  We terminal products are 
now available that support 128 kbps transfer rates (or even higher) 
using reverse multiplexor technology.

It would seem that existing products like Telebit Netblazers should 
support ISDN just fine connected to an appropriate terminal adapter.
Xref: sparky comp.dcom.isdn:647 comp.dcom.lans:1938 comp.dcom.servers:104 comp.dcom.cell-relay:570
From: rfiler@usafa.af.mil (Robert E. Filer)
Newsgroups: comp.dcom.isdn
Subject: Broadband ISDN Info
Keywords: broadband isdn
Date: 9 Oct 92 13:58:42 GMT
Organization: United States Air Force Academy

I'm looking for pointers to information on broadband ISDN.  Any information
on products, vendors, technical articles, etc would be appreciated.

-Bob
Newsgroups: comp.dcom.isdn
From: huntting@advtech.uswest.com (Brad Huntting)
Subject: Re: IP encapsulation
Organization: U S WEST Advanced Technologies
Date: Fri, 16 Oct 1992 23:19:39 GMT

In article <peterd.719033529@pjd.dev.cdx.mot.com> peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:
>I wouldn't be so pessimistic. Neither SLIP nor PPP really address the
>routing issues of bringing up multiple links to arbitrary destinations
>on an as-needed, cost-minimizing basis. Nor, as far as I can tell,
>would they be incompatible with such a routing scheme. You figure out
>what link you want to establish, and then use SLIP or PPP to set it
>up.

All SLIP will do is take a data stream and insert framing information
in it to turn it into an IP packet stream.  C-slip adds header
compression on top of this.  It's ideal for use over something like
LAP-M, or (I would imagine) 64Kb/s "clean" B channels.  If the channel
isnt "clean", or worse if ones or zeros are intentionally inserted as
an to some internal clock somewhere SLIP is a bad choice.


brad
From: dem@nhmpw2.fnal.gov (David E. Martin)
Newsgroups: comp.dcom.isdn
Subject: Re: Interop BOF Announcement
Date: 14 Oct 92 18:27:23 GMT
Reply-To: dem@nhmpw2.fnal.gov
Organization: Fermi National Acclerator Laboratory, Batavia, IL, USA
NNTP-Posting-Host: nhmpw2.fnal.gov

husemann@camelot.informatik.uni-erlangen.de (Dirk Husemann) writes:

>>Is there any interest in getting together Thursday night instead of
>>Wednesday or in addition to Wednesday?
>
>Yes. Instead.

The BOF is already on the official Interop schedule and the room is reserved.  I
don't want to stop any meetings later in the week, but the Wednesday night BOF
will be held.

---
David E. Martin
National HEPnet Management                      ||    Phone: +1 708 840-8275
Fermi National Accelerator Laboratory           ||    FAX: +1 708 840-8463
P.O. Box 500, MS 368; Batavia, IL 60510  USA   /  \   E-Mail: DEM@FNAL.FNAL.Gov
Newsgroups: comp.dcom.isdn
From: peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
Subject: Re: IP encapsulation
Organization: Motorola Codex, Canton, Massachusetts
Date: Wed, 14 Oct 1992 03:32:09 GMT


>In article <2927712779.2.p00136@psilink.com>, p00136@psilink.com (Bob Larribeau) writes:
>- Is there any reason why existing serial line IP protocols, such as PPP 
>- or even SLIP will not be adequate for transmitting IP over ISDN circuit 
>- mode data links? 

vulture@carrion.cc.ic.ac.uk (Thomas Sippel - Dau) writes:

>About as adaequate as a camel is to transport coal over a railway line.

I wouldn't be so pessimistic. Neither SLIP nor PPP really address the
routing issues of bringing up multiple links to arbitrary destinations
on an as-needed, cost-minimizing basis. Nor, as far as I can tell,
would they be incompatible with such a routing scheme. You figure out
what link you want to establish, and then use SLIP or PPP to set it
up.

				Peter Desnoyers

-- 
Newsgroups: comp.dcom.isdn
From: jake@cae.prds.cdx.mot.com (Jake Jacobson)
Subject: Re: Availability of Primary Rate ISDN Cards for PCs
Organization: none
Date: Thu, 15 Oct 1992 17:32:48 GMT


You might also try PRI - Primary Rate Incorporated
                         Lexington, MA ?
                         (800) 950-ISDN

I saw their card at a show recently.


         _____________________________________________________                 
        /  jake jacobson     / jake@cae.prds.cdx.mot.com     /                 
       /  Motorola Codex    / jacobson_m@msm.cdx.mot.com    //                 
      / (617) 821-7838     /                               //                  
     / FAX (617) 821-4956 /      ESCHEW OBFUSCATION       //                   
    /____________________/_______________________________//                    
    /____________________________________________________/ 

                    
Newsgroups: comp.dcom.isdn
From: husemann@camelot.informatik.uni-erlangen.de (Dirk Husemann)
Subject: Re: Interop BOF Announcement
Organization: CSD., University of Erlangen
Date: Wed, 14 Oct 1992 10:02:00 GMT

stoltz@denwa.Eng.Sun.COM (Ben Stoltz) writes:

>It looks like I might not be able to make it to InterOp until Thursday.
>I would like to give a short presentation about Sun's ISDN/Audio hardware
>at the BOF. I believe that one of the engineers who is working on our
>IP over ISDN application may also be available for some questions, but
>this depends on an ok from marketing since the IP/ISDN product has not
>officially been anounced.

>Is there any interest in getting together Thursday night instead of
>Wednesday or in addition to Wednesday?

Yes. Instead.

	Dirk

Dirk Husemann						 Tel.: +49 9131 85 8029
University of Erlangen-Nuremberg			 FAX: +49 9131 39388
Department of Computer Science IV
Martenstrasse 1 	   
D-W 8520 Erlangen, Germany

Dirk.Husemann@informatik.uni-erlangen.de
/C=de/A=dbp/P=uni-erlangen/OU=informatik/S=husemann/G=dirk/

---
From: stoltz@denwa.Eng.Sun.COM (Ben Stoltz)
Newsgroups: comp.dcom.isdn
Subject: Re: Interop BOF Announcement
Date: 13 Oct 1992 20:25:23 GMT
Organization: Sun Microsystems Inc., Mountain View, CA
NNTP-Posting-Host: denwa

It looks like I might not be able to make it to InterOp until Thursday.
I would like to give a short presentation about Sun's ISDN/Audio hardware
at the BOF. I believe that one of the engineers who is working on our
IP over ISDN application may also be available for some questions, but
this depends on an ok from marketing since the IP/ISDN product has not
officially been anounced.

Is there any interest in getting together Thursday night instead of
Wednesday or in addition to Wednesday?

Ben Stoltz
Sun Microsystems, Inc.
stoltz@Eng.Sun.COM

dem@nhmpw2 (David E. Martin) writes:
>----------------------------------------------------------------------
>Interop Birds-of-a-Feather Announcement

>Low-Cost Remote LAN Access via ISDN
>Wednesday, October 28, 1992, 7:30-9:30 PM
>Room 121, Moscone Convention Center, San Francisco
>Open to All

>----------------------------------------------------------------------
>Computer users are increasingly dependent upon LAN network services
>such as X Windows, electronic mail, remote printing, and remote file
>access.  Unfortunately, the current model of remote computing from a
>home or auxiliary office is still that of logging in as dumb terminal,
>despite powerful PC's and X-terminals being highly available outside
>the local environment.  Basic Rate ISDN promises to extend traditional
>LAN services outside normal geographical boundaries by making
>high-bandwidth connectivity widely available upon demand.  This BOF
>will be a lively discussion, led by those currently using ISDN, of
>topics such as ISDN terminal equipment, obtaining ISDN service,
>software to support IP and DECnet via ISDN, and performance of
>applications.  Come ready to discuss such neat technological tricks as
>turning your home PC into a highly networked workstation.


>David E. Martin
>National HEPnet Management                      ||    Phone: +1 708 840-8275
>Fermi National Accelerator Laboratory           ||    FAX: +1 708 840-8463
>P.O. Box 500, MS 368; Batavia, IL 60510  USA   /  \   E-Mail: DEM@FNAL.FNAL.Gov
Newsgroups: comp.dcom.isdn
From: "Bob Larribeau" <p00136@psilink.com>
Subject: DTMF interaction on ISDN
Organization: Performance Systems Int'l
Date: Sat, 10 Oct 1992 15:38:03 GMT
X-Mailer: PSILink (3.2)

There are a couple of ways of using voice over ISDN.

The simplest way is to use a terminal adapter with an RJ11 adapter.  The 
TA has the responsibility of converting DTMF dialing to D channel 
signalling.  Once the call is cut through, then the DTMF set can 
interact directly with the device on the other end of the call.  These 
TAs often work with pulse dialing sets which can not interoperate with 
DTMF devices.

All of the ISDN telephone sets in the U.S. provide DTMF after the call 
cuts through.  This works exactly as you might think and there is no 
problem for an ordinary user to use an ISDN set to interact with voice 
mail or other DTMF based devices.  In the early days people ran into 
bugs with 800 numbers or international calling because the signalling of 
the cut through was a little different, but the major vendors have 
sorted this out by now.

The Fujitsu ISDN sets have a one touch pause feature that combines ISDN D 
channel signalling and DTMF signalling.  For example you can put the 
phone number of a voice mail system in the one touch followed by a pause 
followed by a voice mail address and password.  The set will send the 
phone number out using D channel signalling.  When it sees the pause it 
will wait until the call has been connected and will then sent the rest 
of the number in DTMF.

The short answer to your question is that it is not a problem.

		Bob
Newsgroups: comp.dcom.isdn
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: IP encapsulation
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Mon, 12 Oct 1992 15:58:09 GMT

In article <1992Oct12.100557.15432@cc.ic.ac.uk>, vulture@carrion.cc.ic.ac.uk (Thomas Sippel - Dau) writes:
> In article <2927712779.2.p00136@psilink.com>, p00136@psilink.com (Bob Larribeau) writes:
> - Is there any reason why existing serial line IP protocols, such as PPP 
> - or even SLIP will not be adequate for transmitting IP over ISDN circuit 
> - mode data links? 
> 
> About as adaequate as a camel is to transport coal over a railway line.
> The camel could carry the coal and tread only on the sleepers, or you could
> bundle the camel carrying the coal onto a cattle car. It just is not
> practical. 
> 
> With ISDN you want to mainatain multiple links transparently, building up
> and tearing down connections as required. The only wildcard at the moment
> is cost. If you only want to connect to sites "on the Internet" and you
> have a near and cheap internet host you can use on a fixed subscription,
> then ppp or slip will be enough. Once you need connections outside that
> cosy (and heavily subsidized) world, better software is a must.


You may be right about using PPP or SLIP over ISDN being a bad fit (I
don't know), but I don't think you're right about the costs on the
Internet (at least in the U.S.) nor about building up and tearing down
B channel connections on every other packet.

First, the Internet for many sites is not subsidized in the U.S.  For
example, commercial members of the "regionals" are often asked to pay
more than their share to subsidized the academic sites.  (Some of the
"regionals" span the globe.)

There are at least three independent, complete commercial Internet
providers that last I knew looked viable, Alternet, PSI, and
Sprintnet.  They are not subsidized.  There are others that I less
about, including ANS.  Most of the local regionals (those that span no
more "small" areas of 500 or 1000 miles--e.g. CERFNET and BARRNET) seem
to be trying to become commercial as fast as they can change their
preconceptions, articles of incorporation, and so forth  (i.e. very,
very slowy, but with measurable speed).

Second, building B circuits for each TCP virtual circuit might work for
home machines, whether amatuers or "tele-commuters".  (It would work
for me.)  However, it would not work for machines with several
neighbors, and so with several simultaneous TCP (or UDP as in NFS)
virtual circuits.  Isn't a B circuit going to take most of a second to
create?  (After they fix things so that it no longer takes tens of
seconds?)  Having that much latency just would not fly.  It is not
appropriate to compare building B channels for IP addresses with the
old Internet scheme of building x.25 vritual circuits for IP addresses,
because no Internet routers were ever limited to only 2 x.25 virtual
circuits.


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.dcom.isdn
From: bcapps@atlastele.com (Brent Capps)
Subject: ISDN and voice response systems
Organization: Atlas Telecom Inc.
Date: Thu, 8 Oct 1992 20:43:28 GMT

Since ISDN doesn't use DTMF, does anyone know how ISDN is supposed to
interact with voice response systems that require input from touch-tone
phones?  Can ISDN sets typically generate DTMF tones?
-- 
Brent Capps                           |
bcapps@agora.rain.com (gay stuff)     | I can view my employer from here
bcapps@atlastele.com (telecom stuff)  |
Newsgroups: comp.dcom.isdn
From: husemann@camelot.informatik.uni-erlangen.de (Dirk Husemann)
Subject: Re: IP encapsulation
Organization: CSD., University of Erlangen
Date: Wed, 14 Oct 1992 09:57:40 GMT

pjw@galadriel.bt.co.uk (Peter Willis) writes:

>If you want to keep your ISDN call charges low it is NOT a good idea to setup 
>a connection and tear down the connection for every packet. The reason is that 
>charging works like in the telephone system. Every time you setup a connection
>you get charged a unit (just under 5p here in the UK) even if the connection is
>held for just a millisecond ! I don't want to be charged 5 p per packet !

>The algorithm required to optimise costs is to tear down the connection (if
>it is idle) just prior to being charged a unit for the next time period. This
>time period can be between 240 seconds and 19.2 seconds for inland calls in the
>UK dependent on distance and time of day. For international connections this 
>can be of the order of 2 seconds, so when it takes 13 seconds to set-up an
>international ISDN connection you've got a problem with this algorithm !

This would be the right approach I think. One unit is about 360 sec during the
day locally and 720 sec after 6 pm over here in Germany at about DM 0.23 per 
unit (0.15 U$ as of today/0.09 GBP as of today). Besides --- the algorithm to
tear down the B channel could be enhanced into the other `direction' as well,
as soon as the load gets too high one could open up another B channel to handle
that additional load and after being sufficiently (which needs some definition
--- so does `too high') long below a certain threshold tear it down again
(allowing my wife to use the phone again 8=).

	Dirk

Dirk Husemann						 Tel.: +49 9131 85 8029
University of Erlangen-Nuremberg			 FAX: +49 9131 39388
Department of Computer Science IV
Martenstrasse 1 	   
D-W 8520 Erlangen, Germany

Dirk.Husemann@informatik.uni-erlangen.de
/C=de/A=dbp/P=uni-erlangen/OU=informatik/S=husemann/G=dirk/
---

Newsgroups: comp.dcom.isdn
From: finns@hal.nta.no (Finn Stafsnes FBA)
Subject: Re: DTMF interaction on ISDN
Organization: Norwegian Telecom Research
Date: Wed, 14 Oct 92 10:08:07 GMT

In article <1992Oct12.164424.15662@atlastele.com>, bcapps@atlastele.com 
(Brent Capps) writes:
|> 
|> 
|> Is DTMF cut over a mandatory feature or is it supplied at the discretion of
|> the manufacturer?  My concern is that DTMF cut over that hasn't been
|> through an official approval process may cause problems for voice mail/VRU
|> systems in the areas of talk-off, dB twist, minimum duration and interdigit
|> timing.  It would only take one ISDN set vendor doing it differently to cause a
|> huge problem for a voice mail/VRU vendor.
|> 
|> -- 
|> Brent Capps 


I have to restrict my comment to what is going on in Europe.

DTMF is an optional feature in ISDN terminals. However, if DTMF is included
in a terminal it has to fulfill a set of requirements such as signal level, 
level difference, on / off time, noise ++.
There is no requirement for automatic activation of the DTMF facility. 
(The buttons on the set could be used for user-to-user information or other 
use in the terminal itself.)
There are requirements specifying when the DTMF generator can be connected 
to the B-channel (which messages must be received before connecting the 
generator).


Finn Stafsnes
Newsgroups: comp.dcom.servers
From: jesmith@gdfwc3 (Jesse Smith)
Subject: Annex 3 and lpd
Organization: General Dynamics, Fort Worth Division
Date: Thu, 8 Oct 1992 15:05:09 GMT

For those folks familiar with the Xylogics Annex-3 terminal server:
Do you know of any technical reasons why a person has to use their
software (aprint or rtelnet) to send print jobs from Un*x hosts to
printers attached to the terminal server?  Could they not make it
completely compatible with, say, BSD 4.3 lpd?  What am I missing
here?

Any and all responses appreciated.  Please post to this group or email
to the address below.

Jesse Smith
General Dynamics Corp., Fort Worth, TX
jsmith@gdwest.gd.com
Newsgroups: comp.dcom.servers