To date, the ISDN potential remains unclear to many observers because they are unaware of what this new technology can do. Even though ISDN has been under development since 1968, applications have been unwilling to develop. In the U.S., this was made more difficult by the divestiture of the Bell Operating Companies from AT&T, which created seven large local service providers, the Regional Bell Operating Companies (RBOCs). This had removed a central controlling authority to lead ISDN national development and deployment. Bellcore remained a central development authority, but only "in the labs" and it could not deploy ISDN with its own resources. Almost every RBOC (and man non-Bell companies) offered ISDN on a limited trial basis in a handful of urban areas starting in the mid-to-late 1980s. Most of the companies deploying ISDN could not connect to or interoperate with any other companies ISDN service until the 1990s. Most observed that this lack of cooperation prevented the development of applications.
Needless to say, ISDN services have been created and are offered in most major cities in the US today, especially in large urban areas. Through trials and now deployment by the RBOCs the developing interest in related technologies for use in private networks or over leased lines enables a variety of applications that can be identified to take advantage of the digital bandwidth that ISDN makes possible.
The functionality most often describing advanced telecommunications networks can be delivered over ISDN lines. The following report identifies a handful of representative examples of what is being done today with the bandwidth and functionality that ISDN offers to Value Added Networks (VANs) specifically Internet Service Providers (ISPs). This paper will focus on the developing market for and selected applications of Internet via ISDN as well as some background on the Internet.
The Value Added Networks and Internet Service Providers
Until just recently the RBOCs have stayed away from the
Internet access community excep
for providing local loop connections to ISPs. Today Pacific
Bell and Ameritech are both
actively pursuing Internet products and managing two of the
new Network Access Points
(NAPs) funded by the National Science Foundation. Each of
the four federally funded
NAPs allow for the Internet to work by allowing for digital
packets of information to be
exchanged between the different National ISPs. Most
companies have traditionally used
dedicated switched 56Kbs(Kilo Bits per second), digital T1
(1.5 Mega bits per second or
Mbs digital data communication), and T3 (45 Mbs) lines to
provide their services. The
delivery of ISDN has enabled for areas with ISDN service to
have the same abilities as
those businesses with dedicated lines and usually in a
quicker and more cost effective
manner.
The demand of Internet access is growing because the technological and social acceptability of it has rapidly evolved. Every day, computing technology is becoming faster, less expensive, and more powerful every month, many people are becoming familiar to increasingly more complex computers in their offices and homes. These two trends - more powerful and inexpensive computing tools and the adoption of Internet access - are creating a new interest in fast access to the Internet via ISDN.
More Bang Through Those Little Wires
ISDN is basically digital phone service. Right now most
subscribers receive a Basic
Rate Interface (BRI) connection. Those BRI lines consist of
2B+D or (two separate phone
lines with one control line). Each line can be used
separately or together to place
either digital or analog calls. ISDN equipment allows for
either a single 64Kbs or a
digital 128Kbs dialup connection via this BRI type of
service. Current "off the shelf"
technology allows compression of up to 512Kbs through an
ISDN BRI line using both B
channels. This is a vast improvement to the now common
28.8Kbs analog modem
connections. Every day even faster means of compressing
those digital lines will soon
have those ISDN compression speeds up to full digital T1
equivalents.
The Internet Past Present and Future
The modern history of Internet can be said to have begun in
1969 when the Advanced
Research and Projects Agency (ARPA, now known as DARPA) of
the Department of Defense
established the first such network -- ARPANET. The original
ARPANET connected 4
computers (known as hosts), located at UCLA, UCSB, SRI in
Menlo Park, CA and the
University of Utah in Salt Lake City. By 1983, more than 400
hosts were connected via
ARPANET. In that year ARPANET split into two networks,
MILNET - the unclassified
military production part of the old ARPANET, and ARPANET -
the academic research
portion. By 1985 MILNET had about 400 hosts and ARPANET
about 140. Collectively the two
networks were called the ARPA Internet.
One of the drawbacks of ARPANET, from the perspective of potential users, was that access to it was officially limited to organizations doing research funded by federal money. As more and more researchers benefited from using ARPANET, the demand for less restrictive networks arose. Thus, in 1981 the National Science Foundation provided funding for the establishment of CSNET whose purpose was to facilitate research and advanced development in computer science by providing a means for increased collaboration among those working in the field. The basic CSNET service was electronic mail though some portions of CSNET ran the full TCP/IP protocols suite.
In 1985-86, to enhance the quality of scientific research in the United States, the National Science Foundation embarked on an effort to build a data network which would both link the Supercomputer Centers together and link the major research facilities -- academic, governmental and commercial -- to the centers. This network was originally envisioned as a companion network to ARPANET, extending Network access to the broad community of university researchers not yet on ARPANET.
The NSF did not want to limit Supercomputer accessibility to researchers using fixed computer hardware. It therefore mandated that all NSF-funded Supercomputer centers and computer networks use the TCP/IP computer communications protocol, which was a non-proprietary protocol.
As a consequence of the NSFNET effort, a chain of regional and state data networks sprang into existence. The first network organized explicitly in response to this national initiative was NYSERNet, which came into being in late 1985. This was soon followed by others. By the beginning of 1987 there were 14 regional, statewide and special interest networks, such as JvNCNet, MERIT, NEARNet, MIDNet, CICNet, BARRNet, CERFNet, PREPNet, OARNet, THENet, SesquiNet, Westnet, NorthWestNet, SURANet, etc. As the number of such networks grew, the NSF was considering how to link all these diverse entities together. In 1986, the NSF created the NSFNET backbone, a national backbone network of 56,000 bit/second (56Kbs) trunk lines linking the 6 NSF funded Supercomputer centers together. This backbone network also served to link all the regional networks together via the regional connections to Supercomputer centers.
The emergence and rapid growth of these mid-level networks led to enormous increases in network usage. By early 1987, it was clear to the NSF that the NSFNET backbone would be saturated within a year. As a result, the NSF released a solicitation for a new NSFNET backbone. The idea now was to interconnect the regional networks and Supercomputer centers using higher capacity lines. In November 1987, a contract to engineer, install, operate and manage a new expanded NSF backbone was awarded to a consortium of IBM, MCI and the State of Michigan Network, MERIT, Inc. The expanded backbone linked together 13 node sites, located all over the U.S. with three 1.544 million bps (T-1) lines coming into each node. In 1992, an expansion of this backbone into a 16 node network with 45 million bps (T-3) trunks was completed. Just recently the NSF retired the backbone network. The replacement was four high-speed interconnection locations called NAPs, Network Access Points, sponsored by the NSF in Chicago, Washington DC, New York, and Southern California. The theory here was that so many commercial Internet Providers had their own nation-wide networks that the NSF having one of its own was not needed. Instead the NAPs address one of the greatest technical problems of the Internet today which is the actual interconnection, or exchanging of packets, between the different network providers.
As the NSFNET and CSNET grew the term "Internet" came to refer to the Internetworking of networks using the TCP/IP protocols and the ability to communicate with one another. These include not only the NSFNET backbone and regional networks, the DOD networks and CSNET, but also networks of many other government agencies such as the Department or Energy's ESNET, NASA networks and various foreign networks as well. In the late 1980s a new trend began with the formation of some commercial Internet access providers. UUNet, Netcom and Performance Systems International all began to provide direct access for commercial companies to connect to a Commercial Internet Exchange, CIX. Today the Internet now connects directly to about 96 countries. In addition, mail gateways to BITNET, MCIMail, America OnLine, CompuServe, Prodigy, Delphi and ad hoc efforts such as FIDONET allow for electronic message exchange with over 170 countries directly all over the world. By most estimates, the Internet has over 50 Million people with possible access connecting to it on at least a monthly basis.
Business Use of the Internet
There are no rules, real instructions or how-to guides on
what to do "on-line" for
businesses. Every month a dozen new books are available
trying to provide this needed
instruction, but in most cases the information is not
accurate nor is many useful
examples included. The best way to discover what is
available on the Internet is to
start surfing and get on-line. If one can be guided by an
expert or take a formal class
all the better.
Most experts say that a business must not do any form of aggressive advertising on the Internet. This only holds true for any type of discussion forums where direct selling would seem inappropriate. An example would be that on an email discussion forum on automobiles one should not advertise a dealer or parts warehouse, but one could recommend or ask for a recommendation of a good source. This type of gray area leads many people not to get on-line till the medium matures. Other ways of getting on-line have come out in the past two years, mainly the World Wide Web.
The World Wide Web, has been the fastest growing section of the Internet. Companies large and small have been using the Web for many different aspects of their businesses. A great deal of attention has come to advertising and marketing efforts of companies and products on the Web. On-line initiatives from Playboy Enterprises and Zima Beverage Company have drawn a lot of attention in the news lately from their projects. An even larger target sector has been real estate agents using the Internet to advertise properties available to a new global audience.
Beyond these marketing efforts or extensions of advertising campaigns on the Internet, sales lead generation, feedback from potential customers, company human resource job listings, customer support supplements, press releases, internal MIS access to outside support and resources and even EDI ordering of products are all possibly with access to the Internet.
Most estimate put people with Internet access at around 25 million in the US. At least half of those people access the Internet via a dialup connection. As the numbers increase the desire for faster and cheaper services continue. Every few months it seems a new application comes out for the Internet. Each one needs more computing power and is usually more and more graphical in nature. Netscape's commercial acceptance has brought the World Wide Web to America. This business success is driving consumers even faster onto the Internet with the strongest desire for access to the graphically oriented World Wide Web. Using a Web browser can include downloading a video clip at 14.4Kbs for a 5 Mb file. This can take 10 to 20 minutes to download by modem, whereas with ISDN it can take less than a minute. This type of radical difference will make the jump to ISDN more attractable for most consumers.
ISDN and the Internet Projects
The Fashion Industry
The Fashion industry is headquartered in New York and Paris.
Made up of literally
hundreds of companies with no strong desire to every merge
together. They all have
difficulty communicating with one another and also need to
work with many companies with
facilities globally. With no common telecommunications
infrastructure except the common
phone system how can this industry with its fax machines and
Federal Express be improved
by ISDN? Furthermore, is it possible for the industry to
also shorten its own operating
cycles to be more competitive in a global environment?
By using the Internet as a common data communications
network in the close-knit fashion
industry can be revolutionary. Now designers can email
design plans to the factories,
inspect live different fabrics and patterns via web browsers
to use to make their
patterns with. Wholesalers and department stores can
preview what designers have chosen
as their new clothes lines and order prior to high profile
shows. This entire process
now takes weeks, could easily take days and in some cases
less than a day.
Using an ISDN/Internet solution instead of dedicated digital phones lines is what makes the fashion scenario possible. The fashion industry uses computers everywhere, but to design and develop a global industry wide dedicated computer system would be impossible and impractical. One large appealing aspect will be that for smaller companies, which the fashion industry is made primarily of, ISDN Internet access will give them th chance to be seen on equal ground as the large companies. This type of incentive will probably make the fashion industry an easy market to integrate.
Telecommuting
Telecommuting refers to the use of telecommunications links
to work from home. While
not a new phenomenon, telecommuting is seen by many as an
application that could be
greatly enhanced by ISDN. Through faster data
communication, sophisticated call routing
services, and integrated voice and data capacity, ISDN has
the potential to enable
people working at home to have their calls passed instantly
from the office at the same
time they access their office LAN for file sharing, e-mail,
and file retrieval and
applications from a server, with only somewhat slower
response than if they were
actually in their office. What makes an ISDN/Internet
solution even more appealing is
that of infrastructure. Most telecommuting scenarios
require for the company to set up
ISDN into their PBXs and into their LANs. With an Internet
solution a company can get a
high speed T3 and connect employees with TCP/IP protocols.
This outsource of the
computer data communication dialup infrastructure, thus
enabling for the company to
concentrate on PBX dial ups via ISDN.
Video Dialtone
Today there are many different video conferencing packages.
If one was connected to the
Internet there are many advantages to investing into some of
the commercial and free
video conferencing tools. One such Project is Cornell
University CUSeeMe project.
Basically with any AV Mac, Audio Visual Macintosh computer,
and a camera one can
broadcast and receive real-time video signals over the
Internet. Using it with ISDN
through the Internet infrastructure one can have a
conversation to anyone with a similar
set up anywhere in the world.( A PC version is also
available). Because the Internet is
already running on dedicated lines no additional charges
need to be paid to anyone.
Although the Internet can not handle everyone using it for
this type of services, it is
completely possibly to do this in a reliable way today.
Why Not Yet?
Well why isn't everyone connected? ISDN has not rolled out
as the Telephone companies
would have liked. Delays have occurred everywhere and
threats from the US Government to
raise tariffs that would result in tripling the current
costs of ISDN have helped keep
consumers away. The general fear of new technology always
keeps some people away. Most
people think that it isn't fast enough and are waiting for
something else.
The Cable TV Industry has been promising Internet access via
their systems for years now
and very little has been deployed yet much has been
promised. Cable companies claim
10Mbs speeds almost 100 times faster than ISDN. This factor
has probably been ISDN
biggest opponent to be delivered. Recently such large
companies such as Contential
Cable Vision and TCI which represent more than 20 million
people from coast to coast
have been promising Internet access via the Cable system.
Not much has been delivered
and the Cable industry has encountered with many technical
problems. It might takes
years for that Industry to really fit in and work with the
Internet Industry as did
Sprint and MCI take a while to work together.
Conclusion
ISDN is a fast reliable technology, if it available in your
area. The Internet is a
fast moving very dynamic and powerful platform to be using
and be a part of. By placing
the two together one creates a large fast moving force which
is empowered with speed and
connectivity around the world. As more Internet Service
Providers specialize in ISDN
service the more people will be able to use the Internet as
a tool which is what
technology is all about.
Appendix I
ISDN Contacts
National ISDN Hotline
* 1-800-992-ISDN
* Fax: (201) 829-2263
* Email: isdn@cc.bellcore.com
* URL: http://www.bellcore.com
* FTP site: ftp info.bellcore.com/pub/ISDN
AMERITECH:
* National ISDN Hotline - 1-800-TEAMDATA
BELL ATLANTIC:
* In N.J., call your localtelephone office.
* http://www.bellatlantic.com
Outside of N.J.:
* ISDN Sales & Tech Ctr. - 1-800-570-ISDN
* For Small Businesses - 1-800-843-2255
BELLSOUTH:
* ISDN HotLine - 1-800-428-ISDN
CINCINNATI BELL:
* ISDN Service Center - 513-566-DATA
NEVADA BELL
* Small business - 702-333-4811
* Large business - 702-688-7100
NYNEX:
* ISDN Sales Hotline - 1-800-GET-ISDN
* New England States - 617-743-2466
PACIFIC BELL
* ISDN Service
Center - 1-800-472-ISDN
* 24 Hr. Automated ISDN/Avail. Hotline - 1-800-995-0346
ROCHESTER TELEPHONE:
* ISDN Information - 716-777-1234
SNET:
* Donovan Dillon - 203-553-2369
STENTOR (Canada):
* ISDN "Facts by Fax" - 1-800-578-ISDN
* Steve Finlay - 604-654-7504
* Glen Duxbury - 403-945-8130
SOUTHWESTERN BELL:
* Austin, TX - 1-800-SWB-ISDN
* Dallas, TX - 214-268-1403
* North Houston, TX - 713-537-3930
* South Houston, TX - 713-567-4300
* San Antonio, TX - 210-351-8050
* For remaining SWBT locations: Bellcore
ISDN HotLine -
1-800-992-ISDN
U S WEST:
* Ron Woldeit - 206-447-4029
* Denver, CO - 1-800-246-5226
**********
National ISDN Long Distance Carrier contacts are as follows:
AT&T:
* AT&T Front End Center - 1-800-222-7956
GTE:
* N'wide avail./pricing - 1-800-888-8799
* Ron Sterrenberg - 214-718-5608
MCI:
* Tony Hylton - 214-701-6745
* ISDN Availability - 1-800-MCI-ISDN
US SPRINT:
* Nancy Johnson - 913-624-4308
WILTEL:
* Justin Remington - 918-588-5069
Appendix II
Archive-name: isdn-faq/part1
Last-modified: $Date: 1995/07/01 18:40:31 $
Version: $Revision: 4.3 $
------------------------------
1.01) Summary of changes from the last version
- Update to HP product info from Pierre_Vidalenc@hp6300.desk.hp.com
(add to Who is shipping what) (Pierre Vidalenc)
- Update to Telrad product info from Azriel Heuman
(azi@mofet.elex.co.il)
- Add Motorola Semiconductor info from Robert W. O'Dell
(roberto@aurora.sps.mot.com)
- Add ACC info from Gary Krall (Gary_Krall@mac-gateway.acc.com)
- Update to Mitel product info from Irene Crosby
(IRENE__CROSBY_at_Kanata-Software-1@ccmail.Mitel.COM)
- Updated info about URL access to Combinet's deployment database
from Jim Fenton <fenton@combinet.com>
- Updated info about William Stalling's ISDN book from
Bill Stallings (ws@shore.net)
- Fixed Southwestern Bell's Dallas telephone number (info from
Clayton Nash, nash.clayton%a1martex@swrunr.sbc.com)
- Added Fujitsu product info from Rick Pitz (rlp@fns.com)
- Added Trend product info from Allard Van der Horst
(allard@trend.demon.co.uk)
- Updated Bell Atlantic info from Pat D'Innocenzo
(b1f4bx1@baplaza.bell-atl.com)
- Updated UK telephone number format as per Peter
Ilieve (peter@aldie.co.uk)
- Updated Teleos info from Chip Sharp (hhs@teleoscom.com)
- Added Web pointers for ITU documents from Helge Stenstrom
(helge@mest.ericsson.se)
- Updated Tone Commander NT-1 info from Steve Hill (tcs@halcyon.com)
Add Network Services Group info from Neville Walker (NEVatNSG@aol.com)
- Updates to the reference section from Michael McCalpin
(mmccalpi@spd.dsccc.com)
- Update to the Silicon Graphics info from Wayne Mesard (wmesard@sgi.com)
- Numerous corrections of e-mail addresses, typos, etc.
------------------------------
1.02) comp.dcom.isdn Frequently Asked Questions - Introduction
These questions and answers have (almost entirely) been extracted from
comp.dcom.isdn. Please post any comments or new material that you
have, or email them to the current FAQ editor, cherkus@unimaster.com.
In particular, the vendor equipment chart is incomplete. If you want
to share vendor equipment info, just cut and paste the headers from the
chart below and create a new entry for the new information, and send it
to me.
This FAQ consists almost entirely of information posted to this group.
There are a fair number of holes and there may be some outdated
information in it. There is no claim of completeness or guarantee of
accuracy of any kind, or no warranties for merchantability or fitness
for a particular purpose. If you have some useful information that you
would like to share, email it to me. My goal is to have the FAQ mirror
the information provided to the newsgroup itself. The next-to-last
section of this FAQ gives references that provide much more information
than this FAQ does.
This FAQ is posted biweekly to the comp.dcom.isdn news group with an
expiration period of two weeks. This FAQ is available via anonymous ftp
to host rtfm.mit.edu, in the directory /pub/usenet/news.answers/isdn-faq.
It's also accessible via the e-mail server -- send the command
"send usenet/news.answers/isdn-faq/*" (without the quotes) in the body
of a e-mail message to mail-server@rtfm.mit.edu. It is also available
via any other site that shadows news.answers. Some of these sites
are:
North America: ftp.uu.net /usenet/news.answers
Europe: ftp.uni-paderborn.de /pub/FAQ
ftp.Germany.EU.net
/pub/newsarchive/news.answers
grasp1.univ-lyon1.fr /pub/faq
ftp.win.tue.nl
/pub/usenet/news.answers
ftp.sunet.se /pub/usenet
Asia: nctuccca.edu.tw /USENET/FAQ
hwarang.postech.ac.kr
/pub/usenet/news.answers
If you have Web access, I recommend you access Dan Kegel's ISDN Web
page at http://alumni.caltech.edu/~dank/isdn/,whichhasevenmoreISDN
information and a pointer to a Web-accessible copy of this ISDN FAQ.
I would like to thank Sean Welch for creating the previous edition
of the FAQ. His work is still responsible for the majority of the
information gathered here. I hope to continue the fine example that
Sean has set.
------------------------------
1.03) Table of Contents
Section 1:
Subject: 1.01) Summary of changes from the last version
Subject: 1.02) comp.dcom.isdn Frequently Asked Questions - Introduction
Subject: 1.03) Table of Contents
Subject: 1.04) To Do List
Subject: 1.05) Who do I have to thank for this list?
Section 2:
Subject: 2.01) What is ISDN?
Subject: 2.02) What does an ISDN network connection look like?
Subject: 2.03) What will Basic Rate (2B+D) ISDN look like in my house/office?
Subject: 2.04) What is a NT1? Who sells them?
Subject: 2.05) Can the existing local loop lines be reused for ISDN?
Subject: 2.06) How does this compare to regular phone lines?
Subject: 2.07) Is caller ID available on ISDN?
Subject: 2.08) What do I get above and beyond plain old telephone service?
Subject: 2.09) What do ISDN phones cost?
Subject: 2.10) Can you use existing telephone equipment with the voice
portion?
Subject: 2.11) What is National ISDN?
Subject: 2.12) What is the NIUF?
Subject: 2.13) What is ATM?
Subject: 2.14) What is B-ISDN?
Subject: 2.15) What is BONDING?
Subject: 2.16) Data Encapsulation for IP over ISDN
Subject: 2.17) Full Motion Video over ISDN
Subject: 2.18) What is a SPID? How come my ISDN device won't work without one?
Subject: 2.19) Will ISDN terminal equipment that works in one country
work properly when it is installed in another country?
Subject: 2.20) Will ISDN terminal equipment that works with
one vendor's ISDN
switch work properly when used with another vendor's switch?
Subject: 2.21) Do different manufacturers' Terminal Adaptors
interoperate when
used asynchronously?
Subject: 2.22) Why do I get only about 19.2k throughput from
my TA?
Subject: 2.23) How long should call setup take when using a TA?
Section 3:
Subject: 3.01) How do I find out about getting ISDN in my area?
Section 4:
Subject: 4.01) Where can I find what all of these acronyms mean?
Subject: 4.02) What are the relevant standards?
Subject: 4.03) Where can I read more?
Subject: 4.04) Can I get on-line National ISDN information from Bellcore?
Section 5:
Subject: 5.01) Who is shipping what?
Subject: 5.02) How about that SPARCstation 10?
Subject: 5.03) How about that IBM Waverunner?
Subject: 5.04) How about that SGI?
Subject: 5.05) How about that HP?
Subject: 5.06) How about that Intel RemoteExpress?
------------------------------
1.04) To Do List
Questions for which I have not yet put together an answer, but for which
I
am accepting suggestions:
a) What programming API's are useful for creating ISDN applications?
(e.g. Sun, Microsoft TAPI, NIUF ASI, ETSI(?), CAPI(?), more(?))
What are their strengths and weaknesses?
------------------------------
1.05) Who do I have to thank for this list?
Lots of people, in one way or another.
CLAUSS1@AppleLink.Apple.COM (Clauss, Chris)
Dave@yost.com (Dave Yost)
Eric_Boll-RXNN70Q@email.sps.mot.com (Eric Boll)
Gary_Krall@mac-gateway.acc.com (Gary Krall)
Greg.Onufer@Eng.Sun.COM
Helge.Oldach@Stollmann.DE (Helge Oldach)
IRENE__CROSBY_at_Kanata-Software-1@ccmail.Mitel.COM
JGFIELDS@delphi.com
Jim.Rees@umich.edu (Jim Rees)
NEVatNSG@aol.com (Neville Walker)
PMW1@psuvm.psu.edu (Peter M. Weiss)
Pierre_Vidalenc@hp6300.desk.hp.com (Pierre Vidalenc)
SYSGAERTNER@cygnus.frm.maschinenbau.th-darmstadt.de
(Mathias Gaertner)
allard@trend.demon.co.uk (Allard Van der Horst)
apsteph@cs.utexas.edu (Alan Palmer Stephens)
art@acc.com (Art Berggreen)
awillis@athena.mit.edu (Albert Willis)
b1f4bx1@baplaza.bell-atl.com (Pat D'Innocenzo)
bernot@inf-wiss.uni-konstanz.de (Gerhard Bernot)
beyries@csisdn.com (Mike Beyries)
bharrell@garfield.catt.ncsu.edu (Ben Harrell)
billsohl@planet.net (sohl, william h)
blsouth!klein@gatech.edu (Michael Klein)
bob@larribeau.com (Bob Larribeau)
bob_clemmons@smtp.esl.com (Bob Clemmons)
cabo@Informatik.Uni-Bremen.DE (Carsten)
cherkus@UniMaster.COM (Dave Cherkus)
cliff@Berkeley.EDU (Cliff Frost)
craig@aland.bbn.com (Craig Partridge)
cstorry@gandalf.ca (Chuck Storry)
curt@kcwc.com (Curt Welch)
dagj@netcom.com (Dag Johansen Esq.)
dank@alumni.caltech.edu (Daniel R. Kegel)
dav@genisco.gtc.com (David L. Markowitz)
dave@philips.oz.au
dem@hep.net (David E. Martin)
dror@digibd.com (Dror Kessler)
dwight@hyphen.com (Dwight Ernest)
earle@poseur.JPL.NASA.GOV (Greg Earle - Sun JPL on-site Software Support)
eleskg@nuscc.nus.sg (Winston Seah)
elitman@wam.umd.edu (Eric A. Litman)
etxorst@eos.ericsson.se (Torsten Lif)
ews@Babel.COM (Ed Sznyter)
fenton@combinet.com (Jim Fenton)
garym@netcom.com (Gary Martin)
giles@paxdata.demon.co.uk (Giles Heron)
glarson@bnr.ca (Greg Larson)
goldstein@bbn.com (Fred R. Goldstein)
helge@mest.ericsson.se (Helge Stenstrom)
hhs@teleoscom.com (Chip Sharp)
hopkins@aw.com (Gerald L. Hopkins)
huntting@futureworld.advtech.uswest.com (Brad Huntting)
james@kaiwan.com (James - The Keeper)
jerry@watchman.sfc.sony.com (Jerry Scharf)
jfritz@wvnvm.wvnet.edu (Jeffrey Fritz)
jhonan@kralizec.zeta.org.au (Jamie Honan)
jik@security.ov.com (Jonathan I. Kamens)
jms@romana.Tymnet.COM (Joe Smith)
jordan@hursley.ibm.com (Rob Jordan)
jsteinb@charm.gandalf.ca (Jennifer Steinberg)
jwb@capek.rdt.monash.edu.au (Jim Breen)
kessler@Eng.Sun.COM (Tom Kessler)
ketil@edb.tih.no (Ketil Albertsen,TIH)
kevin@adtran.com (Kevin Schneider)
kevin@newshost.pictel.com (Kevin Davis)
kevinc@aspect.UUCP (Kevin Collins)
keyman@Eng.Sun.COM (Dave Evans)
knapp@conware.de (Roland Knapp)
kph@cisco.com (Kevin Paul Herbert)
krowett@large.cisco.com (Kevin J. Rowett)
kumquat@hill.com (Gary C. Kessler)
linimon@lonesome.com (Mark Linimon)
lmarks@vnet.ibm.com (Laurence V. Marks)
marc@Destek.NET (Marc Evans)
marc@dumbcat.sf.ca.us (Marco S Hyman)
marjorie_j_panditji@ccm.jf.intel.com (Marjorie Panditji)
mea@intgp1.att.com (Mark Anderson)
mike@tn.com (Mike Sanders)
mikes2@cc.bellcore.com (Mike Souryal)
mmccalpi@spd.dsccc.com (Michael McCalpin)
mstelema@icil64.cilea.it ()
msun@ntmtv.com (Ming Sun)
muftix@junior.bintec.de (Juergen Ernst Guenther)
mwang@abravanel.esd.sgi.com (Michael Wang)
nash.clayton%a1martex@swrunr.sbc.com (Clayton Nash)
oj@vivo.com (Oliver Jones)
oppedahl@panix.com (Carl Oppedahl)
p45dpmg@sherritt.ca (Peter Graw)
paul@suite.sw.oz.au (Paul Antoine)
peter@aldie.co.uk (Peter Ilieve)
pturner@eng.auburn.edu (Patton M. Turner)
rachelw@spider.co.uk (Rachel Willmer)
randys@access.digex.net (Randolph A. Sisto)
rdavies@janus.enet.dec.com (Rob Davies)
rjl@fawlty1.eng.monash.edu.au (Russell Lang)
rlp@fns.com (Rick Pitz)
roberto@aurora.sps.mot.com (Robert W. O'Dell H3-463)
rogers@eplrx7.es.dupont.com (Wade T. Rogers)
ronnie@cisco.com (Ronnie B. Kon)
sanjay@media.mit.edu (Sanjay Manandhar)
scott@labtam.labtam.oz.au (Scott Colwell)
scotty@l5next.gagetalker.com (Scott Turner)
sklower@toe.CS.Berkeley.EDU (Keith Sklower)
sorflet@bnr.ca (winston (w.l.) sorfleet)
spike@coke.std.com (Joe Ilacqua)
stamp@cc.bellcore.com (stamp,scott)
tcs@halcyon.com (Steve Hill)
tilman@gb1.sema.de (Tilman Schmidt)
tnixon@microsoft.com (Toby Nixon)
turtle@newshub.sdsu.edu (Andrew Scherpbier)
uh@diehl.de (Uwe Huebner)
vances@xenitec.on.ca (Vance Shipley)
varney@ihlpf.att.com (Al Varney)
wb8foz@scl.cwru.edu (David Lesher)
we34329@is1.vub.ac.be (Sven De Kerpel)
welch@watchtower.Berkeley.EDU (Sean N. Welch)
wmartin@nsa.bt.co.uk (William Martin)
wmesard@sgi.com (Wayne Mesard)
ws@shore.net (William Stallings)
zok@ins.net (Andreas Frackowiak)
--
Dave Cherkus ----- UniMaster, Inc. ----- Contract Software Development
Specialties: UNIX TCP/IP X OSF/1 AlphaAXP AIX RS/6000 Performance ISDN
Email: cherkus@UniMaster.COM Tel: (603) 888-8308 Fax: (603) 888-4598
Live Free or Die - New Hampshire has 3 seasons: ice, mud and black fly
Archive-name: isdn-faq/part2
Last-modified: $Date: 1995/07/01 18:41:07 $
Version: $Revision: 4.3 $
------------------------------
2.01) What is ISDN?
ISDN stands for "Integrated Services Digital Networks", and it's a
ITU-T (formerly CCITT) term for a relatively new telecommunications
service package. ISDN is basically the telephone network turned
all-digital end to end, using existing switches and wiring (for the
most part) upgraded so that the basic "call" is a 64 kbps end-to-end
channel, with bit-diddling as needed (but not when not needed!).
Packet and maybe frame modes are thrown in for good measure, too, in
some places. It's offered by local telephone companies, but most
readily in Australia, Western Europe, Japan, Singapore, and portions
of the USA, and with other portions of USA asomewhat more behind.
In France, ISDN is known as "RNIS".
eleskg@nuscc.nus.sg (Winston Seah)
goldstein@bbn.com (Fred R. Goldstein)
paul@suite.sw.oz.au (Paul Antoine)
tilman@gb1.sema.de (Tilman Schmidt)
------------------------------
2.02) What does an ISDN network connection look like?
A Basic Rate Interface (BRI) is two 64K bearer ("B") channels and a single
delta ("D") channel. The B channels are used for voice or data, and the D
channel is used for signaling and/or X.25 packet networking. This is the
variety most likely to be found in residential service.
Equipment known as a Terminal Adapter (TA) can be used to adapt these
channels to existing terminal equipment standards such as RS-232 and
V.35. This equipment is typically packaged in a similar fashion to
modems, either as standalone units or as interface cards that plug into
a computer or various kinds of commmunications equipment (such as
routers or PBXs). TAs do not interoperate with the modem; they
replace the modem.
There may be cases where there is no need to interface to existing
terminal equipment or to emulate exisiting terminal equipment, or there
may equipment with synchronous interfaces present. In these cases,
standalone units or computer interfaces can provide high speed
synchronous connections to the B channels without converting to an
asynchronous standard.
Another common type of equipment can be used to implement a bridge
between local area networks using the ISDN channel to transport the
data. These devices typically provide features such as demand
dialing and/or data compression.
Of course, more traditional devices such as telephones and fax machines
can be attached to the BRI, assuming they have the proper interface
hardware and software.
Another flavor of ISDN is Primary Rate Interface (PRI). Inside North
America and Japan, this consists of 24 channels, usually divided into
23 B channels and 1 D channel, and runs over the same physical
interface as T1. Outside of these areas the PRI has 31 user channels,
usually divided into 30 B channels and 1 D channel and is based on the
E1 interface. It is typically used for connections such as one between
a PBX (private branch exchange, a telephone echange operated by the
customer of a telephone company) and a CO (central office, of the
telephone company) or IXC (inter exchange carrier, a long distance
telephone company).
kevinc@aspect.UUCP (Kevin Collins)
keyman@doorway.Eng.Sun.COM (Dave Evans)
turtle@newshub.sdsu.edu (Andrew Scherpbier)
cherkus@UniMaster.COM (Dave Cherkus)
oj@vivo.com (Oliver Jones)
kumquat@hill.com (Gary C. Kessler)
------------------------------
2.03) What will Basic Rate (2B+D) ISDN look like in my house/office?
An ISDN BRI U-Loop is 2 conductors from the CO (telephone company
central office) to the customer premises. Its maximum length may be
5.5 km (18000 ft). The equipment on both sides of the U loop has to be
carefully designed to deal with the long length of the U loop and the
noisy environment it operates in.
At the customer premises the U-loop is terminated by an NT1 (network
termination 1) device. The NT1 drives an S/T-bus which is usually 4
wires, but in some cases it may be 6 or 8 wires. In these optional
cases, the extra wires are used provide power to operate telephones
when normal power fails. Alternately, 'phantom' power may be derived
from the standard four wires. Outside of North America emergency mode
operation provides power for basic voice service only in the case of
loss of local power. In emergency mode operation the NT1 receives up
to 1.2W from the central office. In North America there is no provision
for emergency mode operation.
The name of the S/T bus comes from the letters used in the ISDN
specifications used to refer to two reference points, S and T. Point T
refers to the connection between the NT1 device and customer supplied
equipment. Terminals can connect directly to NT1 at point T, or there
may be a PBX (private branch exchange, i.e. a customer-owned telephone
exchange). When a PBX is present, point S refers to the connection
between the PBX and the terminal. Note that in ISDN terminology,
"terminal" can mean any sort of end-user ISDN device, such as data
terminals, telephones, FAX machines, etc.
The T bus is a multipoint bus in this configuration. It is sometimes
called the passive bus because there are no repeaters on the line
between the NT1 and the devices. It can be implemented using the same
cable and connectors as is 10 base T Ethernet. There may be up to 8
devices on the S/T bus. The bus may be formed with splitters and T
connectors - it is a bus, not a star. The D channel is used to control
the attachment of the one to eight devices to the two B channels. No
two devices attach to the same B channel at the same time.
In this configuration, the major function of the NT is to allow more
than one device to have access to the 2 B channels provided by the ISDN
BRI. For instance, you may have an ISDN telephone, an ISDN fax and an
ISDN computer interface attached to the BRI. Each device can listen
for calls and only connect to a B channel when it identifies a message
requesting a service it can provide.
The NT1 only implements part of the channel sharing scheme; the other
devices participate as well, and the communication protocol used by the
NT1 and the other devices is an integral part of the scheme. The NT1
also performs other functions; it translates the bit encoding scheme
used on the lines between it and the telephone company (the U loop) to
the encoding used between it and the devices. These schemes are
different because the device to NT encoding was designed to enable
channel sharing whereas the NT to telco encoding was designed to allow
transmission across long distances.
In the United States, the customer pays for the NT device, so don't
forget to include the cost of this unit in your cost estimates, or if
you don't need the multiple device attachment feature, try to find a
device that does not require the NT device (i.e. it attaches directly
to the U loop). If you are not in the United States the telephone
company provides the NT device, but remember there is no such thing as
a free lunch - you are probably paying for it through increased rates,
or increased taxes, etc. (flames to sci.economics or alt.talk.politics).
Unfortunately, the NT1 is not an inexpensive device. It has to convert
between the signalling used on the U loop (which is operates over long
distances (5.5 km, 18000 ft) in a noisy environment and does not have
to deal with contention between devices) and the signalling of the S/T
bus (which operates over shorter distances in a quieter environment but
it does have to deal with contention between devices and other protocol
functions). It also provides diagnostic functions such as loopback
mode, and it may have to provide power, as descibed above.
In this configuration, the wires at points S and T are point-to-point
links. Electrically, the S and T points are the same, which is why the
name S/T bus is almost always used. This makes sense; the terminal
should see the same physical interface whether it is hooked up with or
without a PBX. But, logically they are different. The telephone
company needs to know that there is a PBX between itself and the user
so that it can coordinate its efforts with the PBX. So, in cases where
the difference is important, the specifications use the S and T
terminology.
When there is no PBX in the configuration, the NT1 device is usually a
standalone device that is packaged a lot like a modem: in a small box
when there are only a few, and in a rackmount when you need a lot of
them. In the United States, the customer buys the NT1 but in most of
the rest of the world the telephone company provides the NT1. When
there is a PBX the rackmounted NT1s are quite common. Also, when
there is a PBX the use of PRI lines instead of BRI lines is common.
cherkus@unimaster.com (Dave Cherkus)
cliff@Berkeley.EDU (Cliff Frost)
curt@kcwc.com (Curt Welch)
dror@digibd.com (Dror Kessler)
Eric_Boll-RXNN70Q@email.sps.mot.com (Eric Boll)
glarson@bnr.ca (Greg Larson)
krowett@large.cisco.com (Kevin J. Rowett)
mea@intgp1.att.com (Mark Anderson)
paul@suite.sw.oz.au (Paul Antoine)
pturner@eng.auburn.edu ( Patton M. Turner)
ronnie@cisco.com (Ronnie B. Kon)
------------------------------
2.04) What is a NT1? Who sells them?
[ Ed Note: Some may feel that there's a bit of overlap between the
preceding sections and this one, but the preceding sections are
hard to write without integrating NT1 information and this one
is so informative and well-written that it can stand on its own
so I think I should leave it as is. Comments? ]
Reply: What's an NT1, why do I need one, and where do I get one?
An NT1 (network terminator 1) is a device which provides an interface
between the two-wire twisted pairs used by telephone companies in
their ISDN Basic Rate (BRI) network and an end-user's four-wire
terminal equipment. The NT1 also provides power for the terminal
equipment if necessary (most ISDN phones need power from the NT1, but
most data terminal adapters--TAs--don't).
Most ISDN central office equipment (including AT&T 5ESS and Northern
Telecom DMS-100 switches) sends data to your home or office via what's
known in ITU-T lingo as a U interface on a single twisted pair. The
NT1 hooks up to this twisted pair, and converts the signals from the U
interface to the four-wire S/T interface. Most terminal equipment
(for example, the IBM Wave Runner add-in-card TA and most telephones)
offers the S/T interface.
In North America, you have to buy and maintain your own NT1 device.
The telephone company offers end-users a U interface. In Europe and
Japan, the telephone company provides the NT1, owns it, and offers
end-users a S/T interface directly. In North America, some ISDN
equipment vendors offer devices which connect directly to the U
interface (for example, the Combinet CB160). If you have one of these
devices, you don't need to buy a separate NT1. The U interface can't
be built in to the device when it's offered for sale in Europe or
Japan. (This is unfortunate for vendors, who must build and test
separate products for the relatively small North American market if
they want to offer the convenience of a U-interface.)
Many types of NT1s require an external power supply, although some
include a built-in supply. There are typically two classes of
external power supplies. One class provides ten to twelve
watts--enough power for both the NT1 and for the terminal equipment.
The other class provides about two watts--enough power for the NT1
alone. Many good power supplies offer at least a few seconds of
battery backup, to cover for glitches in line power.
Physically, the NT1 is a little plastic box with LEDs on it which can
be screwed to a wall. The external power supply (if one is included)
is a typical plug-wart. If you're using a lot of BRI lines, you can
buy a rack holding a dozen or so NT1s with a built in power supply.
It's a good idea to install your NT1 in a permanent fashion. If you
unplug the ISDN line (the U interface twisted pair) from the NT1, it
shows up as a sign of line trouble in the central office. Some
telephone companies respond to this so-called "trouble" by disabling
your ISDN line at the central office, and require you to place a
service call on your analog telephone to get your ISDN service
restored.
All the vendors shown here accept credit card orders and ship
promptly. All the vendors have well-organized telesales operations
with friendly and reasonably knowledgeable sales people. Prices are in
US dollars, as of 10/26/94, for single-unit purchases. Pricing is
becoming volatile; competition seems to be heating up.
AT&T, Northern Telecom, and Tone Commander NT1s can be ordered from:
Bell Atlantic Teleproducts
West Building, Suite 150
50 E. Swedesford Rd
Frazer Pa, 19355
tel +1-215-695-2300 or 800-221-0845
Maker Description Part No. Price
----- ----------- -------- ------
Northern Telecom NT1 standalone IN51000 108.00
Northern Telecom 10w power supply IN61000 72.00
Northern Telecom 2w power supply IN61005 36.00
AT&T NT1U-220 IA51007
276.00
AT&T NT1U-230 IA51009
165.00
AT&T 10w power supply IA61000
105.00
Tone Commander manufactures a variety of standalone and rack-mount NT1s
and racks. The NT1U-100 series is intended for locally powered terminal
adapters - no power is provided through the NT1. The NT1U-200 series provides
PS1 and PS2 power for voice terminals and also has additional status
indicators. Specific features, pictures, and more detailed information is
available at the Tone Commander home page: http://www.halcyon.comm/tcs/
Tone Commander Systems
11609 49th Place West
Mukilteo, WA 98275
voice: (800)524-0024 or (206)349-1000
fax: (206)349-1010
Prices listed below are Dealer List Prices. Additional 5% discounts are
provided for VISA/MC sales; 8% discounts for COD sales. Tone
Commander products are also available through various distributors.
Maker Description Part No. Price
-------------- -------------------------------- ------------- ------
Tone Commander Standalone NT1 with power supply NT1U-100TC 169.00
Tone Commander Rack-mount NT1 circuit card NT1U-110TC 159.00
Tone Commander 16 card rack for NT1U-110TCs NT1U-100 Rack 399.00
Tone Commander Standalone or rack-mount NT1 NT1U-220TC 195.00
Tone Commander Power supply for NT1U-220TC 901034 30.00
Tone Commander 12 unit rack for NT1U-220TCs NT1-220 Rack 595.00
Tone Commander UPS for NT1-220 Rack NT1-200 Backup 450.00
Tone Commander Add-on battery for NT1-200 Backup NT1-200 Add-on 385.00
Adtran offers their own NT1 products for sale.
Adtran, Inc.
901 Explorer Blvd Huntsville, AL 35806-2807 USA
+1 205 971 8000
fax +1 205 971 8030
Maker Description Part No. Price
----- ----------- -------- ------
Adtran NT1 NT1 ACE 395.00
Adtran Power Supply PS2 150.00
Adtran Power Kit 74.00
Adtran Standalone NT1 NT1/T400 575.00
(incl 7W supply)
Adtran Rackmount NT1
NT1/T400 395.00
IBM sells the RoadRunner, an NT1 device with added value: it can
operate either as a standard NT1 or in extended mode. In extended mode
it provides an intergrated voice terminal adapter and a connection to
which POTS telephone devices (including modems, FAXs, and answering
machines) can be attached. This allow a home POTS line to be replaced
with an ISDN line.
When operating with a DMS-100 switch, one B channel is devoted to the
analog phones and one B channel is devoted to the data terminal
adapter. When attached to a 5ESS switch, the B channels may be
allocated dynamically. The analog phones may use either B channel that
is available, and the data terminal device may use either or both B
channels.
The device includes a built in power supply and a back up battery,
providing up to 18 hours of on-hook, or 6 hours of off-hook operation
during a local power failure.
IBM
800-426-2255
+1-404-238-2157
Maker Description Part No. Price
----- ----------- -------- ------
IBM 7845 Network 82G6060 350.00
Terminator
Extended
Motorola UDS offers the NT100 Network Termination Unit. This is an
NT1 with added value: a series of diagnostic tests can be chosen via a
front-panel rotary switch.
Motorola UDS
5000 Bradford Drive
Huntsville AL 35805-1993
+1 205 430 8000
800 451 2369
fax +1 205 830 5657
Maker
Description Part No. Price
----- ----------- -------- ------
Motorola UDS Net. Term. Unit NT100
Thanks to the following people who helped uncover this information.
tynane@chdasic.sps.mot.com (Ed Tynan)
rkp@bighorn.dr.att.com (Russell Pierce)
"H.A. Kippenhan Jr." <KIPPENHAN@fndcd.fnal.gov>
csederholm@VNET.IBM.COM
The people who compiled the NIUF solutions catalog
Steve Hill (tcs@halcyon.com)
Special thanks to oj@vivo.com (Oliver Jones) for editing this section.
------------------------------
2.05) Can the existing local loop lines be reused for ISDN?
The ISDN pairs are the same wires as used for regular telephone
service. If you became an ISDN user at home, the same wire pair that
now provides your telephone service would be used to provide ISDN
(assuming you no longer have the regular line).
Most of the lines do not require any special conditioning. Yes, if
a line has load coils on it they must be removed, BUT load coils
are usually only found on existing lines that are 15,000 feet or
longer. As to lines with bridge taps, the 2B1Q line transmission
scheme (not to be confused with 2B + D channelization) is tolerant
of a certain amount of bridge taps and, therefore it is only a minimal
subset of existing lines (lines with bridge taps whose total length is
greater than 3000 feet for the bridge taps) that would require
special "de-conditioning."
With those things as the criteria, (in North America) we find than
generally around 90% or so of existing telephone lines need no
"de-conditioning" in order to be used for ISDN BRI service.
billsohl@planet.net (sohl, william h)
------------------------------
2.06) How does this compare to regular phone lines?
The ISDN line may act like two independent phone lines with two numbers.
Depending on the CO equipment, conferencing features etc. may be available
(conferencing in the telephone switch). BRI ISDN phones can support key-set
features such as you would expect to get on an office PBX like:
- multiple directory numers per line.
- multiple lines per directory number.
- conferencing features.
- forwarding features.
- voice mail features.
- speed call.
- call park.
- call pickup.
- ring again.
- textual status displays.
curt@kcwc.com (Curt Welch)
glarson@bnr.ca (Greg Larson)
------------------------------
2.07) Is caller ID
available on ISDN?
Caller ID (name or number display) may be supported (depending on the
CO setup). The availability of caller ID for residential phones would
depend on the capabilities of the local phone network and legislation
allowing or disallowing caller ID. The availability of Caller ID
relies on the underlying switching protocol used by the switches
that make up the telephone system (e.g. SS7).
curt@kcwc.com (Curt Welch)
glarson@bnr.ca (Greg Larson)
kumquat@hill.com (Gary C. Kessler)
------------------------------
2.08) What do I get above and beyond plain old telephone service?
Plain old telephone service is transmitted between the central office
to your home or office telephone set (or modem, or fax) in analog
form. At the central office, the analog signal is converted to a
series of digital samples at a rate of 8000 samples per second. Each
sample is seven or eight bits in length. As the signals for a
telephone call move around the central office, or between central
offices, they are transmitted in digital form. Thus, a telephone call
consumes a transmission bandwidth of either 56 or 64 kilobits per
second. The theoretical (Nyquist) limit for the frequency response of
a signal sampled 8000 times per second is 4kHz. However, due to
various losses in the telephone system, the frequency response of an
ordinary telephone call is usually quoted as 3.1kHz. Ordinary
modem-based data transmission uses schemes for encoding data in an
analog signal so it fits in this 3.1kHz bandwidth. 14.4kbps is a
commonly available transmission rate at the high end of the scale.
With this transmission rate, over three-quarters of the bitrate handled
by the central office is wasted.
Notice that in telephony, 64kpbs means 64000 bits per second, whereas
in computer engineering 64k bytes typically means 65536 bytes.
ISDN brings the digital signal all the way to your home or desktop. With
ISDN, you can place a data call which uses all 56kbps or 64kbps, because
there is no need to convert the signal to analog in your modem and back
to digital at the central office. The availability of the full bandwidth
presents some interesting technological opportunities:
-- transmission of high-fidelity compressed audio
-- transmission of encrypted audio
-- transmission of lots of data
-- transmission of other compressed signals, such as video
Basic-rate ISDN (BRI) offers two channels of this service. In
BRI, the
connection between your site and the central office offers 64kbps
bidirectionally on each channel. Each of these channels may be used
for a voice call, for circuit-switched data, or for X.25 packet
switched data. Thus, the existing POTS circuit [POTS: Plain Old
Telephone Service, i.e. traditional analog telephony] can be
conditioned to carry two calls at the same time. (Your mileage may
vary; you have to specifically order and pay for the various services
from your telephone company, just as you have to order and pay for Call
Waiting for an ordinary phone line. Also, not all services are
available everywhere; X.25 connectivity between COs is a notable
problem in the Greater Boston area as of 9/93, for example.)
Incidentally, ISDN brings another interesting service to your home or
desktop: a highly reliable 8000Hz clock signal. In most cases, the
central office switches, long-distance carriers, and ISDN terminal
equipment all operate with exactly the same clock frequency. In a
real-time communications environment (like a voice phone call) this
means that there's no need to compensate for differences between the
sampling rates at each end of the call.
One of the other features is that instead of the CO sending an AC ring
signal to activate your bell, it sends a digital packet that tells WHO
is calling (if available), WHAT TYPE of call (speech, datacomm?), the
NUMBER DIALED (maybe one of your aliases) and some other stuff. Your
equipment can then analyze this stuff and make an "intelligent" decision
what to do with it. For example, a phone (with speech-only capacity)
would completely ignore a datacomm call while a Terminal Adapter (ISDN
"modem") or a phone with built-in datacom functions would respond to it.
If you have several "aliases" tied to your line, you can program certain
phones to answer calls for certain numbers only. Datacomm calls contain
baud rate and protocol information within the setup signal so that the
connection is virtually instantaneous (no messing around with trying
different carriers until both ends match).
curt@kcwc.com (Curt Welch)
etxorst@eos.ericsson.se (Torsten Lif)
oj@vivo.com (Oliver Jones)
Helge.Oldach@Stollmann.DE (Helge Oldach)
------------------------------
2.09) What do ISDN phones cost?
The ISDN sets can cost between $180 for an AT&T 8503T ISDN phone from
Pacific Bell up to $1900 depending on what/how many features are needed.
A recent report states that the price is $536.90 for an AT&T 7506 with
the RS-232 port on the back and $102.70 to get the 507A adaptor to hook
analog devices to my 7506.
Recent quotes were "$200" for a Coretelco 1800 and "$600" for a Fujitsu
SRS 1050.
keyman@doorway.Eng.Sun.COM (Dave Evans)
huntting@futureworld.advtech.uswest.com (Brad Huntting)
spike@coke.std.com (Joe Ilacqua)
scotty@l5next.gagetalker.com (Scott Turner)
------------------------------
2.10) Can you use existing telephone equipment with the voice portion?
Terminal Adapters (TA's) are available that will interface non ISDN terminal
equipment (TE), called TE2, to the S/T interface. At least one RBOC provides
a modem pool to allow for interchange of data with POTS subscribers.
Bellcore
may approve a standard to allow a analog pair to interface to POTS sets from
a NT1. Also w/o a NT2 only one set can be connected to a B channel at a
time. This prevents 2 sets from participating in the same voice call.
pturner@eng.auburn.edu ( Patton M. Turner)
spike@coke.std.com (Joe Ilacqua)
------------------------------
2.11) What is National ISDN?
Because of the breadth of the international ISDN standards, there are a
number of implementation choices that vendors of ISDN equipment can
make. Given the number of choices vendors can make, different vendors
equipment may not interoperate. In the United States, Bellcore has
released a series of specifications to try to avoid these
interoperability problems. These are the National ISDN
specifications. Contact the Bellcore ISDN hot line listed below for
more information.
kumquat@hill.com (Gary C. Kessler)
cherkus@UniMaster.COM (Dave Cherkus)
------------------------------
2.12) What is the NIUF?
North American ISDN Users Forum (NIUF) is an org. of ISDN-interested
parties, coordinated by NIST (National Institute of Stds. and Tech.)
Contact:
NIUF Secretariat
National Institute of Standards and Technology
Building 223, Room B364
Gaithersberg, MD 20899
(301) 975-2937 voice
(301) 926-9675 fax
(301) 869-7281 BBS 8N1 2400 bps
Bellcore has made the PostScript files for "A Catalog of National
ISDN Solutions for Selected NIUF Applications, Second Edition"
accessable via anonymous ftp from the machine info.bellcore.com.
This document has a tremendous amount of information about
ISDN products and vendors, among many other things. See the item
below for details.
The currently approved documents for the Application Software
Interface (ASI) from the North American ISDN User's Forum (NIUF)
are available via anonymous FTP from dsys.ncsl.nist.gov. The
documents are in Postscript and found in uncompressed ASCII (foo.ps),
compressed (foo.Z) and zipped (foo.zip) files.
These documents describe the Implementation Agreements made by the
NIUF for an API to ISDN services.
The file sizes are approximate and intended to help determine space
requirements for transfer.
Part 1: Overview and Protocols - Approved: 10/4/91, Updated: 10/30/92
~ftp/asi/docs/part1.ps - 347853 bytes
~ftp/asi/docs/part1.Z - 119655 bytes
~ftp/asi/docs/part1.zip - 89545 bytes
Part 2: MS-DOS Access Method - Approved: 6/5/92
~ftp/asi/docs/part2.ps - 146474 bytes
~ftp/asi/docs/part2.Z - 44450 bytes
~ftp/asi/docs/part2.zip - 31599 bytes
Part 3: Enhanced DOS/Protected Mode Shell Access Method -
Approved: June 5, 1992, Updated: 10/30/92
~ftp/asi/docs/part3.ps - 285344 bytes
~ftp/asi/docs/part3.Z - 91273 bytes
~ftp/asi/docs/part3.zip - 68331 bytes
Part 4: UNIX Access Method -
Approved: 10/30/92
~ftp/asi/docs/part4.ps - 151809 bytes
~ftp/asi/docs/part4.Z - 47765 bytes
~ftp/asi/docs/part4.zip - 33465 bytes
For further information regarding these documents please contact
Robert Toense (rtoense@nist.gov) (phone: +1 301 975 2930).
cherkus@UniMaster.COM (Dave Cherkus)
vances@xenitec.on.ca (Vance Shipley)
------------------------------
2.13) What is ATM?
ATM (Asynchronous Transfer Mode) is a switching/transmission technique
where data is transmitted in small, fixed sized cells (5 byte header,
48 byte payload). The cells lend themselves both to the time-division-
multiplexing characteristics of the transmission media, and the packet
switching characteristics desired of data networks. At each switching
node, the ATM header identifies a "virtual path" or "virtual circuit"
that the cell contains data for, enabling the switch to forward the
cell to the correct next-hop trunk. The "virtual path" is set up
through the involved switches when two endpoints wish to communicate.
This type of switching can be implemented in hardware, almost essential
when trunk speed range from 45Mb/s to 1Gb/s.
One use of ATM is to serve as the core technology for a new set of ISDN
offerings known as Broadband ISDN (B-ISDN).
For more information, read comp.dcom.cell-relay.
This group has a Frequently Asked Questions list; it is posted
to news.answers and is in various archives as cell-relay-faq.
art@acc.com (Art Berggreen)
cherkus@UniMaster.COM (Dave Cherkus)
------------------------------
2.14) What is B-ISDN?
Broadband ISDN refers to services that require channel rates greater than
a single primary rate channel. While this does not specificially imply
any particular technology, ATM will be used as the switching infrastructure
for B-ISDN services.
B-ISDN services are categorized as:
INTERACTIVE
Conversational -- such as videotelephony, videoconferencing, ...
Messaging -- such as electronic mail for images, video, graphics,...
Retrieval -- such as teleshopping, news retrieval, remote education,...
DISTRIBUTION
Without user presentation control -- electronic newspaper, electronic
newspaper, TV distribution With user presentation control -- remote
education, teleadvertising, news retrieval
More information: ITU ITU-T Rec. I.211.
kumquat@hill.com (Gary C. Kessler)
------------------------------
2.15) What is BONDING?
An inverse multiplexing method of the Bandwidth ON Demand
INteroperability Group, implemented by most (all?) inverse multiplexor
vendors to interoperate with inverse multiplexors of other vendors.
BONDING is a set of protocols developed by U.S. inverse multiplexor
that supports communication over a set of separate channels as if their
bandwidth were combined into a single coherent channel. For example it
supports a single 384 kb/s data stream over 6 64 kb/s channels.
The specification defines a way of calculating relative delay between
multiple network channels and ordering data such that what goes in one
end comes out the other.
Most (all?) vendors also have their own proprietary methods that
usually add features and functions not present in BONDING mode 1. Mode
1 is the mode used for recent interoperability testing between vendors.
Chip Sharp at Teleos has made available electronic copies of the
BONDING (Bandwidth on Demand Interoperability Group) 1.0 and 1.1
specifications. The specs are available via WWW, gopher, anonymous
FTP, DECnet COPY, and AFS (see instructions below).
The following files are available:
- aaareadme-networks help file (in ascii text)
- bdmain.doc main body of BONDING 1.0 specification
(Word for Windows 2.0 format)
- bdmain.ps main body of BONDING
1.0 specification (Postscript)
- bdannex.doc annex of BONDING 1.0 specification (Word
for Windows 2.0 format)
- bdannex.ps annex of BONDING 1.0
specification (Postscript)
- bd_v1_1.doc changes for BONDING 1.1 specification (Word
for Windows 2.0 format)
- bd_v1_1.ps changes for BONDING
1.1 specification (Postscript)
Transfer Instructions:
WWW:
server: www.hep.net
URL: gopher://www.hep.net:70/11/info_center/networks/bonding
Gopher:
server: gopher.hep.net
Bookmark:
Name=Bandwidth on Demand Interoperability Group (BONDING) Documents
Type=1
Port=70
Path=1/info_center/networks/bonding
Host=gopher.hep.net
Anonymous FTP:
server: ftp.hep.net
directory: networks/bonding
DECnet COPY (only for those on HEP-NSI DECnet):
HEPNET::[ANON_FTP.NETWORKS.BONDING]
AFS:
/afs/hepafs1.hep.net/public/anon_ftp/networks/bonding
marc@dumbcat.sf.ca.us (Marco S Hyman)
"Bob Larribeau" <p00136@psilink.com>
"David E. Martin" <dem@hep.net>
------------------------------
2.16) Data Encapsulation for IP over ISDN
A decision was made at the Amsterdam IETF to state that all systems
wishing to guarantee IP interoperability should implement PPP. Such
systems may also implement the Frame Relay or X.25 encapsulations, and
an RFC will be published delineating how, when it is known that the
encapsulations are limited to that set of three, they may be
distinguished by examination of the first correctly checksummed and
HDLC bit-stuffed packet.
Many implementations are using PPP so that they can negotiate
compression and/or multilink operation.
There is an Internet Draft from the Point-to-Point Protocol Working
Group of the Internet Engineering Task Force that describes the use of
PPP over ISDN. This draft is named draft-ietf-pppext-isdn-NN.txt in
the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
nic.nordu.net, ftp.nisc.sri.com, munnari.oz.au, Germany.EU.net and on
many, many other mirror archives. This is also discussed in RFC 1356
by Malis, et. al.
A common practice in most European countries is raw IP packets
delimited by HDLC flags. Another common practice is an encapsulation
using simple HDLC in layer 1, X.75 (LAPB, usually I-frames) in layer 2
and, sometimes, T.70 in layer 3. PPP is used instead of HDLC/X.75/T.70
when the network doesn't provide the callers telephone number eg. when
emulating a modem or the callers number is lost on telephone company
borders. In this case, caller authentication is done via PAP/CHAP
instead.
sklower@toe.CS.Berkeley.EDU (Keith Sklower)
cherkus@UniMaster.COM (Dave Cherkus)
kumquat@hill.com (Gary C. Kessler)
muftix@junior.bintec.de (Juergen Ernst Guenther)
cabo@Informatik.Uni-Bremen.DE (Carsten)
------------------------------
2.17) Full Motion Video over ISDN
In ISDN, video isn't a "service being offered" - at least not for
low/midrange quality. You buy the proper equipment for both
subscribers, plug it in, and place the call. Just like speaking French
on ISDN isn't something being offered - it is something you just do,
yourself.
Video telephony over narrowband ISDN is governed by a suite of ITU-T
(formerly CCITT) interoperability standards. The overall video
telephony suite is known informally as p * 64 (and pronounced
'p star 64'), and formally as standard H.320. H.320 is an "umbrella"
standard; it specifies H.261 for video compression, H.221, H.230, and
H.242 for communications, control, and indication, G.711, G.722, and
G.728 for audio signals, and several others for specialized purposes.
A common misconception, exploited by some equipment manufacturers, is
that compliance with H.261 (the video compression standard) is enough
to guarantee interoperability.
Bandwidth can be divided up among video, voice, and data in a
bewildering variety of ways. Typically, 56kbps might be allocated to
voice, with 1.6kbps to signalling (control and indication signals) and
the balance allocated to video.
An H.320-compatible terminal can support audio and video in one B
channel using G.728 audio at 16 kb/s. For a 64 kb/s channel, this
leaves 46.4 kb/s for video (after subtracting 1.6 kb/s for H.221
framing).
The resolution of a H.261 video image is either 352x288 (known as CIF)
or 176x144 (known as quarter-CIF or QCIF). The frame rate can be
anything from 30 frames/second and down. Configurations typically use
a 2B (BRI) or a 6B (switched-384 or 3xBRI with an inverse multiplexer)
service, depending on the desired cost and video quality. In a 384kbps
call, a video conferencing system can achieve 30 frames/second at CIF,
and looks comparable to a VHS videotape picture. In a 2B BRI call, a
standard video phone can achieve 15 frames/second at CIF.
Those who have seen the 1B video call in operation generally agree that
the quality is not sufficient for anything useful like computer based
training - only for the social aspect of being able to *see* Grandma as
well as hear her (sort of like the snapshot pictures you make with that
$5 camera with no controls).
A 2B picture, on the other hand, is for all practical purposes
sufficient for remote education, presentations etc. Rapidly changing
scenes are still not very well handled, but as soon as the picture
calms down, the sharpness and color quality are impressive (considering
that only two plain phone channels are being used). With 2B+D being the
standard BRI, this kind of picturephone will be usable "everywhere"
(including private homes).
However, it should still be noted that 6xB or H0 does allow for dramatic
improvement in picture quality compared to 2xB. In particular, H.320
video/audio applications will often allocate 56kbps for audio, leaving
only 68.8kbps for video when using 2xB. On the other hand, using H0
would get you 326.4kbps for video with 56kbps for audio. Alternative
audio algorithms can improve picture quality over 2xB by not stealing
as many bits. Note that 6B is not identical to H0; the latter is a
single channel which will give you 80kbps above that of six separate B
channels. Inverse multiplexors can be used to combine B channels.
ketil@edb.tih.no (Ketil Albertsen,TIH)
kevin@newshost.pictel.com (Kevin Davis)
oj@vivo.com (Oliver Jones)
mikes2@cc.bellcore.com (Mike Souryal)
------------------------------
2.18) What is a SPID? How come my ISDN device won't work without one?
SPIDs are Service Profiles IDs. SPIDs are used to identify what sort
of services and features the switch provides to the ISDN device.
Currently they are used only for circuit-switched service (as opposed
to packet-switched). Annex A to ITU recommendation Q.932 specifies the
(optional) procedures for SPIDs. They are most commonly implemented by
ISDN equipment used in North America.
When a new subscriber is added, the telco personnel allocate a SPID
just as they allocate a directory number. In many cases, the SPID
number is identical to the (full ten digit) directory number. In other
cases it may be the directory number concatinated with various other
strings of digits, such as digits 0100 or 0010, 1 or 2 (indicating the
first or second B channel on a non-centrex line), or 100 or 200 (same
idea but on a centrex line) or some other, seemingly arbitrary string.
Some people report SPIDs of the form 01nnnnnnn0 for AT&T custom and
01nnnnnnn011 for NI-1, where n is the seven digit directory number.
It is all quite implementation dependent.
The subscriber needs to configure the SPID into their terminal (i.e.
computer or telephone, etc., not their NT-1 or NT-2) before they will
be able to connect to the central office switch.
When the subscriber plugs in a properly configured device to the line,
Layer 2 initialization takes place, establishing the basic transport
mechanism. However if the subscriber has not configured the given SPID
into their ISDN device, the device will not perform layer 3
initialization and the subscriber will not be able to make calls. This
is, unfortunately, how many subscribers discover they need a SPID.
Once the SPID is configured, the terminals go through an
initialization/identification state which has the terminal send the
SPID to the network in a Layer 3 INFOrmation message whereby the
network responds with an INFO message with the EID information element
(ie). Thereafter the SPID is not sent again to the switch. The switch
may send the EID or the Called Party Number (CdPN) in the SETUP message
to the terminal for the purpose of terminal selection.
SPIDs should not be confused with TEIs (terminal endpoint identifiers).
TEIs identify the terminal at Layer 2 for a particular interface
(line). TEIs will be unique on an interface, whereas SPIDs will be
unique on the whole switch and tend to be derived from the primary
directory number of the subscriber. Although they are used at
different layers, they have a 1-to-1 correspondence so mixing them up
isn't too dangerous. TEIs are dynamic (different each time the terminal
is plugged into the switch) but SPIDS are not. Following the
initialization sequence mentioned above the 1-to-1 correspondence is
established. TEIs are usually not visible to the ISDN user so they are
not as well known as SPIDs.
The "address" of the layer 3 message is usually considered to be the
Call Reference Value (also dynamic but this time on a per call basis)
as opposed to the SPID, so the management entity in the ISDN device's
software must associate EID/CdPN on a particular TEI and Call Reference
Number to a SPID.
There are some standards that call for a default Service Profile, where
a terminal doesn't need to provide a SPID to become active. Without
the SPID however, the switch has no way of knowing which terminal is
which on the interface so for multiple terminals an incoming call would
be offered to the first terminal that responded, rather than to a
specific terminal.
sorflet@bnr.ca (winston (w.l.) sorfleet)
cstorry@gandalf.ca (Chuck Storry)
------------------------------
2.19) Will ISDN terminal equipment that works in one country
work properly when it is installed in another country?
There are four major problem areas.
The first has to do with voice encoding, and is only a problem if the
equipment is a telephone. Equipment designed for use in North America
and Japan uses mu-law encoding when converting from analog to digital,
whereas the rest of the world uses A-law. If the equipment has a
switch for selecting one or the other of these encoding types, then
there will not be a problem with the voice encoding.
The second has to do with the way the equipment communicates with the
telephone exchange. There are interoperability problems because
* there are so many different services (and related parameters) that the
user can request and
* each country can decide whether or not to allow the telephone exchange
to offer a given service and
* the specifications that describe the services are open to interpretation
in many different ways.
So, as with other interoperability problems, you must work withthe vendors
to determine if the equipment will interoperate. This is a basic problem;
it impacts all ISDN equipment, not just voice equipment.
The third has to do with homologation, or regulatory approval. In most
countries in the world the manufacturer of telephone equipment must
obtain approvals before the equipment may be connected to the network.
So, even if the equipment works with the network in a particular
country, it isn't OK to hook it up until the manufacturer has jumped
through the various hoops to demonstrate safety and compliance. It is
typically more expensive to obtain world-wide homologation approvals
for a newly-developed piece of ISDN equipment than it is to develop it
and tool up to manufacture it.
A fourth issue is in the US the TA and NT1 are both provided by the
customer, while in Europe the NT1 is provided by telephone company.
Stated differently, if you walk into a store in the US and buy
something to plug into an ISDN line it may be designed as a one-piece
unit that connects to point U. In Europe you would get something that
plugs into point T. Thus you might take a piece of US-originated
equipment to Europe and find that it won't work because the jack in
Europe is a T interface and the plug on your US equipment is a U
interface.
There are attempts to remedy this situation, particularly for BRI
ISDN. In North America, the National ISDN User's Forum is coming
up with standards that increase the uniformity of ISDN services.
In Europe, a new standard called NET3 is being developed.
msun@ntmtv.com (Ming Sun)
marc@dumbcat.sf.ca.us (Marco S Hyman)
jwb@capek.rdt.monash.edu.au (Jim Breen)
keyman@Eng.Sun.COM (Dave Evans)
oj@vivo.com (Oliver Jones)
wmartin@nsa.bt.co.uk (William Martin)
oppedahl@panix.com (Carl Oppedahl)
------------------------------
2.20) Will ISDN terminal equipment that works with one vendor's ISDN
switch work properly when used with another vendor's switch?
[Ed. Note: The title is edited from the previous faq to try
to fit in
with the preceding question]
[Also, this seems to imply that there are only two implementations
to worry about and it is very US-centric. This section needs to be
reworked]
When the National ISDN-1 standard is implemented, there will be a single
standard for how TE communicates with the CO (the call setup dialogue).
Until that time, you may encounter two different varieties of CO
equipment,
each with its own call setup dialogue:
* ATT 5ESS
* Northern Telecom DMS100
Some ISDN TE equipment can be configured to communicate with either;
some works with only one variety.
Jim.Rees@umich.edu (Jim Rees)
jerry@watchman.sfc.sony.com (Jerry Scharf)
------------------------------
2.21) Do different manufacturers' Terminal Adaptors interoperate when
used asynchronously?
There is a standard up to 19.2k (V.110) but above that
there is no real
standard implemented. However, in practice there is a fair degree of
interoperability (even when the TA's manual tells you otherwise)
because many TAs use the same chip set (supplied by Siemens) which
happily goes up to 38.4. TAs from different suppliers that are using
the Siemens chips have a fair chance of interoperating at up to 38.4k.
wmartin@nsa.bt.co.uk (William Martin)
------------------------------
2.22) Why do I get only about 19.2k throughput from my TA?
The problems in using TA's are the same as those in using fast modems.
You only get the throughput that your serial port can handle. The
serial ports of many machines struggle to receive at 19.2k. Sending is
easier to implement efficiently. Many machines will happily send data
to a TA at 38.4, but choke down to around 19.2k or lower when receiving
(with lots of retries on ZMODEM file transfer).
wmartin@nsa.bt.co.uk (William Martin)
------------------------------
2.23) How long should call setup take when using a TA?
The "less than a second" call setup sometimes claimed seems to be rare.
TAs have a negotiation phase and it typically takes around 4 seconds
to get through to the remote site.
wmartin@nsa.bt.co.uk (William Martin)
--
Dave Cherkus ----- UniMaster, Inc. ----- Contract Software Development
Specialties: UNIX TCP/IP X OSF/1 AlphaAXP AIX RS/6000 Performance ISDN
Email: cherkus@UniMaster.COM Tel: (603) 888-8308 Fax: (603) 888-4598
Live Free or Die - New Hampshire has 3 seasons: ice, mud and black fly
Adam Hersh© 95
Comments can be sent to the
Webmaster these documents