HDTenEightyP/NetNews huggingface dataset:
From: finns@hal.nta.no (Finn Stafsnes FBA)
Subject: Re: Use of HLC in the US
Organization: Norwegian Telecom Research
Date: Fri, 9 Oct 92 15:30:36 GMT

First: Thanks to David G Lewis for an extensive answer to my question.

In article <1992Oct6.172619.5319@cbfsb.cb.att.com>, deej@cbnewsf.cb.att.com (david.g.lewis) writes:
|> In article <1992Oct6.125349.5359@nntp.nta.no> finns@hal.nta.no (Finn Stafsnes FBA) writes:
    (Stuff deleted)
|> >
|> >To me this says that an HLC-element which is sent from the 
|> >originating ISDN terminal, will be presented at the destination 
|> >interface if we have end-to-end ISDN.
|> >
|> >Will anybody please confirm my assumption (or tell me it is wrong)?
|> 
|> Well, I'll start by expanding a little bit in three areas.

   (Information deleted)
|> 
|> "The SS7 Access Transport Parameter (ATP) is shown in Section B.1 in
|> Appendix B.  It is used to carry information elements received from an
|> originating ISDN access transparently through the SS7 network to the
|> terminating SPCS.

I must admit that I am not familiar with some of the abbreviations. That is
SPCS which I believe must be some functional part of the local exchange and 
IXC (below) which I believe could be an international connection point (?).

|> "The ATP should be included in the SS7 IAM if
|>   - information elements are delivered from the ISDN originating access to
|> be delivered transparently (i.e. unchanged and without SS7 processing) to
|> the terinating SPCS, and
|>   - (i) the call does not involve an IXC, or (ii) the call involves an IXC
|> and the selected IXC is allowed to receive the access transport parameter.
|> (See Section 3.3.1).

   (Information deleted)
|> 
|> So the answer to your question is an unqualified "maybe".
|> 
|> Disclaimer: my own opinions, not AT&Ts, etc., etc.

Or possibly the answer could be "yes" in some ideal future when everything 
is implemented and operating according to specs?  :-)

In the meantime we have to make sure that the services (eg. videophone) can
operate without information elements that are supposed to be transmitted 
end to end (eg. HLC).

Finn Stafsnes
From: djones@iex.iex.com
Newsgroups: comp.dcom.isdn
Subject: Re: Availability of Primary Rate ISDN Cards for PCs
Date: 14 Oct 92 21:47:19 GMT
Organization: IEX Corporation Inc.

In article <1992Oct8.083119.24916@cs.su.oz.au> mrj@moria.cs.su.oz.au (Mark
James) writes:
>Does anyone know of manufacturers of primary rate ISDN (2Mbps)
>interface cards for PCs (preferably EISA)?
>
Mark,
The Dialogic Corporation has a Primary Rate Card. It is not EISA
but ISA. It was done for them by Promptus Communications Inc. It is
compatible with AT&T 4ESS & 5ESS, Northern Telecom DMS-100 and DMS-250 and
Japan's NTT INS-1500 switches.

I believe they only support a terminating configuration which allows you to
connect any of the 23 B channels onto their PEB (PCM Expansion Bus) for routing
to Call Processing/Voice Processing hardware. They also claim to support
Non-Associated Signaling.

I do not work for Dialogic nor do I receive any compensation form them. I have
used their hardware in the past, and plan on adding their hardware to an
existing product we did for a client in November. If you would like the name
and phone number of a Dialogic sales type please send me e-mail.

Doug
-------------------------------------------------------------------
'I am a traveler of                |    Douglas R. Jones
     both Time and Space'          |    IEX Corporation
       Led Zeppelin                |    (214)612-2600 ext: 325
                                   |    djones@iex.iex.com
                                   |    uunet!iex!djones
-------------------------------------------------------------------
Newsgroups: comp.dcom.isdn
From: vulture@carrion.cc.ic.ac.uk (Thomas Sippel - Dau)
Subject: Re: IP encapsulation
Reply-To: cmaae47@cc.ic.ac.uk
Organization: Imperial College of Science, Technology and Medicine
Date: Mon, 12 Oct 92 10:05:57 BST

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.

                                      Thomas

