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: <<A HREF="http://www.shore.net/~dreaming/ascend-faq">http://www.shore.net/~dreaming/ascend-faq</A>> or <<A HREF="ftp://ftp.shore.net/members/dreaming/ascend-faq.txt">ftp://ftp.shore.net/members/dreaming/ascend-faq.txt</A>> </PRE> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <!--X-Follow-Ups-End--> <!--X-References--> <!--X-References-End--> <!--X-BotPNI--> <HR> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00108.html">Re: (ASCEND) 48 modem limit on Max with 56k cards</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00107.html">Re: (ASCEND) MAX4000 Trumpet Winsock</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00106.html">(ASCEND) Voice vs. Data usage on a P75.</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00128.html">RE: (ASCEND) SNMP polling of interface statistics for Max 1800</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="mail9.html#00110"><STRONG>Main</STRONG></A></LI> <LI><A HREF="thrd6.html#00110"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> </BODY> </HTML>