From: etxorst@eos.ericsson.se (Torsten Lif)
Subject: Re: Network Connections over ISDN
Reply-To: etxorst@eos.ericsson.se
Organization: Ericsson Telecom AB
Date: Mon, 17 Aug 1992 09:25:19 GMT

In article 17079@ulysses.att.com, lgm@ulysses.att.com (L. G. McKnight) writes:
>There are enough misconceptions in this article to warrant a detailed
>reply:

Since the article Mr. McKnight quotes is mine I suppose I'd better
stand up for it a bit. At least the parts where he seems to have
misunderstood what I was talking about.

But first a bit from another article.

In article 1934@digibd.com, dror@digibd.com (Dror Kessler) writes:

>Are you reffering to D channel packet (X.25) or Q.931 user-to-user signalling?
>
>Using D channel X.25, I have seen close to 14000 bps of user data. 
>
>Q.931 user-to-user signalling is not intended to move large amounts of
>information. The main use would be signalling setup information user-to-user
>upon connection establishment. Trying to move data with this facility is
>asking for it.

That really says it all. I was referring to Q.931 user-to-user
signalling. It can be used during a call as well, using (for example)
INFO signals with the User-User-Info signal element. However, it's slow
and eats CO resources.

I wasn't even aware that there existed a "real" D-channel X-25 protocol
which goes to show that I've been away from all this too long.

I would like at this point to apologize for the confusion my mistake
has caused. Humbly.

[The beginning of Mr. McKnights article deleted here since it refers to
the capacity available over D-channel X-25]

>> The CO's primary function today is to transfer phone calls (audio). A
>>few subscribers have ISDN and get their calls routed direct into the
>>digital channels, others have analog lines and go through codecs at the
>>CO first. The CO normally assumes that the data on the channel is
>>PCM-coded audio and does not interfere with it except to translate
>>u-law<->A-law in the case of international calls.
>
>The CO's only function is to switch circuits.  For a digital switch
>it is immaterial whether the circuits are voice or data because
>all the circuits are treated as data.

Yes, but when the data stream stems from the codec of a POTS home
subscriber line, the CO can't tell the difference between a modem
transmitting digital info encoded as audio signals and a human making
funny whistles.

Hence, a switched circuit is established and the "squeaks" from the
subscriber line is sent through it in digitized form. If the call is to
Europe, the u-law audio is converted to A-law and (hopefully) correctly
D/A-converted in the codec at the other end.

>For ISDN lines the data is sent out on the
>line in the proper time slot without conversion.  Incoming data is
>taken from the relevant time slot and routed through the switch --
>to the proper circuit or virtual circuit depending on the call --
>without converting the data.

True, unless the call is to a region that uses different encoding or is
only available through analog trunks.

An ISDN phone in Europe does not normally need to have u-law
capability. There's nothing saying it CAN'T have it either, but there's
little need for it. If a call is from the US, the A-law <-> u-law
conversion will be done at the international interface between the
CO:s, not in the subscriber equipment.

It is, of course, technically possible that the originating phone may
"lie" about its call request and specify "64 kb transparent" which
effectively prohibits the CO from converting any of the data. The
receiving phone will then have to recognize that this is in fact u-law
and switch operating mode of its codec. Possible but rather pointless.
The 64 kb transparent mode should not be used for phone calls unless
they're end-to-end encrypted or something similar.

When an ISDN TA establishes a datacomm link, it will normally be
assigned a circuit at the CO in exactly the same manner as a phone, but
this time the circuit is earmarked in such a way that no conversion
(corruption) of the digital data is introduced, even if the call is
international. A call to an analog-only region will of course not be
possible at all.

>>						The ISDN call
>>designators that identify the call type as "datacomm" are actually
>>primarily to prevent the CO from jumbling the data by converting it (or
>>passing it through an analog intermediate line).
>
>The messages between the switch and the CPE are to see what services are
>being requested and to check to see if the service is authorized i.e.
>paid for.  ISDN allows each user to request the the type of service that
>is desired.  The switch is responsible for obtaining the service, setting
>up the circuit (or the virtual circuit), transmitting the data and billing
>the user.

