From: deej@cbnewsf.cb.att.com (david.g.lewis)
Subject: Re: TCP/IP over ISDN
Organization: AT&T
Date: Thu, 10 Sep 1992 14:38:36 GMT

In article <1992Sep10.040648.20853@dumbcat.sf.ca.us> marc@ascend.com writes:
>In article <1992Sep8.183030.330@gandalf.ca> djarrett@gandalf.ca (Dave Jarrett) writes:
> > Don't get hung up on this user-user information thing. All we require 
> > to do a poll, is 1 available bit, anywhere in the connect packet, which
> > will tell the receiving node that this connect request is really a poll.
> > Surely even ITR6 has 1 available bit which can be used for this purpose?
>
>Hmmmm,  I'm looking at the AT&T PRI spec (TR 41449/TR 41459) and the only
>Information Elements that are mandatory are:
>
>	Bearer Capability
>	Channel Identification
>	Called party number

Protocol Discriminator, Message Type, and Call Reference are also mandatory.

>Experience tells me that the Bearer Capability for an incoming call often
>bears no relation to the one in the originators setup message.

I feel I must take some exception to this...

First, TR 41459 specifies the AT&T network ISDN PRI - the protocol that you
use when you purchase a PRI from AT&T Communications Services, or whatever
we're calling ourselves these days.

If the call both originates and terminates on AT&T network PRIs, the BCs
should be very closely related.  In fact, they should be identical.

IF the call originates or terminates on another network, BRI or PRI, the
situation may be different.  If it's a voice call, an Information Transfer
Capability of "speech" may be mapped to "3.1kHz audio", or vice-versa; as I
recall, Bellcore TRs treat them pretty much interchangeably.

If it's a data call, and it interworks with CSDC access ("switched 56"),
things may be a little more complicated.  For example, a call may be
originated from an AT&T PRI, destined for an Accunet Switched Digital
Service customer served by a LEC BRI, with access to Accunet SDS through a
digital switched access arrangement using 56kb/s CSDC trunks.  In this case,
the BC at the originating PRI must be coded 64kb/s circuit mode, with octet
5 of the BC indicating a user information layer 1 protocol of V.110 rate
adaption to 56kb/s.  Because this detailed information can not be
transferred across the CSDC (in-band signaled) trunks, the LEC switch may
not code the BC in the SETUP message to the BRI in this way.  Similarly, if a
call is delivered to the AT&T network over CSDC trunks for delivery to a
PRI, the Information Transfer Rate field of the BC IE will be coded 64kb/s.
Octet 5 should show rate adaption to 56kb/s.  The access BRI may not require
the rate adaption to be explicitly coded.

>The "mandatory" called party number isn't in setups that come from a Definity
>Generic I PBX.

Over a PRI it certainly is.  If a SETUP message is sent by a PBX to the AT&T
network and does not include a Called Party Number IE, the call attempt will
be cleared.  On the terminal side of the Definity, the terminal may receive
information via Keypad IEs.

>Ok, on to BRI and the 5ESS specifically (I'm not picking on AT&T, it's just
>that I happen to have their manuals at home).  Only the Bearer capability is
>required.

Called Party Number is not mandatory over BRI because BRI may use Keypad IEs
with overlap signaling procedures.  Channel ID, I'm guessing, may not be
mandatory if the switch chooses the channel and returns the selected channel
in the first Call Proceeding or Setup Ack message.

>Maybe in the future when the world is SS7 you'll be able to trust the bearer
>cap IE. 
> Until that time
>* as your call goes from switch to switch it can (and will) be munged
>* it sometimes lies.  I've received calls with a 64K Bearer Cap IE that I
>  *know* went over at least one line/network that only had 56K capabilities.
>
>Now where is that bit?

Again, to get back to the original thread, certain IEs are designated as
usable for user to user information transfer.  These include UUI, High Layer
Compatibility, Low Layer Compatibility, subaddress IEs, and Codeset 7 IEs.
If you attempt to use anything else to transfer user to user information,
there is no guarantee, explicit or implied, that it will be delivered the
way you want it - or that it will be delivered at all.


Disclaimer: Anyplace I say "may" I'm hypothesizing based on
generally-available information.  Anyplace I say "does" or "will" or "must"
I'm pulling info from TR 41459 - you could look it up...


David G Lewis                              AT&T Bell Laboratories
david.g.lewis@att.com or !att!houxa!deej     Switching & ISDN Implementation