-- 
*** This is the operative statement, all previous statements are inoperative.
*   email: cmaae47 @ cc.ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic.cc on Janet)
*   voice: +44 71 589 5111 x4937 or 4934 (day), or +44 71 823 9497 (fax)
*   snail: Imperial College of Science, Technology and Medicine
*   The Center for Computing Services, Kensington SW7 2BX, Great Britain
From: markd@werple.apana.org.au (Mark Delany)
Newsgroups: comp.dcom.isdn
Subject: Re: Any experience of ISDN access from Sun S
Date: 14 Oct 92 00:14:26 GMT
Organization: werple public-access UNIX, Melbourne
NNTP-Posting-Host: werple.apana.org.au

etxorst@eos.ericsson.se (Torsten Lif) writes:

>According to the Swedish Sun salescreatures, the port HW is fully
>functional but Sun does not at this stage include any driving SW for it
>(if they have any and intend to make it available at some later time or
>if they expect others to write it is unclear). The port is "sealed"
>pending "classification" since many (most?) markets still require
>equipment that's to be connected to the public phone networks to be
>approved by some telcom agency.

Just to throw another drift into the fray.

I hear much the same as Torsten says re H/W. That is, it's largely
going through approval by the various country's telecos. Boy wouldn't
*that* be a nightmare - getting approval from dozens of different
telecos!

On the S/W front I'm told that there will be PPP and a development
kit.  Obviously from Sun's point of view, once IP is there, then all
else falls into place.

Which brings us back to the original question. Who will help you when
your having trouble using the development kit? In my country, the
teleco is definitely in learning mode re ISDN.



--
Mark Delany                                          markd@werple.apana.org.au
Newsgroups: comp.dcom.isdn
From: cstorry@gandalf.ca (Chuck Storry)
Subject: When to connect ? 
Organization: Gandalf Data Ltd.
Distribution: na
Date: Fri, 16 Oct 1992 12:56:53 GMT

In <1992Oct16.042901.22017@cbnewsd.cb.att.com> varney@cbnewsd.cb.att.com (Al Varney) writes:

>   True, but it's not sent to the caller.  But you can't rely on
>a CONNect message either!!!  Why?  Well, there are a lot of cases
>where you are routed to a TELCO or semi-TELCO connection that wants
>DTMF, but DOESN'T return answer.  In all these situations, the
>B-channel must also be connected to the handset -- otherwise you
>wouldn't be able to talk to an operator (or the mechanical equivalent).
>So CONNect isn't the answer.  Basically, you want to be able to
>both send B-channel voice and DTMF either before or when the switch
>connects the B-channel in the forward-call direction.  DTMF before
>that (and after CALL PROCeeding) can't reach the far end anyway.

>   Now for the big question -- if it ain't CONNect, what message
>is the clue that DTMF can be used?  Well, anytime after the CALL
>PROCeeding message -- the switch will refuse any more digits via
>the D-channel, so why not switch then.  If you want to be helpful
>to the user, you could wait for a PROGress, ALERTing or CONNect
>message for a few seconds -- one of them should arrive with information
>about the call.  If it's over a non-SS7 trunk, you'll get a PROGress
>with call progress indicator "not end-to-end ISDN ..."  If it's
>an SS7 trunk, you either get (avoiding some special cases) treated
>like end-to-end ISDN, or you get the "not end-to-end ISDN" or you
>get "inband information or appropriate pattern now available".
>The latter is usually an indication the call did not complete for
>some reason, and a tone/announcement is being played.

Say, that's something I hadn't realized before !

You mean that for operator services and for some "semi-telco" (??? service
bureau ???) connections the Q.931 stops after call proceeding and you're
connected ?

I presume at least a PROGRESS msg is sent so that the Q.931 timers are
stopped ?

Is this a billing related issue ? Why doesn't the protocol complete ?

-- 
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
Newsgroups: comp.dcom.isdn
From: "Bob Larribeau" <p00136@psilink.com>
Subject: PRI Terminal Adapters
Organization: Performance Systems Int'l
Date: Fri, 9 Oct 1992 14:11:10 GMT
X-Mailer: PSILink (3.2)

Rockwell International
CMC Network Products
125 Cremona Drive
Santa Barbara, CA 93117
D. Kent Stevens
(714)833-4383

Rockwell has a PRI TAs with a VME bus (CMC 1800) and ISA bus (CMC 680).

DGM&S
1025 Briggs Rodad
Mt. Laurel, NJ 08054
V (609)866-1212
F (609)866-8850

DGM&S has a PRI adapter called the ISDN DSP PRIMARY Rate Adapter (IDC PRI).

Primary Rate, Inc.
Salem, N.H.
(603)898-1414

