Subject: 5. How should a BRI be provisioned for a Pipeline 50?

The other prevalent ISDN-capable switches in the U.S. are Northern Telecom DMS-100s; Nortel supports only NI-1 (at least until it's superseded by another standard).

With an NI-1 switch, the user must find out the Service Profile IDs (SPIDs) associated with the BRI, and enter them in the appropriate fields in the main "Configure..." menu. Since the local telephone company assigns the SPIDs, only it can inform you what they are (and they have been known to get them wrong).

With a BRI provisioned as AT&T custom Point-to-Point, the user merely needs to enter the telephone number associated with their line.

• 5a. What about AT&T Multipoint, and the AT&T "type sets" (A/B/C/D/E)?

  AT&T Multipoint should be used when you wish to have multiple devices connected to your BRI. Each device then needs to be assigned at least one SPID and directory number, so you lose the simple configuration of P-t-P.

  Steve Lemke notes:
  

  	 > I have a multipoint BRI line on an AT&T 5ESS switch.  I clearly
  	 > didn't need multipoint when all I had was the P50, but now that I
  	 > have a 7845, I'm glad I set it up that way.  I've assigned one
  	 > directory number and SPID to the 7845, for the POTS interface
  	 > (which is now my fax line), and I've entered the other directory
  	 > number and SPID into *BOTH* fields of the P50's "Configure..."
  	 > screen. 
  	 > It would appear that the P50 really only needs one directory
  	 > number (and a SPID in the case of multipoint) to be happy.
       

  Fred R. Goldstein explained the AT&T type sets (specified in telco provisioning) in comp.dcom.isdn:

  > The five Terminal Types are an AT&T invention, part of the AT&T
  > Custom feature set.  Types A-D correspond to telephone types,
  > E to pure data. In practice E is rarely used.
  >
  > A = HCDT, FCO
  > B = HCDT, FCO, TM
  > C = HCDT, FCO, KEY
  > D = HCDT, FCO, TM, KEY
  > E = Data only
  >
  > HCDT is "hold, conference, drop, transfer" (mainly voice features)
  > FCO is "flexible call offering" (make/take calls with others on hold)
  > TM is Terminal Management (light the lights on the feature phone)
  > KEY is Key System emulation (multiple DNs, shared DNs, etc.)
  >
  > So if you have D, you have all of C plus some TM features that
  > your gear may or may not tolerate (usually will).  You need C
  > for the "extended" features because that basically emulates a
  > key telephone set in order to jockey the calls.
  >
  > The trick to AT&T Custom is that you have to think like a phone;
  > if you can figure that out, it's extremely powerful.  But its
  > Centrex heritage is obvious.
           

• 5b. Should my BRI channels be provisioned as CSV, CSD, or PSD? What about DOSBS/V.110? And what the heck does that all mean?

  If you're going to use your BRI for both voice and data (using an ISDN phone or NT1 that supports analog phones), then you'll need to have it provisioned by your phone company to support circuit-switched voice (CSV+D) on at least one bearer channel. It can be set up that way on both B channels, but some RBOCs do not permit both channels to be CSV+D, requiring at one to be circuit-switched data (CSD) only.

  Packet-switched data (PSD) provisioning implies that your BRI will be connecting to a packet-switched network, like X.25. [I know of no one who actually does this with a Pipeline 50; if you're out there, drop me a line!]

  Using V.110 (aka DOSBS, Data Over Speech Bearer Service) means your ISDN device does a call SETUP as if it were an analog/voice call traversing the public telephone network. The advantage to this is that residential customers can make local calls at a flat rate, something that many RBOCs do not support for ISDN (wretched tarrifs). Ascend supports this: set "Data Svc=Voice" in your connection profile (Telco options).

  There are a few downsides to using DOSBS: data rate is generally restricted to 56Kbps, and on long-distance calls, you might not get through because of the rare non-digital trunk (but then, DOSBS is really only useful for local calls anyway). Locally, there may be special encoding on the line geared towards voice traffic (echo cancellation, for example), which will cause a digital call to fail. Some ISDN T.A.s which support V.110/DOSBS try to emulate a modem signal for the first few seconds of the call, to cause the telco switch not to use any special processing routines; as far as I know, Ascend does not.