From: deej@cbnewsf.cb.att.com (david.g.lewis)
Subject: Re: The ISDN network
Organization: AT&T
Date: Mon, 14 Dec 1992 14:31:28 GMT

In article <1992Dec11.013446.24560@atlastele.com> bcapps@atlastele.com (Brent Capps) writes:
>In a previous article Jim.Rees@umich.edu writes:
>>In a previous article bcapps@atlastele.com (Brent Capps) writes:
>>
>>> An ISDN set won't talk to an analog modem.  An engineer might call this a
>>> deployment issue WRT the modem, but the end user is going to see it as a 
>>> technical impediment.

Actually, this engineer would call it a backward-compatibility issue.

>>There isn't anything about ISDN that prevents you from using a modem with
>>it, although you have to provide your own analog conversion...
>
>I wasn't talking about the modem on your end, but the one on the other end.
>I never said you couldn't plug a modem into a TA on your end, but who in
>their right minds will want to shell out $$$ for the CPE and $$ monthly
>for the ISDN service once they realize they're still going to be dependent
>on an analog fax/modem to talk to 99.997% of the world?

To start with, the people who have a need to communicate with the .003% who
also have ISDN, and want the benefits of ISDN.

>So here's the situation.  I've got a modem plugged into a TA on my
>premises when a call comes in.  How do I determine whether the caller is
>analog or digital?  I can't listen for tones, because modem tone is
>supposed to be generated by the *receiving* party. 

A little thing called the Bearer capability information element.  Octet 3,
bits 5-1, coded 01000 indicates unrestricted digital information; coded
10000 indicates 3.1kHz audio (which is recommended for analog modems).  ISDN
- out of band signaling, remember?

>>Eventually someone will even offer a digital ISDN modem, which will be 
>>cheaper to manufacture than an analog modem.
>
>Great, what a technological leap forward that will be.  I'm so glad we
>spend billions developing and deploying ISDN so we could continue to
>communicate using modems to get our real work done.

Backward-compatibility, remember?  Like the people who spend billions
developing and deploying complex computer networks so they can emulate
punch-card readers to work with existing applications.  Like the people who
spend billions developing and deploying Windows so they can continue to use
Lotus 1-2-3.  Any time you deploy new technology, you have to be concerned
with maintaining compatibility with existing technology.  That doesn't mean
that the new technology is only a front end to the existing technology; it
means that you use the new technology where possible, and where not possible
you can interwork it with the old technology.

Remember, God was only able to create the world in six days because He
didn't have an embedded base...

(great, now someone's going to launch a flame at me for bringing religion
into the debate... ;-))

> If I have an ISDN box that automatically delivers fax or ASCII 
>messages it's going to have a hell of a time determining on a per-call basis
>whether to deliver a message via analog or digital form.

1. It could maintain a customer database with subscription information,
indicating whether the customer prefers G3Fax, G4Fax, text (and what
format), etc.

2. It could use a multiple-call method, first attempting a 64UDI call, and
if that is cleared by the network or the called customer, reattempting using
3.1kHz audio.

3. When bearer capability fallback becomes available, this could replace (2).

Furthermore, I submit that "knowing" whether to deliver, for example, a fax
or text message is unrelated to "knowing" whether to setup a 64kUDI or
3.1kHz audio call.  If I have automated calling equipment with a bank of
modems and faxmodems, and I have to deliver a message to customer Y, I have
the same problem - use a modem to send text, or use a faxmodem to send a
fax?  This is a layer 7 issue, not a layer 3 issue.

David G Lewis                              AT&T Bell Laboratories
david.g.lewis@att.com or !att!goofy!deej     Switching & ISDN Implementation
Newsgroups: comp.dcom.isdn