PRI adapter with a VME bus.  May also have a PC version.

Hope this helps.

		Bob



>DATE:   Thu, 8 Oct 1992 08:31:19 GMT
>FROM:   Mark James <mrj@moria.cs.su.oz.au>
>
>Does anyone know of manufacturers of primary rate ISDN (2Mbps)
>interface cards for PCs (preferably EISA)?
>
>Thanks,
>
>Mark James                                   |  EMAIL : mrj@cs.su.oz.au  |
>Basser Department of Computer Science, F09   |  PHONE : +61-2-692-4276   |
>The University of Sydney NSW 2006 AUSTRALIA  |  FAX   : +61-2-692-3838   |
From: peter@micromuse.co.uk (Peter Galbavy)
Newsgroups: comp.dcom.isdn
Subject: Re: Any experience of ISDN access from Sun SS10 Workstations yet?
Date: 7 Oct 92 08:51:37 GMT
Organization: MicroMuse Limited, London, England.

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

>dap@aber.ac.uk (D E Price) writes:

>>Dear All,
>>	Like many others, we have two SUN SS10 workstations on order
>>here at Aberystwyth in Wales, UK. A few questions....

>We got some delivered over here.

We have been shipping Model 20 and Model 30 systems for a while now...

>>1/. Does anyone have experience of using the ISDN connections?

>No. Currently Sun Germany tells us that the ISDN device is unsupported for the
>time being.

They are blocked off in the UK waiting for approval (some time this month
I am told on the grapevine), and Solaris 2.1. There is a set of the
Sunlink products (PPP, IR etc) that run on the 4.1.3 SunOS but these
are*very* internal to Sun - they won't let me even see them :-(

>>2/. Does anyone have an on-line copy of information on the
>>Applications Prograaming interfaces we are going to be
>>offered.

>No. At least we don't --- Sun probably has but we couldn't yet twist it out
>of them ...

Again, no sorry.

>>3/. Does anyone have information on the encapsulation that is being
>>used to carry IP over the ISDN connections?

>This is still an open question --- not only for Sun as I gather it.

There will be Sunlink PPP as well as others... but these will be optional
software products.

>>4/. Does anyone have information about trhe 'Server' process
>>that will be provided?

>Vide supra.

My latin is sh*t - what ?

>>5/. Has anyone in the UK had one delivered?

See 1. above - they are nice systems.

-- 
Peter Galbavy
Tech Support, Micromuse Ltd
Phone: +44 71 352 7774		E-Mail: P.Galbavy@micromuse.co.uk
Newsgroups: comp.dcom.isdn
From: deej@cbnewsf.cb.att.com (david.g.lewis)
Subject: Re: Use of HLC in the US
Organization: AT&T
Date: Fri, 9 Oct 1992 16:40:59 GMT

In article <1992Oct9.153036.23747@nntp.nta.no> finns@hal.nta.no (Finn Stafsnes FBA) writes:
>In article <1992Oct6.172619.5319@cbfsb.cb.att.com>, deej@cbnewsf.cb.att.com (david.g.lewis) writes:
(quoting from Bellcore TR-NWT-000444)
>|> "The SS7 Access Transport Parameter (ATP) is shown in Section B.1 in
>|> Appendix B.  It is used to carry information elements received from an
>|> originating ISDN access transparently through the SS7 network to the
>|> terminating SPCS.
>
>I must admit that I am not familiar with some of the abbreviations. That is
>SPCS which I believe must be some functional part of the local exchange and 
>IXC (below) which I believe could be an international connection point (?).

SPCS = Stored Program Control Switch.  Bellcore uses the term SPCS to refer
to the switching system to which the requirements apply.

IXC = Interexchange Carrier.  A carrier such as AT&T, MCI, Sprint, Cable &
Wireless, LCI, etc. that provides interLATA ("long distance") service in the
US.  An IXC may or may not also be an International Carrier (INC).

David G Lewis                              AT&T Bell Laboratories
david.g.lewis@att.com or !att!goofy!deej     Switching & ISDN Implementation
Newsgroups: comp.dcom.isdn
From: Helge.Oldach@Stollmann.DE (Helge Oldach)
Subject: Re: Any experience of ISDN access from Sun SS10 Workstations yet?
Date: Mon, 12 Oct 92 19:05:14 GMT
Organization: Stollmann GmbH, D-2000 Hamburg 50, Germany
Originator: he@sup

