Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(ASCEND) Want 2nd number on a MAX to answer with Force 56k

We have a MAX-HP that's behind a NT Meridian PBX.
I'm seeking a setup on the MAX to work-around a PBX problem.

There are two problems that I'm pretty much convinced, after many hours
of investigation, are the fault of PBX software:

 1) When a DID call comes in to the PBX from the CO, with 64k unrestricted,
    and a User Rate Adaption of 56k, the PBX strips off the User Rate
    (essentially removes octet 5) when the call is presented to
    the MAX. My NT contact has verified that their code is written
    to do this. He (now) also agrees that this is a legit call setup
    we are getting from GTE on the PRI (more background on this below,
    please take a look before you tell me it's not).

 2) If I turn on a PBX feature called ISDN BRI Interworking, on the
    PRI trunks to the CO, this fixes problem #1 above. The PBX
    then passes the entire call setup unmolested to the MAX. BUT;
    once Interworking is on, then BRI extensions on the PBX
    (assorted Pipeline and Proshare) cannot make outgoing calls
    on the CO PRI trunks. Both 56 & 64k BRI originated calls
    fail with Cause Code 28. Needless to say, we have to leave
    Interworking off for now. (This problem may be unique to NT
    Rls 19 software, we couldn't duplicate it on Rls 21 system.)

I've had a trouble ticket open with NT ETAS since November of last year,
with little movement on their part, apart from the traditional "you need
to try the latest issue of Rls 19 [but WE won't bother to check the list
of problems & fixes to see if this will actually do you any good]"
delaying tactic. It (19.60) didn't do us any good.
This should not surprise anybody who's dealt with NT before...

Anyhow, the current work-around situation is:
We have to support units that are calling from locations that do not
support 64k calls.
To that end, I've set the MAX Ethernet/Answer/Force56=Yes.
This forces it to apply 56k rate adaption to all incoming calls, even
those stripped of the User Rate info. Obviously, this also means NONE
of the users can connect at 64k, even when facilities are available.
All are forced to run at the 56k rate. Needless to say, some of the
users are not impressed by this performance.

My idea of an IDEAL work-around, would be to configure the MAX to answer
two phone numbers; one number that treats incoming calls as if
Ethernet/Answer/Force 56=No, and a second number that treats calls 
as if Ethernet/Answer/Force 56=Yes.
This would allow us to accommodate both 64k & 56k calls respectively,
with only a minor bit of klunkyness.

Unfortunately I see no way to implement the above idea in the MAX software,
currently version 4.5Ci11 (and please don't ask my why we are running
that version; it's a long story and out of my hands).
I've taken a look at every Release Note that is still available on the
FTP site between that and up to 5.0A, and found no new feature description
that sounds like it does anything close to what I want.
It is entirely possible that I would miss such a thing, given the volume
of stuff I've skimmed, plus those which are no longer available.

As there is no telling if NT will EVER fix the PBX problems,
does anybody know if it IS possible to do such a thing on the MAX?



Some optional boring background info:

Initially, the NT guy tried to tell me, or at least suggest, that a call
setup with a Bearer Rate of 64k unrestricted, with a User Rate Aadaption
of 56k, was not valid. He now agreeing that it IS a valid call setup.
(BTW, the PBX code DOES pass the 56k user rate if the call initially
comes into the PBX from the CO as a 64k RESTRICTED call. The vast 
majority, or perhapps all, of 56k calls come in as UNrestricted.)

I had the local GTE ISDN guru investigate the calls we were getting long
before we called NT, and he insists they are proper and OK.

I recently asked the instructor of a ISDN course I took what he thought
of this. He too initially said he didn't think that it was valid, but
did some digging and changed his mind. What he found was:
Bellcore "Generic Guidelines for ISDN Terminal Equipment on Basic Access
Interfaces, Special Report SR-NWT-001953 , Issue 1 June 1991", section
5.2.5.2 "Bearer Capability" p5-56, which lists "64KBPS, Unrestricted
Digital, User Rate 56k, Octets 6 & 7 not present" as a valid call type.
Bingo.

After some digging in the NT Practices, I came up with:
 NTP 553-3901-101 Standard 4.0 December 1994,
  ISDN Basic Rate Interface Product description,
   ISDN BRI circuit-switched data calls,
   p111, ISDN BRI accessing ISDN PRI,
   "The ISDN PRI interface supports three bearer capability encodings:"
    the third listed of which is:
     " 56k: Octet 3=restricted or unrestricted digital information,
       octet 4=64kbits/s, octet 5=v.110 and octet 5a=56kbits/s. "

...Which EXACTLY describes the (unrestricted 56k) call setups GTE is
giving us, octet for octet. This didn't phase the NT guy, as he then
suggested the NTP might simply be incorrect. (This indeed does happen,
but funny how when the NTP proves them right, it's right, where if it
proves you right, it's wrong. Go figure...) He's checking on that.

The NTP goes on to state that "ISDN BRI devices using OTHER bearer
capability encodings can communicate with another ISDN BRI device across
ISDN PRI under these conditions:" which essentially amount to turning on
ISDN BRI interworking feature on the PRI interfaces involved. The
implication here is that the BRI Interworking feature should NOT be
necessary to pass the User Rate on the calls as we are getting them.

As I've mentioned, turning it on fixes problem #1, but creates problem
#2. The NT guy has tried to tell me we shouldn't be using BRI Interworking,
because it "causes you other problems", but wouldn't get specific. Well,
looks like he's right about that, but my dumb idea is; if it has problems,
they oughta be fixing them. Silly me. We did have BRI Interworking turned
on for almost a year before we put in BRI extensions on the PBX. We then
found out it was killing outgoing calls from the BRI's, so it had to be
turned off. That was the last time we enjoyed a working mix of 64 & 56k
calls to the MAX.

O.K., enough already.
If nobody knows of a work-around, maybe this rambling will help 
somebody else.


++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd:	<http://www.shore.net/~dreaming/ascend-faq>
or		<ftp://ftp.shore.net/members/dreaming/ascend-faq.txt>