Yes, but don't forget that in the "normal" case of a phone call between
two subscribers, it's the CO's responsibility to make sure the two of
them can REALLY talk by converting the data stream formats in such a
way that an end-to-end speech link is established, while in the case of
datacomm the 64 kb link should be totally transparent. This is new in
ISDN compared to POTS where there is (from the CO's perspective) no
difference between a TrailBlazer and a 300 baud acoustic coupler.

>>					In a future scenario
>>where datacomm is a larger part of the CO's business than it is today
>>(remember: modems create audio sound streams, so today ALL non-ISDN
>>calls are "audio") it may become interesting for them to provide more
>>and better datacomm functionality.
>
>As I said above, almost all calls in the U.S. are transmitted digitally
>and there is lots of data on the network at speeds between 2.4kbits/sec
>and 44 Mbits/sec.  Not to mention modem based voice band data (VBD).

It doesn't matter that it's transmitted digitally when it comes from an
analog line with 3.5 kHz max bandwidth. The CO treats phone calls and
datalinks the same when they come from analog subscriber loops. Or,
given the stuff about echo cancelling below, maybe I should say: Here
in Europe they do.

>Data on the network differs from voice in that it is not routed through
>echo cancelers.  Otherwise it's all just data.  Data (which does not have
>to go through echo cancelers) should not cost more to transmit than voice
>(which does).  Packet switched networks don't have echo cancelers.


>>The D-channel<->B-channel multiplexing as described is entirely within
>>the reach of today's technology but I don't know that it's been
>>implemented in the CO as such.
>
>A call can be set up to route data to a packet switched network by any
>number of routes.   Currently our CO switch routes D-channel data to
>the packet handler section of the switch.  Higher data rates are
>more economically sent as circuit switched data so our switch does
>not have a link from the B-channel to the packet switched network.

So what you're saying is that you do not currently automatically route
several D-channel connections through one B-channel. I believe that's
what I said too...

>>		The easy way is to hook up an external
>>computer (say, a Sun SS10 with the ISDN chipset) and let it do the
>>routing. Having the CO do it sounds extravagant to me.
>
>The CO has to do the routing for every call through the telephone
>network.  The cost is not "extravagant" -- after all the switch
>does the routing for voice calls all the time.  The decision
>as to whether a call should be circuit switched or packet switched
>is up to the user.

It seems I used the word "routing" in an ambiguous way. Let me outline
a scenario.

If you're at a site with an ISDN PABX (so that internal calls of all
types are "free") and want to make a D-channel connection to another
user at a similar site (but only available through the public phone
network) you have two choices. You can either establish a D-channel
connection "direct" and use that. If another pair of users at your site
do the same they grab (and pay for) another similar circuit.  Or you
can connect to a router at your site which connects to another router
at the other site which in turn connects to the other user. Now, if
that other pair of users at the same two sites want to do the same, the
router can have enough "intelligence" to decide when it becomes more
economical to establish a B-channel connection to the other router and
multiplex the 16 kb links on that instead of paying for separate
D-channel calls.

Obviously, in the US a similar scenario could be conceived for
long-distance data "calls", with local D-channel calls being routed
through a long-distance B-channel carrier and then on to another local
D-channel. I don't know if this would be financially viable but it's
certainly possible.

>>Then vjs@rhyolite.wpd.sgi.com (Vernon Schryver) says:
>>
>>>How much will that cost?  Will it be billed by the packet?  At rates
>>>as outrageous as D-channel?
>>
>>The D-channel rates may seem outrageous to you but I assure you they
>>are motivated by the exceptionally high costs D-channel connections
>>cause in the CO. If the charges seem steep then I suggest you look at
>>the alternatives, such as B-channel connections.
>
>The rates for telephone services in the U.S. are too complex to
>discuss here.  But certainly B-channel connections are not expensive --
>as every modem user knows.  Sending data over B-channels is no more
>expensive than sending VBD using a modem.  D-channel data should be cheaper
>for bursty data over long distances.  If D-channel data is not cheaper
>then data will be sent circuit switched over the B-channel.

I was thinking of the Q.931-type links as I said at the beginning.

>Lee McKnight
>AT&T Bell Laboratories
>Murray Hill, New Jersey, 07974
>lgm@ulysses.att.com

---
 Torsten Lif
 Ericsson Telecom AB, EO/ETX/TX/AD
 S-126 25  STOCKHOLM, SWEDEN
 Phone: +46 8 719 4881

Newsgroups: comp.dcom.isdn