husemann@camelot.informatik.uni-erlangen.de (Dirk Husemann) writes:
| dap@aber.ac.uk (D E Price) writes:
| >3/. Does anyone have information on the encapsulation that is being
| >used to carry IP over the ISDN connections?
| This is still an open question --- not only for Sun as I gather it.

I have the information that an IETF working group is working on an
Internet draft for this. If you look for something like PPP this is a
good start, although somewhat overshooting the subject. SLIP certainly
is overkill (and does probably not work on the SS-10 either).
-- 
Helge.Oldach@Stollmann.DE
From: vulture@carrion.cc.ic.ac.uk (Thomas Sippel - Dau)
Newsgroups: comp.dcom.isdn
Subject: Re: IP encapsulation
Date: 15 Oct 92 09:30:06 GMT
Reply-To: cmaae47@cc.ic.ac.uk
Organization: Imperial College of Science, Technology and Medicine

In article <1992Oct13.150409.4109@galadriel.bt.co.uk>, 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 !

And if I buy equipment that optimizes my isdn usage now, can you guarantee that
that will still be optimal for the charge structure in 5 years ? Of course you
cannot, thats one of the sacrifices when (and where) telcos ceased to be 
statutory monopolies. Even in Germany, where it still is (just), time charge
for local calls rather than connection charge (i.e. one charge unit per call,
however long) was introduced in the early seventies. Reason: unwanted user 
call charge optimization was considered a nuisance. Businesses had found that
they could phone up a branch and just never drop the call, switching it on 
their respective PBXs.

Thats why software that tries to control connectivity over ISDN has to be 
adaptable and capable of collecting charging information from the network
and optimization parameters from the user. It is not necessary to have a 
complete solution, not even practical. Most actual users will only connect 
to a few sites on a regular basis, and would probably be happy if they can 
get away with some 125% of the perceived "optimal" cost, given that foresight
is required and only hindsight available.

                                        Thomas
-- 
*** This is the operative statement, all previous statements are inoperative.
*   email: cmaae47 @ cc.ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic.cc on Janet)
*   voice: +44 71 589 5111 x4937 or 4934 (day), or +44 71 823 9497 (fax)
*   snail: Imperial College of Science, Technology and Medicine
*   The Center for Computing Services, Kensington SW7 2BX, Great Britain
Newsgroups: comp.dcom.isdn
From: deej@cbnewsf.cb.att.com (david.g.lewis)
Subject: Re: ISDN and voice response systems
Organization: AT&T
Distribution: na
Date: Thu, 15 Oct 1992 14:16:39 GMT

In article <peterd.719082854@pjd.dev.cdx.mot.com> peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:
>eswara@bnr.ca (Srinivas Eswara) writes:
>
>Interestingly enough, even if you have ISDN phones on both ends you are
>still probably going to have to send DTMF tones to send keypress
>information. As far as I can tell the reasonable way to send keypresses
>would be to attach keypad information elements to USER_INFO Q.931
>messages. However, this combination of information element and message
>type is not allowed.
>
>I've heard that someone (British Telecom?) was pushing for just this
>capability, but no one else wanted it. 

The User-user IE can carry anything the user wants it to.  If the user wants
to encapsulate Q.931 Keypad IEs in a User-user IE, it can.  If the user
would rather use ASN.1 to carry digit info, it can do that.  But considering
the whole thing is passed transparently by the network, I can understand why
no one else wanted to burden the network with the ability to carry other
IEs.

Now, if standards for user-user communication are what are wanted, someone
like ISO or NIUF has to settle on standard ways to handle this - Q.931
encapsulation, or OSI high-layer protocols, or whatever.  (Hey, I don't know
anything above layer 3...)

David G Lewis                              AT&T Bell Laboratories
david.g.lewis@att.com or !att!goofy!deej     Switching & ISDN Implementation
From: imhw400@indyvax.iupui.edu
Newsgroups: comp.dcom.isdn
Subject: Will I get ISDN before my bank does?
Date: 14 Oct 92 08:51:40 -0500

In article <1992Oct14.082857.4571@ericsson.se>, amongst much thoughtful
argument, etxorst@eos.ericsson.se (Torsten Lif) writes:
> Let's say you call your bank to read your account status. The bank sits
> in a different part of town and has an analog PABX which connects to an
> old analog CO.

