HDTenEightyP/NetNews huggingface dataset:
From: etxorst@eos.ericsson.se (Torsten Lif)
Subject: Re: TCP/IP over ISDN
Reply-To: etxorst@eos.ericsson.se
Organization: Ericsson Telecom AB
Date: Sat, 29 Aug 1992 09:48:46 GMT

In article 25416@stc.nato.int, koelman@cuby.stc.nl (Ton Koelman) writes:
>> 
>>  - If the client is still alive, it returns a "disconnect" response to
>>    the connect request with predefined user "cause" value. 
>> 
>>  - If the server receives a disconnect response with any other "cause"
>>    code, it knows that the client has been powered off or disconnected. 
>> 
>> This approach has two advantages over polling using SYNs:
>> 
>>  1. No connection is ever established during the polling process,
>>     so no connection tariffs are applicable.
>> 
>> This approach depends on the availability of user-user data in the
>> connect request. If your local PTT does not support user-user data, 
>> it might be possible to issue the connect request with a specific,
>> predefined DDI (extension number) used only for polls. 
>> 
>> If anyone has reason to believe that this approach will not work, or 
>> can think of viable alternative approaches, feel free to comment. 
>> 
>
>This would imply that you get bandwidth for free through the
>user-to-user data  (unless that is charged separately).
>I don't think PTTs are that stupid.
>If they are then let's send all our IP traffic this way...
>(the MTU may be limited though :-))

I wouldn't know about other manufacturers, but the controlling sowtware
in Ericsson's ISDN switches CAN charge for user-user-info even for a
call that's been rejected. It is, as always, up to the PTT (or whoever
your local "provider" is) to enable this charging, but it has been
thought of.

There exist various possibilities here since u-u-info can be sent in
numerous different signals.

The PTT can charge for (or choose to allow for free :-) the following
(at least):

    u-u-info in call setup (A->B)

    u-u-info in call setup (B->A)
    
    u-u-info during an established call
    
    u-u-info in reject/disconnect

The option to charge for u-u-info in setup ONLY if the call is NOT
accepted also exists, specifically to prevent the kind of "free
signalling" that is outlined above. The rationale behind this is that
if the call is accepted, the info transfer from the u-u-info is paid
for in the startup charge for the call, but if the call is rejected an
information transfer has still taken place.

>Ton K.

Disclaimer: I'm not an official spokesman for Ericsson - I just worked
in an early ISDN project there in -83 to -88.

---
 Torsten Lif
 Ericsson Telecom AB, EO/ETX/TX/AD
 S-126 25  STOCKHOLM, SWEDEN
 Phone: +46 8 719 4881
From: dlr@dlr.net.com (Dave Ramsthaler)
Newsgroups: comp.dcom.isdn
Subject: Length of ISDN addresses
Date: 27 Aug 92 18:15:28 GMT
Organization: Network Equipment Technologies


The ISDN standards specify addresses (numbers) with a maximum of 
55 digits. This includes a 15 digit international number, and a 
40 digit subaddress.

I am building a BRI interface on our multiplexer, and would like 
to limit the subaddresses it handles to a maximum of 15 digits. 

Does anyone out there use, or plan to use, subaddresses longer 
than 15 digits?

David Ramsthaler dlr@net.com
(805) 562-3202
Fax: (805) 562-3303
Newsgroups: comp.dcom.isdn
From: dcarr@gandalf.ca (Dave Carr)
Subject: Re: ISDN on Sparcstations (not 10's)
Organization: Gandalf Data Ltd.
Date: Mon, 31 Aug 1992 21:46:42 GMT

In <8381@sirius.ucs.adelaide.edu.au> dclunie@ucs.adelaide.edu.au (David Clunie) writes:


>Does anyone have any recommendations for connecting a Sun Sparcstation
>to ISDN (without buying an SS10 !) ? Can one get something that plugs
>into serial ports (I presume one could drive them at 56K or so) or
>the SBUS ... I dare say a little software is probably required also
>(I would want to route TCP/IP over it).

We make a personal bridge (LanLine 5510) that connects an Ethernet port to ISDN.
Our distributor down under is:

Ctec
61-2-975-4722
French Forest.
-- 
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.
From: ariel@world.std.com (Robert L Ullmann)
Newsgroups: comp.dcom.isdn
Subject: Re: Length of ISDN addresses
Date: 27 Aug 92 23:00:49 GMT
Organization: The World in Boston

dlr@dlr.net.com (Dave Ramsthaler) writes:

> The ISDN standards specify addresses (numbers) with a maximum of 
> 55 digits. This includes a 15 digit international number, and a 
> 40 digit subaddress.

> Does anyone out there use, or plan to use, subaddresses longer 
> than 15 digits?

When an OSI NSAP is used as a subaddress, it is always 40 digits
long. (Remember, hex digits here.) Whether anyone is using OSI
is a different issue. (<--Humor.)

--
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 de l'eau min irale et,
la t jte renvers ie en arri hre, se gargarisa.  -- Simenon
Newsgroups: comp.dcom.isdn
From: rees@dabo.citi.umich.edu (Jim Rees)
Subject: Re: Length of ISDN addresses
Reply-To: Jim.Rees@umich.edu
Organization: University of Michigan IFS Project
Date: Fri, 4 Sep 1992 14:37:03 GMT

In article <1992Sep3.123932.23973@gandalf.ca>, cstorry@gandalf.ca (Chuck Storry) writes:

  The problems we've had with subaddresses is that the content of the subaddress
  information element is not standardised. It may be encoded as bcd, hex, ascii
  digit, or as per NSAP in one of many formats. If you're after compatibility
  with other CPE then this can be a real problem.

I would consider it a bug if the network imposed any particular structure on
the subaddress.  Can you give an example of where this is a problem?
From: dclunie@ucs.adelaide.edu.au (David Clunie)
Newsgroups: comp.dcom.isdn
Subject: ISDN on Sparcstations (not 10's)
Date: 31 Aug 92 10:01:02 GMT
Organization: Her Master's Voice


Does anyone have any recommendations for connecting a Sun Sparcstation
to ISDN (without buying an SS10 !) ? Can one get something that plugs
into serial ports (I presume one could drive them at 56K or so) or
the SBUS ... I dare say a little software is probably required also
(I would want to route TCP/IP over it).

-- 
David Clunie (dclunie@itd.adelaide.edu.au)
Newsgroups: comp.dcom.isdn
From: rodney@cssc-syd.tansu.com.au (Rodney Campbell)
Subject: Re: ISDN on Sparcstations (not 10's)
Organization: Customised Software Solutions Centres, AOTC
Date: Tue, 1 Sep 1992 03:56:54 GMT

dclunie@ucs.adelaide.edu.au (David Clunie) writes:

>Does anyone have any recommendations for connecting a Sun Sparcstation
>to ISDN (without buying an SS10 !) ? Can one get something that plugs
>into serial ports (I presume one could drive them at 56K or so) or
>the SBUS ... I dare say a little software is probably required also
>(I would want to route TCP/IP over it).

>-- 
>David Clunie (dclunie@itd.adelaide.edu.au)

You can use something like an ISDN-TA (Terminal Adaptor) which plugs into
an ISDN SBUS (As opposed to a Sun SBus) and into the serial port of the
Sun. Then you run a Serial IP Protocol like SL/IP or PPP across the link.
We have done this for some time now as the second solution (see below) has
not really been available in Australia until now (or next week).

An SBus ISDN card for Sun's is supposed to get AUSTEL Approval sometime in
the very near future which will allow you to plug a Sun directly into an
ISDN Net. Sun is also reported to be offering the same technology as in
the SS10 as an SBus module to plug into older SPARC machines.

Lastly if you wish to plug Networks together over ISDN you have a number
of possible options including:

   NetA -> Router/Bridge (X.21 or RS449) -> Macrospan/Microlink (X.21)
   ---- ISDN ---- Macrospan/Microlink (X.21) -> Router/Bridge (X.21 or
   RS449) -> NetB

We have used this successfully for about 9 months now. At the moment this
direct connection from the Router/Bridge to the Macro/Micro Link for 64KBs
(One B Channel) - For Channel Aggregation we use a DataCraft DS2000 as a
channel aggregator which gives us a 7*64KB pipe and requires putting the
DS200 between the Router/Bridge and the Macro/Micro link at both ends.

A number of Router/Bridge manufacturers are reported to be coming out with
ISDN capability with things like Channel Aggregation, Bandwidth on demand
and call on demand, etc.

		    						Rodney...
-- 
     Rodney Campbell - AOTC    |Email : rodney@cssc-syd.tansu.com.au
   Advanced Network Products   |Snail : Level 1, 18-20 Orion Rd, Lane Cove West
 Customised Software Solutions |  -  PO Box A226, Sydney South 2000, Australia.
        Centre - Sydney        |Phone : +61 (0)2 911 3123   Fax: +61 2 911 3199
Newsgroups: comp.dcom.isdn
From: cstorry@gandalf.ca (Chuck Storry)
Subject: Re: Length of ISDN addresses
Organization: Gandalf Data Ltd.
Date: Fri, 4 Sep 1992 20:14:21 GMT

In <5af7f9b6.cb12@dabo.citi.umich.edu> rees@dabo.citi.umich.edu (Jim Rees) writes:

>In article <1992Sep3.123932.23973@gandalf.ca>, cstorry@gandalf.ca (Chuck Storry) writes:

>  The problems we've had with subaddresses is that the content of the subaddress
>  information element is not standardised. It may be encoded as bcd, hex, ascii
>  digit, or as per NSAP in one of many formats. If you're after compatibility
>  with other CPE then this can be a real problem.

>I would consider it a bug if the network imposed any particular structure on
>the subaddress.  Can you give an example of where this is a problem


The problem occurs when CPE from one vendor needs to talk to equipment of
another and they encode/decode the called party subaddress differently. 
Both the originator and recipient must encode the information element
with the same algorithm. This may work for NSAP provided your equipment
recognises the encoded NSAP type; ASCII, HEX, etc. But for "type of
subaddress == User specified" there is of course to agreed to convention
for the subsequent encoding of the subaddress information field. although
CCITT does indicate that the odd/even field is for use when the type of
subaddress is user specified and the coding is BCD.
D
D
D
decodes the same format (actually specified by NSAP encoding?
-- 
Chuck Storry               CAnet: cstorry@gandalf.ca
Gandalf Data Ltd.          Voice: (613) 723-6500
Nepean, Ontario              Fax: (613) 226-1717
Canada  K2E 7M4
Newsgroups: comp.dcom.isdn
From: cstorry@gandalf.ca (Chuck Storry)
Subject: Re: Length of ISDN addresses
Organization: Gandalf Data Ltd.
Date: Thu, 3 Sep 1992 12:39:32 GMT

In <2343@unet.UUCP> dlr@dlr.net.com (Dave Ramsthaler) writes:


>The ISDN standards specify addresses (numbers) with a maximum of 
>55 digits. This includes a 15 digit international number, and a 
>40 digit subaddress.


I'm not sure I follow you David, as I know Q.931 the Called Party Number
length is network dependent (maybe as much as 20 digits in places like
the UK) and the Called Paty Subaddress is specified as a maximum of
23 octets by CCITT but I'll bet is less for most real life implementations.

>I am building a BRI interface on our multiplexer, and would like 
>to limit the subaddresses it handles to a maximum of 15 digits. 

>Does anyone out there use, or plan to use, subaddresses longer 
>than 15 digits?

The problems we've had with subaddresses is that the content of the subaddress
information element is not standardised. It may be encoded as bcd, hex, ascii
digit, or as per NSAP in one of many formats. If you're after compatibility
with other CPE then this can be a real problem.

>David Ramsthaler dlr@net.com
>(805) 562-3202
>Fax: (805) 562-3303
-- 
Chuck Storry               CAnet: cstorry@gandalf.ca
Gandalf Data Ltd.          Voice: (613) 723-6500
Nepean, Ontario              Fax: (613) 226-1717
Canada  K2E 7M4
From: sklower@diva.Berkeley.EDU (Keith Sklower)
Newsgroups: comp.dcom.isdn
Subject: Re: Length of ISDN addresses
Date: 28 Aug 92 19:49:43 GMT
Organization: /etc/organizaton

In article <2343@unet.UUCP> dlr@dlr.net.com (Dave Ramsthaler) writes:
>Does anyone out there use, or plan to use, subaddresses longer 
>than 15 digits?

The 40 byte subaddresses are used to pass OSI nsaps when using
ISDN to implement the connection-oriented network service.

(Hey don't blame me - I'm a true TCP believer!)
Newsgroups: comp.dcom.servers
From: aistmain@vntic.msk.su (Dispatcher of AIST-EuroAIST-RELCOM Boris I. Tarakanov)
Subject: NEW CIPHER-SYSTEM
Summary: NEW CIPHER-SYSTEM
Keywords: NEW CIPHER-SYSTEM
Reply-To: aistmain@vntic.msk.su
Organization: AIST-VNTIC INFORMATION NETWORK
Date: Mon, 31 Aug 92 01:14:18 +0300

              New cipher-system

 1. When the original information is euciphered every bit is
    treaded and redundancy of this information is absent
 2. The amount of variants of eucipher may be so much great,
    for example n=10**91
 3. The quantity of encipher operations for 1 bit are <=22,
    but decipher operations are <= 9 for case n=10**91
 4. Ecodered file is deciphered in turn bit from the end  of
    the text.

    This new cipher-system may be  used  for  protection  of
    information  from   unauthorized  access  and  for  data
    communications by communication chanels.

    Relation by electronic mail.
From: leonard@telcom.arizona.edu (Aaron Leonard)
Newsgroups: comp.dcom.servers
Subject: Re: Anyone have experience with ANNEX3 from Xylogics?
Date: 4 Sep 92 14:55:32 GMT
Reply-To: Leonard@Arizona.EDU
Followup-To: comp.dcom.servers
Distribution: world,local
Organization: University of Arizona Telecommunications

In article <MARKE.92Sep3130549@fsi-ssd.csg.ssd.fsi.com>, marke@fsi-ssd.csg.ssd.fsi.com (Mark W.
Easter) writes:
| 
| We are anticipating adding a couple ANNEX3 Communications Servers in
| our network soon, and I was wondering if anyone in netland had
| anything good or bad to say before we spend our budget for the next
| fifty years.  It will be used as a terminal server (in forward and
| reverse modes), a modem server, and a printer server.  We would be
| especially interested in any experience with the company's support
| capabilities.

We've recently gone with the Annex 3 as our primary asynch comm 
server, and are overall quite satisfied.  

They do an outstanding job providing inbound and outbound terminal access.
Their configurability, as far as defining macros, menus, and customizing
security, is the best in the market.  As they provide full modem control
plus hardware flow control on all serial lines, they are ideal for handling
high-speed modems.

Their software support staff has proved to be extremely helpful and 
responsive.

The one downside is that their printer support capabilities leave something
to be desired.  We have encountered some subtle difficulties involving flow
control on serial-attached printers.  Xylogics has worked hard to resolve
these problems, but I would recommend that, if printing is a MAJOR concern
of yours, you test drive a Xylogics in your application.

| (If you would rather suggest some other piece of equipment other than
| the Annex3, please feel free to pass that along as well.)

I would also recommend checking out the Xyplex line, especially the new
MAXserver 1600, and maybe also cisco's new comm server line.

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
|>   If it ain't broke, break it.
Newsgroups: comp.dcom.servers,comp.dcom.lans
From: marke@fsi-ssd.csg.ssd.fsi.com (Mark W. Easter)
Subject: Anyone have experience with ANNEX3 from Xylogics??
Date: Thu, 3 Sep 1992 18:05:48 GMT
Distribution: comp
Organization: FlightSafety-SSD, Tulsa, OK, USA

We are anticipating adding a couple ANNEX3 Communications Servers in
our network soon, and I was wondering if anyone in netland had
anything good or bad to say before we spend our budget for the next
fifty years.  It will be used as a terminal server (in forward and
reverse modes), a modem server, and a printer server.  We would be
especially interested in any experience with the company's support
capabilities.

(If you would rather suggest some other piece of equipment other than
the Annex3, please feel free to pass that along as well.)

Thanks!
-- 
                                                                         
----------------------------------------------------------------    /|  -
Mark W. Easter            FlightSafety International               / | /|
Staff Engineer            Simulation Systems Division         -----------
Computer Systems Group    Broken Arrow, Oklahoma 74012    Flight   \ |   
marke@fsi.com             918-251-0500 x596                  Safety \|SSD
                   "You wreck 'em - we'll rack 'em"                       
----------------------------------------------------------------------------
From: mcdonald@sacomm.schulz.unisa.edu.au (Ian McDonald)
Newsgroups: comp.dcom.servers
Subject: Can I do this (Annex 3 programming)?
Date: 1 Sep 92 04:30:41 GMT
Reply-To: mcdonald@sacomm.schulz.unisa.edu.au (Ian McDonald)
Organization: University of South Australia


I have some Annex 3s that I manage remotely.  I have set the vcli password
so that nobody else can get in there and manage them for me :-)  Hence, at
the prompt:

Rotaries Defined:
    cli                              -

Enter Annex port name or number:

I choose cli and proceed to enter the password.

The major function of these Annexes is to provide network access to the
serial ports of attached minicomputers.  This is achieved by having remote
users telnet to the Annexes at, say, port 6000 which causes the Annex to
select the next available RS232 port for connection to the attached host.

The difficulty I have is that remote users can telnet to the default port
(23) of the Annexes and at the prompt above, they can pick an RS232 port
number for themselves.  I would like to prevent this, so that the users
don't/can't see the Annex, by not offering the choice of entering a port
number.  Can this be done?

Regards,

Ian McDonald
University of South Australia
Information Technology Branch
Newsgroups: comp.dcom.servers
From: gene@aee.aee.com (Gene Kochanowsky)
Subject: Re: NEW CIPHER-SYSTEM
Keywords: NEW CIPHER-SYSTEM
Organization: Associated Electronic Engineers
Date: Tue, 1 Sep 1992 02:33:52 GMT

aistmain@vntic.msk.su (Dispatcher of AIST-EuroAIST-RELCOM Boris I. Tarakanov) writes:


>              New cipher-system

> 1. When the original information is euciphered every bit is
>    treaded and redundancy of this information is absent
> 2. The amount of variants of eucipher may be so much great,
>    for example n=10**91
> 3. The quantity of encipher operations for 1 bit are <=22,
>    but decipher operations are <= 9 for case n=10**91
> 4. Ecodered file is deciphered in turn bit from the end  of
>    the text.

>    This new cipher-system may be  used  for  protection  of
>    information  from   unauthorized  access  and  for  data
>    communications by communication chanels.

>    Relation by electronic mail.

How can I find out more about this new cipher system?

Gene Kochanowsky  (gene@aee.com)

-- 
------------------------------------------------------------------------------
Gene Kochanowsky                           | "And remember ....
Associated Electronic Engineers, Inc.      |       The better you look ... 
2864 Cercy Trace                           |
From: voorhis@aecom.yu.edu (Adrienne Voorhis)
Newsgroups: comp.dcom.telecom
Subject: Monitoring of Broadcasts
Date: 25 Aug 92 12:18:08 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 661, Message 12 of 19

jon@Turing.ORG (Jon Gefaell)> writes:

> It is illegal to disclose anything heard on any Radio Frequency in any
> mode other than public broadcast, Amateur Radio, and that's about it.
> This means that you can own a scanner and listen to the police, even
> covert operations (I listen to very interesting operations from time
> to time) but you _may not_ disclose those communications to any one
> else.

     Could someone please explain how the federal government can allow
you to legally monitor such broadcasts but can stop you from
disclosing what was heard?  I'm not a First Amendment lawyer, but it
would seem to me that if you lawfully became aware of information,
that the government could not muzzle you from discussing what you have
legitimately obtained.

     What if a reporter, for instance, was listening to a police band
radio and heard a newsworthy event?  Could he or she legitimately be
punished for reporting this information?


Adrienne Voorhis    Albert Einstein College of Medicine
Bronx, New York     Just MY opinion...
Date: 30 Aug 92 20:54:33 GMT
From: arubin@Apple.COM (Android Rubin)
Newsgroups: comp.dcom.telecom
Subject: Re: How Do I Locate Graybar?
Organization: Apple Computer Inc., Cupertino, CA
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 12, Issue 670, Message 1 of 12

In article <telecom12.664.10@eecs.nwu.edu> schuster@panix.com (Michael
Schuster) writes:

> Some recent posts have referred to a supplier called "Graybar".  Is
> this a chain? Mail order house? Regional store?  Do they have a
> catalog?

Graybar
2345 Paragon Dr
San Jose, CA
(408) 441-9009


Andy   arubin@apple.com
From: bob@sunspot.noao.edu (Bob Riegelmann)
Newsgroups: comp.dcom.telecom
Subject: Re: A Bad Time to Fall Asleep
Date: 31 Aug 92 19:51:17 GMT
Organization: National Solar Observatory/SP, Sunspot NM, USA
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 12, Issue 674, Message 3 of 10

In article <telecom12.667.6@eecs.nwu.edu> TELECOM Moderator
(telecom@eecs.nwu.edu) writes:
X-Telecom-Digest: Volume 12, Issue 667, Message 6 of 6

> Mrs. Fermi and I lived in the same apartment building on East
> 56th Street, directly across the street from the Museum of Science and
> Industry, and we chatted and dined together frequently.

Then you must have lived close to my graduate advisor, Russ Donnelly.
And knew one of my best friends, their son, Jim, (who was still in
diapers I expect.)

[Moderator's Interjection: I lived in the Windermere Hotel, 56th and
Stony Island Avenue, and ate in the hotel dining room 'The Anchorage'
most evenings.]

> In Alamogordo, we checked into the hotel then drove out to where
> Enrico had been assigned. It was set up that the scientists were
> deployed over about a two hundred square mile area; we were about
> fifteen miles from the target.
 
I now live in Sunspot, 5000 feet straight up from Alamogordo and in
the hills.

> "Where we stopped was in front of a house on one of the residential
> streets there, but what looked odd to me was on the side of the house,
> there were hundreds of wires converging, coming in from a dozen
> telephone poles which all seemed to meet in the back yard or on the
> side of the house. And all these wires came down out of the sky you
> might say, and went in the side of the house in a big bundle.

This fits with the service I get here in the hills.  No Class here for
a long time to come.

> "Really, I can't blame the lady much. The whole summer of 1945 was
> just horrid. When we arrived the day before, the temperature was over
> a hundred; 

This also fits well, the temps in Alamogordo lately have been in the 90's.
When it gets really hot, I flee home to the hills, where I can see alamogordo,
but the daily highs are in the 70's.

> "When I was there in town two weeks ago for the (twentieth
> anniversary) reunion, just from curiosity I went past that house; it
> took me awhile to remember where it was.

I could go ask, the house is probably still there.

Small world, huh?

Thanks for posting this, it made my day, I'll forward it on to Jim, if
he hasn't seen it.


Bob Riegelmann   bob@sunspot.sunspot.noao.edu
P.O. Box 58      Sunspot, NM 88349-0058 


[Moderator's Note: I would suggest including the lead article in this
issue with any distribution of the original article however.   PAT]