Is this scenario really very likely?  Much more likely the bank, being a
business and therefore considered worthy by the telco, will have ISDN (though
they may still have their own analog gear) and I, being mere residential scum,
will still not be able to get it.  Or has the Swedish telco achieved
enlightenment, realizing that many businesses may want ISDN mainly to get into
their customers' and/or employees' homes?
-- 
Mark H. Wood, Lead Analyst/Programmer    +1 317 274 0749   [@disclaimer@]
Internet:  IMHW400@INDYVAX.IUPUI.EDU     BITNET:  IMHW400@INDYVAX
Celebrate freedom:  read a banned newsgroup.
Newsgroups: comp.dcom.isdn
From: etxorst@eos.ericsson.se (Torsten Lif)
Subject: Re: Any experience of ISDN access from Sun S
Reply-To: etxorst@eos.ericsson.se
Organization: Ericsson Telecom AB
Date: Mon, 12 Oct 1992 07:32:05 GMT

In article 10010@xenitec.on.ca, vances@xenitec.on.ca (Vance Shipley) writes:
>In article <Bvp9Gs.CpG@immd4.informatik.uni-erlangen.de> husemann@camelot.informatik.uni-erlangen.de (Dirk Husemann) writes:
>>
>>No. Currently Sun Germany tells us that the ISDN device is unsupported for the
>>time being.
>>
>
>Does this mean that "Sun Germany" is not capable of providing technical
>support for the ISDN device and applications or that it does not DO anything
>yet?

According to the Swedish Sun salescreatures, the port HW is fully
functional but Sun does not at this stage include any driving SW for it
(if they have any and intend to make it available at some later time or
if they expect others to write it is unclear). The port is "sealed"
pending "classification" since many (most?) markets still require
equipment that's to be connected to the public phone networks to be
approved by some telcom agency.

>-- 
>Vance Shipley 
>vances@xenitec.on.ca   vances@ltg.uucp   ..uunet.ca!xenitec!vances

---
 Torsten Lif                        !  These are my personal opinions only.
 Ericsson Telecom AB, EO/ETX/TX/AD  !  I do not speak for Ericsson.
 S-126 25  STOCKHOLM                !  Ericsson is perfectly capable of
 Phone: +46 8 719 4881              !  speaking for itself.
From: eswara@bnr.ca (Srinivas Eswara)
Newsgroups: comp.dcom.isdn
Subject: Re: ISDN and voice response systems
Date: 14 Oct 92 13:07:55 GMT
Reply-To: babineau@BNR.CA
Distribution: na
Organization: Bell-Northern Research Ltd.

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
Newsgroups: comp.dcom.isdn
From: peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
Subject: Re: ISDN and voice response systems
Organization: Motorola Codex, Canton, Massachusetts
Distribution: na
Date: Thu, 15 Oct 1992 16:14:42 GMT


>In article <peterd.719082854@pjd.dev.cdx.mot.com> peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:
>>
>>Interestingly enough, even if you have ISDN phones on both ends you are
>>still probably going to have to send DTMF tones to send keypress
>>information.

deej@cbnewsf.cb.att.com (david.g.lewis) writes:

>The User-user IE can carry anything the user wants it to.

No, it can carry anything that the designer of the telephone wants it
to. There's a big difference between the two.

>Now, if standards for user-user communication are what are wanted, someone
>like ISO or NIUF has to settle on standard ways to handle this - Q.931
>encapsulation, or OSI high-layer protocols, or whatever.  (Hey, I don't know
>anything above layer 3...)

If this approach had been taken with phone-to-switch signalling (i.e. a
terminal-to-network info IE, with undefined contents, rather than a
keypad IE) then stimulus signalling would have no doubt died an early and
possibly unlamented death as well. 

I guess there are two points that I'm trying to make. First, keypad info
is a telephony feature, not just random user information. This distinction
has been made when it suited the switch vendors (i.e. for the INFO message)
but not otherwise. (possibly because the voice response industry was in
its infancy at the time, and so didn't speak up)

Second, if you don't standardize something, you can't communicate. The
only standardized way of getting a character from the alphabet
"1234567890*#" from one ISDN phone to another is via DTMF. You can come
up with a proprietary solution (even if it's ASN.1-based, it's still
proprietary) but you can't force the other end of the call to understand
it.

Third, I find it ironic that if we ever do migrate to ISDN in a few 
decades, your phone will still probably be generating DTMF tones whenever
you deal with an ACD or voicemail system.

				Peter Desnoyers
-- 
Newsgroups: comp.dcom.isdn